nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

[Portfolio] Changes not saving for specific users?

Tyler Berard_qltqo4

We have multiple people using portfolio. For some reason, most of the users (who are jira admins as well as portfolio admins) cannot save changes.

The review changes button turns blue, the modal pops up, you confirm, the status bar finished and it says changes complete, yet when you refresh portfolio, the review changes button is still blue (with the orange badge).

This is only happening for specific users for some reason. Is this a permissions thing?

Comments

Earl McCutcheon

Hey Tyler,

Portfolio has a few different level of permissions, and then Jira has additional permissions that come into play as well. So first the user needs to meet permission requirements in jira and then portfolio permission checks. From your description this sounds like a jira side permission issue and not the portfolio side permissions.

So to narrow down a permission issue in portfolio I would recomend the following approach to verify but I noted which ones are not likely:

Start at the Portfolio Global permissions, this is the overarching permission set that allows access to plans or to the administrative options to the portfolio application level details can be seen here:
1. A user must be "Portfolio for Jira User" level or higher to create and edit a plan, so from your description the users are at least at this level as they can edit plans across any plan with additional constraints by the Plan level permissions
Next the Plan level permissions the users need editor permissions on the plan level again to edit a plan on a per plan basis
1. As the users can edit the plan but cannot commit this again does not sound like it applies
Next is a high suspect on the list as the Project level permissions,
1. a plan editor can make changes to a plan but the project permissions are required to commit that change back to jira and a user with both editor permission on the plan and Project level permissions is needed to apply that action on the issue
2. Exe if a user does not have edit permissions they cannot update fields of existing issues from portfolio, OR is a user does not have create issue permission they cannot create issues from the plan, OR a user does not have Manage sprint but is trying to add an issue to a sprint from the plan, etc....
3. You can use the "Jira Admin Helper" Permission checker tool to help troubleshoot this one, choose the user, an issue the action is being applied to, and the action being applied and it will tell you wether the user can complete this via the Project permission settings
Next would be workflow level items such as conditions or properties that prevent a user from completing an action as covered in "Advanced workflow configuration"
1. Check the Create issue permission to see if there are any permission related validators such as only users with X permission can execute this permission
2. Check the Workflow properties for a permission based property on both statuses and Transitions. EXE: jira.permission.edit.group.1=some-group-one on a status so that only users in some-group-one can edit an issue in that status

Let me know what you find

Regards,
Earl

Tyler Berard_qltqo4

Thanks, Earl. I've set the people that I need to make these changes to jira-level admins. They all have the same permission level as I do and all of the projects we're using have the same permissions scheme, so it's proving harder to figure this out.

Portfolio global permissions have them all set to admin-level, too. Should I go in manually set each person as a project admin, too, to see if this works? I'm at my wits end here trying to resolve this...

Earl McCutcheon

Hi Tyler,

Thanks for the update, and since the projects all share the same permission scheme, are the permissions set to use project Roles, or are they pointed to groups? As using Project roles in the permission scheme would still allow distinction between actions possible for a user at the project level and add in a per project level permission based on which user is in the project role. The roles just line up what action can be completed as a standard across all projects with the shared scheme delegating the permission allocation to the role.

Check out the "Managing project roles" document for how the configuration is set up, and this is something that should be picked up by the admin helper if you run it against a user. noting something along the lines of:

<USERNAME> is not a member of any of these project roles: Administrators, atlassian-addons-project-access, Developers

You can change this by going to the 'THE PROJECT KEY' project roles and adding <USERNAME> to the missing role(s)

Also if using roles, are the users granted the necessary permissions across all projects on the plan? Because if user1 and user2 only have access to project1 and project 2 respectively, and they each make a change to the plan on their respective project, the commit will attempt to push both the updates from user1 and user2 and since the users only have access to one of the two projects the commit will fail on a permission violation, and must be completed by a user that has the appropriate permission on both projects that require the update.

Per your suggestion, adding in a user to project admin permission directly might help depending on the hangup, but just being admin is not the only thing you have to look at permission wise, but being admin would give that use the ability to add themselves to various permissions to complete actions, it does not give them access to all permissions directly as Admin only grants access to the project administration settings not the other actions in other permissions, as there are scenarios like in a HR project where a Admin should not be able to see the issues by default for privacy concerns in the project, but still have access to configure the project settings for the users of that project.

But thinking about project admin permissions, Something else to look at as well, is the filter used by a board that is linked to the plan. First check that the filter is shared for every project in the filters on the plan, if the filter is not shared with the users that cannot trigger a commit for issues in that filter?

Also a filter can be set up in a manner that is project agnostic and is considered a "Complex Filter" by the board, and in this case the filter would as the system is concerned be able to access infinite possible projects that do not even exist yet, and if a user has every permission for every project they still do not have permission for the future projects and this will break the Manage sprint permissions, requiring a user to have global admin to have access to the future projects and enable manage sprint, Additional details on this scenario can be seen in the HB article:

Users cannot manage a sprint (start, close, etc) despite having the Manage Sprint project permission

The most common offender is a unclosed OR operator so that you can have values returned from any project per the condition after an OR operator.

Let me know what the filters are that you have for the boards linked as issue sources to the plan.

Regards,
Earl

Deshnee

Hi All

We have just upgraded the stack and now users that previously could commit changes on portfolio in their respective buckets cannot do this anymore.

The user created the portfolio and has edit rights to the portfolio, is loaded as a user in the project bucket, the scheme says "users" can edit the issue, but the commited button is still grayed out.