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