Work items
Purpose
Everything somebody works on is a work item — a task in a project just as much as a ticket from customer service. The two are not related objects but the same object in two flavours.
The gain shows exactly where systems usually fall apart: when an internal task turns into a customer matter, it changes flavour and keeps its history — comments, ownership, timeline, time entries. There is nothing to copy across and nothing that has to be maintained twice.
Scope
- Attributes shared by both flavours: status, priority, ownership, due date, start date,
visibility, timeline and comments.
- Statuses and priorities are master data, not fixed program code — renameable, extensible,
reorderable. A category maps every freely named status onto one of the meanings open, active, done, cancelled; all reporting hangs off that.
- Subtasks and dependencies, including one work item blocking another.
- Lists as the ordering device — global or per project, sortable by dragging or keyboard.
- Visibility per work item, so that internal matters do not reach outsiders by accident.
Interplay
Work items are the pivot for many modules: projects plan them, time tracking books against them, customer service runs them as tickets, and the automation engine reacts to their events. The personal view of them is My work, the complete one the task list.
Limits
- A work item is not a document. Quotes, invoices and delivery notes are their own objects with
their own rules, see commerce core.
- The flavour governs the interface. Tasks and tickets appear in separate surfaces even though
the same object sits behind them — deliberately, because the work differs.
- Ownership does not replace permissions. Being responsible does not by itself let anyone see
more; permissions decide.