Creating a support project

[Alyson Reis]

I've spent the last few days creating and configuring a support project in my JIRA, seen that this is the first time I have to create/configure a project (issue types, workflows, screens, roles, etc) from scratch I must say I'm spinning my wheels to get everything working (I looked into the How Atlassian Uses JIRA for Support page, but it's quite outdated).

Right now, my problem is the following:

I'm using my company JIRA to host the support project which my customer will have to access in order to create support issues. However, there are tons of other projects/issues which my customer obviously shouldn't have visibility. That being the case I have created an internal user and a specific group for this user, I also removed this newly created user from the jira-users group (reason is because users in this default group will have access to a lot of other internal projects). Once I remove the user from jira-users I can no longer log in as JIRA will only allow users from the jira-users group to log in, and that is my current issue... Any help or suggestion of an alternative configuration will be appreciated.

Thanks

[George Lewe (LSY)]

HI you (you forgot your name )

the jira-users groups is essential for being able to log in. It also is the group that JIRA uses to count the users against your license. Having that said, you need to put all users you want to be able to log in into that group. That also means, if I understand you correctly, that you have to remove the group jira-users from all permissions (groups and roles). Use that group only to control access to JIRA, nothing else.

After that you should be fine to create a user group for your customer project. Add all customer accounts to the group jira-users (so that they can log in) and to the project group. Use that project group in your permission scheme of the project.

We have a similar set up with about 800 projects. We maintain user groups for each of those projects to manage permissions. We do not use jira-users in any of them.

[Nic Brough -Adaptavist-]

Yes, I'm afraid you've run into the inherited default group problem.

JIRA ships with jira-users as the group that defines "can log in".  That's fine on its own, but they then go on to use this group by default as "can use project".  Again, that's fine, until the first time you realise you need a less visible project.

At this point, you probably want to un-pick the defaults.  Remove jira-users from all the project roles for "private" project, replacing it with other groups or users as needed so that people can still get into their projects.  Think about removing it from the default role so that new projects don't inherit it too.

In general, my usual line is "don't use jira-users at all, except for 'can log in', and maybe 'browse users', 'bulk edit' and when you really do have a completely open project like 'JIRA support'"

[Steffen Stamprath]

I can recommend the following plugin for Support: Issue Viewer:
https://marketplace.atlassian.com/plugins/aptis.plugins.issueViewer

With this plugin, you can give each customer a view of a issue, but it only needs one support user.

[David Nickell]

One other complexity that you may want to consider – we have more than one customer in our support project and they're not allowed to see each other's issues.  So our customers are in three groups....  jira-users, our-customer, and customer-X.  The customer-X group further restricts the visibility of an issue using Security Levels.   if you're going to have multiple customers, you may want to consider using 3 groups per user.

[Dave]

What Nic said is probably the best way to go about this if you're doing it from scratch, but in your case it's helpful to understand that any group that has the JIRA User Global Permission will be given Application Access, and consequently a license.  So, you can add this new group to that permission, which will allow them to login, but not provide all of the permissions that come with using the jira-users group.

[Alyson Reis]

Thank you, I was afraid that would be the only way, it will be quite painful to go over every single project and apply new group permissions. At least I have the answer I needed. Thanks!

Alyson =)