Collaboration over restricted projects

MarcSch

Hi community,

we are internally discussing options to configure our Jira instance to be able to allow sharing tasks over multiple projects and I'm interested in your opinions.

Background

• Multiple JSM projects, generally one for each department. Access for other departments is not allowd.
• Need to share tasks between projects.
• Work must be tracked on both sides.

Example:

• Team A is process owner of process A that is implemented by a Jira workflow.
• Team B has to process a task that is part of process A.
  • Team A starts process A (tasks 1, 2, 3), Team B receives a task (task 4), after finishing Team A finalizes process (task 5, task 6).

Ideas:

• Work with security levels:
  • Team B gets access to Team A's project but just can see tickets with a specific security level.
  • Not preferred as there might be multiple correlations in both directions (or more as more teams share processes).
• Work with portal view:
  • Team A is process owner and task 4 can be viewd and be done by Team B as customer in the portal view. Comments and information can be shared.
  • Works in another instance, but the task is not shown on any report (or queue/board) of Team B and cannot be tracked therefore.
• Work with multiple issues:
  • An issue is created in Team B's project.
  • Can be tracked but there is not Jira issue that can be seen by both so now collaboration (comments etc.) is possible.
    • Could be done through workarounds as automations that clone comments. But much technical effort.

Do you have any other ideas what could be a practical solution?

Matthias Gaiser _K15t_

Hey @MarcSch

that's an interesting scenario which you describe. I'll add some of my thoughts to your ideas to develop them further:

1. Work with security levels
   If you go that path, you could also think about such a setup:
   • Create a custom (multi-)group picker field which stores which groups should see a ticket
   • Setup a security scheme with one security level and add as members the Team A as well as the group picker field configured before.
   • With this setup you can simply add a group to the multi picker field and they'd be able to view this ticket.
2. Work with portal view
   This approach somehow works, but I'd discourage it because it mixes customers and departments.
3. Work with multiple issues
   That's the clearest option to actually separate concerns, e.g. Team B doesn't need to know about the tasks 1,2,3. It requires some effort to setup an automation or a sync tool or similar, but depending on your requirements it can also be quite simple.
   • I'd enable some comment sync, a simple Jira automation could do the trick to copy every comment from one issue to the other.
   • I'd also add some automation based on the status, so if Team B is finished that the ticket of Team A gets updated with a comment/status change, etc.
   • Instead of automation, you could also use an issue sync app and configure it accordingly so that it synchronizes the ticket to Team B as soon as it matches some condition.

Please note that with the first solution, you only have the option to share the whole ticket or nothing. This gets more selective if you setup an automation or use another app to exchange exactly what you need/want.

I hope my thoughts help a bit in finding a solution.

Cheers,
Matthias.

PS: Please note that I'm part of the team behind Backbone Issue Sync. If you want to follow the path to use an issue sync app, we're happy to guide you in the process. Let us know via help@k15t.com.