Colleagues, thought about this problem: how to make a different order status at one time for different users?
The task can be as follows: a) the order is transmitted along a chain of users, where at every stage something happens to it. User P1 creates the Order, he receives the status A. Then sends it to the user P2, the Order changes the status to A1. User P2 performs an action on the application, the status changes to B1 and it moves further along the chain. For the previous P1 user, the status remains unchanged - A1. User P3 receives the application and sees it with the status B1.
b) the task can be simplified by throwing the transmission along the chain, leaving only the essence: at one point in time N users should see "their" status. Probably, it is even more correct to set the task, because the implementation of the chain can be considered as a separate task.
It is logical to assume that initially there should be a certain register of possible statuses:
table status N | key ----------------- 1 | draft 2 | new 3 | processing N | .... The second. It is necessary to determine the number of different users ("roles") for which there may be different statuses. Well, suppose there are three of them: Coward, Balbes and Experienced.
Here the paths diverge. It is necessary to determine in which logic the statuses work. If the development of events occurs linearly, you can write down a similar table:
N | key | Trus | Balbes | Byvaly | ----------------------------------------------------------- 1 | draft | Черновик | Черновик | Неизвестный | 2 | new | Новый | Черновик | Неизвестный | 3 | processing | Обработка | Обработка | Неизвестный | 4 | finish | Готово | Обработка | Неизвестный | N | .... | | | | Where each status should have a text designation for each role. Thus, each sees his own status name, depending on the role / user.
But it is not interesting. After all, events can flow nonlinearly. And here I am stalled. The only solution that comes to mind is to have its own order status matrix for each user role.
The situation is aggravated if it is assumed that someone from the users can see their orders and others. But in the logic of the order processing chain, this list may also contain “your own”, something must also be done with this “shizoy”.
Another consequence of this logic is how, say, to make a selection from the database of all new orders of all users, if each has its own set of statuses (and identifiers, respectively). No, you can do it ... but will this decision be beautiful?
In short, there were a lot of questions. It is interesting to hear those who have come across or have an idea how problems of this type are solved.
I supplement the question:
We are interested in non-linear order processing:
So.
1) There are users (P1, P2, P3), each user has a certain role. For simplicity, specifying a user with a buoy implies that they are all in different roles.
2) Imagine the life cycle of the application:
- P1 creates an application, it is sent to P2;
- П2 performs actions on it and thereby changes its status;
- P2 returns the application P1 or her P3;
(While the application from P1 is at P2 / P3, he sees one single status “at work”, while relations of P2 and P3 are regulated by their own statuses, but P1 should not soar)
Then the fork: - received an application (returned back) P1; - application received P3
The logic remains the same. The user conjures over the application and sends it back or forth along the chain. Those. There is no strict order processing sequence in the sense that it must pass from P1 to P3 “without turning off the path”. This plug can be repeated N times again between P1 and P2, and between P2 and P3.
In other words, the sequence of processing looks like a trace. in the following way:
P1 ← → P2 ← → P3
While I here see two registries of statuses:
- P2 and P3 (this is a classic case)
- for P1
and maybe for each role separately.
Why two status registries? Because the business logic for each user role can be different. P1 can work within, say, four statuses (new, processing, denied, confirmed), whereas in relations P2 and P3, the statuses can reflect a more detailed picture of the processes taking place.
But several registries will lead to crap in implementation. As a compromise, I see the ability to store the available statuses for each role based on a single registry. Those. we have a table with all possible statuses (above, Fig. 1), and we have a pivot table for each role with statuses only available to it (well, or to add columns to the order table is a secondary issue).
What we have in the end: the order must store its own status index for the user (ie, the role). But all the statuses, as I noted in the previous paragraph, will be from a single registry, thereby removing the crap in implementation.
Those. at the output we have something like this:
id | order_id | role1 | Role2 | role3 | ----------------------------------------------------------- 1 | 1 | 1 | 2 | 3 | 
