+1 We're currently evaluating Stash and this may be a deciding feature for us. We like the JIRA integration, but deployment keys are critical to our use case, since not having them would bump us to the next licensing tier.

This is great news. I only suggested the "fix version" as a way of communicating its place in queue. Knowing it will be worked on soon works just as well.

Thanks for getting back to the community.

The work on deployment keys will start next week.

Generally, we do not assign a "fix version" until we are certain that a feature will ship in a specific release. For a number of reasons we can not promise specific release dates, versions or time-frames unless we are absolutely sure that we can deliver on our promise.

Artem:

Automated processes need to run somewhere. This is typically a Unix or Windows scheduled job or job in response to a web action in a web application, such as a user clicking a "Build" button (Bamboo!). For the Unix or Windows scheduled job, it is usually something like a crontab entry, where the crontab entry is owned by a "service account" rather than an individual user. So, in all of these cases, the need for this "service account" is wider than just Stash. It must be in the corporate directories so that it can be used as a Unix user.

The automated processes also trigger actions to happen in JIRA and other tools, where we want the action to execute as the "service account" and not as some token user such as the manager. Therefore the user must exist in these other systems as well.

I think the case of using Stash internal directory is perhaps not very "Enterprise".... Although it might still be important usage...

i think it's clear that for security reasons we could create 1 separate user for each repository and give him access only for this repository.
so i don't understand how ldap helps making it easy.
i think, that adding users in external user directory(ldap too) is much more annoying than in Stash internal directory, because you could wait for synchronization or manually sync user directories.

so for me there is not task about license and users count. there is task about convenience and usability.
i'm very tired creating useless users and giving them dummy permissions =(

+1 - We were very disappointed by the lack of deployment keys in Stash.

Just another voice in there that this is not the most important issue facing "Enterprise". As an "Enterprise" customer, we use LDAP, and our LDAP service has "service accounts" registered. So, adding these bogus users is as simple as adding regular users. And, for the higher usage counts instances, the "service account" licensing should be more of a drop in a bucket compared to the most impacting issue.

We also appreciate the recent Stash releases, and the continual and aggressive improvements we see in Stash. Maybe the order of delivery doesn't exactly match our preferred feature list, but +/- a few features, it's been excellent from our perspective.

However, the reason I continue to watch this issue, is because it seems improper that we should pay for licenses for tool accounts. For various other products that I won't name, we have exception processes. Either we just filter our license report to remove the tool accounts, or we officially register a list with the vendor of our tool accounts and they increase our license count to include "number of real users (which we pay for) PLUS number of tool accounts (which we do not pay for)".

Basically it forces us to choose between: A) Accepting that service accounts cost licenses, and just dealing with it, or B) Changing our architecture to avoid the use of service accounts, probably to the detriment of our architecture, in order to save on unnecessary licensing costs.

With one other particular vendor that fought us on exempting our tool accounts, where they questioned that we would really have "50 service accounts" and wanted to interview us to see why, and they asked us "why can't you consolidate to 1 service account?" we had to clearly tell them that they had no idea what they were talking about when it comes to "Enterprise". That is, we have dozens of design teams of varying sizes with hundreds of build processes (many being legacy), and to support this scale we need to make use of delegation. We allow our product teams to create their own service accounts, and we give their service accounts access to the parts of the tools that their product team requires access to. That is, team A on one side of the corporation, should not be able to commit to a repository owned by team B on the other side of the corporation. Consolidation would be a stupid compromise as it would either invalidate security or it would invalidate our delegation model. The vendor finally yielded and gave us 50 free licenses to cover our service accounts.

So mostly I see this issue about "fair pay". That is, we expect to pay for a good product that meets our requirements. However, we don't expect to pay double for some users, just because we have a "best practice" of asking our design teams to never run tools as their own accounts, but to always request a service account for their department, such that if they leave the company, the business process doesn't suddenly fail when their personal LDAP account is disabled...

I don't think its fair to say this is more important than the other features that were delivered in the last 2 releases – they were certainly important to my company.

That said, we too are creating dummy users or having to make them public (assuming the data isn't sensitive enough you CAN) which is less than ideal.

I would be nice if they moved it off the backlog and at least took a swag at a "fix version"

+1

when we will see this in roadmap?
it's more important for companies then 2 last releases of Stash
We are very tired of making dummy users and configuring permissions for them

We are almost ready to move to gitlab so...