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?
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:
Let me know what you find
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...
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:
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.
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.
To see this feature in action check out our recent dependencies demo here: https://www.youtube.com/watch?v=eQu5VsUqyZA Keeping on top of your dependencies is a key part of ensuring project success....
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events