Jira
Connect Jira Cloud: read-only Atlassian OAuth, the user, group and project access data Noru reads, the evidence and findings it produces, and what it never collects.
- Authentication
- OAuth
- Categories
- Productivity, IAM
- Sync cadence
- Daily by default (hourly, weekly, or monthly on request)
- Requested access
read:jira-workread:jira-userread:group:jiraread:user:jiraread:application-role:jiraread:avatar:jiraread:meoffline_access
Jira holds who can sign in to your issue tracker, who administers it, and who can read each project. Noru reads those three things from Jira Cloud to evidence user access, privileged access and project access settings, and to offer Jira as a system in user access reviews. It reads no issue text.
Jira Data Center and Jira Server are not supported.
What Noru collects
| Object | Source call | Fields kept | What it feeds |
|---|---|---|---|
| Connected account | GET /myself | Account id | Confirms the connection still works for the site |
| Users | GET /users/search | Account id, display name, email (when the profile shows it), active or deactivated | People directory, user access evidence, access reviews |
| Groups | GET /group/bulk | Group id and name | Group count, finding the administrator groups |
| Administrator group members | GET /group/member | Account id, email, active or deactivated | Administrator evidence, the Admin role in access reviews |
| Product access | GET /applicationrole | Product name, groups that grant it, user count, seats | Product access in the user access evidence |
| Projects | GET /project/search | Id, key, name, type, team-managed or company-managed | Project access evidence |
| Permission schemes | GET /permissionscheme, GET /project/{id}/permissionscheme | Scheme name and who holds Browse Projects | Who can read each project |
| Issue security levels | GET /project/{id}/securitylevel | The number of levels | Project access evidence |
| Tickets, in projects you choose | POST /search/jql | Key, issue type, status category, priority, created and resolved dates, whether it is assigned | Change, incident and bug ticket evidence |
Every response is reduced to the fields above as it is read; nothing else from a record is stored or logged. Only people are kept: app accounts and customer portal accounts are left out. A sync reads up to 5,000 users, 200 groups and 500 projects, and the evidence says when a list was cut short.
Jira has no way to list who holds the global administrator permission, so Noru
treats a group as an administrator group when its name contains "admin"
(site-admins, org-admins, jira-administrators, jira-admins-<site>).
What Noru does not collect
- Issue summaries, descriptions, comments, attachments or work logs. Ticket evidence asks Jira for workflow fields only, so the text never leaves Jira.
- Any ticket outside the projects you choose, and who a ticket is assigned to.
- Boards, sprints, filters or dashboards.
- Installed Marketplace apps. Jira offers no way for a connection like this one to list them.
- Avatars, time zones or locales of users.
- Noru never writes to Jira through the data source. Creating tickets is a
separate choice under Settings → Task tracker, which asks you to approve
the connection again with
write:jira-work. See Task tracker.
Before you connect
- A Jira Cloud site.
- Connect as a Jira administrator. Any Jira user can approve the connection, but Jira only lets administrators list groups, their members and product access. Without that, Noru skips groups and administrators and still collects the rest.
- Each Jira site can be connected once per Noru organization.
- If Confluence is already connected with the same Atlassian account, the approval screen also lists the Confluence permissions. Atlassian keeps one approval per account, so Noru asks for both together to keep Confluence working.
Connect
/data-sources and click Connect data source.Allow pop-ups for Noru if the Atlassian window does not open. See Naming and using connection dialogs for naming, scrolling, and closing behavior.
The first sync starts shortly after you connect and then runs daily. Use Sync now on the source to run one sooner.
Choose projects for ticket evidence
Ticket evidence is off until you choose projects.
/data-sources.From each chosen project Noru reads tickets of these issue types, created in the last 180 days or still open, up to 200 per project and kind:
| Evidence | Issue types |
|---|---|
| Change tickets | Change, Change Request |
| Incident tickets | Incident, Major Incident |
| Bug and vulnerability tickets | Bug, Vulnerability |
Issue types are matched by these names. A project that uses other names contributes no tickets.
After connecting
- People directory. Each user whose Atlassian profile shows an email becomes a person, or is matched to an existing one by email. A user whose profile hides the email cannot be matched and is counted in the evidence as a user without email.
- Access reviews. Jira is offered as a system. Each person's role is Admin when they are in an administrator group and User otherwise. When groups could not be read, no role is shown.
- Evidence and controls. Each record maps only to control and evidence pairs from Noru's control catalog:
| Evidence | Content | Controls |
|---|---|---|
| Jira User Access | Active and deactivated users, users without email, product access by group | IAM-42 User & Service Account Inventories (User & Service Inventory); IAM-12 (Existing User listing); IAM-09 (List of User IDs), only when every user was read |
| Jira Groups and Administrators | Group count, administrator groups and their members, deactivated accounts still in them | IAM-61 (Privileged User Inventory); IAM-29 and IAM-51 (Defined Roles & Authorizations) |
| Jira Project Access Configuration | Per project: permission scheme, who can browse it, issue security levels | IAM-29 (Defined Roles & Authorizations) |
| Jira Change Tickets | Change tickets in the chosen projects: open and resolved counts, time to resolve, a sample of ticket keys | CHM-01 Change Management Workflow (Change Records) |
| Jira Incident Tickets | Incident tickets: open and resolved counts, tickets open more than 30 days, by priority | IR-03, IR-10, IR-11 and IR-17 (Sample of incidents, Incident Tracking, Logs of Incident maintained) |
| Jira Bug and Vulnerability Tickets | Bug and vulnerability tickets: counts by priority, tickets open more than 90 days | VM-23 Backlog Prioritization (Sample Identified Bugs), when tickets carry a priority |
| Jira Collection Coverage | Which of the areas above the last sync could read, and why not | None; it describes the sync |
-
Findings.
- Projects are open to anyone on the internet (high).
- Projects are open to every signed-in user (medium).
- Deactivated accounts are still in administrator groups (medium).
- More than five people administer Jira (low).
- Incident tickets have been open for more than 30 days (low).
- Bug or vulnerability tickets have been open for more than 90 days (medium).
Each finding is re-evaluated on every sync and closes on its own once the condition is gone.
How project access is decided
| Shown as | When |
|---|---|
| Public | The project's permission scheme grants Browse Projects to Public (anyone) |
| Any signed-in user | The scheme grants Browse Projects to Any logged in user |
| Restricted | Browse Projects is limited to named groups, project roles or people |
| Not determined | Jira did not return a permission scheme, which is usual for team-managed projects |
Permissions in detail
| Scope | Why Noru asks | What it could technically allow |
|---|---|---|
read:jira-work | Projects, permission schemes and issue security levels | Reading issues, comments and attachments. Noru requests none of them |
read:jira-user | The user list and the connected account | User profile fields. Noru keeps the id, name, email and active state |
read:group:jira, read:user:jira, read:avatar:jira | Groups and the members of administrator groups | Members of every group. Noru reads members of administrator groups only |
read:application-role:jira | Which groups grant access to each Jira product | Nothing beyond product access settings |
read:me | Identify the Atlassian account that approved the connection | Basic profile of that account |
offline_access | Keep syncing without asking you to approve again | Nothing by itself |
Atlassian issues the tokens to Noru's app. They are encrypted at rest with a key held by Noru and refreshed before they expire. Remove Noru under Connected apps in your Atlassian account to cut access immediately.
Troubleshooting
| Symptom | Cause and fix |
|---|---|
| "That approval did not include a Jira site." | The site you chose in the Atlassian window has no Jira. Connect again and choose a site that has Jira |
| "This Jira site is already connected." | Your organization already has this site connected. Use Reauthenticate on that connection rather than adding a second one |
| "That approval was for a different Jira site." | A reconnect must approve the site the connection uses. Reauthenticate and choose that site |
| "Choosing a Jira site took too long." | The site choice is kept for ten minutes. Start again from Connect Jira |
| The source shows Disconnected | Atlassian refused the stored approval, usually after Noru was removed from the connected apps. Click Reauthenticate and approve again |
| No administrator evidence, and Jira people have no role in access reviews | The person who connected Jira is not a Jira administrator. Reauthenticate as one. Jira Collection Coverage shows what was skipped |
| Fewer people than Jira users | Users whose Atlassian profile hides their email cannot be matched to a person. The user access evidence counts them |
| No ticket evidence | No projects are chosen, or the chosen projects use other issue type names than the ones listed above |
| A project shows "Not determined" | Team-managed projects set access inside the project, which Jira does not report through a permission scheme |
Related
- How syncs run
- Permissions and security
- Troubleshooting data sources
- User access reviews (UARs)
- Confluence, the other Atlassian source
Last updated on
incident.io
Connect incident.io: read-only API key setup, the incident, postmortem, follow-up, on-call and user metadata Noru reads, the controls it supports, and the incident content that stays in incident.io.
JungleMap
Connect JungleMap (NanoLearning): credential setup, how activity plans become training campaigns, and which completion data Noru writes.