Create Right: Manage Roles

To sum up - all works:

• POST /api/roles

• PUT /api/roles/ {roleId}

• GET /api/roles/{roleId}

• DELETE /api/roles/ {roleId}

• GET /api/roles

• POST /api/roles
  administrator:

devadmin:

• PUT /api/roles/{roleId}
  administrator:

  Open

devadmin

• GET /api/roles/{roleId}
  administrator:

  Open

devadmin:

• DELETE /api/roles/{roleId}
  administrator:

  Open

devadmin

• there is a new Administrative type of right named USER_ROLES_MANAGE in Reference Data

• the endpoint POST /api/roles and PUT /api/roles/{id} may use the above right in creating Administrative roles

• the PUT, POST & DELETE endpoints (for collection and single resource) check if the User has the given right, returns a 403 if the User doesn't have the right

• the GET endpoint requires the user has this right, or that the token is a service level token. Returns 403 otherwise.

administrator:

devadmin:

• RAML is updated

@Sebastian Brudziński @Josh Zamor The style guide in the service template specifies that names should have a RESOURCE_ACTION pattern, so ROLES_MANAGE. It does not specify a service/component prefix. After some thought on it, I think it is appropriate not to have a service/component prefix, since a right may not necessarily belong to a service (an example is SYSTEM_SETTINGS_MANAGE, to manage system settings for the whole system, not just one service). So in this case, I think ROLES_MANAGE is good. I would prefer to pluralize resources (so ROLES_MANAGE, not ROLE_MANAGE), since the right is to manage roles, not manage just one role.

Good point. @Chongsun Ahn does the guidance cover this? Or did I remember our discussion wrong? @Sebastian Brudziński we will clear this up by tomorrow, we're on holiday here.