Work management
Availability:Timeora TimeFeature: projects
Timeora’s work model has a small number of building blocks. Once they are set up, tracking time and reading reports become mostly automatic.
| Building block | Purpose | Where it is maintained |
|---|---|---|
| Client | The organisation a project belongs to. | Project form and client reporting. |
| Project | The container for work that is billed or reported as a unit. | Projects |
| Activity | The type of work inside a project. | Activities |
| Task | A single unit of work with an owner and a status. | Work |
Projects
Section titled “Projects”A project groups time entries and usually belongs to a client. Reports, invoices and budgets are expressed per project.
Activities
Section titled “Activities”Activities describe what kind of work a time entry contains — development, design, a client meeting, internal administration. They are shared across projects so reports can compare like with like.
Keep the list short. A dozen meaningful activities produce useful reports; a hundred free-text variants do not.
Clients
Section titled “Clients”Clients appear in project reporting and in accounting. Track time without choosing a client and the project still works, but client reports will not attribute it.
The Work module adds tasks with an owner, a due date and a status. Tasks are separate from time entries: closing a task does not create a time entry, and tracking time does not close a task.
Tasks require the work feature and the work.tasks.* permissions, so they are available on Timeora One.
Permissions
Section titled “Permissions”Reading projects or activities needs projects.read or activities.read. This read permission is what makes them selectable in the timer. Creating, editing and archiving needs the matching create, update and delete permissions — typically a manager or administrator task.