Model Analysis
Let’s analyze the fabric Model. It is composed of:
5 properties: unique_name, id_technician, id_employee, available, notes.
3 mutations: send_to_processing, send_to_confirmed, send_to_recalled.
4 states: open(default), processing, confirmed, recalled.
The required properties are id_technician and unique_name.
The mutation send_to_processing contains only one transition change to shift the model from the open state to the processing state. This mutation can be executed only by a user who is a member of the admin group.
The mutation send_to_confirmed contains a collection of 5 changes:
transition type: changes the model state from processing to confirmed.
dynamic type: the id_technician value will be updated with the one the user writes in the API request. The field must be valued in the request's body as it is marked as "required: 'true'".
dynamic type: the id_employee value will be updated with the one the user writes in the API request. The field may be valued in the request as it is marked as "required: 'false'" (i.e. optional field).
static type: the value of the field available will be updated automatically by the system with the predetermined value true.
one external mutation invokes the send_to_available mutation defined in the garment Model. This implies that a model outside the fabric Model, the model garment, will also change due to the send_to_confirmed mutation.
Note: The users authorized to call this mutation are the admin or controller group members.
The mutation send_to_recalled contains a collection of 3 changes:
transition type: changes the model state from confirmed to recalled.
dynamic type: the value of the notes will be updated with the one written by the user in the API request. The field must be valued in the request's body as it is marked as "required: 'true'".
static type: the value of the field available will be updated automatically by the system with the predetermined value true.
Last updated