License Types and Best Practices

By Janessa posted 06-22-2015 17:58

  

The license types available in Jama are Creator, Collaborator, Stakeholder, Test Runner and Reviewer. Each type has different capabilities and allows certain access within the software, therefore allowing the different licenses to complete different jobs.  The figure below demonstrates how these licenses differ from each other on three functional levels: writing, reading, test execution, and reviewing.


See the help guide for a handy overview of the license types and the abilities linked to each.  Please note that the Collaborator licenses are being phased out in preference of a combination of Stakeholder and Test Runner.

Floating vs. Named?

Some of your licenses might fall under the classification of Named or Floating.

Floating License can be assigned to multiple users, however only one user at a time will be able to log into Jama using a Floating License. If all Floating Creator licenses are in use when a user tries to log in, they will be logged in as a Floating Reviewer assuming Floating Reviewer licenses are available (Named Reviewer will not work as a fallback). Otherwise, the user will have to wait until someone logs out of Jama. A user that is downgraded to a float review will not be shown as DENIED ACCESS in this view on the administration license page.
Picture1.png

Named License is assigned to one user and cannot be shared between users. Unlike Floating Licenses, a user with a Named License will always have access to Jama when they log in.

Adding Users to Jama Connect

The most common way to bring a new user into Jama is as an Administrator, under Admin > Users > New User


From here, you will have to manually add the details for the new user, as well as select what license type to give them. If you add a new user this way, it will use one of your licenses.


Users can also be imported via the user import plug-in or synced in when integrating with Atlassian’s Crowd.

Inviting Users into Jama Connect

If you need to allow an outside user to access Jama for their input or to collaborate on a review, there are a few ways available for the user to be invited into Jama: the Collaboration Stream, the Review Center (you must be a Review Moderator)or as an Administrator

Inviting Users through the Collaboration Stream will grant the new user a 30 Day Creator Trial License, which will not take up any of your current available licenses. The added user will not have permissions to any projects within Jama, so you will need to manually provide them appropriate access under Admin > Permissions. It is important to note that the same email may not be used more than once for a 30 Day Creator Trial License, so only new users will be able to use this.





Review Moderators can invite users through the Review Center. Users added this way will be given a Reviewer License. Be sure to have "Allow review moderators to invite new users to Jama by email" enabled under Admin > Review Center Settings. Additionally, you can restrict who can be invited to specific email domains.




Inviting a user this way will take one of your available reviewer licenses, and you will not be able to invite a user into the Review Center if you have no Reviewer licenses available. (A temporary workaround to this would be inviting them through the Collaboration Stream, and then inviting them into the review.)



Self-Registration

Customers using LDAP have an option to enable self-registration. Self-registration is automatic for customer’s using SAML for SSO however the behavior is similar to a Collaboration Stream invitation where the user will have no permissions and be granted a 30 Day Trial license.

Best Practices With Assigning Licenses

Deciding which license type is best for users can be a complex process. The following chart can help determine what type of license a user should be assigned.

conditions.png
When deciding who in your organization should get a Floating or Named license, it is important to consider what each person's role will be in Jama. For those who will be acting as Jama Admins or Project Managers, it is important that they are always able to log in to Jama to perform administrative functions. Issues can arise for Jama Admins and Project Managers who do not have Named Licenses because they can get locked out of Jama if all the Floating licenses are taken up. For this reason, it is a best practice to assign these users Named Creator licenses, thus ensuring they are always able to access your Jama instance.

There is a feature in Jama that will notify the Administrator via email if users are nearing the licensing threshold for the Jama instance. To use this feature, navigate to Admin > License, and select the gear on the top right of the license graph. 




This will open a pop-up menu. From here, you can select what user threshold percentage you'd like for your organization's licenses, as well as if you want to be notified when that threshold is met and who Jama should notify. On the bottom half of the menu, you can select which days this percentage should be calculated. 



#administration #tutorial #administration
14 comments
967 views

Comments

09-16-2016 12:23

Thanks for the confirmation, Janessa!

09-15-2016 21:16

Hi Victor! The self-registration is designed to take the "highest" available license type first. At this time it is not possible to configure this to do otherwise. 

09-15-2016 17:13

Hi Janessa,

We enabled self-registration and when users use this feature to register themselves to Jama, by default the system is assigning them the "Creator" type license.

Is there any way to configure this to assign a different type of license?  Ideally, we'd like to assign the floating license instead.  Otherwise, we'd run out very quickly of the "Creator" license.

Thanks,
victor

05-17-2016 15:57

