This feature enables a site to use a collection properties entry for tracking ownership/responsibility for file data found in collections ("who was responsible for uploading these files to Arvados?") even after the collections are modified and copied/moved from one project to another.

When creating a new collection, if the caller has not provided values for these keys in the properties hash, they are automatically populated with the UUID of the user who owns [the parent of …] the containing project.

When updating a collection, a protected entry in the properties hash cannot be changed by a non-admin user, even the collection's owner. Attempting to do so results in a 403 error.

The default is the empty set (no special behavior).

Supporting this, we should provide some example admin scripts:

List UUIDs/names of collections with no responsible_person_uuid property value

Update the responsible_person_uuid property from nil to X on all collections in the project hierarchy rooted at P, where P is a user UUID or a group UUID.

Update the responsible_person_uuid property from X to Y on all collections where it is X.

We should also confirm that Workbench/Workbench2 preserve the properties hash when copying a collection.

I created a collection in workbench2 and it had the expected initial properties set on it

In Workbench1 I can edit/delete/add non-protected properties, and trying to modify or delete the protected property displays an error.

I tested copying the collection in both workbench1 and workbench2 and the properties were correctly copied.

Things to fix:

I think you mentioned this in chat -- something is turning 'responsible_person_uuid' to 'responsiblePersonUuid'. We should fix that.

In Workbench2, when I try to delete a non-protected property on a collection with a protected property, it will report "Protected property cannot be updated" for the protected property. I get the same error when I try to add a tag.

From chat: we tracked down the use of mapKeys on responses from the API server. The method applies recursively, and has the effect of corrupting the keys of any field containing a JSON object such as properties, mounts, etc containing punctuation such as "_" or "/".

That explains why wb2 reports 'Protected property cannot be updated: responsible_person_uuid' because it was mangled into 'responsiblePersonUuid' so when it attempts to write it back, the protected field is indeed no longer there.

These look fine. You could simplify them a bit using arvados.util.list_all().

I am generally reluctant to add code to the documentation where the user is expected to directly copy and paste, it is an awkward category that is more than a small example but less than a fully supported admin tool. I don't know if we will have met the customer need until they actually have a chance to try it.

I know we're trying to wrap this story up but it just occurred to me that new API call(s) "apply default properties" and/or "reset default properties" might be a better approach than reimplementing the "root owner of project" logic in Python. What do you think?

I know we're trying to wrap this story up but it just occurred to me that new API call(s) "apply default properties" and/or "reset default properties" might be a better approach than reimplementing the "root owner of project" logic in Python. What do you think?

From discussion in chat, we don't want to add new API design to this ticket, so this LGTM.