Bug for ADA: the 4 fields (Name, Email, Institution, Position) for guestbooks are editable for logged in users

[mdmADA]

What steps does it take to reproduce the issue? Create a a dataset with at least 1 restricted file and allow access request. Create the guestbook for this dataset and include any or all of the 4 authenticateduser details: Name, Email, Institution, Position in the guestbook. Set the guestbook to appear at request (also happens when they download but the gb at request is ADA's primary workflow). Login as a regular user that will be able to request access. Go to the dataset and click 'request access' for the file. The guestbook pops up. The 4 fields are editable. Add any values to the fields that you like.

When does this issue occur? With every guestbook.

Which page(s) does it occurs on? All datasets that have a guestbook.

What happens? See description of steps. Being able to add any value to these 4 fields means the requesting user can spoof who they are and requires extra verification by the people evaluating the access request.

To whom does it occur (all users, curators, superusers)? All users who enter guestbook values. All access request managers who need to evaluate the guestbook entries.

What did you expect to happen? I expected that for a logged in user, that the values for the 4 fields would be pulled from the authenticateduser table, and be non-editable (especially for email address, which should be verified by the requesting user).

As the person setting up the guestbook, I would like to be able to specify these field values need to be pulled from the authenticateduser table and that they can't be edited.

ADA would want this to be an installation-wide setting but more flexibility (dataverse level, dataset level) may be useful at some point, and/or for other Dataverse installations.

Which version of Dataverse are you using? 6.2

Any related open or closed issues to this bug report? Not that I can find.

[cmbz]

@mdmADA

Recommendation:

• Ask the UX Working Group to review this proposal, identify broader implications (possibly for consideration in October 2024 time frame)
  • @jggautier added a link to this issue into the UX Working Group tracking document
  • @jggautier mentioned this in the UX WG Zulip channel
• Dataverse team performs technical analysis to determine implications for existing and planning APIs
• Frontend team considers the UI implications and whether/when to implement in SPA assuming API support exists

[mdmADA]

@jggautier - can I ask if this has been implemented/released, or where it's at? Or if there are plans to implement it, given it seems to have been added to the "[Dataverse Prioritization Testing]"...

[jggautier]

Hi @mdmADA. I don't think we've added a way for folks managing repositories to make their guestbooks' name, email, institution and position fields uneditable by logged in users who see those guestbooks.

I think we'd like to help implement it but have lacked the resources so far. We certainly haven't been able to take up the recommendations we wrote about in an earlier comment in June.

Those recommendations seemed to suggest that this is something that may be implemented for the SPA version of Dataverse. The JSF version wasn't mentioned, which I think meant that at the time we were thinking it wouldn't be implemented for the JSF version.

I'll try to follow up with colleagues today.

[jggautier]

Hi again @mdmADA. @cmbz let me know that she also thought that we'd look into this for the SPA version of Dataverse and she removed it from that Dataverse Prioritization Testing GitHub Projects column you mentioned.

So we won't consider making this change for the JSF version of Dataverse.

[mdmADA]

Thank you for looking into it, and for updating this issue @jggautier.