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
@callum_mccann @nicornk providing an update on this thread:
We are currently working on project-level approval policies for protecting resources in a project. The way this will work:
- you can choose to mark some resources as “protected” in a project.
- for the resources that you marked as “protected”, editing their main branch will have to go through a proposal, and will have to satisfy the approval policies that are set at the project level.
For instance, say your project contains 2 workshop modules W1 and W2, and the approval policy is set as “require at least one approval from multipass group M1”. From your compass file system, you can choose to mark W1 as protected. This means that all changes to W1 will have to go through branching and will have to have at least one approval from a member of M1. W2 is left unprotected and will not require branching or approvals.
How this will work for the ontology: towards about end of April/early May, you will be able to start moving your ontology entities to projects. Similarly to what I described above for workshop modules, you’ll be able to select within a project which ontology entities you’d like to protect, and therefore any change to these entities will have to go through branching + satisfy the approval policy set at the project level.
On top of this, we are also exploring a space-level setting to mark as “protected” every ontology resource in a given space (so that would basically flip the “protected” toggle on all your ontology entities in that space, meaning enforcing branching + whatever approvals are set at the project level). This is still at the scoping stage.