Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,300,585
Community Members
 
Community Events
165
Community Groups

Involving customer's developers to projects

Hi everyone.

I'm working as a project manager and deal with cloud migration projects, which involves collaborating with our customers' developers, system admins and testers.

We manage our internal process in a Jira project and collaborate with the client in another project, which require an extra effort.

I've thought about mixing these 2 projects but at the same time keep our internal tasks hidden from the external actors.

Have you ever been in this situation? If so, have you tried any of the above approaches? Any feedback?

 

 

7 comments

Hi @Shams 

You can try to use Issue Security Schemes - those schemes are design to deal with such cases.

Regards,

Piotr

Like # people like this

Sure. I'll have a look and check its convenience. Thank you.

Hi @Shams 

I personally avoid giving access to projects that contain information I don't want anyone with access to be able to see.

Issue security is useful but it relies on everyone setting up issues to understand how it works. Every new issue needs to be defined with which group can access it and if you create a sensitive issue and forget to exclude the right users, they will have access.

It's a pitfall that I'm wary of, I only use it when I am the only one creating issues in the project. You just have to manage it quite carefully.

Like # people like this

@Stuart Capel - London has of'course right but there are some things you can do to minimalize or even avoid any potential risk.

For example you can set "Internal" security level (access only for your internal employees and reporter) as default one and grant project permission "Set issue security" only to internal employees (or even subset of them defined in some internal role/group). In such configuration every new issue will be only visible to internal users and reporter of the this issue and the only one able to change that behaviour will be trusted employees.

You can also configure similiar configuration without using Issue Security Scheme at all and just utylizing Browse projects permission by granting this permission only to internal employees, reporter and group custom field which would be populated with Client employees group by automation rule every time when issue would be created by member of Client group. With such configuration every issue will be visible by internal employee. Additionally if that issue was created by Client representative, it will also be visible by every other Client employee. Internal employee can also make internal issue visible by the Client by populating this group custom field. Does it make any sense? - Maybe I overcomplicated it :)     

Taranjeet Singh Community Leader Aug 03, 2021

As suggested by other members here, use "Issue Security Schemes" and automate the setting of Security Level value after creation of your issues as per your requirements, so that no issue is left without a required Security Level value.

Daniel Ebers Community Leader Aug 04, 2021

I came across configurations like @Piotr Zadrożny _Eyzee_ decribed it - it worked very well.
The basic idea is to have a role for internal employees, one for external employees and let's say one for Members (all project roles).
Internal employees have more permissions (i.e. to browse a project) than external employees - they are only able to browse if put to a custom field like Piotr said (like group custom field, or user picker single - depends on your team's needs).
In case some external exployees are considered needing access to a project fully they are put to Members role (where some internal employees also receive permissions through, in particular those ones who need to interact with issues opened by others, f.e. transitioning, closing, commenting, logging work).

This is a more rigid and general approach which applies mostly to whole instances rather than a specific project - if you only need some internal tasks hidden you alternatively also could consider Issue Security Schemes like mentioned earlier in this thread.
In fact, in the scenario I described above we used a mix of both implementations. They work together like a charm.

Erica Moss Community Manager Aug 06, 2021

@Shams Welcome to the Community!

Like Shams likes this

Comment

Log in or Sign up to comment
TAGS

Community Events

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

Events near you