Freeing unused STASH licenses?

[Johannes Kilian]

A question concerning licensing model of STASH:

As there is some turnover in development teams, certain people do not need their stash licenses anymore (as they changed their position or left).

Having a volume license of STASH: Is it possible to free those licenses - so that those licenses can be reused by other users ?

[cofarrell · Accepted solution]

Hi Johannes,

From your previous question you may have gathered that our licensing is based on permissions. If you want to remove someone's license, you just need to remove all their permissions. I suspect this is probably not as easy as it sounds, because many people have fairly large groups in their directory. If you can remove them from those groups, or use finer-grained groups to control access, you should find their licenses are made available.

Does that help?

Charles

[Johannes Kilian]

Yes and no.

Most of our users login via AD. Those "AD-users" eat up our STASH license pool on their first login - they do not have any explicitly given permissions within stash (they do NOT appear on page http://stash:7990/admin/permissions) - so I cannot revoke their permissions within stash. As a STASH-Admin I do not have permissions to edit our ActiveDirectory.

I already asked a similar question: https://answers.atlassian.com/questions/191749/how-to-get-the-names-of-licensed-users

As an answer I got a workaround for STASH to list the "licensed users" via https://confluence.atlassian.com/display/STASHKB/Determine+the+users+that+currently+occupy+Stash+license+seat.

It's the same problem: AD-users are not listed on http://stash:7990/admin/permissions (unless they are STASH-users) - you have to apply a workaround ...

I think your description only works for users listed on http://stash:7990/admin/permissions - and not for the described case (AD-Users).

[cofarrell]

Hi Johannes,

That's what I feared. The permissions _are_ being granted, but via a group. If you (hypothetically) remove permissions from those AD groups you would find the license count altered.

Of course this doesn't help you in practice, as I suspect you have them assigned to Stash for a reason. Just to confirm - if people are leaving or changing permissions it's not possible to get AD updated to reflect those changes (or at least not immediately)?

The other option might be to create local Stash groups and manually assign known AD users to that instead. This requires you to have the 'Read-only with local groups' setting enabled in your AD configuration.

I'm sorry I can't give you anything more concrete. At this point we would have to change the way we count licensed users, which I would suggest raising a feature request for.

Charles

[Johannes Kilian]

That's what I feared. ;-)

I hardly can make our ActiveDirectory admins updating the AD according to STASH neccesities ...

Creating local stash groups might be an alternative, but then the STASH admins do have to add and grant individual rights to each AD user who wants to do more than reading the repository. That's a work we wanted to keep away from us. We planned to let the project owner grant the rights on repository level. On top-level we don't want to bother with creating prerequisites for this ....Did I get you right here?

So I'm creating a feature request for this ...

I don't think your way count of counting the licensed users has to be changed. As https://confluence.atlassian.com/display/STASHKB/Determine+the+users+that+currently+occupy+Stash+license+seat. shows, all licensed users can be retrieved with a "simple" workaround. The result is a list - all I'm asking for is a possibility for direct manipulation of this list (remove an entry) ...

Edit: Feature Request

[cofarrell]

Hi Johannes,

Fair enough.

One last thing. Just to explain how that plugin works - it's fetching all the groups with permissions in Stash, and then quering _all_ of their members from AD directly. Which is exactly how the license counting works. So manipulating that list is not quite as simple as it might seem because there's nothing actually stored in our DB except for the group permissions. There's no list. :(

Charles

[Johannes Kilian]

Too bad ... ;-(

Hoping for implementation of my feature request. Thanks Charles, for your deeper insights ...