Control, which epics, stories, tasks etc. can be viewed by which partner

[Dimitrios Madis]

Hello everybody,

I am new to the community. Therefore, please excuse me if I should forget any details :)

Topic: In our corporation we have a special use case, regarding Jira Software projects.
I would appreciate your feedback :)

First of all, let me give you some basic information about the system/applications:
* We run Jira Server
* Version: 7.11.1 (planing on an update next week probably)
* Java version: 1.8.0_102
* Jira Core/Software 7.11.1
* Jira Service Desk 3.14.1

* The server runs on Ubuntu 18.04.1 LTS
* The installation of Service Desk is somewhere else...

* I am global admin in Jira
* I have access to the installation (Core/Software) on Ubuntu
* I do not have access to the installation (Service Desk) on <OS>

Problem: Our corporation works with partners.
These partners should have access to our Jira Software projects (we already have this). However, there will be certain future developments, to which only certain partners should have access to.
The whole thing gets even more complicated, because now we will start introducing epics, stories, etc.

Is it possible to control, which epics, stories, tasks etc. can be viewed by which partner?
Obviously, the corporation does not want to use any addons from the marketplace.

Thank you all in advance :)

PS.: In case you do not understand or misunderstand something because of my language skills, you should know, that english is not my native language. Please do not hesitate to depict something if anything is wrong ;)

[Antoine Berry]

Hi @Dimitrios Madis , 

Welcome to the community ! 

My best advice would be to gather issues tackling each partner business in a distinct project. That way you can simply use the project permissions to control which users have access to the project.

If you still need some filtering, you can use issue security levels. However you will need to manage each issue separately, or use some automation to set the security level (but as far as I know you will need a plug-in for that...).

And do not worry, your english is perfect. :)

Antoine

[Dimitrios Madis]

Hi @Antoine Berry

Thank you for your reply and the warm welcome :)

Unfortunately, creating distinct projects for every partner's business would not work.
I also thought about that, but we would not be able to handle the overhead generated this way.
Furthermore, if two partner's businesses became one i.e. merged, we would need to merge all corresponding projects alike.
If we then had some components, which should be accessible by only one partner within this project, we would encounter the original problem.

I use project permissions to control general access to the project.
Together with groups and project roles, this seems to be the most effective way.

All distinctions in terms of (read only or write) access to epics, stories, tasks etc. have to be controllable within a project.

It sounds like your idea of issue security levels and automation to set these issue security levels seems to be the only way to achieve this level of control.

Do you have a concrete example on how to set up a specific scenario like that? Or did you ever encounter a scenario like this?

With "but as far as I know you will need a plug-in for that..." do you mean an addon from the marketplace?

Thank you very much,
Dimitri

[Antoine Berry]

Hi,

As for the first part, I do not think you would have to merge projects, but instead you would merge the groups of the partners merging. 

However you can only manage view issue permission with Issue security levels. Either you can see it or you can not. So it might not suit your needs. It is quite easy to set-up (I have indeed done it). 

If you need automation, I do not think you can do it out of the box, so an add-on like ScriptRunner would come handy. I would advise to have this add-on anyway, since it is probably the most complete (you can pretty much do anything with it, lots of functionnalities). 

ScriptRunner would also allow you to automate something like : if component = ... then group custom field = ... and map this custom field in the permissions of the project, so solution 1 would work.

Interesting topic anyway. :)

Antoine

[Dimitrios Madis]

Hi Antoine,

It seems like "it might not suit [our] needs" indeed.
For now, I suppose I have to think of something else...

I will definitely research into ScriptRunner, as it is potentially powerful.
Maybe I am able to convince the corporation in the end :)

Thank you very much,
Dimitri