Catalogue Shop Design

Service catalogue as a shop - design (#348)

The request, the decisions taken, and how it is delivered in four slices. Slice 1 is PR #349, merged for 5.4.0 (review). Related: #160 financials (design), Catalogue request approvals, Catalogue group approvals - design.

---

The request

#348 (vsc55) asked for a catalogue item - a mouse, a monitor, a software licence - to be picked the way it would be in a shop: the person sees its picture, a one-line description and its price, requests it, their manager approves it, and once approved a ticket goes straight to the team (or analyst) responsible for that item. A rejected request is closed and the requester told, with the manager's comment.

Most of the machinery was there already (#220, approval before a ticket, Your requests, approve raising the ticket). What was missing: the shop card, the manager as approver, and whom the ticket goes to.

The shape

The item - a Catalogue tab in the form editor, with the card drawn beside it as the portal will show it, saved by the form's own Save:

• Short description (one line, on the card; the long description stays on the item's page).
• Price - optional, in an install currency (System -> Currencies), one-off or per month. Blank shows no price, so items without a cost are unchanged.
• Card picture - an upload; no picture shows the icon as before.
• The price is kept with each request as it was when requested; changing it later never rewrites past requests.
• An item may ask no questions - requesting it is the whole request.

The requester - Your requests on the portal lists every catalogue request: awaiting approval, approved (with its ticket), declined, sent (no approval) and cancelled.

Approval by the requester's manager - a third choice beside a named analyst and a team; the manager is read from the person's Manager field when the request is made and kept with it; no manager, a manager who has left, or the requester being their own manager sends it to the item's fallback approver (analyst or team) - without one, the item cannot be set to manager approval. The service desk can still see, move and override these approvals (Forms -> Approvals).

Approved - the ticket goes to the item's Responsible: a team, an analyst or both, optionally a ticket type. With none set, it is raised as before. A ticket is raised only when a request is approved.

Decisions

Put to Ed on 15 November 2026; his answers are what is built.

Question	Decision	Why
Accept the design and its four slices?	Yes - all four slices	The card, the manager as approver, the responsible team and the cost centre each stand alone as a PR, and slice 1 is useful without the rest
Where does the manager approve?	In the portal, plus an email with a link (vsc55's suggestion)	Managers are often not analysts; a To approve list on the portal they already use, with the email as the nudge
The requester's cost centre - now, or with #160?	Now, as slice 4	Small and useful already: the approver and the ticket see whose budget it is. Reporting and charging stay with #160
When may a requester cancel, and is the approver told?	Only while the request is awaiting approval. The approver is told - a catalogue_request.cancelled workflow event, with the reason, beside submitted / approved / rejected	Old sent requests (no approval, no ticket - often handled long ago by email or a webhook) would otherwise carry a Cancel link for ever. They are still listed. Once approved there is a ticket, and the ticket is where to say so. A workflow event lets an install email the approver without a new notification type

A cancelled request is kept as cancelled with its reason, never deleted, and leaves the approvers' inbox.

Slices (one PR each)

Slice	What	Status
1	The shop card: short description, price and picture; items with no questions; the price kept on the request; Your requests listing every request; cancelling a pending request with a reason	PR #349 - merged (5.4.0), with the two changes above - review
2	The manager as approver: approving in the portal (and by email link), the fallback, the rejection notice	To come
3	The item's responsible team / analyst (and ticket type) for the ticket an approval raises	To come
4	The requester's cost centre kept with the request, shown to the approver and in the ticket	To come

Not in this

Approval chains (manager, then cost-centre owner, then the board above an amount), quantities with a total, and stock - each fits #160's later stages, and this design leaves room for them.