Introduction
The JIRA connector for Glean allows Glean to fetch and index content from JIRA, ensuring users can search and access documents with authorized permissions.
Authentication: Glean requires the JIRA admin to authenticate to Glean when setting up the Glean crawler app in the Atlassian marketplace.
Data Storage: All data is stored in the cloud project within the customer's cloud account, ensuring no data leaves the customer's environment
API Usage
Standard API: Glean uses Atlassian’s standard API for JIRA to ingest all data
Integration Features
Content Captured: Glean captures JIRA projects, service management, dashboards, and more.
Permissions Enforcement: Glean respects all user access permissions, ensuring users only see search results for documents they can access. When a user clicks on a search result, they are taken to the JIRA web application, which enforces the permission.
Versions Supported
The JIRA cloud connector has no specific version limitations, which is Atlassian’s SaaS offering of JIRA in the cloud. Glean supports the JIRA datacenter, a customer-managed deployment with a different connector and separate documentation.
Objects Supported
The JIRA connector supports the following objects:
Projects
Issues
Comments
Dashboards
Filters
Authentication Mechanism
The Jira/Confluence admin will install an Atlassian Marketplace app with Admin scope (Note that we need Admin scope to fetch permissions associated with Jira objects (see discussion below)) that will be used for indexing the content, and another Connect app that delivers webhooks to the customer’s Glean instance. Installing the Glean Connect app for Confluence will allow the app to read all unrestricted pages in these spaces. It will not be able to read restricted pages unless the admin grants access to the Glean app for those pages.
Connector credentials requirements
The JIRA connector for Glean requires specific permissions to function correctly.
Glean requires authentication to the JIRA instance to fetch relevant information.
Admin-level permissions are required for setup and configuration
Glean understands all user access permissions and strictly enforces them at the time of the query, ensuring that users cannot see results to which they do not have access.
It’s important to note that all data is stored in the cloud project in the customer's cloud account and no data leaves the customer's environment.
Glean only requires READ-level permissions. Application vendors may not provide granularity in their permission schemes for read-only access as observed by Atlassian for the listing group permissions and issue securit.y
Admin-level Access for Atlassian Cloud JIRA Connector Discussion
The Glean connector for Jira integrates seamlessly with Jira to index data and provide advanced search capabilities across your organization’s Jira projects. To ensure Glean can access the necessary data for indexing while respecting Jira’s permissions and security settings, specific API scopes are required. Two of these scopes require admin-level access. The following will explain why Glean needs admin-level access and follows least privilege.
Granting admin-level permissions for the Glean connector allows Glean to index Jira data securely and effectively, respecting your organization’s permission structures and issue visibility rules. This ensures users only see results they are authorized to access, maintaining both compliance and security.
Why Read-Only Permissions Are Insufficient
While “read” permissions allow access to issue content, they do not grant visibility into permission schemes or group memberships, which are crucial for:
Accurate indexing based on user permissions.
Aligning Glean’s search results with Jira’s access control rules.
Avoid over-exposure of sensitive data in search results.
Admin-level permissions ensure Glean has the necessary access to these configurations while maintaining alignment with Jira’s security model.
Scopes Requiring Admin-Level Access
The following Jira REST API scopes necessitate admin-level permissions:
Group/Member Access
Endpoint: Get group members
Scope: GET /rest/api/2/group/member
Issue Security Schemes and Members
Endpoint: Get issue security scheme members
Scope: GET /rest/api/2/issuesecurityschemes/{id}/members
Why Glean Needs Admin-Level Access
Access Control and Permissions Mapping
Jira projects often implement granular permissions via groups, members, and security schemes to restrict access to sensitive data. Glean needs access to these configurations to:
Determine who can view specific issues or projects.
Respect Jira’s permission settings when indexing and searching within Glean.
Without this data, Glean cannot ensure accurate user results based on their Jira permissions.
Issue Security Schemes
Jira’s issue security schemes define visibility rules for issues, often based on user roles, groups, or custom security configurations. Accessing these schemes allows Glean to:
Understand and replicate visibility restrictions.
Prevent users from seeing search results for issues they are not authorized to access in Jir.
Group and Member Details
Understanding group membership is essential for aligning search results with Jira’s access controls.
Admin-level access ensures Glean can retrieve comprehensive user-group mappings, which are critical for enforcing permissions.
Why Jira Requires Admin Scope for the Following Actions
Jira enforces admin-level access for these endpoints because they expose sensitive metadata about:
User Groups and Memberships
Accessing group data can reveal information about organizational structure and team assignments, which may be sensitive.
Admin permissions ensure that only authorized apps or administrators can retrieve this data.
Issue Security Configurations
Issue security schemes are often tailored to restrict access to high-priority, confidential, or sensitive issues.
Jira requires admin scope to prevent unauthorized or overly broad access to this critical information.
Connection instructions
Disclaimer: The instructions below are updated periodically by Glean on our customer-facing documentation. For the latest instructions, refer to the Glean Admin UI
1. Install the Glean app
Click Get it now.
Select the Jira site you're connecting, click Install App and complete the installation process.
2. Set up the basics
Sign into Jira as an admin. Copy your Atlassian domain from the URL bar and paste into Glean:
https://YourAtlassianDomain.atlassian.net
Click the 3 dots belonging to the organization matching your Atlassian domain from step 1, then click on Manage product access
Click on Manage access for the Jira Software Product
Enter the default groups (there might be only one) as a comma-separated list in Glean. Only users in the provided product access groups will be able to see results in Glean.
Click Create Webhook URL in Glean. This should create an installation link for the Webhook app.
3. Configure Webhook and Activity Plugin
3a. Install the Activity plugin
Click Get it now.
Select the Jira site you're connecting, click Install App and complete the installation process.
After the app installation is successful, download the webhook app as described below.
3b. Connect the webhook
Copy the Webhook app installation link from Glean.
Go back to Jira, i.e. https://YourAtlassianDomain.atlassian.net/jira, click on the Settings gear in the top right corner, then click Apps > Manage apps.
Click on Settings near the bottom of the page and ensure Enable development mode and Enable private listings are selected. Click Apply and refresh the page.
Click on Upload app near the top right of the page.
Paste the webhook app installation link in the box that appears.
Click Upload.
Authentication scope requirements
Use case | App | Installation Flow | Scope | Link |
Crawl | Crawler app (central) | User installs the app on their instance. Atlassian sends us an installed event with a shared secret, which we store in Scio apps. | READ
ACCESS_EMAIL_ADDRESSES
ADMIN
PROJECT_ADMIN
| |
Update events | Webhook app (central). This central app exists to support CWS | Installed via a public static URL | READ | |
Webhook app (deployment) | We generate a URL dynamically and register the app with Atlassian | READ |
|
|
Items crawled
Content Indexed
Projects
Issues
Comments
Dashboards
Filters
Identity
Users: Information about users within the JIRA
Groups: Details about groups within JIRA at the global, project, and issue level
Memberships: Information about group memberships at global and project level, indicating which users belong to which groups.
The identity crawl operates with the following configurations:
Incremental Identity Crawls: These are performed to capture changes since the last crawl.
Full Identity Crawls: These are conducted periodically to ensure all identity data is up-to-date.
Activity
Adds: New issues, projects, files, or folders added
Updates: Modifications made to existing issues, projects, files, or folders.
Permissions Changes: Changes in issues, projects, files, or folders sharing permissions.
Deletions: issues, projects, files, or folders that have been deleted.
View Activity: Events indicating when an issues, projects, files, or folders has been viewed.
The Glean Activity plugin for Jira helps Glean to provide highly personalized search results for the users. By sending webhook events to Glean each time a user views an issue in Jira, the plugin enables Glean instance to gather valuable information that is crucial to delivering an outstanding search experience. This information is stored securely in your dedicated cloud project, ensuring complete privacy and protection of your data.
Rate Limits
Queries per Second (QPS): The default rate limit is set to 12 queries per second per user.
Update frequency
Content updates for the JIRA connector in Glean can happen quite rapidly, depending on the type of update and the configuration settings. Here are the key areas:
Activity Reports: Adds, updates, and permissions changes are crawled every 10 minutes. This means that any new files, modifications to existing files, or changes in sharing permissions are detected and processed quickly.
People / Identity Crawls: Changes to group memberships are picked up by the identity crawl, which runs every hour. This ensures that updates to user groups and their permissions are reflected promptly.
Incremental Crawls occur every 3 hours to provide additional reliability beyond the minute-by-minute activity reports.
Full Crawls: The frequency of full crawls can be configured, but they are generally less frequent than incremental crawls at 28 days
Changes in data must be crawled, processed, and indexed before the data is reflected in the UI. Actual time may vary depending on the number of changes and corpus size. For the most up-to-date crawler refresh information, please refer to [External] Glean crawling strategy
How the crawl works
The JIRA crawler follows the traditional crawler strategy, including utilizing the JIRA API and the following ways to get and update data:
Identity Crawl: updating and adding of People data, including users, groups, and other information
Activity Crawl: Adds, updates, and permissions changes to content
Webhooks: are messages sent by the application to notify Glean of changes in real-time, and then Glean either initiates crawl or picks up the change on the next crawl
Content Crawls: Full crawls the entire defined scope of the application, whereas incremental crawls only capture the changes from the previous full or incremental crawl
Known Limitations in Crawl
The crawl speed can be affected by the rate limits imposed by the JIRA API
The Glean JIRA connector cannot read restricted pages unless the admin grants access to the Glean app for those pages. This means that restricted pages will not be indexed or searchable by default.
API endpoints
Purpose | Cloud Endpoint | Cloud level Permission | OAuth 2.0 scopes required & recommended | Connect app scope required | Description |
Get all dashboards | None | Classic: read:jira-work | READ | Returns a list of dashboards owned by or shared with the user. The list may be filtered to include only favorite or owned dashboards | |
Get dashboard | None | Classic: read:jira-work | READ | Returns a dashboard for the user | |
Get users from group | Browse users and groups global permission or Administer Jira global permission | Classic: manage:jira-configuration | ADMIN | Returns a paginated list of all users in a group | |
Find groups | Browse projects project permission | Classic: read:jira-user | READ | Returns a list of groups whose names contain a query string | |
Get issue | Browse projects project permission | Classic: read:jira-work | READ | Returns the details for an issue | |
Get issue security level members | Administer Jira global permission. | Classic: manage:jira-configuration | ADMIN | Returns issue security level members: identifying which users, groups, or roles have access to issues under specific security levels within classic projects | |
Get project | Browse projects project permission | Classic: read:jira-work | READ | Returns the project details for a project. | |
Get project issue security scheme | Administer Jira global permission or the Administer Projects project permission. | Classic: manage:jira-configuration | READ | allows you to understand the security configurations governing issue visibility within that project | |
Get assigned permission scheme | Administer Jira global permission or Administer projects project permission. | Classic: read:jira-work | READ | permissions granted to users and groups within a project, determining their capabilities such as issue creation, editing, or project administration | |
Get project role for project | Administer Projects project permission for the project or Administer Jira global permission. | Classic: read:jira-work | READ | retrieves detailed information about a particular project role within a specified project. This includes the role’s description and the list of users and groups assigned to that role, known as “actors.” | |
Search for issues using JQL | Browse projects project permission | Classic: read:jira-work | READ | Searches for issues using JQL | |
Get request types | Permission to access the service desk | Classic: read:servicedesk-request | READ | Returns all customer request types from a service desk | |
Get request type fields | Permission to access the service desk | Classic: read:servicedesk-request | READ | returns the fields for a service desk's customer request type | |
Get project form index | Permission to access the project | Classic: read:jira-work | READ | Returns all the forms associated with the project | |
Get form template | Permission to access the project | Classic: read:jira-work | READ | Returns the template aka schema of the form | |
Search for filters | None | Classic: read:jira-work | READ | Returns a paginated list of filters | |
Get filter | None | Classic: read:jira-work | READ | Returns a filter | |
List projects | Browse Projects project permission for the project. Administer Projects project permission for the project. Administer Jira global permission.
| Classic: read:jira-work | READ | Returns a paginated list of projects visible to the user | |
Access email addresses | N/A | read:email-address:jira | ACCESS_EMAIL_ADDRESSES | Returns a user's email address regardless of the user's profile visibility settings. For Connect apps, this API is only available to apps approved by Atlassian, according to these guidelines. For Forge apps, this API only supports access via asApp() requests. | |
Get user groups | N/A | Classic: read:jira-user | READ | Returns the groups to which a user belongs | |
Register a webhook | Classic: read:jira-work, manage:jira-webhook | READ | Registers webhooks |
Content Configuration
Note: If Inclusion (Green-Listing) options are enabled, only content from the Inclusion category will be indexed. If Exclusion (Red-Listing) options are enabled, all content in the exclusion category will be removed. If both rules are applied to the same content, then the content will NOT be indexed, as exclusion rules take priority.
The rules below should be used MINIMALLY to preserve the enterprise search experience, as most end-users expect to find all content. Most customers do not apply any rules or apply exclusion rules sparingly for sensitive folders.
There may be a delay before the system fully reflects these changes. Furthermore, customers can hide the relevant documents if access has been inadvertently granted to an individual. For detailed guidance on using the “Hide” functionality via CSV upload, please refer to How to Hide Documents via CSV Upload article.
Exclusion (Red-Listing) Options
By entering specific project ID’s in the box within UI, the specified projects will be excluded from being crawled and indexed by Glean.
Note: Exclusion rules are applied automatically after the next full crawl.
Inclusion (Green-Listing) Options
By entering specific project ID’s in the box within UI, the specified projects will be crawled and indexed by Glean (and nothing else)