Feature: Render Data Package Permissions in the metadata view

[csjx]

We currently include a permissions section in the XSLT-rendered view of EML documents when there is an /eml/access section in the metadata, which is of course deprecated, but still present in older EML documents. The SystemMetadata.rightsHolder and SystemMetadata.AccessPolicy entries are currently not shown in the metadata view. Feedback from ESS-DIVE scientists and their UX?UI specialist (Sarah) was that it would be helpful for research groups to see this metadata prominently below the Data Package Table, but conditionally only for those that have write or changePermission permission on the dataset. This would help managers have a quick look at who currently has access without entering edit mode. Sarah provided a mockup:

For review: Should the rendered data package permissions metadata prominence be configurable (it may bump the abstract "below the fold)"? What if there are individual file-level ACLs? Do we link to them lower in the rendered metadata?

This relates to https://github.com/NCEAS/metacatui/issues/1640 and should be considered with the wider permissions management challenges described there.

This ticket is derived from the ESS-DIVE private repo ticket https://github.com/ess-dive/ess-dive-catalog/issues/493

[laurenwalker]

I think this is great. Some feedback:

What if there are individual file-level ACLs?

• If we want to display the file-level access rules, we might want to implement the same table style used in the editor where each object's Access Policy is accessible via a button in that table row. (I've actually wanted to upgrade that table view to use the same table view as the editor, anyway).
• If we don't use the table design, I'd suggest collapsing the permissions list or moving it to the bottom of the page. Displaying it at the very top seems like too high of a visual priority, to me. (But we could make the placement configurable per deployment). This also brings up the well-known issue of this view being way too long and scrolly and in need of a better table of contents.
• I'd suggest hiding the permissions list for people who only have read (can view) or write (can edit) permission. Because those people don't have changePermission permission, they cannot edit the access policy, so it seems odd to show them the access policy here. But maybe there are some use cases for this that I'm not thinking of.
• I'd suggest we use the same design as AccessPolicyView in the editor, rather than matching the metadata style. This saves us from creating and maintaining more CSS and it also keeps the look consistent, and separates it visually from the metadata.

But overall I think this is a very doable task