Response To Issue 262

Response to #262 - a support provider's list of bugs and ideas

#262 is a thoughtful list from pappas81, who runs a small business giving remote support to other small businesses. That is a different shape from an internal IT department, and it shows up exactly the places where FreeITSM assumes one. Thank you - every item was checked against the code before deciding.

This page is the full answer: what each item turned out to be, which ones are going in (each with its own issue to follow), and the few that are not, with the reasons.

---

At a glance

#	Item	Verdict	Issue
1	Dragging a task on the board sends no notifications	✅ Bug, confirmed - fixed (write-up)	#266
2	Pages do not refresh when somebody else changes something	✅ Real gap	#267
3	Workflow "Add a note" only shows in the history	✅ Works as designed, but misleading - changing it	#268
4	Mail: mark as read and leave it in the folder	✅ Built	#269
5	Mail: copy sent mail to the Sent folder	✅ Going in (Basic IMAP)	#270
6	Checklists: the same step types on tickets as on tasks	✅ Going in	#271
7	Forms on tickets	✅ Going in	#272
8	Checklists in the API	✅ Going in	#273
9	Workflows for tasks (e.g. task done → note on its ticket)	✅ Going in	#274
10	API fields as workflow variables	✅ Built - works in every action now	#275
11	Watch / get involved from the right-click menu	✅ Tasks: built - tickets designed next	#276, #277
12	A customer / business entity	🔶 Yes, on Companies - not a separate record	#279
13	Calculated fields	🔶 Partly - the "set a field" action is built; live outside lookups no	#278
-	Found while answering: the duplicate-email check scans every email	✅ Fixed (write-up)	#280

---

The three bugs

1. Dragging a task sends no notifications - confirmed (#266)

Exactly as reported. Changing a task's status from its menu, the right-click menu or the detail panel goes through the task service, which tells the workflow engine - and the engine sends the bell notifications, emails and workflows. Dragging on the board saves through a different, older path that never tells the engine. So no notification, no workflow and no calendar update. The REST API's "move" had the same gap, and the API docs even called it deliberate. It is not: a task finished by dragging should behave like one finished any other way.

2. Nothing refreshes by itself - a real gap (#267)

It is not a PHP limitation - the bell already proves FreeITSM can poll. The ticket list does refresh every minute, but only when new mail or a new note arrives: a colleague changing a status, priority or assignee does not trigger it. An open email ticket never refreshes, and the tasks board has no refresh at all. The fix keeps the same simple polling (nothing new to install) and widens what counts as "something changed", without ever wiping a half-written reply.

3. "Add a note to the ticket" only lands in the history - by design, but changing (#268)

This one is working as it was built: the action writes to the ticket's history, and the documentation says so. But the name promises a note, and the issue-tracker sample makes it look like one - so it should write a real note (labelled System), with an option to keep today's behaviour so no existing workflow changes on upgrade.

---

What is going in

• Mail: mark as read and leave it (#269). The machinery already exists - FreeITSM can already mark mail read on every kind of mailbox, it just was not offered for imported mail. Two honest caveats go on the screen: mail somebody opens in Thunderbird before FreeITSM collects it is skipped (collection is by "unread"), and switching it on for a mailbox full of old unread mail imports that backlog. And on 15,000 messages: the folder size itself is not the problem - the server answers "which are unread" from its own index - but the duplicate check on FreeITSM's side was, which is #280.
• Mail: copy sent mail to the Sent folder (#270). Microsoft 365 and Gmail already do this; it is only missing for Basic IMAP. It will be off by default, per mailbox, because some mail servers already file sent mail themselves and you would get two copies.
• Checklists on tickets like checklists on tasks (#271). The difference is real and was deliberate when tickets got checklists first - the pass / fail / not applicable step came later, for tasks. Tickets will move onto the same checklist engine.
• Forms on tickets (#272). Agreed: a two-minute data-entry step should not need a task. Tickets get forms the way tasks have them, optionally required before closing.
• Checklists in the API (#273). Read endpoints first, after #271 so both sides return the same shape.
• Workflows for tasks (#274). The task triggers already exist (task created, status changed, completed and more). What stopped "task done → note on its ticket" was three things: the drag bug (#266), the note going to history (#268), and the task's ticket not being in the trigger's data - plus there are no actions that change a task yet. All four are covered.
• API fields as variables (#275). Mostly there already: {{ticket.requester.email}}, array indexes like {{steps.1.ticket_id}} and earlier steps' results all work. The whole API-shaped record ({{task.full}}) is only filled inside webhooks today; it will be available to every action, so {{task.full.ticket_id}} works anywhere.
• Involve me from the right-click menu (#276). Small, for tasks. Watching a ticket (#277) is bigger - tickets have no watcher idea at all yet - so it has its own design first.
• A "set a field" workflow action (#278) - see calculated fields below.

---

The customer / business entity - yes, but on Companies (#279)

The need is clear and reasonable: about 3,000 customer businesses, each identified by its tax ID (AFM), kept in step from an ERP or CRM that stays the source of truth.

What is not going in: a separate "customer" record beside Companies. In FreeITSM a Company is not just a label - it decides what each analyst may see. A second, lighter "customer" with its own idea of who belongs to whom would be a second definition of company, and two definitions that mostly agree is how one customer's data leaks into another's. The People roadmap explains this in more detail: Why not a separate Contacts module? The Manager structure is not the answer either - it describes people, not businesses.

What is going in: Companies grow what they were missing.

• an outside reference and a tax ID on each company;
• create and update companies through the API, with "create or update by outside reference" so an ERP sync is one call per customer;
• custom fields on companies (and people), on the same engine ticket fields already use;
• the person's outside reference visible and searchable through the API.

On the worries in the request: per-company ticket numbering is optional - the default numbering is one sequence for everybody, so 3,000 companies add nothing there. What does need checking is how the company screens behave with 3,000 entries, and that is part of the issue. Customers on Gmail addresses already work through the person's record; the issue includes checking that incoming mail always finds the company from the person, not the email domain.

Related: One company supporting another (#228) - built this week - lets a support company work tickets for the companies it supports, which fits this kind of business.

---

Calculated fields - partly (#278)

Three different ideas were in this request, with three answers:

• A field worked out from other fields - yes, as a workflow action. A Set a field action fills a custom field from text with {{placeholders}}, so a workflow on "ticket created" or "field changed" can work one value out from others. That covers most cases without inventing a formula language.
• A field filled from an ERP or CRM - already possible. The outside system pushes the value in through the REST API (custom_fields on tickets today, companies with #279). The ERP stays the source of truth, which is what the request asked for.
• Proper formula fields are already designed as the Calculated question in Financial approvals - design (#160), worked out on the server and frozen with the answer. They will come from there rather than a second design.

What is not going in: a field that calls an outside system live, while a record is being saved. Every save would wait on somebody else's server - slow or down means FreeITSM is slow or stuck - and a URL an administrator can point anywhere is a way to make FreeITSM request internal addresses it should never reach. FreeITSM's webhooks are a queue for exactly that reason. The same goes for a workflow action that calls an API and uses its answer in later steps: it is a reasonable idea, but it needs its own careful design (timeouts, retries, and refusing internal addresses), so it is not part of this round. Pushing data in through the API does the same job without the risk.

---

Thank you

Some of these will land in the next release and some later; each issue says what it involves. If anything here misunderstands what was meant, say so on #262 or on the issue itself.

Related

• People, customers and suppliers - roadmap
• Multi-tenancy concepts · One company supporting another
• Workflows · Checklists and SOPs · Forms on tasks
• Basic IMAP mailboxes