It appears that there are many feature requests bundled up in this single issue!

Crowd 1.4 will include a basic user console which will allow users to:

• Edit their details (name, email, password)
• View the groups and roles they are a member of
• View the applications they are allowed to authenticate with

The user console will be accessible to users that have authentication access to the "crowd" application. The current Crowd Admin Console will only be viewable to users that are in the "crowd-administrators" group.

In addition, there are separate JIRA issues for related features:

• CWD-410 - User console registration
• CWD-925 - User console skinning / look and feel customisation
• CWD-926 - Viewing and editing custom attributes via the user console
• CWD-927 - Group/role/application access request via the user console
• CWD-766 - Integrate OpenID profiles with the Crowd user console

Please vote for the features that are important to you and add comments so we can take your specific requirements into consideration.

I agree with Preston on this one, our users need a central user management console, not the ability to manage security in whichever application (Jira/Crowd/Forums) they happen to be in at the time. Currently our user/group management is a very complex because each application manages security in a different way. Crowd has started to show how this could be made uniform but only five people out of 5000 in our organization can use Crowd. We have around six main Intranet applications and more on the way and they each use a different user/management arrangement. Its nearly too difficult for our dedicated IT helpdesk to work with let alone delegating to users. Here is my ideal scenario.

We would decouple group/role management from our applications where possible. It seems to me the only way to really do this well is for our users to have a personal management console that shows them all the groups/roles they have access to. And potentially all the groups they could join. Ideally if there was someway for them to request to join a group and have that request approved that would be great as well. It would be nice if they could see the impact of joining a group.. ie. When you join the "Womens Rights Activists in Brazil" group you get access to "Confluence Human Rights in Brazil space" and "Jira Womens Rights Project" through rules or nesting. If you happen to have the role "Womens Rights Activists in Brazil group manager" then you can approve group requests and add people to the group. All this would be a thin Crowd-like layer on top of the directory. Some skinning would be nice of course but is not the most important thing for us.

This type of functionality is commonly available in a given application but by moving it down to the directory layer these security structures can be shared between applications. I see much of this functionality as being end-user extensions to the directory centralization functions that Crowd provides to administrators.

Even with just a rudimentary UI that let you choose your applications, supporting public signup would be a good intermediate step.

I integrate Crowd with 4 different user-accessible applications. When a user signs up on ANY ONE of these applications, I want them to get the same set of base group privileges.

Personally, I would rather disable user management (which looks, feels and acts differently from app to app) and have instead a central user management console. Then just change the signup and change password links to load the Crowd user self-service screen - which no matter what has the same look and feel, and same fields you can modify in the same format (some have one 'name' field, some 'first name', 'last name', some allow/support extra fields, some don't, etc).

The main problem with admin via. JIRA is I am using crowd even for things like Jive forums. Now, I have to tell a user to sign up on JIRA before they can use the forums - this is quite odd. A similar thing is true for people who want to use my Confluence, they now have to go to a different app (which they may never user - especially if they just want to comment on confluence pages). The crowd self-service screen would only have that purpose, so having ALL apps direct you to that common screen makes sense. Plus I don't have to setup a 'default groups' list for newly created users in each of 4 applications, depending on which app created the user.

It also makes more sense, from the context of multiple applications to do group/role management from crowd (as it is done now) anyway. Though from a users perspective, this doesn't matter, from an admin's perspective, it gets confusing if you can modify these kinds of settings that affect OTHER applications from within an application that is more or less unrelated (but linked). For example, why should I be able to add a user to confluence-users from JIRA? I can understand from crowd, but it doesn't make sense that a JIRA admin can now affect confluence users (not to mention things like having subversion integration, which I do. LAST thing I want is a JIRA admin to grant source repository write access!).

I would agree with Sam. I'd rather see Crowd be able to integrate with the password change functionality already provided by Jira and Confluence. If it were a set of APIs added to the Crowd integration JAR, other vendors could use it as well.

I'm proposing this integration under the assumption that it would be simpler than creating these additional portals for users. But if its simpler to make a simple portal because less simultaneous releases are required, I would go for that. Not being able to change one's password is a 'very annoying feature' for most users...

I have created the JIRA-integration issue as JRA-12946. That feature, and a service station in Crowd, would make integration with JIRA and other applications much more seamless.

Now that Crowd has gained the feature to use pre-existing passwords for JIRA, we are re-investigating backing our JIRA by Crowd (and also using it for Bamboo, FishEye/Crucible, and further on down the line: MediaWiki, vBulletin, and some blogs...). In order for the integration to work, though, Crowd absolutely needs a (skinnable) self-service console that each user can hit to update their information. This includes email address, name, password, and any other attributes that may have been added (that are used by the various applications).

In addition, it would be very nice if JIRA integration had some kind of "enable external user management" that didn't remove the 'create user', 'reset/update password', and other options. This is a stretch from the initial issue, though, so I'll create another issue for this.

Yes, this is also something we have been talking about, ie the ability to have the self service console look like the application that the user is associated with.

However, what happens when you are associated to many applications. which one do you choose? Do you allow the user to see that they are associated to many applications (JIRA, Confluence, Bamboo, etc ...).

When you say separate application, do you mean a separate context? Personally I would prefer to not have this. We already have issues with trying to offer our users a WAR release of Crowd, and I think if we go breaking up Crowd into more 'applications'/contexts this just makes this even harder.

Please make this console easily customisable in terms of look and feel, either by modifiying css or some other similar means.

Crowd's own console is in our case used only by admins, and doesn't include any UI modifications we've done to Confluence and JIRA.

Could this be a separate application in Crowd?