ACP-620 "Managing Jira Projects for Cloud" Practice exam question 02.2385

[Kerli Loopman]

I am currently practicing with ACP-620 "Managing Jira Projects for Cloud" Practice exam questions and I am stuck with question 02.2385. 

Question: 

"DAPPS is a team-managed project where Project access is set to Private.

Belle Sebastian is a Scrum Master for the team. She can access the project and confirms that she can view issues and edit them. 

The team needs her to help manage sprints for their board, but she cannot see or access the board. 

What must you do to fix this?"

Answers: 

A. Grant her the Administrator Role for the project 

B. Grant her the Viewers Role for the project 

C. Create a new Custom Role and grant it to her in the project. 

D. Request a change to her product access.

E. Update the Project access to Open

F. Change the project access to Limited.

Explanation:

D. Correct. People in the Members Role can already Manage sprints but in requires product access to Jira Software. Granting her Jira Software product access will fix the problem.

I can't understand how Belle Sebastian is able to access the project and confirm she can view issues and edit them if she does not have Jira Software product access?

When I have user listed as a member in project, but user does not have Jira Software product Access, they can't see or edit the projects either. What am I missing here?  

[Sam Nadarajan · Accepted solution]

It took me a while to understand this concept, but essentially there's a difference between project data and project functionality. 

For Jira Software, yes she has access to the project data and can view some things simply because she has been given project access. However, the ability to manage sprints is specifically a Jira Software feature and thus requires a Jira Software license. Without the Jira Software license, she would not be able to do sprint-related work.

The concept is similar with Jira Service Management, a user might have access to a service project, but without a JSM license a user would not be able to view SLAs, queues, or other JSM-specific functionality, even though the user can view the service project tickets.

In this case it's likely that the user has a user account on the Jira site and also has a license to another Jira product, which is why she's able to see the data.

[Kerli Loopman]

Thanks, this helped. :) 

[Diogo Teles]

Hi, thanks for the reply. What gets me here is the edit permission. How could she edit the issue without product access? This question is twisting my brain.

[Robert Wen_Cprime_]

@Diogo Teles : 

First, let me welcome you to the Atlassian Community!

The reason why product access is not a factor when editing issues comes down to the fact that this is controlled by the Permission Scheme used by the project.

To edit an issue, a person needs to be identified in the Browse Project, and Edit Issue permission on the Permission Scheme either explicitly, or by specific Project role or Group.  If Application Access is added as criteria for those permissions, then yes, Product access would be required.

The question deals specifically with access to Scrum/Kanban boards which is a feature of Jira Software.   Because it's specific to Jira Software, if the user had a JSM license, they wouldn't see the board.

[Diogo Teles]

Thank you for your reply and the welcome :) ! It makes perfect sense. That is interesting, and I had never encountered that particular situation before. It does open up some interesting use cases. I shall explore.

[Robert Wen_Cprime_]

Actually the answer I gave pertains to company-managed projects and not team-managed projects as specified by the original question.  But the gist is the same.

Permissions to work on the project are defined by adding the user to the specific project role.  That is still separate from product access.

[Robert Wen_Cprime_ · Accepted solution]

Here's my wild-ass guess:

She could have access to the project itself through a different Jira product.  That would allow her to see the project and its issues.

Boards are a Jira Software-only feature.  So, if she had JWM or JSM product access, she wouldn't be allowed to see boards.

That's my reasoning for D being the correct answer.

[Kerli Loopman]

Ok, that makes sense. Thank you!

[Kerli Loopman]

Had to test this solution out myself!

I gave my test customer JSM access but not JSW and I added the user as a member in JSW team-managed project. The account sees only issues and filters but not any boards and other JSW stuff.

That's good to know! 

[Diogo Teles]

Hi all,

Lots of good answers already (thank you!). I thought I'd add more since I have been testing this.

If a user has Site Access and at least one of the following Product Accesses:

• Jira Software
• Jira Service Management
• Jira Product Discovery

Then they can perform all actions under all permissions

• except for Administer Projects and Product-Specific activities (e.g. using boards for JS or looking at queues and creating external comments on JFM),
• and as long as the Permission scheme allows it (e.g. granting permission to any logged-in user) or, in the case of Team-Managed projects, they are added to a role (in that case, actions allowed are defined by the role).

From the user end, the look and feel are the same as giving the "Public" permission to "Browse projects" and "Edit Issues" (and others in addition if needed) and looking at an issue from an incognito browser window.

Out of curiosity, I tried giving a user Site access and only Confluence access. That does not work. 

[Tauwa]

This question pushes you to think out of the box.

[Valerie Knapp]

Hi all,

I am also interested in the answer to this question because it seems out-of-date to the current state of team-managed projects:

Where you can add a Sprint / Board / Backlog.

What do y'all think?

[Robert Wen_Cprime_]

I think this might be a verification of the answer we came up with.  Are you sure you have Jira Software product access?

[Jacquelyn Coopman]

@Kerli Loopman I think this is where the Team Managed projects vs Organization managed projects come into play.  When creating a new project that is something Jira ask which way you want to set it up.  As the Jira admin at my company we try to make sure all projects are Org managed so that all our standards are across our projects and this isn't an issue as much.   

Knowing that piece is why you would need to grant them access to the product b/c of the set up.  At first reading that question I would have came to the same conclusion but I realized now and remembered the "Team managed" project piece would come into play, not all users in an org managed project would have access to it unless they were granted access in the Team managed project. 

However I'm not an expert, I just fly by the seat of my pants, figure it out as I go Admin, so anyone else can correct me if I'm wrong.

[Kerli Loopman]

I tested it out and gave my test user JSM access but not JSW access. It really doesn't matter if it is team-managed or company-managed project, the user sees all of the JSW projects, where I added it as a member. Can't access boards or other JSW stuff, but still sees issues & filters in project and can edit them because JSM access. 

[Aaron Geister]

@Kerli Loopman I love this question and it had me for a moment. This would be awesome for study buddy. 

It will always go back to License or Product access.

Example that really will prove this is JSM. 
I usually create a development role so that we can show dev teams issues we get on the Help Desk. This allows them to see issues in the JSW issue view since they are license for Jira in the ORG. What it won't do is allow them to be assigned to JSM issues or comment to the customer. It will only allow them to make internal comments and it will omit SLA's in their view. But it does allow them to collaborate on JSM issue through the JSW issue view. 

Thanks for bringing this up as this is so helpful to use for study material. Awesomeness!