Setting Up Permissions

How JetTime decides who can see and manage which work logs.

JetTime has its own permissions, and you set them inside the app — in Settings > Roles and Permissions. Nothing to configure in Jira, no Jira groups to build first.

A fresh install is already usable: everyone can log their own time, and Jira administrators can do everything. You only start configuring when you want someone to see more than their own hours, or less than everything.

The Two Layers

JetTime follows the model Jira uses, so it should feel familiar:

  • Global Permissions — app-wide. A global permission grants a capability on every team, account, and workstream at once. This is the layer for "everyone can log their own time" and "these three people administer JetTime".
  • Permission Schemes — per object. A scheme is a matrix that says what each permission role may do, and you attach it to a team, an account, or a workstream. Who holds which role is decided on that object's Access tab. This is the layer for "she manages this client's hours, he only reads them".

Both layers only ever add. A permission never takes anything away, so to give someone less, you grant them less rather than adding a narrower rule on top.

Underneath both sits a third set of rules that isn't ours: Jira's own. Work logs in JetTime are ordinary Jira work logs, so Jira checks its work-log permissions on the space before anything is stored, and no JetTime grant overrides that. What follows from it — and how to make JetTime's rules apply across Jira — is in Managing App Permissions.

What a New Install Already Has

Two grants ship with the app:

  • Any logged in user holds the View and Manage Own Work Logs global permission — so anyone on the instance can log and manage their own time straight away.
  • Everyone who was a Jira administrator at install holds the Full Access global permission, each as their own row.

Both sit in JetTime, on the Global Permissions page under Settings > Roles and Permissions — as ordinary rows you can change or remove like any other. That page is also where you add the next ones.

Where to Configure It

The Roles and Permissions group in Settings holds it all. Global Permissions is the app-wide layer; Permission Schemes and Permission Roles make up the granular one. Function Roles sits in the same group: it is the list of jobs people log work under — Developer, Designer, QA — and it drives the per-role breakdowns your reports and invoices are built on. It is not a permission, but it does gate one thing: a person has to hold a function role in a team before they can log time to that team.

Nobody can lock themselves out. If the in-app permission that opens Settings is taken away from every administrator — including by someone removing their own — there is a way back in, and it sits outside JetTime: JetTime – View and Manage Settings in Jira's own Global permissions screen still lets a Jira administrator in to put things right.

For the full picture — every global permission and what it opens up — read Managing Global Permissions.

On this page