Assign Issue to User without project access

[Felix Rucker]

Hi, 

we are a small company and recently started to work with jira. We are using next-gen projects, mainly because of the roadmap feature.

We want to assign certain issues to users which are not members of the specific project. This is possible in classical projects using permission schemes, I think. The next-gen projects now feature a way to configure roles within a project, which brings some of the permission scheme features through the back door. However, I can not restrict board access in the role definition which means, every user which is added to a project (regardless of their role) can access the board and view all issues (which is undesired). 

Is there any workaround? 

Thanks for any idea. 

Cheers, Felix

[J. Caldwell · Accepted solution]

Scrum. Your Epic would be "Jira as a Support Application", stories would be the larger group of items (e.g. Environment Standup) with specific tasks under that story of "get hardware", get db, configure, etc...

Make sense?

[Jeff Wright]

Yeah, it makes sense. I've already built up a project plan using a checklist that's more or less timeline-based. I think the Atlassian stuff is user-friendly enough to where I'll be able to figure it out as I go along. Thanks.

[J. Caldwell]

Jira. Get the Greenhopper plugin. Make sure you have a setup for you ticket support base projects that is reusible and doesn't change much. Tracking a project roll out and communicating out the status will be easier with Greenhopper and managing it inside there as well.

[Jeff Wright]

Thank you for your response...I will take a look at Greenhopper. (Although I thought Greenhopper was only for Agile projects.) Could you elaborate a little bit on "make sure you have a setup for you ticket support base projects that isreusible and doesn't change much"? I'm not sure exactly what you mean by that.

[J. Caldwell]

Greenhopper can me blended to work for your needs. Most of the teams that I support that use it, us it as a blended method where workflow plays heavily on the project management side of things.

Support is support. Most of the stuff that will be going into support projects is probably going to be largely the same definition. If you allow every project doing support to heavily customize, you will either have to make a bunch of folks Admins who shouldn't be, or you are going to have a high overhead. Think of defining a common "template" for a project, so each project is 80% the same. 10% of the customization could be done via context of project for Jira. The last 10% is genuine need for difference, but it shouldn't be common.

For example, in a support instance of Jira we spun up it went from 5 projects for 5 different teams up to now 20. If we didn't define a project template and what is "common", we would be repeating the same discovery over and over again.

[Jeff Wright]

OK, got Greenhopper as an eval. Would you recommend starting as a Scrum or Kanban project for this particular situation? It's mostly tasks and milestone tracking that I'm going to be doing here.