In our projects that use the "subtree" ACL modes for Hatrac, it seems we could simplify our ACLs stored in the DB. By storing fewer ACLs, we will have some performance benefit but more importantly it will be easier to review or export large object stores in the future and understand which ACLs are truly significant if there are not many redundant ones generated by every resource creation event.
I am wondering if any of these should be new modes of Hatrac either all the time, by configuration switches, and/or by new query parameters:
When creating resources, don't set the resource-level "owner" ACL to the requesting client if they already are granted owner-level privileges due to a "subtree-owner" ACL in an ancestor node of the resource hierarchy. Just leave the resource-level ownership blank.
When managing ACLs via REST API, apply the same optimization to skip or prune "redundant" entries.
Reject removal of a subtree-owner ACL entry if it would orphan any descendent resources.
In past projects, we've even seen a need for even more controlled rights. These might also be served by new deployment settings. For example, the whole store is governed by a curator class and regular clients can do more limited data operations but do not gain full ownership-level rights even on resources they created, meaning a curator may need to be involved to adjust policies or retract content. For example, you might be able to use chunked upload to create an object but once it is created, you can only read it and only the curator can remove it or reassign it to another consumer.
@ljpearlman @carlkesselman @bugacov @hongsudt @akumar03
In our projects that use the "subtree" ACL modes for Hatrac, it seems we could simplify our ACLs stored in the DB. By storing fewer ACLs, we will have some performance benefit but more importantly it will be easier to review or export large object stores in the future and understand which ACLs are truly significant if there are not many redundant ones generated by every resource creation event.
I am wondering if any of these should be new modes of Hatrac either all the time, by configuration switches, and/or by new query parameters:
In past projects, we've even seen a need for even more controlled rights. These might also be served by new deployment settings. For example, the whole store is governed by a curator class and regular clients can do more limited data operations but do not gain full ownership-level rights even on resources they created, meaning a curator may need to be involved to adjust policies or retract content. For example, you might be able to use chunked upload to create an object but once it is created, you can only read it and only the curator can remove it or reassign it to another consumer.