This section focuses on user administration tools and tasks.
The Manage Users table gives the network administrator a list of all user accounts in table form. You can access it by clicking the “Manage Users” button on the Dashboard, which is linked from the header of all Dataverse installation pages (if you’re logged in as an administrator). It lists username, full name, email address, affiliation, the authentication method they use, the roles their account has been granted, and whether or not they have Superuser status.
Users are listed alphabetically by username. The search bar above the table allows you to search for a specific user. It performs a right-truncated wildcard search of the Username, Name, and Email columns. This means, if you search “baseba” then it will search those three columns for any string of text that begins with “baseba”, e.g. “baseball” or “baseballfan”.
If you would like to assign or remove a user’s Superuser status, then you can do so by checking or unchecking their checkbox under the “Superuser” column.
If you would like to remove all roles/permissions from a user’s account (in the event of their leaving your organization, for example) then you can do so by clicking the “Remove All” button under the Roles column. This will keep the user’s account active, but will revert it to put the account on the level of a default user with default permissions.
There are two ways to list users via API. If you have relatively few users, you can get them all as a dump with this command with a superuser API token:
curl -H "X-Dataverse-key: $API_TOKEN" http://localhost:8080/api/admin/authenticatedUsers
If you have many users and want to be able to search and paginate through the results, use the command below with a superuser API token:
curl -H "X-Dataverse-key: $API_TOKEN" http://localhost:8080/api/admin/list-users
list-users form you can include the following optional query parameters:
searchTermA string that matches the beginning of a user identifier, first name, last name or email address.
itemsPerPageThe number of detailed results to return. The default is 25. This number has no limit. e.g. You could set it to 1000 to return 1,000 results
selectedPageThe page of results to return. The default is 1.
A Dataverse installation encourages builtin/local users to verify their email address upon signup or email change so that sysadmins can be assured that users can be contacted.
The app will send a standard welcome email with a URL the user can click, which, when activated, will store a
lastconfirmed timestamp in the
authenticateduser table of the database. Any time this is “null” for a user (immediately after signup and/or changing of their Dataverse installation email address), their current email on file is considered to not be verified. The link that is sent expires after a time (the default is 24 hours), but this is configurable by a superuser via the
:MinutesUntilConfirmEmailTokenExpires config option.
Should users’ URL token expire, they will see a “Verify Email” button on the account information page to send another URL.
Sysadmins can determine which users have verified their email addresses by looking for the presence of the value
emailLastConfirmed in the JSON output from listing users (see Admin section of Native API in the API Guide). As mentioned in the Account Creation + Management section of the User Guide, the email addresses for Shibboleth users are re-confirmed on every login (so their welcome email does not contain a URL to click for this purpose).
If an API token is compromised it should be deleted. Users can generate a new one for themselves as explained in the Account Creation + Management section of the User Guide, but you may want to preemptively delete tokens from the database.
Using the API token 7ae33670-be21-491d-a244-008149856437 as an example:
delete from apitoken where tokenstring = '7ae33670-be21-491d-a244-008149856437';
You should expect the output
DELETE 1 after issuing the command above.
See Notifications in the User Guide for how notifications are described to end users.
You can let users manage which notification types they wish to receive by setting :ShowMuteOptions to “true”:
curl -X PUT -d 'true' http://localhost:8080/api/admin/settings/:ShowMuteOptions
This enables additional settings for each user in the notifications tab of their account page. The users can select which in-app notifications and/or e-mails they wish to receive out of the following list:
APIGENERATEDAPI token is generated
ASSIGNROLERole is assigned
CHECKSUMFAILChecksum validation failed
CHECKSUMIMPORTDataset had file checksums added via a batch job
CREATEACCAccount is created
CREATEDSYour dataset is created
CREATEDVDataverse collection is created
DATASETCREATEDDataset was created by user
FILESYSTEMIMPORTDataset has been successfully uploaded and verified
GRANTFILEACCESSAccess to file is granted
INGESTCOMPLETEDWITHERRORSIngest completed with errors
INGESTCOMPLETEDIngest is completed
PUBLISHEDDSDataset is published
PUBLISHFAILED_PIDREGPublish has failed
REJECTFILEACCESSAccess to file is rejected
REQUESTFILEACCESSAccess to file is requested
RETURNEDDSReturned from review
REVOKEROLERole is revoked
STATUSUPDATEDStatus of dataset has been updated
SUBMITTEDDSSubmitted for review
WORKFLOW_FAILUREExternal workflow run has failed
WORKFLOW_SUCCESSExternal workflow run has succeeded
After enabling this feature, all notifications are enabled by default, until this is changed by the user.
You can shorten this list by configuring some notification types (e.g.,
REVOKEROLE) to be always muted for everyone and not manageable by users (not visible in the user interface) with the :AlwaysMuted setting:
curl -X PUT -d 'ASSIGNROLE,REVOKEROLE' http://localhost:8080/api/admin/settings/:AlwaysMuted
Finally, you can set some notifications (e.g.,
REJECTFILEACCESS) as always enabled for everyone and not manageable by users (grayed out in the user interface) with the :NeverMuted setting:
curl -X PUT -d 'REQUESTFILEACCESS,GRANTFILEACCESS,REJECTFILEACCESS' http://localhost:8080/api/admin/settings/:NeverMuted