Permissions: Timestamp + user name in notifications/permissions pg for access requests

[sbarbosadataverse]

The"" File Permissions" page does not display a
submitted timestamp next to outstanding requests, and the emails do not
contain the user who requested the files.

Problem : Gmail tends to group similar looking emails into the same conversation. Especially ones
with the same Subject, From, and To. So this may actually be part of the
reason why admins see many more requests in the File Permissions page than
they have unique "Access has been requested for a restricted file" emails in
the inbox.

Action: could be solved by adding a unique string of some sort e.g.,
the requestor's username, in the Subject header ???

[eaquigley]

Adding @tokeefe comment from #2261 to this ticket, "I propose adding a timestamp column to the permissions editing panel to reveal when a user submitted a request to access a restricted file, or files. Alternatively, adding the user's name to the automated email would make this information recoverable."

[dlmurphy]

Recently, @sbarbosadataverse encountered a situation that's relevant to this issue:

Alex from HBS accidently rejected a user who requested access to data. I asked him to send me the notification so I can see if a name was attached to the request and nothing was attached: no name, no email, no username, nothing.

She suggests that access request notifications should include the name of requester. Dataverse should then whether the requester is "approved" or "rejected". The Permissions page should carry a record of both approvals and rejections, so users can refer back to it later.

[scolapasta]

We have recently made changes to the action log record so that we can determine what happened here. Now that we can track it as needed, I'd wait to add UI / functionality for this until we see how often this is needed.

[pdurbin]

@scolapasta which change was that?

[scolapasta]

I was thinking the change who made for the actionlogrecord to allow commands to override describe. But now that I think about it, we only overrode for AssignRoleCommand. So we'd need to add a command for rejecting roles (currently not a command).

[pdurbin]

Regarding the three comments above...

• "the emails do not contain the user who requested the files"
• "adding the user's name to the automated email would make this information recoverable"
• "Alex from HBS accidently rejected a user who requested access to data. I asked him to send me the notification so I can see if a name was attached to the request and nothing was attached: no name, no email, no username, nothing."

... I thought I'd provide a screenshot below of how the "Access has been requested for a restricted file" emails look as of the latest release, Dataverse 4.9.4, and how the person receiving the email gets no information about who is requesting access. No name, no username, no email address. See also the discussion at #3404 (comment)

I can't imagine it would be very difficult to put the name, username and email address of the person requesting access in these "Access has been requested for a restricted file" emails.

[pdurbin]

I brought this issue up in a meeting just now and we didn't estimate it but afterwards @sekmiller helped me find pull request #5134 (merged but not yet released) where we added "requestor" to the notifications database table. This was for #5013 for a certain kind of requestor:

• As as someone requesting review of my dataset...

We could use this "requestor" field to also mean:

• As someone requesting a file...

[pdurbin]

how the person receiving the email gets no information about who is requesting access

I just spoke with @sekmiller and a fix for this is in pull request #5309.

[mheppler]

@pdurbin @sekmiller Can we get some UI screenshots of the emails and request table changes? Please? Thank you!

[sekmiller]

This is what the notification looks like. Be aware that it's FirstName LastName at email address. (We use some weird user names in integration tests.)

[scolapasta]

Minor quibble:
"FirstName LastName at email address" seems like a strange way to list these values.
"FirstName LastName (email address)" or "FirstName LastName " seems more standard and readable.

[sekmiller]

I favored the email in parens version but Julian had asked for the "at" construction for Submit Dataset for Review so I followed that pattern.

[mheppler]

After confirming the UI impact of this issue with @scolapasta, I would like to strike it from the connection to the #5229 PR as it does not address the original request from @sbarbosadataverse...

The "(Restricted File Permissions)" page does not display a submitted timestamp next to outstanding requests

Just want to make sure that request does not get lost in the closing of this issue after the PR goes through QA.

[pdurbin]

@mheppler makes sense but heads up to all that emails and in-app notifications were improved in that pull request.

[kcondon]

@pdurbin was that part of the original scope?

[pdurbin]

@kcondon not to my knowledge.

[mheppler]

@pdurbin Could we get an updates email screenshot in this issue for tracking purposes?

[pdurbin]

@mheppler I didn't work on the code but you could ask someone who has the branch spun up. Or spin it up yourself.

[mheppler]

See #5300 for how the date and time format of the time stamps on the Versions Details popup (labeled "Dataset Versions, Difference" above) on the Dataset pg, as well as the Notification table on the Account pg have been updated for the internationalization efforts across the site.

Also consider Date/Time Stamp Format - Consistency Across App #1391 for preferred date and time formatting.

[cmbz]

To focus on the most important features and bugs, we are closing issues created before 2020 (version 5.0) that are not new feature requests with the label 'Type: Feature'.

If you created this issue and you feel the team should revisit this decision, please reopen the issue and leave a comment.