ACP-100 cheat sheet

Project types: Company-managed (classic) projects use shared schemes; team-managed (next-gen) projects use independent, simplified configurations.

Project key: 2–10 characters, uppercase letters and numbers, must start with a letter; immutable after creation.

Issue type schemes map issue types to a workflow; a project can have only one issue type scheme.

Field configuration schemes control field visibility and requiredness per issue type; field configuration is the unit of field behavior.

Screens are attached to projects via screen schemes, which map operations (create, edit, view) to screens.

Workflow schemes bind issue types to workflows; each issue type can have exactly one workflow per scheme.

Notification schemes define who receives email events; default notification scheme applies when none is specified.

Permission schemes define project-level access; global permissions are separate and apply instance-wide.

Project category groups projects for reporting and permission inheritance in some contexts; it does not grant access by itself.

Global permission 'Jira Administrators' controls access to administration; 'Jira Users' grants application access.

Group membership is the primary way to grant project permissions; individual user grants are possible but discouraged for scale.

Permission schemes have three grant types: application access, group, and single user; project roles are separate.

Project roles are project-specific and can be assigned to users or groups; they are used in permission schemes and notifications.

Default groups (jira-administrators, jira-users) exist; removing users from jira-users can block login unless application access is granted otherwise.

Permission to 'Browse Projects' is required to see issues; other permissions build on it.

User directories (internal, LDAP, Crowd) can be ordered; the first directory that authenticates wins.

Group names are case-sensitive in some versions; avoid spaces and special characters for script compatibility.

Permission helper (built-in) shows why a user does or does not have a permission in a project.

Issue type scheme: one default issue type plus a list; the default is used when no type is specified.

Field configuration: controls renderer, description, and required flag; it is linked to a field configuration scheme.

Field configuration scheme maps issue types to field configurations; issue types not mapped use the default configuration.

Screen scheme maps operations (create, edit, view) to screens; a screen scheme can have a default screen.

Screen: ordered collection of fields and tabs; fields not on a screen are not visible in that operation.

Custom field context: limits a field to specific projects and issue types; a field can have multiple contexts.

Field type cannot be changed after creation; create a new field and migrate data if needed.

Issue type scheme can be shared across projects; changing it affects all associated projects.

Workflow: set of statuses and transitions; each transition has a target status and optional conditions, validators, post functions.

Condition: must evaluate true for the transition to be available; if false, the transition is hidden.

Validator: must evaluate true for the transition to execute; if false, an error is shown and the transition fails.

Post function: runs after the transition succeeds; order matters, and the first post function can set the assignee.

Common conditions: 'Only Assignee', 'Only Reporter', 'Permission', 'User Is In Group'.

Common validators: 'Required Field', 'Field has been modified', 'Regular expression'.

Common post functions: 'Set issue status to', 'Assign to current user', 'Update change history', 'Fire event'.

Workflow scheme maps issue types to workflows; a project can have only one workflow scheme.

Global transitions apply to all statuses; they are often used for 'Close' or 'Reopen'.

Automation rules consist of a trigger, optional conditions, and actions; rules can be global or project-scoped.

Triggers include issue created, field changed, scheduled (cron), and incoming webhook.

Conditions include JQL, user, and field-based checks; actions include transition, edit, comment, and web request.

Notification scheme: associates events (issue created, commented, transitioned) with recipients (groups, roles, users, email addresses).

Event types: system events (Issue Created, Issue Updated) and custom events; custom events can be fired by post functions.

Notification scheme can be associated with a project; if none, the default notification scheme applies.

Automation 'Send email' action uses the mail server configured in Jira; it is separate from notification schemes.

Automation audit log records rule executions and errors; it is the primary debugging tool.

Filter: saved JQL query; can be shared with users, groups, or projects, or kept private.

Dashboard: collection of gadgets; can be shared with users, groups, or everyone; must have at least one gadget to be useful.

Gadget: configurable dashboard widget; examples: Filter Results, Pie Chart, Two-Dimensional Filter Statistics, Created vs Resolved.

JQL functions: currentUser(), membersOf(), linkedIssues(), issueHistory(), now(), startOfDay().

Filter subscriptions: schedule email of filter results daily, weekly, or monthly.

Reports (built-in) include Sprint Report, Burndown, Version Report, and Time Tracking Report; they rely on project data.

Dashboards can be favorited; favorites appear in the Dashboards menu.

A filter used by a gadget must be shared with the gadget's viewers, or the gadget shows no data.

REST API: base URL /rest/api/2/ or /rest/api/3/; authentication via basic auth, OAuth, or personal access token (Data Center).

Webhooks: outbound HTTP POST on events; configured in System > Webhooks; useful for real-time integrations.

Application links: configure trust between Jira and other Atlassian products (Confluence, Bitbucket) or external apps.

Marketplace apps: installed via Universal Plugin Manager (UPM); check compatibility with Jira version before install.

Data migration: CSV import maps columns to fields; must include summary and issue type; project key must exist or be created.

CSV import can create users and issues; date formats and field mappings must match Jira configuration.

Backup: XML backup includes data but not attachments; attachments must be copied separately.

Project import (from another Jira) requires a backup file and a mapping of users, statuses, and custom fields.

App license: apps are licensed per user tier; check license compatibility after Jira upgrade.