Support for entities create, update, and delete dynamic permission policies
Dudi - Port team
As described here, the "policy" key for entity permissions is currently supported for the "read" permission type. As part of this item, we would like to add support for create, update, and delete operations as well.
Z
Zayne Halsall
Dudi - Port team as requested, our use cases.
We have seniors that are expected to own/manage specific entities within a catalog, but we can't apply permissions at the entity level. We're using the Moderator role right now as compromise, but it means all seniors can edit all entities.
We'd also like specific users to be able to manage a catalog, but not be able to modify the blueprint. Again, Moderator allows them to do both. It was suggested by support we revert them to Member role and instead add permissions for individual users but that's error prone, high maintenance, and not scalable.
Essentially (if my understanding is correct) dynamic permissions would give us "custom roles" defined by _user blueprint properties and entity blueprint properties, solving both use cases.
Beyond
read
, most crucial to us is update
.Dudi - Port team
Zayne Halsall: Thanks a lot for the feedback!
Can you please explain what you mean by "We'd also like specific users to be able to manage a catalog"? What actions would you like the user to be able to perform?
Regarding the catalog edit permissions - it sounds like dynamic permissions for entity update will solve your issue. Until it is released, I would suggest creating specific "teams" and providing permissions to users who are part of that team. For example, create a "seniors" team, and grant this team permissions to edit specific entities/entities' properties. See details here.
Z
Zayne Halsall
Dudi - Port team
By manage a catalog, I mean primarily the ability to update entities. Everything else is dependent on catalog (some we may create via self-service, some we may allow deletion, etc.), but ultimately they should be able to manage a catalog's content as needed (maybe even the page, but that's a separate thing). The important bit is allowing them to do so without being able to modify the blueprint itself.
Regarding the "seniors" team approach, it would still mean all seniors can update all entities (first use case) but it would remove the need for Moderator (second use case). I suspect it could create complexity for our existing setup between Port and GWS, but I will give it some thought as an interim possibility.