Jira Project Admin test Questions and
Answers 100% Solved
What is a condition?
What is a validator?
What is a trigger? C- should the transition appear to the user?
V - stops you to tell you you need to do something else?
T - Listener that fires when something happens - cannot block anything
What requirements must a user meet in order to use a particular workflow transition?
They must have the browse projects permission, application access (if using boards),
transition issues permission, and close/resolve issue permission for non simplified workflows.
Also they must not be excluded from a workflow transition condition/validator
What is an Issue Collector and what permissions are needed to configure it? allows you to
easily embed a Jira feedback form into your own web site, when a customer clicks the link it
creates an issue in Jira. Must be a Jira Admin globally to configure this
,Where are all the places you need to look to fully identify what permissions a particular user
has? users and Roles, and permission schemes, conditions
What are the use cases where it is best to use Project Roles rather than Groups? Better for
roles - reduce the number of schemes, project admins can manage membership, changes can be
made quickly if membership changes
Roles
membership is for one project
Project admin can alter this membership
Group
membership is global
only JIRA admin can change this
Which business requirements necessitate the use of separate issue types in a project
(e.g. different screens, workflows, etc.)? Internal/External requests have different
workflows
They have different required/hidden fields
They need different screens
If you need to report them separately
, What is the relationship between screens, screen schemes and issue type screen schemes?
Screens - collection of fields that appear when an issue is created, edited or viewed
Screen schemes - allow you to assign screens to issue operations, specifically Create, Edit, and
View (determine which screens are shown for each issue operation)
Issue type screen schemes - allow you to map particular screen schemes to a specific issue type,
much like you do with other schemes
Screens inside screen scheme inside issue type screen scheme
How are they (screens, screen schemes and issue type screen schemes) related to field
configurations? Field configurations list all the system and custom fields that are available
in JIRA to use in screens/schemes/issue schemes
Field configs also define how fields behave (required/optional)
What can Jira admins change in field configurations? Field optional/required
Field hidden/visible
Field description
What renderer is used by the field (mostly used by text fields)
Answers 100% Solved
What is a condition?
What is a validator?
What is a trigger? C- should the transition appear to the user?
V - stops you to tell you you need to do something else?
T - Listener that fires when something happens - cannot block anything
What requirements must a user meet in order to use a particular workflow transition?
They must have the browse projects permission, application access (if using boards),
transition issues permission, and close/resolve issue permission for non simplified workflows.
Also they must not be excluded from a workflow transition condition/validator
What is an Issue Collector and what permissions are needed to configure it? allows you to
easily embed a Jira feedback form into your own web site, when a customer clicks the link it
creates an issue in Jira. Must be a Jira Admin globally to configure this
,Where are all the places you need to look to fully identify what permissions a particular user
has? users and Roles, and permission schemes, conditions
What are the use cases where it is best to use Project Roles rather than Groups? Better for
roles - reduce the number of schemes, project admins can manage membership, changes can be
made quickly if membership changes
Roles
membership is for one project
Project admin can alter this membership
Group
membership is global
only JIRA admin can change this
Which business requirements necessitate the use of separate issue types in a project
(e.g. different screens, workflows, etc.)? Internal/External requests have different
workflows
They have different required/hidden fields
They need different screens
If you need to report them separately
, What is the relationship between screens, screen schemes and issue type screen schemes?
Screens - collection of fields that appear when an issue is created, edited or viewed
Screen schemes - allow you to assign screens to issue operations, specifically Create, Edit, and
View (determine which screens are shown for each issue operation)
Issue type screen schemes - allow you to map particular screen schemes to a specific issue type,
much like you do with other schemes
Screens inside screen scheme inside issue type screen scheme
How are they (screens, screen schemes and issue type screen schemes) related to field
configurations? Field configurations list all the system and custom fields that are available
in JIRA to use in screens/schemes/issue schemes
Field configs also define how fields behave (required/optional)
What can Jira admins change in field configurations? Field optional/required
Field hidden/visible
Field description
What renderer is used by the field (mostly used by text fields)
