Managing Global Permissions

Global permissions are JetTime's app-wide layer of access. One grant covers every team, account, and workstream at once — which is what you want for the people who administer time tracking for the whole company, and for the baseline everybody else gets. They live inside JetTime, so there are no Jira groups to build first.

When a global grant is too wide, the other layer is the Permission Scheme, which grants rights on one object at a time.

Where Global Permissions Live

Open the JetTime app, go to Settings, and under Roles and Permissions click Global Permissions. The page is one section per permission, each listing everyone who holds it, so it reads top to bottom as the answer to "who can do what here".

Who You Can Grant To

A grant goes to one of three kinds of subject:

• A user — one person.
• A team — the team members all hold the permission, and anyone who joins the team later inherits it. This is how you grant to a group without maintaining a list twice. It follows the team's People tab, not who has access to the team.
• A special — today there is exactly one, Any logged in user: everyone on the instance. This is the baseline grant, the one a new install uses so people can log time without any setup.

Granting a Permission

To take a permission away, use the delete button at the end of its row.

What Each Global Permission Grants

• Full Access — everything, every feature and every object. The permission for whoever administers JetTime.
• View and Manage Own Work Logs — log, edit, and delete your own work logs, use timers, and see all accounts and workstreams. The everyday permission.
• View Others Work Logs — read other people's work logs, plus see all teams, accounts, and workstreams. Read-only, and useful on its own for an accountant or an auditor.
• View and Manage Others Work Logs — the same, plus editing and deleting other people's work logs.
• View and Manage Accounts — create, edit, and delete accounts, and see the full account list.
• View and Manage Teams — the same for teams.
• View and Manage Workstreams — the same for workstreams.
• View and Manage Settings — open Settings and configure the app.

Own and others are separate. View Others Work Logs never includes your own hours, and View and Manage Own Work Logs never includes anyone else's — someone who needs both gets both.

The three object permissions are about the objects, not the hours logged to them. View and Manage Teams lets you create, rename, archive, and delete teams; it doesn't hand you anyone's work logs.

What a New Install Already Has

Two grants ship with the app, and both are ordinary rows you can change or remove:

• Any logged in user holds the View and Manage Own Work Logs global permission, so everyone can log their own time from the first minute.
• Everyone who was a Jira administrator when JetTime was installed holds the Full Access global permission — each as their own User row, not as a group.

Because those rows name people rather than a group, an administrator appointed in Jira later does not pick up Full Access automatically. Grant it to them on this page, or grant it to a team so it follows the people in it.

If you want tighter control than the default, remove the Any logged in user row and hand out access per object instead.

Permissions Only Add

A global permission is a wildcard: it grants that capability on every team, account, and workstream, including the ones created tomorrow. Nothing subtracts it. There is no deny rule anywhere in JetTime, and no way to grant a global permission "except for this one account".

So the way to restrict someone is to grant narrowly rather than to grant the global and carve out exceptions. Give them a permission role on the two accounts they work on, and they see those two.

Where a Global Grant Still Isn't Enough

A person may act on an object if a global permission allows it or their permission role on that object allows it — the wider of the two applies. Three places are worth knowing:

• Logging to a team also needs membership. A global permission grants the right, but the team still has to be one you belong to on its People tab, because the work log records the function role you worked under. See Teams and Function Roles.
• An archived team, account, or workstream grants nothing. It drops out of access resolution while staying in reports. Its managers keep their per-object Manage Settings on it, so they can bring it back.
• Jira has the final say. Work logs are ordinary Jira work logs, written through Jira's API as the person they belong to, so Jira checks its own work-log permissions on the space first. Someone holding the Full Access global permission who still can't log on one space is being stopped by Jira — check that space's permission scheme. See Managing App Permissions.

Getting Back Into Settings — the One Permission That Lives in Jira

Everything above is configured inside JetTime. This one is not.

JetTime declares a single permission in Jira's own Global permissions screen, outside the app: JetTime – View and Manage Settings, held by Jira administrators. It serves exactly one purpose — getting back into JetTime's Settings.

That matters because nothing on JetTime's Global Permissions page stops you removing your own access, including the last Full Access row. If that happens — or an administrator deletes their own JetTime View and Manage Settings global permission and nobody else holds it — no one could reach Settings to undo it. The Jira-side permission is the way back in.

A Jira administrator manages it in Jira, not here: Settings > System, then Global permissions in the Security section. It is the only JetTime permission in that screen.

Additional Tips

• Grant to a team rather than to a list of people. Teams change, and a team grant follows them.
• Start with the two default grants, then add. Most companies need a handful of global rows and do the rest per object.
• Deleting a team, account, or workstream always needs the matching global permission. Granular Manage Settings covers editing one, never deleting it.