Ticket Workspace Design

The ticket workspace - design (PR #206)

Status: proposal - nothing here is built yet. This page sets out how the ticket workspace proposed in pull request #206 should fit into FreeITSM, so the shape is agreed before the code is finished. Comments on the PR are welcome. The open decisions are in section 8.

The proposal, from PR #206 (by @Dr4inder):

"Working through a ticket can mean moving between its conversation, properties and a separate task window. This proposes an optional Workspace layout that keeps those activities together."

In plain words

A ticket today is one long reading pane: the conversation, with the properties in a toolbar above it, and linked tasks opening in their own window. The workspace lays the same ticket out for working rather than reading: its properties in a column, and its conversation, its work (linked tasks, opened in place), its links, its time and SLA, and its history on tabs beside them.

Not every team wants that, and not every ticket needs it. A password reset is quicker in the reading pane; a server move with six linked tasks is easier in a workspace. So:

1. An administrator decides whether the workspace is used at all, and if so whether every ticket can be a workspace or only the ones somebody turns into a workspace.
2. Each analyst decides for themselves whether to use it, within what the administrator allows.
3. Nothing changes on upgrade. The workspace is off until an administrator turns it on.

The PR also contains two other features - editing a linked task inside the ticket, and a paginated ticket table with a CSV export. Both are good ideas, and both are separate pieces of work, so they come after the workspace as their own pull requests (section 6).

---

1. Where it fits

The workspace is another way to draw the reading pane - not a new ticket page, and not a new place where ticket data is written.

• One renderer. The ticket's controls - status, priority, owner, the toolbar actions, the custom fields - are the existing ones, with the existing handlers and the existing server checks. The workspace arranges them; it never duplicates them, and it never writes anything the reading pane does not already write.
• The folder list and the message list do not change. Choosing a ticket opens it in the reading pane or the workspace; everything to the left of it behaves as it does today.
• The Messages / Inbox list choice stays independent of the workspace, as the PR already has it.

---

2. What an administrator chooses

Tickets → Settings → General → Ticket workspace (ticket_workspace_mode), a dropdown:

Choice	What happens
Off (the default)	No workspace anywhere. The preference below is hidden, and so is Make workspace. Exactly as FreeITSM is today
Only tickets turned into a workspace	A ticket opens as a workspace only once somebody has turned it into one. Every other ticket opens in the reading pane
Every ticket	Every ticket can open as a workspace

Changing the setting changes nothing stored: a ticket turned into a workspace keeps that, so switching from Only tickets turned into a workspace to Off and back restores the same tickets.

---

3. What each analyst chooses

Tickets → (the list's view menu) and System → Preferences → Tickets → Use the ticket workspace, an on/off switch (ticket_workspace), on by default. Shown only when the workspace is not Off.

Install setting	Analyst's switch on	Analyst's switch off
Off	Reading pane	Reading pane
Only tickets turned into a workspace	Workspace for those tickets, reading pane for the rest	Reading pane for every ticket; a turned-into-a-workspace ticket shows a small Workspace badge, so they know a colleague is working it that way
Every ticket	Workspace	Reading pane

The switch is personal: one analyst's choice never changes what another sees. It is part of the analyst's preferences, so a preference template (Preferences - Developer Guide) can set it for new analysts.

---

4. Turning a ticket into a workspace

Only when the install setting is Only tickets turned into a workspace:

• More → Make workspace on a ticket, and More → Back to the reading pane on one that is already a workspace.
• It is a property of the ticket, not of the analyst - stored as tickets.is_workspace (TINYINT NOT NULL DEFAULT 0) - so everyone who opens the ticket, with their switch on, gets the same layout. That is the point of making a ticket into a workspace: the people working it see it the same way.
• Who may do it: anyone who may change the ticket. It is written through TicketsService::updateTicket(), so it is checked and audited like any other change (Workspace: on / off), and over the REST API it is a workspace boolean on the ticket.
• It does not fire a workflow event: it changes how the ticket is shown, not anything about the work.

---

5. Inside the workspace

The layout the PR proposes, with the existing controls:

Area	Contains
Header	The ticket number, subject, requester and the toolbar - Reply, Forward, Add note, Schedule, Checklist, Ask AI, More, Link to... - exactly as the reading pane has them
Properties column	Department, type, status, priority, sensitivity, owner, origin and the custom fields, grouped as Request and classification, Responsibility and Other properties
Conversation	The message thread, with every existing option (collapsing, quoting, split)
Work	The ticket's linked tasks. In the first version each opens in the task window, as today. Editing a task in place is the second pull request
Links	Linked equipment, CIs, problems, changes, projects and documents
Time and SLA	Time entries and the SLA clocks
History	The audit trail, loaded when the tab is opened

On a phone the properties fold into a section under the conversation, as in the PR's narrow-layout screenshot, following the mobile techniques.

Unsaved work is protected as the PR does it: a reply draft, a pending save or a half-filled field is never lost by switching tab, ticket or layout.

---

6. Three pull requests, not one

Order	Pull request	Contains	Depends on
1	The workspace	Sections 2 to 5: the install setting, the personal switch, Make workspace, the layout, and its tests	-
2	Tasks inside the ticket	The Work tab opening a linked task's own editor in place, as the PR's second screenshot shows - checklists, forms, procedures, subtasks, comments - with Open separately	1
3	The ticket table	The paginated, server-side table list with saved views, and its CSV export	- (but easier to review after 1)

Each one is reviewed, merged and released on its own, so a problem in one never holds up the others. The second and third are already well thought through in the PR - especially the task bridge's checks on message origin and the server re-checking ticket and task access - and the design for them is mostly what the PR already does. Two things to settle for them:

• Tasks inside the ticket embeds the whole Tasks page in a frame. That works, but it means every change to the Tasks page also runs inside a ticket, so the PR should add a short section to the Tasks on tickets developer guide saying what the embedded page relies on.
• The ticket table's CSV export is a new way to take the whole filtered queue out of FreeITSM in one click. It should be a setting - Tickets → Settings → General → Who can export the ticket list (section 8, decision 2).

---

7. How the code should be shaped

Taken from the Contributing guide, with the points that matter most for this change:

• Based on current main. The PR was branched from 3.14.0; main is now past 4.0.0, and four files conflict, tickets/index.php among them.
• One feature per pull request (section 6).
• No new SQL by text replacement. The PR adds the table's columns by str_replace() on the inbox query. The next change to that query would make the replacement silently match nothing. The shared query should take the extra columns as a parameter instead - the move of the inbox query into includes/ticket_list.php is otherwise a good one.
• One renderer, chosen when it renders. Moving the reading pane's controls after they are drawn ties the workspace to the reading pane's markup, so a later change to inbox.js could break the workspace without anything noticing. The render function should draw the controls into whichever layout is in use, and the Inbox.js developer guide should say how to add a control so it appears in both.
• House style: match the file you are in, keep the comments that explain why, and add a TRAP: comment where the obvious change would be wrong. New strings go in lang/en only.
• Upgrades invisible: the install setting defaults to Off, and the new column is added by Database Verification and guarded until it exists.
• Tests: the PR's tests are a strength - keep them, add the three install settings and the personal switch to them, and give each a positive control.

---

8. Open decisions

#	Decision	My recommendation
1	The personal switch's default when an administrator turns the workspace on	On. An administrator who turns it on for every ticket expects people to see it; anyone who prefers the reading pane turns it off once.
2	Who can export the ticket list as CSV (the third pull request)	A setting: Administrators only (the default), Anyone with Tickets, or Nobody. It is a bulk export of ticket data, so it starts narrow.
3	Whether Make workspace is offered in Every ticket mode	No. In that mode every ticket already is one, so a per-ticket switch would only confuse. The stored flag is kept for if the mode changes back.
4	Whether an analyst with the switch off sees the Workspace badge	Yes, so they know a colleague works that ticket in the workspace - without it changing their own layout.

---

Related pages

• Tickets · Inbox.js developer guide · Tickets settings - developer guide
• Tasks on tickets - developer guide · Preferences - developer guide
• Contributing · Mobile-friendly techniques