It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

Can I change the default usergroup, which is added to new users?

I do not want new users to automatically join jira-users. I'd rather have a separate group. So if new users are created by sending an email to jira (incoming email rule), they should be added to an email group, not jira group, so I can work out something else with them.


3 answers

1 accepted

3 votes
Answer accepted

Hi Jan,

If you can see on the Global Permissions, the user group assigned to the permission called 'Jira Users' is the jira-users it self. What happens is that when you create a new he automatically is assigned to the that group because of that permission, if you put other group the user will assigned to that to.

Basically, every user in that group is able to use jira and every new user is assigned to that group. Change the group assigned and remember to assign all users to that group.

Hope it helps!

Hi Ramiro,

this is clear so far. The thing is, I do NOT want them belonging to the group, which can log in to jira, but a different group instead (license issue etc). If I change the groups configured at Jira Users, I have the same situation, just with different names (which is actually the case, as I have a different structure already).

Thanks, Jan-Hendrik

What I would recommend in that case is to use the jira-users group as the default and do not configure the permissions using this group, or in other way, create a new group, one that is assigned to everyone but it only gives you the permission to get inside Jira (Jira Users Global Permissions), nothing more.

In one way or another you will need to have a default group where everyone belongs so you can use that Global Permission.

This is not exactly true. I can configure manually a user / remove the jira-users group, but leave attached a group which is also attached to a project. So what I can do now is to have that user sending emails to the system, which are added as tasks. I can also edit the tasks with another user, and assign it back to the email-user.

But the user does not and should not log in, so it doesn't have the jira-users group attached. But this is automatically the case of I configure email-in configuration to add new users automatically - which I do not want.


Ok, I believe I missunderstood, so just to clarify you want users that can create tasks by mail but not be able to login?

Yes, Perfect. This is perfectly working already.

The problem is, that if users are created by the email-in configuration, then the group IS added, and I can not configure it not to do so.

You mean the jira-users is added to that new user?

Yes. And I can not configure which group, but it takes automatically the group being attached to the Jira Users settings.

Right... Thanks for trying a lot :-)

I'm sure this can't be changed, every new user must be assigned to any group from the Jira Users permission. Unless if maybe there is a way doing a code modification from the user creation. Can't help there.

One important thing, even the user has the Jira Users permission if it isn't part of any other group or Global Permission or Permission scheme, he will only be able to login, nothing more.

Other tedious way could be to erase the user from the group manually after created... I know, very tedious :/

Good! Hope it works with the API!

True. Just thinking about an API option to do so every few minutes. We'll see. But I can cope with it, if I have to add the users manually once instead of let them create themself via email in. They're not too many anyway.

Remember to post an answer or mark one as correct.

I didn't find a solution, and these don't answer it, what do I do instead? I thought voting up at least has benefit... :-)

Hi Jan,

Have you had a look at the thread at ? It suggests that you might be able to achieve what you want by using the JEMH Plugin (

There's not a complete solution on the thread, but it might give you another avenue of investigation?


Hi Andrew,

I played with JEMH today, and it seems it follows the same concept I did before when doing experiments: The email-address is saved into a custom field. This way, I can not really interact with that user in terms of assigning tasks to the user etc...

It seems my workaround will be:

  • Add users by API, but only with a group related to the project inside jira to give access to the data, not a jira user (numer of seats)
  • So the user is able to email into the system
  • Use the API to manipulate additional data where necessary.

So my old approach with using custom fields is not even needed, as I can use the real users, they just don't have access. The good thing: If they turn out to be a proper user later on, I can just add the jira group, and all relations to old tasks are kept. That's not the case with the custom field, and what JEMH is using.

Thanks anyway!!

Just to follow up, JEMH supports two ways of interacting with non-jira users, it can as you say store incoming email from: address in a custom field, but if you also enable user creation, and set a default group membership other than jira-users, they will have a user account created, but will not count towards seats, in that way you would be able to assign issues if the permissions in the project allowed it, but the user would only be able to interact via email.

Suggest an answer

Log in or Sign up to answer

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you