Involving customer's developers to projects

[#1]

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?

[Piotr Zadrożny _Eyzee_]

Hi @Shams 

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

Regards,

Piotr

[Shams]

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

[Stuart Capel - London]

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.

[Piotr Zadrożny _Eyzee_]

@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]

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]

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]

@Shams Welcome to the Community!