Creating a support project

Alyson Reis February 4, 2015

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

6 answers

2 votes
George Lewe (LSY)
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 4, 2015

HI you (you forgot your name smile )

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.

2 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
February 4, 2015

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'"

1 vote
Steffen Stamprath
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 23, 2015

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.

0 votes
David Nickell February 4, 2015

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.

 

0 votes
Dave
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
February 4, 2015

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.

0 votes
Alyson Reis February 4, 2015

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 =)

Suggest an answer

Log in or Sign up to answer