GNIP 99: Implement a CRUD REST API for users

[giohappy]

GNIP 99: Implement a CRUD REST API for users

Overview

The current api/v2/users API will be extended to cover the following operations for the Profile model:

• Create, Update, Delete operations
• Batch transfer of resources ownership
• Batch removal of a user as a group manager

The following proposal includes only the API, no work on the user interface is considered.

Proposed By

GeoSolustions s.a.s. (giovanni.allegri@geosolutionsgroup.com)

Assigned to Release

This proposal is for GeoNode 4.3.0.

State

• [x] Under Discussion
• [x] In Progress
• [ ] Completed
• [ ] Rejected
• [ ] Deferred

Motivation

At the moment GeoNode doesn't implement an API for the management of users from third-party client applications and services. The lack of the possibility to delete an account is particularly critical in terms of compliance with the current data policy rules, which require any application to implement the option for users to delete their accounts.

Proposal

Retrieve a list of users

Endpoint: api/v2/users The endpoint is already implemented and returns the list of users visible to the current user.

Retrieve user data

Endpoint: api/v2/users/<id> The endpoint is already implemented and returns information about the current user.

Create a new user

Endpoint: api/v2/users/<id> Authorization: The action will only be available to administrators and for authenticated users only for their user id

Example of user creation:

URL: /api/v2/users/
METHOD: POST
PAYLOAD: 

{
    "username": "user",
    "password": "".
        ...
}

Implementation notes:

• If the environment variable ACCOUNT_EMAIL_REQUIRED is set to True, the email will be mandatory in the payload.
• If the email confirmation requirement is configured, a verification email will be sent to the user before allowing them to log in.
• If a password validator is set via AUTH_PASSWORD_VALIDATORS, the API will return an error if the validation fails

Update user data

Endpoint: api/v2/users/<id> Authorization: The action will only be available to administrators or users who want to modify their information.

The updatable information is the same as the one defined in the Profile/AbstractUser model.

Example of user update:

URL: /api/v2/users/<userid>
METHOD: PATCH
PAYLOAD: 

{
    "username": "user",
    "email": "Email",
    ....
}

Implementation notes:

• If a new password is set and password validator is set via AUTH_PASSWORD_VALIDATORS, the API will return an error if the validation fails

Delete a user

Endpoint: api/v2/users/<id> Authorization: The action will only be available to administrators and for authenticated users only for their user id

The following rules will be implemented to validate the deletion request:

• the user doesn’t own resources
• the user isn’t a group manager (optional: this rule will be configurable, since for Groups having a group manager is not a strict requirement. When a user is deleted any GroupManager entry will be cascade deleted)

In case either of these two rules are violated, the request will be denied.

Two dedicated endpoints will be implemented to allow a user to transfer the ownership of resources and to unregister as a group manager. These actions will permit the user to fulfill the rules for the account deletion.

Example of user delete:

URL: /api/v2/users/<id>
METHOD: DELETE

Transfer of resource ownership

Endpoint: api/v2/users/<id>/transfer_resources Authorization: The action will only be available to administrators and for authenticated users only for their own user id

This action will transfer the ownership of the resources owned by the current user to a target user. Resources can only be assigned to users that are visible to the current user, or the default administrator. Visible users are:

• public users
• members of private groups the current user belongs to

The target user is set inside the payload. The “DEFAULT” constant string can be used to transfer ownership to the default user, which is the principal administrator.

Example of a transfer request:

URL: /api/v2/users/<id>/transfer_resources
METHOD: POST
PAYLOAD: 

{
    "owner": <user_id> | "DEFAULT"
}

Unregister as a group manager

Endpoint: api/v2/users/<id>/remove_from_group_manager Authorization: The action will only be available to administrators and for authenticated users only for their user id

A user can request to be removed from the role of group manager for one or multiple groups. The target groups (list) can be set inside the payload. The “ALL” constant string can be used to request the removal of a group manager from all the groups.

Example of a removal request:

URL: /api/v2/users/<id>/remove_from_group_manager
METHOD: POST
PAYLOAD: 

{
    "groups": <comma separatad list of group_profile_id> | "ALL"
}

Back compatibility

The changes will grant back compatibility with the already user's API.

Backwards Compatibility

The current /api/v2/users listing endpoint will maintain the same interface.

Future evolution

The future enhancements could include:

• the possibility of submitting requests for the deletion of resources in batch
• the possibility of transferring contact roles in batch

Feedback

Update this section with relevant feedback, if any.

Voting

Project Steering Committee:

• Alessio Fabiani: +1
• Francesco Bartoli:
• Giovanni Allegri: +1
• Toni Schoenbuchner: +1
• Florian Hoedt: +1

[t-book]

Thanks @giohappy

[afabiani]

💯

[t-book]

Do we still list GNIPs here? https://github.com/GeoNode/geonode/wiki/GeoNode-Improvement-Proposals

[giohappy]

Do we still list GNIPs here? https://github.com/GeoNode/geonode/wiki/GeoNode-Improvement-Proposals

@t-book tight, we should update that list. Could you do it?

[t-book]

@giohappy will take care of it

[gannebamm]

More API functionality is always welcome. Thanks Giovanni and GeoSolutions