roos-fs tasks #123
Updated by Vadim Pariev 11 months ago
**User story** As a system user (e.g. administrator or staff member), I want the service object to follow a clearly defined state machine, So that each stage of the service (from creation to completion or cancellation) follows business logic, validation rules, and restrictions. **State Machine Flow & Requirements** <u>Statuses</u> - Created - Opened - Booked - Completed - Cancelled → By customer / Internally - Deleted (only possible from Created) <u>Transitions & Conditions</u> SERVICE → Created Initial state. No restrictions on field editing. Created → Opened At least one task must be created to be able to change to this state. Triggered actively by a button in the service overview. No restriction on field editing. Opened → Booked Triggered actively by a button in the service overview. Employee can add tasks, but cannot edit service fields, except for additional costs. Booked → Completed Triggered actively by a button in the service overview. Must validate that all tasks are in a completed state. Price field must be filled (mandatory) before this transition. Created → Deleted simple hard delete allowed from created state only _____________________________________________________________ Any active state (Created, Opened, Booked) → Cancelled Service may be cancelled at any time, and the reason (internally or by customer) with the comment needs to be provided. All tasks that are still in progress or opened must also be cancelled with the same reason. **Acceptance Criteria** <u>State Machine</u> - Each transition only allowed as described. - Transitions must be user-triggered (e.g., via buttons). - Field Editability --In Created and Opened, all service fields are editable. --In Booked, only the additional cost field is editable (for Employee). <u>Task Management</u> - At least one task must be created before moving out of Created. - In Booked, new tasks can be added, but not edited. - Completion of the service requires all tasks to be completed. <u>Price Validation</u> - Completing a service (Booked → Completed) is only allowed if the price field is filled. - Error messages must be clear when validations fail (“Price field is required”). <u>Cancellation</u> - Cancelling a service requires a documented reason. - Cancelled services must cascade the cancellation reason to all in progress or opened tasks. <u>Reason Tracking</u> - When cancelled, user must select either: --By customer --Internally <u>Audit & Visibility</u> All state changes must be logged with timestamp, triggering user, and reason (if applicable). *In case questions appear, please go to redmine documents and find the latest version of the diagram*