Dataverse: Enable Display of Installation Users

[djbrooke]

As a Superuser I want to search a list of all users so that I can see who has access to my installation.

This was an available feature in 3.x that we need to bring back in 4.x. Clicking on a user's name will navigate to that user's information (#3615).

[raprasad]

• Consider adding email to the table, or at least to the filter.

[djbrooke]

• How will we handle pagination?
• Will users be able to sort?
• How does the filter/search work (all fields or some subset)? (Consider how current filters work)
• Ignore create user button

[raprasad]

• How will sorting work for roles? (Is there sorting?)
• Is there sorting for names? Split first and last name?

[pdurbin]

As I mentioned in the Sprint Planning meeting this afternoon, it's probably worth taking a look at the "Admin Dashboard for Design" doc at https://docs.google.com/document/d/1qnB3E7aNaLHHE9yM205BOKYVfQJIrysJQbEIA28txZc/edit?usp=sharing and mentioned at https://trello.com/c/kDSgIVVS/8-administrative-dashboard-(4.7)

There are screenshots in there but here's the text:

1. As a Superuser I want to add another Superuser so that I can have assistance in managing my dataverse installation.
2. As a Superuser I want to remove another Superuser so that I can remove an administrator who has moved to a different institution.
3. As a Superuser I want to search a list of all users so that I can see who has access to my installation.
4. As a Superuser I want to view more information about a user so that I can determine the best way to contact them.

[dlmurphy]

Was there documentation for this feature in 3.x? If so, how can I access it?

[pdurbin]

@dlmurphy yes, here you go: http://guides.dataverse.org/en/3.6.2/dataverse-user-main.html#permissions-and-users-section

@kcondon gave me and @raprasad a live demo of how user management works in DVN 3.6.2 yesterday and I'm sure he'd be happy to do the same for you if you're interested.

[pdurbin]

To help keep momentum on this issue following yesterdays consensus to throw a PrimeFaces datatable on the screen, I just created pull request #3874 which is a very small change we can iterate on (or throw away if we don't like it). The branch is called 3614-dashboard-user-table.

Here are screenshots:

@raprasad @mheppler what do you think? Is this a good starting point? I guess we could add stuff from https://www.primefaces.org/showcase/ui/data/datatable/filter.xhtml for filtering, etc, but someone like @scolapasta is more familiar with JSF best practices.

[pdurbin]

Once I added 14,000 users to my laptop on the code behind pull request #3874 (the 3614-dashboard-user-table branch) I ran into serious performance problems. We're also not sure how we want to implement the filter.

I just switched to @raprasad 's branch and it's blazing fast with 14,000 users. I just created pull request #3877 based on it (the 3614-user-list branch) after adding some suggestions on the main dashboard page from @mheppler to show the number of users. Here's how the 3614-user-list branch looks:

[TaniaSchlatter]

Regarding filter/search, if we treat the filter just as it is on the dataset page, we are all set. I don't think we need "watermark" text. Just a "find" button.

[dlmurphy]

Just discussed documentation for this issue with @pdurbin and @sekmiller. Adding sensible documentation for this issue requires moving the Administration subpage of the Installation Guide into the Admin Guide and splitting it into new subsections. Documentation on this feature will be placed in the new "User Administration" subsection.

[dlmurphy]

Noticed this while editing documentation: In the mockup above, shouldn't the "User name" header read "Username"?

[pdurbin]

@dlmurphy yep, "Username". Also let's use "Superuser" instead of "Super-User" as discussed in #2211, which when you're done I'm hoping we can close.

[raprasad]

rewrite checklist:

• [x] SingleUserView class
  
  
  
  • Load generic objects to this class--especially needed as more fields added
  
  
• [x] Integrate pager view
  
  
  
  • [x] connect paging links
  
  
  • consult @sekmiller on link creation
  
  
• [x] add role information

[raprasad]

To do list:

• [x] role retrieval efficiency
  
  
  
  • [x] 1 query role retrieval to build hash of {assigneeIdentifer : [role List]}
    
    
    
    
    
    • current is 2 queries per user which doesn't scale with API that allows any # of results to be returned
    
    
    
  
  
  • [x] integrate into UI business logic (hopefull shared with API/JSON logic)
  
  
  • [x] integrate into API/JSON business logic
  
  
• [x] write rest assured tests

[landreev]

This is related to this, and #3612 issue both:
The "Is superuser?" column - it was being populated with the actual words "true" and "false" (as in @pdurbin's screenshot, above). I personally don't like displaying boolean values like that in UIs; I feel that checkboxes work much better, visually. And I feel that a checkbox there allows a super straightforward, simple implementation of #3612 - allowing an admin to toggle the value. So this is how I've implemented it, as of my last check-in into 3614-user-list branch. As in the screen shot attached:

[raprasad]

@landreev : I can make this change in that branch. For the rest of this ticket (#3614), the work shouldn't touch the .xhtml at all. The "to do" list above has redoing some of the efficiency for role retrieval and getting the API info in sync for automated tests. In other words, the UI should be stable if you want to try merging with it--agreed these tickets are very interconnected

[jggautier]

I agree: checkboxes > true/false. Although checkboxes give the impression that you can click on them to change the status, and I believe that's not something you can do through the UI, right?

[raprasad]

We should check with @mheppler and @TaniaSchlatter. (I'll put a placeholder of bootstrap badges--green/red--sure to inspire UX ire as well as a quick design/usability response:)

[landreev]

@jggautier: No, the checkboxes ARE actually functional - that's how I've implemented toggling the superuser status on/off (#3612). But, as I said in that ticket, I'd like that solution to be reviewed.

[landreev]

Anything I can do to help with this issue?

[raprasad]

updated "to do"

• [x] API finish: > UserListResult.java, a line needs to be added at 195

[raprasad]

To code review with caveat, still needs:

• [ ] Rest Assured tests
• [ ] Guide update for API endpoint;

[pdurbin]

I took a quick look at the code as of c8813b5 and requested some changes to the code at https://github.com/IQSS/dataverse/pull/3877#pullrequestreview-43297633

I also loaded it up on https://dev1.dataverse.org to poke around a bit and will put some screenshots below.

Overall, I think the user dashboard provides a ton of value to a superuser trying to figure out who has accounts on the system.

One thing that struck me is that I'm told on the dashboard that I have 11 superusers but unless I'm mistaken, there's no way to filter down to just the superusers to see who they are. I'd be fine with sorting by the Superuser column but sorting doesn't seem to be supported. Sorting appears to be hard coded to username. I'm wondering if it's possible to make the "User ID" column narrower to make room for the data in the "Authentication" column, which seems to be cut off. We could also just use the shorter, more technical terms in the code such as "builtin" rather than what I assume is "BuiltinAuthenticationProvider".

[landreev]

Added a query.setParameter() to pass the search term to the native query, per code review request.

[raprasad]

summarized code review input

• [x] look at switching to Typed Queries
  
  
  
  • "I think for the time being doing with these native queries is fine and probably the way to go."
  
  
  • _leaving for now, esp. with complex sql for groups_
  
  
• [x] API logic - using session and findUserOrDie?
  
  
  
  • _added comment and removed debug mode flag used in dev_.
  
  
• [x] probably shouldn't have locale like this (for internationization, but get from somewhere?) :
  NumberFormat.getNumberInstance(Locale.US).format(userService.getTotalUserCount());
  
  
  
  • _fixed_
  
  
• [x] toJson vs asJson in different classes, can we go with toJson for all
  
  
  
  • _corrected_
  
  
• [x] is this used: getUserList as opposed to getAuthenticatedUserList?
  
  
  
  • _corrected: getUserList no longer used and removed_
  
  
• [x] do we need row number? especially as part of the API return?
  
  
  
  • _removed from API_
  
  

[raprasad]

@scolapasta for row number, I commented it out of the API. To note, it can be used in conjunction with the API pagination data. e.g. below is the result if the selectedPage is 2.

```json
{
"status":"OK",
"data":{
"userCount":14173,
"selectedPage":2,
"pagination":{
"isNecessary":true,
"numResults":14173,
"numResultsString":"14,173",
"docsPerPage":25,
"selectedPageNumber":2,
"pageCount":567,
"hasPreviousPageNumber":true,
"previousPageNumber":1,
"hasNextPageNumber":true,
"nextPageNumber":3,
"startCardNumber":26,
"endCardNumber":50,
"startCardNumberString":"26",
"endCardNumberString":"50",
"remainingCards":14123,
"numberNextResults":25,
"pageNumberList":[
1,
2,
3,
4,
5
]
},
"bundleStrings":{
"userId":"User ID",
"userIdentifier":"Username",
"lastName":"Last Name",
"firstName":"First Name ",
"email":"Email",
"isSuperuser":"Superuser"
},
"users":[
{
"id":8817,
"rowNum":26,
"userIdentifier":"xxxxxx",
"lastName":"xxxxxx",
"firstName":"xxxxxx",
"email":"xxxxx@xxxxxx",
"affiliation":"xxxxxx",
"isSuperuser":false,
"position":"xxxxxx",
"authenticationProvider":"BuiltinAuthenticationProvider",
"roles":""
},
{
"id":11996,
"rowNum":27,
"userIdentifier":"xxxxxx",
"lastName":"xxxxxx",
"firstName":"xxxxxx",
"email":"xxxxx@xxxxxx",
"affiliation":"xxxxxx",
"isSuperuser":false,
"position":"xxxxxx",
"authenticationProvider":"BuiltinAuthenticationProvider",
"roles":""
},

        (etc)


    ]
}

}```

[raprasad]

last items:

• [x] tests via api
• [x] ui cleanup (.xhtml)

[pdurbin]

Since we're doing development in small chunks these days, should we close #840?

[raprasad]

• [ ] last item, use setParameter within retrieveRolesForUsers

[pdurbin]

I just set up an hourly Jenkins job to put build guides from the 3614-user-list branch. Of special note should be the new "User Administration" page and its "Manage Users Table" section that @dlmurphy worked on: http://guides.dataverse.org/en/3614-user-list/admin/user-administration.html#manage-users-table

Also, this branch (pull request #3877) contains fixes for a variety of issues, mostly having to do with the Installation Guide:

• #3964 Typo: Datavese
• #3857 Documentation: Document zip file size download limit
• #3847 Swift: Document setting that allows setting cloud storage name.
• #3649 Enrich dataverse shibboleth documentation
• #2620 Ingest of tabular data: RoundRoutines:decimal separator no in right place
• #2211 Create Documentation for Superusers in User Guide
• #1293 Consistency: API token vs. key

[mheppler]

Upon reviewing the UI, we should be using cleaner text from the bundle to display in the Authentication column of the Manage Users table. "BuiltinAuthenticationProvider" is too code-geeky and most importantly doesn't break to a second line in the cramped column cell. A suggestion would be to use "Built In" as a value returned from the bundle, which can be translated. All values should be delivered from the bundle.

[raprasad]

• [ ] adding bundle names for authProviderId

[pdurbin]

@mheppler thanks for the screenshot. I completely agree that we should get rid of the code-geeky stuff but while we're in there, instead of showing "oauth2" like the screenshot says, let's show "ORCID", "GitHub" or "Google" so the superuser can help remind the user which OAuth provider the user created an account with. It will help with the problem @TaniaSchlatter identified in #3704 when she wrote, "Now that there are multiple ways to create an account and log in, how does a user remember which option they used to create an account?" The story is here is that a user forgets and contacts a superuser, who brings up the Manage Users table and tells the user which login option their account is associated with.

[kcondon]

Works as advertised. Remaining tasks: sanity check with production data, potentially document api endpoints and try them out.

[raprasad]

• [x] api documentation