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.
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!
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).
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.
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 :/
Have you had a look at the thread at https://answers.atlassian.com/questions/26247/jira-as-pure-email-helpdesk-no-account-setup ? It suggests that you might be able to achieve what you want by using the JEMH Plugin (https://marketplace.atlassian.com/plugins/com.javahollic.jira.jemh-ui).
There's not a complete solution on the thread, but it might give you another avenue of investigation?
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:
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.
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.
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