Display issues from various jira projects without permissions restrictions

[VINCENT DUPONT]

Hello, 

I would like to let my project managers share some issues from their projects with the other project managers. For example all "put to production" events (with date). (cf release calendar)

This is easy to do for one project individually: create a filter on the projet (for example based on a Label or issuetype) and display the result of the filter in a Confluence Calendar.

But when having many projects with various users and permissions restricting access to the issues, how can I merge information from various projects in one result?

I've guessed these solutions but none seem perfect:

1. add all project managers into a group, add this group to all projects with a "Read only" permission. But then all projects are always visibles, anytime. This will show the Projects, issues, Labels, Versions, etc from all projects. that is annoying

2.create a dedicated project and ask project managers to create a specific issue in it describing each event. This is duplicate work (although this would be a better way of managing Production Requests, but anyway...)

3. use automation to duplicate all target issues from all projects into a new (unique) project where every project manager can read. Then we have to sync all changes, status update etc. It seems technically complex

what is your proposal/idea?

thank you very much
Vincent

[Abyyba]

Hello @VINCENT DUPONT ,

While it would be helpful to know the specifics of your Jira setup, here's a general approach you can take to solve this.

Underestanding the Situation

• You have two projects: "Developers" (DEV) and "Support" (SUP)
• You want tasks for "Managers > DEV" (Deployed status) to be visible to "Managers > SUP" (In production status)

Let's break down the necessary permissions, starting form the broadset to the most specific:

1. Global Permissions: Browse users and groups: Both sets of managers need this to see the select users/groups in Jira.
2. Project Permissions (Permissions Scheme): Browse Projects: Both sets of managers needs this to see the projects and thjeir issues.
   
   

Key Questions:

• Do both projects (DEV and SUP) share the same permissions scheme? This impacts how you'll adjust permissions.
• What level of access do you have in Jira? This determines which options are available to you (e.g., modify schemes, creating groups).

Assuming both projects share the same permission scheme, here are a few approaches:

• Groups: If this is a one-off situation, creating a new group and adding both sets of managers to it might be sufficient. This depends of your Jira permissions.
• Project Roles: If you have permissions, you can create a common project role for both sets of managers and grant it the "Browse Projects" permission in the scheme.

Now that both sets of managers can see the projects, let's filter which task they see, also taking into account the rest of the team, depending on the assignment of these managers, they may or may not share with the members of their respective teams.

• Filters and Boards: Create a filter that combines issues from both projects, filtering by issue type and status (Deployed and In Production). Then, create a board with this filter and share it only with the managers.
• Issue Security Scheme: If you need stricter control. Assign a security level (e.g., "department") to issues in each project. This way, managers from one department won't see the other department's issues unless the issue security level is adjusted accordingly.

Issue security schemes can help you fine-tune who sees what. It is good practice when granting cross-project access, be mindful of restricting visibility to sensitive information.

I hope this has been helpful and given you some ideas on how to approach this using the various tools available in Jira.

Feel free to ask whenever you need if you have any further questions or need more specific guidance tailored to your Jira setup!

We are here to help!

Regards,
Sergio G.

[VINCENT DUPONT]

Hello @Abyyba 

thanks for your answer
I'm full admin of the Jira instance.

I can certainly provide the managers an access to all projects, but this is something I would like to avoid. Because in this case the managers receive plently of information that will disturb them while using jira (visibility of all projects make searching and using Jira more difficult on a daily basis)

Issue Security Scheme could be a good proposal. It seems a bit complex for the daily use inside the developer teams, however. Maybe I need to analyse this more deeply. Maybe I could set a 'default' permission to project team only and a 'public' permission for the general broadcast needs

Vincent

[Abyyba]

Hi @VINCENT DUPONT ,

I understand your perspective. In fact, this was one of my initial challenges with Jira. However, having worked extensively with Jira for years, I can assure you that the visual information becomes manageable over time. Additionally, there are several ways to reduce visual clutter.

Jira has improved significantly over the years, and I'm confident it will continue to do so. While the visual aspect can be overwhelming for new users, it becomes less noticeable with experience.

I've taken this opportunity to submit feedback to Atlassian regarding this issue. I believe that separating the "Browse projects" permission into two, with a new one allowing users to only "Browse Issues in Project," could be beneficial. This would make the "Issue security scheme" a stricter control for sensitive information.

I have confidence that Atlassian will find a solution to enhance this experience, whether it be this suggestion or another. I've witnessed their products improve consistently over the years.

In the meantime, I recommend you seriously consider "issue security schemes." Even with project access, users can utilize "starred projects" to highlight frequently accessed projects and "omit" the rest. Additionally, notification controls can be helpful.

I hope this helps you find a suitable solution for now.

Regards,
Sergio G.
Abyyba Team

[Dick]

You can have a new issuetype that is only used in a single project M (where only the members of a special group have rights to see/edit).

A good example would be the issuetype:      Manager Info

You can link these Manager Info tickets to tickets of other projects X, ie. use the epic link field of the Manager Info ticket to link it to an epic of Project X.

Subsequently, you can use the backlog to access the parent issues with a click.

[VINCENT DUPONT]

Thanks @Dick .
If I understand well your proposal, members of project M still need to have access to the Project X (and all other projects). 

[Dick]

Yes, without that access, they cannot see the issues in those projects. So that's needed to "tag" them with a Manager Info issue

[Dick]

You can keep the number of issues that the managers see/ need to discuss small because you can filter on the special issue type.