search

NCEAS / metacatui

MetacatUI: A client-side web interface for DataONE data repositories
https://nceas.github.io/metacatui
Apache License 2.0
41 stars 27 forks source link

Feature: Include enhanced "My Data Packages" permission filters #1831

Open csjx opened 3 years ago

csjx commented 3 years ago

Navigating to the My Datasets page shows a filter where the authenticated user is the Creator of the data package:

Screen Shot 2021-07-15 at 1 25 25 PM:

Feedback from ESS-DIVE scientists and their curation team includes some finer control over which packages show in this list. They suggest that four different categories would be useful:

See the mockup provided by Madison and Sarah:

These would coincide with the Is Owner, Can Write, and Can Read roles in the permissions editor. Note that they specifically avoided the role of Owner and chose Manager because of feedback from scientists and that Owner is overloaded/ambiguous.

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 commented 3 years ago

Also related to #1160

laurenwalker commented 3 years ago

This sounds like a great feature.

Creator - the SystemMetadata.rightsHolder of the package

What is the use case behind having the rightsHolder/creator as a separate filter? I think treating the rightsHolder differently than any other person or group with changePermission permission will cause some issues. Mainly because the rightsHolder can be changed in the system metadata any time. There are no restrictions in the DataONE model that treat the rightsHolder as the "true" creator or owner of the dataset. And the rightsHolder is displayed in the AccessPolicyView the same way that any other changePermission person is (i.e. they are listed as "Is owner" or "Is manager").

It probably is the best way to filter for datasets that were originally submitted by the user, since submitter can change with each update of the metadata (e.g. if an intern makes an edit to the metadata, they will be saved as the submitter). So I think it should probably be okay to use for this purpose, but I thought I'd point out that there are some issues to consider.

Implementation notes

I'd suggest one of three implementation paths for this, and I've listed them in order from most preferred to least, but I think any would be fine:

  1. Wait until the main search view is upgraded to use DataCatalogViewWithFilters In the new DataCatalogViewWithFilters, we can easily construct custom searches using the new FilterModels. This is how the portal search pages are rendered. This would be such a simple implementation, as we designed DataCatalogViewWithFilters to be super customizable by even just basic JSON.

However, the main search view at /data uses the old DataCatalogView. So this implementation would depend on first upgrading that view, which we want to do anyway.

  1. Upgrade the user profile to a PortalView and link to that instead

Since the PortalViews use the new DataCatalogViewWithFilters, we could upgrade the current user profile to a special portal, just like we did for the DataONE member repository profiles. Then the "My data" link can link to their profile/portal 'Data' tab with those filters applied, like in implementation 1 described above.

But again, this would depend on upgrading the user profiles, which we want to do anyway.

  1. Expand the functionality of DataCatalogView

The most immediate implementation path is to use the old DataCatalogView, which is what is used in the main search view now, but expand the "My data" filter to display as separate filters like in the mockup. Because this doesn't depend on any additional work like 1 and 2 above, it would be finished sooner, but all of that code would be totally replaced once we upgrade to the new DataCatalogViewWithFilters, so I think it's the least efficient.

laurenwalker commented 3 years ago

I mocked up a slightly different interface for how this could look. I propose:

Note that this mockup is in the DataONE theme, but it would look essentially the same in all themes.

My-datasets-filter.png

mbjones commented 3 years ago

I like it. Nice design. 🍦

I particularly liked that you joined the previous proposal of Creator and Manager into one category (Owner), as there isn't really a distinction there. But I don't think that category should be Owner, as that is misleading -- I think Manager would be better, although we could discuss if Creator would be better, given that the rights should really correspond with anyone listed as a an eml:creator within the dataset metadata. But I think Manager is probably clearer on the elevated permissions.

Would a tooltip that explains what each role can do would be helpful? Can manage permissions for the dataset, Can edit the dataset, Can view the dataset.? Or something like that?

laurenwalker commented 3 years ago

Thanks Matt. Manager could work, too. In the permissions panel in the editor we use Is owner for the anyone with changePermission or rightsHolder permissions, so I was matching that language. I think whatever word we go with, we should use it in both places.

I think tooltips would definitely be useful.

laurenwalker commented 3 years ago

I also struggled with the language around Viewer since I'm not sure how intuitive it would be. I think people are more used to things like, Shared with me. But we use can view in the permissions panel, so I decided to stay consistent there. I also think if we use Shared with me, we might want to separate it out from the My data header, and put it under it's own header.

Example: