Cannot update package with private data object

[laurenwalker]

Scenario:

• Someone has changePermission permission on a metadata and resource map object, but does not have read permission on 2/3 data files in the package. This person can still click the Edit button and access the package in the editor. All data files still show up in the Editor, even though they are private. (This is a related bug - the files should not show up in the file listing, or should be grayed out somehow. They are visible because the metadata and resource map are accessible and parsed). The user edits the metadata and clicks Submit. The Submit button spins forever.

Only one file was accessible to this user in the MEtadata View (this is expected.)

All three files show up in the Editor. Error message on DataONEObject:389 (response is null):

Expected behavior:

• Editor should hide private data files
• A user that is "an owner"/changePermission on the metadata and resource map should be able to edit the package and save, even with private data files in the package.
• Perhaps consider adding anyone who is an "owner" of the resource map and metadata as an owner of all files in the package too. This is related to bulk access policy editing in #1829

[amoeba]

Editor should hide private data files

What do you think about always showing all objects in the package in the listing, regardless of access, adjusting the display of non-read-access objects to make it clear to the user what's going on and what they can do about them? My main reasoning is that I think any user with r/w/cP access on the package should have full control over the list of objects in the package. If we don't show non-readable objects, the user can't remove or replace them which I think could be frustrating.

[laurenwalker]

My main reasoning is that I think any user with r/w/cP access on the package should have full control over the list of objects in the package. If we don't show non-readable objects, the user can't remove or replace them which I think could be frustrating.

I agree that in most cases, someone who has chP access on the metadata and package should most likely have it for all of the data files, as well. But with our object-level permissions editing in the UI, it is entirely possible, so we need to accommodate those cases.

If a data object is private to a person, they will not be able to perform an update/replace on it. In spirit, I don't think they should be able to remove it either, although they can since that involves updating the resource map only.

Hiding the private files may be a step too far. Maybe just disabling the Replace button is good enough for now.