Screens & Screen Schemes based on user or user group?

[Josh Kaplan]

Is is possible to create a screen or screen scheme for a user group?

For example, Product Owners and Developers would have one screen view when creating a story.

Account Managers/Business Owners would have a different screen when creating a story.

Reasons:

* PO's need to enter more information than a biz user. PO's will need to set Acceptance criteria & such.

8 Biz users (creating issues as a help desk function) shouldnt worry about Acceptance criteria and such. We just want them to provide a summary, description and maybe attachment.

[Nic Brough -Adaptavist-]

No. Schemes are by project.

It's very difficult to manage a project when people see different sets of information, although it's very handy to be able to let different people enter different pieces of information.

It sounds like you either need different issue types for each type of entry, or maybe you should create a workflow that only lets the business users create and modify and then lets POs enter more data later.

[Josh Kaplan]

Yeah we though about different issue types for them, however since we can't limit users/groups to specific issue types, it doesnt help much. We'd really like to have business owners access an issue type called "Feature Request", but not be able to access "Story" or "Epic" issue types.

How do others set up Jira for help desk scenarios? We thought it was supposed to work real well, but the lack of granular permissions on these types of issues (issue types and screens) is really prohibiting us from being comfortable using it as an internal help desk. Any advice on how to best set this up so we can segment the requests separately from our regular work, but still have the requests come in to our main development project?

Thanks!

[Nic Brough -Adaptavist-]

Yes, it's only the "see different information" that raises my hackles, because it's divisive and confusing. I'd love to see Jira support a proper model of "person matching A can raise issue types X and Y, but not Z".

There's some approaches I've used in the past. I've seen more clever tricks mentioned in Answers I think, but I'm hazy (e.g. I have a feeling the behaviours plugin might to the issue type limitation. It certainly helps users get the right fields filled...).

• Have a triage project where people place all the issues, and then someone else who understands the team structure and working practices moves the issues into a relevant project (And issue type)
• Redesign of projects, having multiple projects and limiting who can create in each.
• Javascript hacks to limit the issue types in the list for certain users
• Use of validators or fields to prevent the creation of inappropriate issue types

None of these are ideal, what really is needed is the configuration of issue type permissions. Even if it's just the creation option.