Ah - thanks. That won't do for us, then, as we need our deactivated users to remain listed in LDAP for reasons of historical audit.

I'm in the midst of writing a Python SOAP API script which cross-checks Jama's active users against LDAP, to flag users who can be deactivated in Jama.

05-17-2016 15:37

I don't think it is; I tested this a few times to be sure, and the only way Jama will deactivate a user when you sync it to LDAP is if the user has been removed from LDAP. 

05-17-2016 13:41

Thanks, Janessa. Can you confirm what would need to be done to a user entry in the LDAP database in order to get Jama to recognize the user as disabled/deactivated?

i.e. Our HR processes typically leave the LDAP entry in the LDAP database, just with a few attributes tweaked, in particular, the entry is added to the "ou=disabled" organization unit, in addition to the "ou=people" the entry was already part of. Is this sufficient?

05-16-2016 21:08

Hi Ryan!

Our method of LDAP-based authentication will prevent that user's credentials from being used to log in to Jama (and other tools) after the user's off-boarding has been processed by HR, but our Jama support team will not necessarily be directly informed of the off-boarding. Does this mean the user's account in Jama will continue to needlessly consume a Named license?

This is correct. When a user is deleted from LDAP, they are not automatically deactivated from Jama (although, they will still not be able to access Jama should they try to login). 

What's the recommended way to handle this? Maybe some periodic script which validates users accounts from LDAP and deactivates any Jama accounts which pertain to a deactivated LDAP account?

The recommended way to handle this would be to sync LDAP with Jama to update the existing Jama users as LDAP users. This would deactivate any user in Jama that was deleted in LDAP. To do this, login to the root menu and select the “System Properties” > “Authentication Properties” tab. Switch to LDAP, and select “Synchronize Now”. 


Please note: you will need to refresh the page to see the updated users, but this will deactivate the deleted LDAP users in Jama, freeing up those licenses. 

If so, does Jama have any existing admin scripts they might be able to provide as a best practice example on how to accomplish this sort of cleanup, or are we on our own?
We do not, mainly because syncing LDAP as shown above should free-up these licenses for you and deactivate the users. 

I hope this helps. Please let me know if you have any other questions!

05-12-2016 13:52

Can you confirm how Named Licenses work when employee turnaround results in an individual leaving the company?

Our method of LDAP-based authentication will prevent that user's credentials from being used to log in to Jama (and other tools) after the user's off-boarding has been processed by HR, but our Jama support team will not necessarily be directly informed of the off-boarding. Does this mean the user's account in Jama will continue to needlessly consume a Named license?

What's the recommended way to handle this? Maybe some periodic script which validates users accounts from LDAP and deactivates any Jama accounts which pertain to a deactivated LDAP account?

If so, does Jama have any existing admin scripts they might be able to provide as a best practice example on how to accomplish this sort of cleanup, or are we on our own?

06-23-2015 20:26

Hello Sebastian!

I'm glad you liked the article. Regarding your question: I don't have this information available, so I have notified Emily, your Account Representative, and she will reach out to you tomorrow with more information!

06-23-2015 05:06

Janessa, thanks for this article. We are still using perpetual floating licenses. That's the only license model that makes sense to us. We have a lot of users that are using JAMA every now and then. If I changed to the enterprise license types, I would have a lot of additional effort to adapt the license assignment.

Is it correct that floating licenses are not available anymore? If I bought new licenses, would existing licenses remain as they are (perpetual floating)?

Best regards,
Sebastian

06-22-2015 19:45

Thanks for reading, Bob!

06-22-2015 19:44

Thank you for pointing this out, Stephen! 

I should also add for our readers that if your Jama instance is on-premises, you can edit the default log out time by logging in as the Root user, under the System Properties tab, Session Timeout (In minutes)

If your Jama instance is hosted and you'd like to change the default logout time, please submit a support ticket and we will be happy to adjust this for you! :)

06-22-2015 18:31

Hi Janessa,

Thanks for a very concise and detailed explanation.

By the way, for those who may are "Jama organization admin-inclined, :-)" note that from the User Guide

"This may sound like a very basic function, but it’s important to remember to log out if you’re a floating user. The Log Out link is located in the upper right of Jama. If you forget to log out the default timeout for the license to be placed back in the pool is 2 hours."

But this in fact can be configured. Some companies change the license timeout to be 30 minutes. I actually know no users who take the trouble of logging out :-)


For those who are "org admin-inclined," you can see additional information on license usage and can actually get a notification when licenses are getting low by clicking on the configuration wheel.

06-22-2015 18:20

Nice job - Thanks!