Creating a user with allocated license - connected e-mail is shared

[Anneliese Pretorius]

We want to create a Jira user, understanding that a license will be allocated. However, the e-mail for this user is a shared outlook e-mail. Users on this e-mail are all individual users on Jira as well. 

Will this contravene licensing terms? Will it contravene licensing terms if we add users to the shared e-mail that are not individual Jira users (Note that this "user" does will not have access to Jira and will not be required to post or view any issues?

[Walter Buggenhout · Accepted solution]

Hi @Anneliese Pretorius ,

I am not sure what you mean with contraversing licensing terms. But in short: an account with a unique email address simply counts as 1 unique user, regardless of it being an individual or a shared account.

I am quite sure I am not telling anything spectacular when I say that handing out a license and access to a shared account may pose all kinds of risks and problems to your instance. If it is really granted access to data, people will be able to access these data using that account. And so at the very least you will need to reset the account password every time someone from the group leaves your company. You won't be able to verify who performed certain changes when they were done with the shared account and so on.

I am slightly intrigued by the statement that you want to give this account a license, but no access to anything in Jira. It doesn't make much sense to give it a license then, no? That comes down to saying: hey, you can use the application, but you can't do anything there.

Hope this helps!

[Anneliese Pretorius]

Hi @Walter Buggenhout I need to allocate projects to a 3rd party (in theory only as this "Person" will not have access to Jira) for what is currently not under our control. It does not provide access to anyone. Effectively creating a Dummy user. Our ARM planning becomes impossible to manage with all the projects that are awaiting external feedback, so I need a dummy user to assign these projects to. 

This is the only solution I can think of. If there is another way, please let me know, I am keen to resolve the problem, not attached to the mentioned method.

No external person who does not have access in their own right is linked to the e-mail. 

@Nic Brough -Adaptavist- : If we only have individuals that have access in their own right on Jira, linked to the shared mail, how will this contravene the licensing agreement?

Not arguing, just curious. Hence the question in the first place as I though there may be issues if we provide log-in details for non-interested parties to have access. However, cannot see it being a problem with existing users.

Thank you both for the prompt response!

[Walter Buggenhout]

Hi @Anneliese Pretorius ,

In order to assign a project / an issue to a user, that user will need at least browse project and assignable user permissions on the relevant issue(s). Just granting application access (assigning a license) is not enough to cover your use case.

If your 3rd party does not actually collaborate with you on the tickets, it is not uncommon to either flag them as impeded and use custom fields where you can select the partner they are with. Combined with a practice if regularly following up on those tickets with that partner may help you unlock them. Or if you have a good understanding with your 3rd party, you could discuss synchronising these issues across; as I am quite sure they will have some kind of system in place to mange requests related to yours.

[Nic Brough -Adaptavist-]

Hi Anneliese,

Jira does not use a "licence per user" model.  You do not give a licence to anyone.  The licence is for the server, and simply says "you can have X active users", which are defined as "anyone who can log in".

I very strongly recommend that you do not create shared accounts.  Not only does it breach your licence terms and conditions with Atlassian, it is insecure and illegal in any industry that is regulated by GDPR or SOX (banking for example), because it destroys the ability to audit change.