Managing App Permissions

JetTime's access model has two layers, and you configure both inside the app, under Settings > Roles and Permissions. Which one you reach for depends on how wide the access should be.

• Global Permissions — app-wide. One grant applies to every team, account, and workstream at once, including the ones created tomorrow. Grant it to a person, to a whole team — meaning its team members — or to everyone. This is the layer for the baseline everyone gets, and for the few people who administer JetTime.
• Permission Schemes — per object. A scheme says what each permission role may do; you attach it to a team, an account, or a workstream, and decide who holds which role on that object's Access tab. This is the layer for "she manages this client's hours, he only reads them".

The two combine: a person may act if either layer allows it. Neither takes anything away, so to give someone less, grant less rather than adding a narrower rule on top.

Two more pages in the same Settings group support these layers: Permission Roles — the access levels a scheme grants permissions to, covered in the scheme article — and Function Roles, the list of jobs people log work under.

JetTime's Permissions Sit on Top of Jira's

There is a third set of rules underneath both layers, and it isn't ours: Jira's own.

Work logs in JetTime are ordinary Jira work logs. JetTime writes them through Jira's API as the person they belong to, so Jira checks its own work-log permissions on the space every time — logging, editing, deleting. JetTime cannot go around that, and no JetTime permission overrides it.

So two sets of rules have to agree before someone can log time: Jira has to allow work on that space, and JetTime has to allow the team or account they are logging to. When someone holds every JetTime permission and still can't log on one space, that is almost always Jira's side saying no — check that space's permission scheme in Jira.

JetTime's own rules apply wherever people work through JetTime, and the surest way to make that everywhere is to set JetTime as your Jira time tracking provider. Jira then hands its work-log surfaces over: the Log work action on a work item and the work logs in its activity tab become JetTime's, so time is logged and edited through JetTime's form even when nobody opens the JetTime app — and your teams, accounts, and permissions apply there too. See Setting JetTime as Time Tracking Provider in Jira.

What stays outside any app's reach is Jira's REST API, where someone holding Jira's work-log permissions can change a work log directly. That is the same for every time tracker that keeps its work logs in Jira, and it is why Jira's own permission schemes remain the place to lock the underlying data down.