As a Super Admin, I want the system to manage package lifecycle transitions so that only valid and approved packages are available to customers while preserving historical package information.

---

Business Background¶

The backend is responsible for enforcing lifecycle rules. A package should only move between statuses when business conditions are satisfied. This ensures catalogue integrity, prevents incomplete packages from becoming customer-facing, and supports future reporting and auditing.

---

Functional Behaviour¶

The system shall:

• Validate user permission.
• Retrieve current package status.
• Verify business validation before publishing.
• Process lifecycle transition.
• Update package status.
• Record audit history.
• Refresh customer catalogue visibility.

---

Lifecycle Business Rules¶

Publish¶

The package can only be published when:

• Mandatory information is complete.
• Package validation is successful.
• Package is currently Draft or Unpublished.
• User has Publish permission.

---

Unpublish¶

The package:

• Remains stored.
• Is removed from customer-facing catalogue.
• Continues to accept administrative updates.

---

Archive¶

The package:

• Is excluded from active catalogue.
• Retains all historical information.
• Cannot receive new customer enquiries.

---

State Transition Matrix¶

Current Status	Action	Result
Draft	Publish	Published
Draft	Archive	Archived
Published	Unpublish	Unpublished
Published	Archive	Archived
Unpublished	Publish	Published
Unpublished	Archive	Archived

Any other transition shall be rejected.

---

Database Entity Changes¶

Package¶

Updated fields:

• Status
• Published Date (when applicable)
• Published By (when applicable)
• Last Updated Date
• Last Updated By

No new package record is created.

---

Validation Rules¶

• Package exists.
• Package status is valid.
• User has required permission.
• Mandatory package information is complete.
• Package is eligible for requested transition.

---

Business Logic¶

• Lifecycle transitions follow the approved state matrix.
• Published packages become available to customer-facing modules.
• Unpublished and Archived packages are excluded from search and enquiry flows.
• Existing customer enquiries remain linked to the package.
• Every lifecycle transition is auditable.

---

Audit Requirements¶

Record:

• Previous Status
• New Status
• Changed By
• Changed Date
• Lifecycle Action
• Optional administrative remarks (if captured)

---

Permission Matrix¶

Role	Publish	Unpublish	Archive
Super Admin	Allowed
Admin	Configurable
Supplier	Not Allowed
Partner	Not Allowed
Customer	Not Allowed

---

Customer Impact¶

Action	Website	Quote Requests
Publish	Visible	Allowed
Unpublish	Hidden	Blocked for new requests
Archive	Hidden	Blocked for new requests

Existing quotations and bookings remain unaffected.

---

Acceptance Criteria¶

1. Only valid lifecycle transitions are processed.
2. Publish is blocked if validation fails.
3. Customer visibility updates after successful lifecycle changes.
4. Audit history records every transition.
5. Invalid status transitions are prevented.
6. Existing enquiries remain associated with the package.
7. Permission rules are enforced.

---

In Scope¶

• Lifecycle management
• Status transitions
• Business rule validation
• Customer visibility updates
• Audit history
• Permission validation

---

Out of Scope¶

• Package restoration
• Permanent deletion
• Package editing
• Pricing approval workflow
• Supplier workflow

---

Edge Cases¶

• Simultaneous publish requests.
• Package archived during validation.
• Package modified while publishing.
• Validation state changes before publish completes.
• Concurrent lifecycle actions by multiple administrators.

---

Definition of Done¶

• Lifecycle rules implemented.
• State transition matrix enforced.
• Audit history captured.
• Customer visibility updated correctly.
• Permission rules verified.
• Acceptance criteria passed.
• QA sign-off completed.
• Product Owner approval obtained.

---