Is it possible to require Proposals on all Ontology changes? We’ve not found any way to configure this as a requirement instead of as an option.
1 Like
Right now there is no first class way to require proposals on all ontology changes. However, if your ontology entities are migrated to use Ontology Roles (https://www.palantir.com/docs/foundry/ontology-manager/ontology-roles-migration/), then you can have most people have the “Ontology Viewer” role, and have a restricted set of “Ontology Editors”. The editors will be able to edit main directly, but the viewers will have to use proposals and request an approval by someone who’s an editor.
Got it. Our instance uses Ontology Roles but it looks like Ontology Viewer has to be set up on every single Object, Relationship, Action, etc.
Given that it is a manual configuration with no method of enforcement, I am confident in saying that there’s no way we can reliably use the proposed methodology you mentioned above. Additionally its also very laborious.
The ideal outcome (in our opinion) is a configuration option in the Ontology Configuration setting that requires the use of Proposals, very similar to how its been set up for Code Repositories. Without this, Ontology remains hard to control at scale.
2 Likes
Totally understand. The reason you’re not seeing any immediate changes with Ontology Proposals is because we’ve been working on Global Branching, an end-to-end version control across the platform. The first release of Global Branching will cover dataset authoring, pipeline builder, Ontology Manager, and Workshop. The good news is that we’re in heavy testing mode right now. Shortly after that release, we’ll be working on a way to protect main for the Ontology.
The other thing I’ll mention is that we’re also working on allowing you to link your ontology entities to projects, and permission them in bulk at the level of the project, using ontology roles. This should should also make it easier to set up Ontology Viewer more easily across your ontology entities. I appreciate this isn’t an immediate fix to your problem, but it’s a temporary solution until we release a way to protect main for the ontology.
The third thing I’ll mention and that could potentially link Global Branching and ontology entities in projects, is that we could explore configuring branch settings at the level of the project. Which would mean protecting main for everything that’s in the project for example. This is still very much at the scoping stage, but we’re keen to hear if you think this is moving in the right direction for you.
@dashoush
A permission model centered around plain old foundry projects (POFP) for ontology branching/definitions is something that we would welcome and could be the missing piece to scale a single ontology to a large organization without having a central reviewer bottleneck.
Today, we have already built automation scripts to reset ontology permissions to project permissions. We are removing the custom permissions that users setup and adding the viewer group as ontology viewer, editor group as ontology editor and owner group as ontology editor. We inform owners of the POFP about these changes via email.
We are very much looking forward to end2end branching, happy to present our challenges and work together on this and what you shared seems like the right direction!
2 Likes