As an Authenticated user, I want to be able to initiate update of user accounts on the platform so that I can correct user information

[adamamyl]

API

Data Collection service should expose the following HTTP REST API to add update user account:

PUT https://<hostUrl>/Users{/Organisation/<organisationId>}/User/<userId> <JSON body defining metadata for user>

The body of the request should contain the following properties:

• Email - string, required, max 255 characters, must be a well formatted e-mail address
• First Name - string, required, max 255 characters
• Last Name - string, required, max 255 characters
• Display Name - string, required, max 255 characters
• About - string, optional, max 4000 characters

The description is expected to be in markdown format (no validation is required - every text is a valid markdown)

The API will be called only by authenticated users:

• SuperAdmins can update users in any organisation and users without any organisation
• Authenticated users can only update their own account

The successful response will contain a unique request ID.

Scenarios

Successful submission

Given:

• I have suitable access rights

• the request is well formed,

  When I send a user update request, Then:

• I receive a unique RequestID as JSON in the HTTP response with an HTTP Status of 200

  Authenticated User trying to update an account other than their own

Given:

• I am a Authenticated user who is not a SuperAdmin
• I want to update any user account other than mine
• the request is well formed,

When I send a user update request, Then:

• I receive an error response (HTTP status code 403 - Forbidden) with error details.

  Standard HTTP REST API behaviour

The API follows standard HTTP REST APIs behaviour defined in NFR #891.

Business rules:

1. It is not possible to change user's user name (login name).
2. User's password cannot be changed by using this API.

   Accept Criteria

   • [ ] As a SuperAdmin I can update the metadata of any user in the platform
   • [ ] As an authenticated user I can update my own user account (except for my organisationId)

[adamamyl]

This would involve splitting the existing form for name, into two blocks; firstname and lastname. See the 'weep' note in #53.

[seanh]

Ok, what I suggest for this is that we integrate it into the user profile editing page in CKAN. I think it's already the case in CKAN that normal users can only update their own accounts, while sysadmins can update any user's account (if they type the edit URL for that user's account profile into their location bar manually).

Does receiving a 200 OK and a request ID from The Platform mean the user details have been updated on The Platform? What is the request ID for?

Agree that we'll need to customize the user edit form and split fullname into first name and last name, which is a real shame (just pointless make-work).

[adamamyl]

Does receiving a 200 OK and a request ID from The Platform mean the user details have been updated on The Platform? What is the request ID for?

Yes, a 200 means the request (should have) worked. The request ID is largely used for the audit logs in the EC.

Agree that we'll need to customize the user edit form and split fullname into first name and last name, which is a real shame (just pointless make-work).

Indeed. It's also contrary to the Government Service Design Manual, but unfortunately, it's what is required of us.

I can only see a need to split names on the

• register, and
• update

forms.

In the rest of cases, given name should be fine to use. Quite how you want to implement that, I'll leave to you.

[adamamyl]

Ok, what I suggest for this is that we integrate it into the user profile editing page in CKAN.

Agree.

[seanh]

The API follows standard HTTP REST APIs behaviour defined in NFR #891.

What is NFR #891?

[Nithyavasudevan]

@seanh All publicly visible HTTP REST APIs should follow behaviours specified: APIs, which require authentication and specific permissions, should check if the caller is authenticated and has required permission before the APIs logic is executed. APIs, which require the request body to have certain structure (e.g. JSON format, required fields, etc.), should validate the request body before the APIs logic is executed. Scenarios: Unauthenticated Given I'm not authenticated or my OAuth authentication token is invalid When I access a public API requiring authentication, Then:

• I receive a response with HTTP 401 status code (Unauthorized)
• APIs logic is not executed

Invalid permissions Given I'm authenticated, but I don't have suitable access rights When I access a public API requiring authentication and specific rights, Then:

• I receive a response with HTTP 403 status code (Forbidden)
• APIs logic is not executed

Bad request Given my request is malformed, When I access a public API requiring its body to follow a certain format, Then I receive a response with HTTP status 400 (Bad Request) and a JSON response containing the error details.

[adamamyl]

This user story needs a clarification, as, as far as I understand things, 'ordinary' users will not be using WAAD (down to cost), but should still be created.

Can Glasgow please confirm that for ordinary users (citizens, etc), user accounts will not be created in WAAD/Identity Services, but that they should live in CKAN? @stevenlivz, maybe?

[adamamyl]

This is to update user profiles.

Complication: we'll be having mixed users (EC and CKAN). We need to do user changes for EC users via the Identity Services / Metadata API, and changes for CKAN users in CKAN.