Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Jira Portfolio rights not multi-tenant ready?


I'm currently working on setting up a Jira installation to use for multiple tenants to use (shared instance) and one requirement is that clients should not see each other or even be aware of each other.

So far this works with the basic Jira installation quite well with having one or multiple projects per client and proper rights management but Jira Portfolio is giving me headaches:

No separate create role - The default Portfolio user and Portfolio restricted used combine the edit and create capability. This means that for a user to be able to use Portfolio in any sensible form he will also be granted the right to create new plans. And since the default visibility for new plans is unrestricted user will create new plans out of curiosity, will put in their company name and expose this to all other customers. And this will happen and no amount of training will make this chance go to 0%, which is a big issue.
What I would like to see is that plan creation and usage/edit are separate rights. We set up the Portfolio plans for our clients anyway so having the possibility to limit plan creation to us admins and/or the customers scrum masters would mitigate the client exposure risk.

No "use" rule, just edit - Again, for a normal developer to be able to use a plan (=like changing a release, estimate or assignee) effectively I also have to give them the rights to edit that plan. This is in my opinion completely unnecessary and has led to issues in the past. Instead I would like to have a separate "use" role for users where they are able to change issue details (like fix version, assignee etc) according to their Jira/issue rights and even be able to commit those changes, but not also be able to configure the plan, which should only be reserved to scrum masters and administrative users.

Edit does not include view - If a user has edit rights on the plan but is only in the Portfolio viewer role globally they will not see the plan at all. Only if I give the user also the view rights on the plan will he see the plan at all. This is both cumbersome and unintuitive and edit rights on a plan should include view rights.

No filtering on permission lists - When a user creates a plan and then edits the access permissions of that plan he has full access to the global user and group lists. The available entries are neither limited by the users access rights nor the project access rights the plan is based on. Since we have prefixed our groups with the client names and use user mail adresses as usernames this exposes our full client list to everybody as well as personal information like mail adresses and full names, which is a GDPR issue.

In summary, I think Portfolio global roles need to be reworked to be as multi-tenant ready as Jira itself is, like in the following manner:
- Viewer - (As present) Only able to view plans in read-only mode
- User - Able to see a portfolio plan and interact with the issue on said plan (change fix version, assignee, create new issues through the plan etc). Also able to commit changes to Jira
- Editor - Able to edit the configuration of a plan
- Creator - Able to create new plans

In addition, User list have to be scoped down based on the issue source, for example a project, or use project rules instead of users and groups.

Otherwise I don't see how we could use Portfolio in a multi-tenant instance without running the risk of exposing our client list as users from the clients make inevitable mistakes.

0 answers

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events