ACP-120 flashcards
ACP-120 · Build recall with a focused review session.
32 cards. Read the term and the definition here. The deck at the top of this page is optional.
- Global permissions
- Site-wide permissions granted only to groups, such as Jira Administrators or Create Shared Objects; they apply across all projects and cannot be assigned to individual users in Jira Cloud.
- Audit log
- A site-level record of administrative configuration changes in Jira Cloud, filterable by category, user, and date; it does not record normal issue edits or comments.
- Create Shared Objects permission
- A global permission that lets users share filters, dashboards, and agile boards with groups or all users; without it, saved items stay private to their owner.
- Atlassian account ID
- A unique, immutable identifier for each user in Jira Cloud that stays constant even when the display name or email address changes, and which APIs and permission records reference.
- Project role
- A project-scoped container for users and groups used in permission and notification schemes; unlike a group, role membership can differ from project to project.
- Group
- A site-wide collection of users managed in Atlassian Administration, reusable across all projects and used for global permissions, application access, and permission scheme grants.
- Deactivating a user
- Removing a user's product access while preserving their issue history, comments, and mentions; Jira Cloud deactivates or removes accounts rather than hard-deleting them.
- Apps access project role
- The built-in atlassian-addons-project-access role used by Marketplace apps; removing it from a project breaks app functionality such as custom fields, workflow integration, and panels.
- Team-managed project
- A project type whose settings are self-contained and edited by project administrators without shared schemes; simpler to configure but more limited than company-managed projects.
- Company-managed project
- A project type that inherits shared schemes for issue types, workflows, fields, permissions, and notifications, allowing one configuration change to affect many projects at once.
- Project key
- A short prefix that begins every issue key in a project, such as PROJ in PROJ-123; it is fixed at project creation and cannot be edited afterwards.
- Project category
- A label that groups related projects for organization, appears in JQL as category = "Name", and can be used to filter project pickers and reports.
- Field configuration
- Defines whether each system or custom field is required, optional, or hidden for the issue types mapped to it through a field configuration scheme.
- Issue type scheme
- Defines which issue types are available in a company-managed project and which one is the default; every such project has exactly one issue type scheme.
- Screen scheme
- Maps the create, edit, and view issue operations to specific screens; an issue type screen scheme then links each issue type to that screen scheme.
- Custom field context
- A configuration scope for a custom field covering chosen projects and issue types, carrying its own options, default value, and description; one field may have several contexts.
- Workflow scheme
- Associates each issue type in a project with a workflow; several issue types may share one workflow, and one workflow may serve many projects.
- Transition condition
- A rule evaluated before a transition is offered; if it fails, the user cannot see or execute that transition from the current status.
- Transition validator
- A check run after conditions pass that blocks the transition and shows an error when its requirement is unmet, such as a required field being empty.
- Post function
- An automated step that runs after a transition completes, for example setting the assignee, updating a field, adding a comment, or firing an event.
- Global transition
- A transition defined without a source status, making it available from any status in the workflow; commonly used for actions like Close or Reopen.
- Permission scheme
- A reusable set of grants assigning project permissions to users, groups, and project roles; each company-managed project is associated with exactly one permission scheme.
- Issue-level security
- Restricts individual issues to specific security levels; a user must belong to the issue's level to see it even when holding Browse Projects permission.
- Browse Projects permission
- The foundational project permission; without it a user cannot see the project or any of its issues, no matter which other permissions are granted.
- Set Issue Security permission
- Allows a user to choose or change an issue's security level, but does not by itself grant visibility to issues sitting at levels they do not belong to.
- Notification scheme
- Maps issue events such as create, comment, or transition to recipients including users, groups, roles, reporter, assignee, and watchers, determining who receives email.
- Watcher
- A user who subscribes to an issue to receive its notifications; they must additionally hold Browse Projects permission on that issue to actually get the email.
- Email visibility setting
- A site-wide privacy option controlling whether users can see each other's email addresses, which also affects whether JQL can search issues by email.
- Autowatch
- A personal user preference that automatically adds that user as a watcher to issues they create, comment on, or are assigned to.
- Automation rule actor
- The user whose permissions a rule's actions run under; if the actor is deactivated or lacks a permission, actions such as transitions fail.
- Smart values
- Placeholders such as {{issue.key}} or {{now}} that inject dynamic data into automation actions, with functions like toUpperCase and jiraDate transforming the output.
- Scheduled automation rule
- A rule triggered by a cron schedule that runs a JQL query and acts on matching issues, typically used for stale-issue cleanup or recurring reminders.