Skip to content

docs for disable/delete/anon, need to move to user admin section #7585

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
scolapasta wants to merge 9 commits into from
Closed

docs for disable/delete/anon, need to move to user admin section #7585

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
9 commits
Select commit Hold shift + click to select a range
1f48426
docs for disable/delete/anon, need to move to user admin section
djbrooke Feb 5, 2021
2af33fd
draft code review feedback
djbrooke Feb 5, 2021
ecaaa9b
removing anon and documentation for remove roles API
djbrooke Feb 5, 2021
ab50ea9
Merge branch 'develop' into 4475-delete-user-api
djbrooke Feb 10, 2021
eafdc73
updates from draft code review
djbrooke Feb 10, 2021
a3b51d7
adding links from user administration
djbrooke Feb 10, 2021
c85691b
updates from more review
djbrooke Feb 11, 2021
bb03310
Update native-api.rst
djbrooke Feb 17, 2021
e9845c0
Update native-api.rst
djbrooke Feb 18, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 10 additions & 0 deletions doc/sphinx-guides/source/admin/user-administration.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -44,6 +44,16 @@ Change User Identifier

See :ref:`change-identifier-label`

Delete a User
-------------

See :ref:`delete-a-user`

Disable a User
--------------

See :ref:`disable-a-user`

Confirm Email
-------------

Expand Down
38 changes: 36 additions & 2 deletions doc/sphinx-guides/source/api/native-api.rst
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -2961,6 +2961,8 @@ Example: ``curl -H "X-Dataverse-key: $API_TOKEN" -X POST http://demo.dataverse.o

This action moves account data from jsmith2 into the account jsmith and deletes the account of jsmith2.

Note: User accounts can only be merged if they are either both enabled or both disabled. See :ref:`disable a user<disable-a-user>`.

.. _change-identifier-label:

Change User Identifier
Expand All @@ -2980,7 +2982,9 @@ Make User a SuperUser
Toggles superuser mode on the ``AuthenticatedUser`` whose ``identifier`` (without the ``@`` sign) is passed. ::

POST http://$SERVER/api/admin/superuser/$identifier


.. _delete-a-user:

Delete a User
~~~~~~~~~~~~~

Expand All @@ -2992,9 +2996,39 @@ Deletes an ``AuthenticatedUser`` whose ``id`` is passed. ::

DELETE http://$SERVER/api/admin/authenticatedUsers/id/$id

Note: If the user has performed certain actions such as creating or contributing to a Dataset or downloading a file they cannot be deleted.
Note: If the user has performed certain actions such as creating or contributing to a Dataset or downloading a file they cannot be deleted. If a user cannot be deleted for this reason, you can choose to :ref:`disable a user<disable-a-user>`.

.. _disable-a-user:

Disable a User
~~~~~~~~~~~~~~

Disables an ``AuthenticatedUser`` whose ``identifier`` (without the ``@`` sign) is passed. ::

PUT http://$SERVER/api/admin/authenticatedUsers/disable/$identifier

Disables an ``AuthenticatedUser`` whose ``id`` is passed. ::

PUT http://$SERVER/api/admin/authenticatedUsers/disable/id/$id

Note: A primary purpose of most Dataverse installations is to serve an archive. In the archival space, there are best practices around the tracking of data access and the tracking of modifications to data and metadata. In support of these key workflows, a simple mechanism to delete users that have performed edit or access actions in the system is not provided. Providing a Disable User endpoint for users who have taken certain actions in the system alongside a Delete User endpoint to remove users that haven't taken certain actions in the system is by design.

This is an irreversible action. There is no option to undisable a user.

Disabling a user with this endpoint will:

- Disable the user's ability to log in to the Dataverse installation. A message will be shown, stating that the account has been disabled. The user will not able to create a new account with the same email address, ORCID, Shibboleth, or other login type.
- Remove the user's access from all Dataverse collections, datasets and files
- Prevent a user from being assigned any roles
- Cancel any pending file access requests generated by the user
- Remove the user from all groups
- No longer have notifications generated or sent by the Dataverse installation
Copy link
Contributor

@mheppler mheppler Feb 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We need to add something that prevents a user from recreating a disabled account with the same username and/or email.

Copy link
Contributor

@djbrooke djbrooke Feb 17, 2021 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mheppler Can you talk a bit more about why? Is this the case of a malicious user or something else?

Copy link
Contributor

@mheppler mheppler Feb 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The first bullet here suggests we disable a user account in order to "disable the user's ability to log in to the Dataverse installation"... seems obvious that we don't leave the front door of the house open if we're trying to add a lock to the back door. I don't have a specific use case in mind. I don't see a list of use cases here in the guides, so I can't point to an existing one. Not trying to expand the scope or make more work for anyone. Just making sure we achieve what we set out to do.

Copy link
Contributor

@djbrooke djbrooke Feb 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mheppler thanks. As a concrete example, you're saying that if I have an account with danny@harvard.edu that gets disabled by an admin, I wouldn't be able to create a new account using danny@harvard.edu?

Copy link
Contributor

@mheppler mheppler Feb 17, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, email or username, both fields are validated on create to be unique.

Copy link
Member

@pdurbin pdurbin Feb 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just chiming in to make sure I understand. You both seem to be using "builtin" user examples (which is fine) but it applies equally to shib/oauth/oidc. For example, if my ORCID account is disabled on the Dataverse side, I am no longer able to create a Dataverse account using my ORCID account. Instead of a conflict of email addresses (like with builtin users) what's conflicting is the unique identifier within ORCID. Same with Shib (eppn is the unique identifier we use), etc.

Copy link
Contributor

@djbrooke djbrooke Feb 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I pushed e9845c0 to reflect my understanding but am not super happy with the phrasing. Feedback welcome.


Disabling a user with this endpoint will keep:

- The user's contributions to datasets, including dataset creation, file uploads, and publishing.
- The user's access history to datafiles in the Dataverse installation, including guestbook records.
- The user's account information (specifically name, email, affiliation, and position)
Copy link
Member

@pdurbin pdurbin Feb 18, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just wanted to note that currently the authenticateduserlookup rows and builtinuser rows (in the case of Builtin users) are also being kept. There has been a suggestion of deleting these rows (which would surely close the door to a "undisable" option in the future) but I haven't explored it at all. I'm getting closer (I hope) to pushing some working code that we can talk about.


List Role Assignments of a Role Assignee
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Expand Down