Roos-fs-ZIP

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

Statuses

• Created
• Opened
• Booked
• Completed
• Cancelled → By customer / Internally
• Deleted (only possible from Created)

Transitions & Conditions

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
State Machine

• 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).

Task Management

• 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.

Price Validation

• 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”).

Cancellation

• Cancelling a service requires a documented reason.
• Cancelled services must cascade the cancellation reason to all in progress or opened tasks.

Reason Tracking

• When cancelled, user must select either:
  --By customer
  --Internally

Audit & Visibility

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