I need the ability to distribute the administration of groups. This way those admins would have control over adding/removing users from their group without having to be a JIRA/Confluence/Crowd admin. This would be similar to how Jira allows project admins to place users into roles for their project.

Hi Dave,

Just to clear things up - Crowd is definitely not going away from our product set. For a small team, Crowd represents an unnecessary barrier to adoption. We've worked to ensure that teams of under 500 users don't need Crowd.

However, Crowd still represents an extremely important part of our product set for larger and more complex installations, for example if you have a large number of users, or multiple instances of JIRA or Confluence.

Currently Atlassian has no plans to enhance roles in any of our applications, which is why we've updated the issue with the current statement.

We've figured bad news is better than no news.

Regards,
Eugene

I have to say I'm confused more than anything. It looks like most of Crowd is being implemented directly in Jira and soon the other Atlassian products (beyond just Confluence) will be able to leverage Jira for authentication. Despite statements to the contrary, this leads me to speculate that Crowd might be going away at some point. Will other applications will be able to leverage the roles defined in Jira? Maybe this is the reason crowd-based roles are now marked as "won't fix"? I think a good solid statement of direction would help.

Eugene,

I think the deafening silence in response to the exciting updates is because everyone that had high hopes for the issue and contributed strong time and energy to helping make Crowd something really competitive. Instead, they've been given a wet noodle in return for their efforts, years later than anyone had ever thought it would take to implement them.

Sorry for the splash of cold water back at you, but I'm just sayin. There's nothing exciting to see here, and if anything, people are doing you a favor by not commenting on the decision.

Brian

Hi everyone,

Just letting you know that we've updated the current Atlassian status in the description of this issue, and you should go check it out!

Eugene Mak
Atlassian Product Management

Hi Brian,

We're at the stage of removing the existing Roles implementation, primarily because they're not actually roles - they're just groups with different names.

I can say that we won't be focusing on this in the next 6 months. We'll be working on a few other things, including sorting out event updates for client applications.

Cheers,
Dave.

How's progress on this? I've seen mention that "roles are deprecated in Crowd" in more recent versions.

These are the primary distinctions I think are necessary between groups and roles:

1. Roles are scoped per application. I think this is necessary, b/c it avoids namespace conflicts, and allows cleaner group naming. For example, you don't have to create a group "jira_administrators" - you can just have an "administrators" role within the "Jira" application. Each application defines the roles it uses, and then users and groups are assigned to each of the application roles.
   • Would be great to provide a standard format for an application to specify the roles that it uses. For example, an XML schema, which could be imported into Crowd when defining a new application, or updating the application configuration within Crowd.
2. Managing application role membership can be distinct from managing group membership. For example, application administrators could be customer account managers, whereas group membership may be more of an operations thing.

I'd like to be able to assign limited authority to other users. For example, allow anyone in the "hr-admin" group to control group membership ONLY in the groups "benefits" and "payroll".

I'd like to be able to manage more than the basic 'username, displayname, password' type attributes of my LDAP entries (ie., postal address, phone numbers, photo). Ideally, the ability to edit these attributes should be restricted based on roles. For example, a user should be able to update his contact info, but only members of "hr-admin" should be able to change his title, manager, etc..

We're using crowd to tie Google apps to our LDAP directory. If the user has forgotten their password, the Crowd self service solution is useless. I can see how this is useful for applications where an external user has an email account not tied to Crowd authentication, but when the two are tied together, sending a new password to the email account that the user cannot access is less the useless. Perhaps an option to reset based on user specified personal questions/answers.

My $0.02: Prior to installing Crowd, I had assumed it had more directory management functionality. Ideally I'd like to see this expanded (ie., modifying additional LDAP attributes for users), and roles used to delegate edit authority with finer granularity than is currently offered. At present, Crowd seems to treat everyone as either an admin, or not. There seems to be no middle ground.