Security

(public)

User Story

An admin should be able to edit the user data, including roles and permissions, for any user. This page will look different than if they edit their own account.
Ways to Instance Page:
1. Click on "edit" link within a row entry in the user management pane
Details:
* Each of the name, email address and passwords fields should be populated to
either the logged-in user's account information (from ways-to-instance #1) or
the selected user's account information (from ways-to-instance #2).
* Confirm password is required if the password field is changed.

API list for this feature?
----------------
/companies/ GET
/companies/{id} GET
/users/ GET POST
/users/current/ GET ?? Not sure about this one for admin user editor
/users/permissions/ GET
/users/permissions/{id}/ GET
/users/roles/ GET
/users/roles/{id}/ GET
/users/roles/{id}/permissions/ GET
/users/roles/{id}/permissions/{permissionId} GET
/users/{id}/ GET PUT
/users/{id}/activate/ PUT
/users/{id}/deactivate/ PUT
/users/{id}/emailchange/{newemail}/ PUT
/users/{id}/emailconfirm/ PUT
/users/{id}/passwordchange/{newpassword}/ PUT
/users/{id}/permissions/ GET
/users/{id}/roles/ GET PUT
/users/{id}/roles/{roleId} DELETE POST

(In reply to comment #1)
> /companies/ GET
> /companies/{id} GET
In the current TCM (and as far as I know up through 1.0) we're doing single-company-only per installation of the TCM. What this means is that the TCM UI configuration requires you to specify a company ID, and pretty much everything will require the /companies/{id} GET, and nothing will require the /companies/ GET. So I think you can just assume that and leave these out of the lists entirely.
> /users/ GET POST
Technically this one will be required for the admin users _list_ screen, but probably not for the individual user editing screen.
> /users/current/ GET ?? Not sure about this one for admin user editor
Again, this is something that pretty much every single page you load uses (to get info on the currently logged in user), so it should definitely be tested but can probably be left out of API call lists for individual features.
> /users/permissions/ GET
> /users/permissions/{id}/ GET
As I think about it, a user-editing screen probably won't deal in permissions directly. Permissions are always assigned to roles, and the user-edit screen will just list roles that you can give the user, it won't refer to individual permissions. So these can be left out, I think.
> /users/roles/ GET
> /users/roles/{id}/ GET
> /users/roles/{id}/permissions/ GET
> /users/roles/{id}/permissions/{permissionId} GET
Again, these last two are probably not needed on this screen.
> /users/{id}/ GET PUT
> /users/{id}/activate/ PUT
> /users/{id}/deactivate/ PUT
> /users/{id}/emailchange/{newemail}/ PUT
> /users/{id}/emailconfirm/ PUT
> /users/{id}/passwordchange/{newpassword}/ PUT
> /users/{id}/permissions/ GET
> /users/{id}/roles/ GET PUT
> /users/{id}/roles/{roleId} DELETE POST
Looks good!