Has anyone tried to use the new "Manage Children" ...
# troubleshoot
m
Has anyone tried to use the new "Manage Children" metadata privilege released in v.0.9.2? If so, would be curious of your results as I am not having luck setting up a policy to allow a user access to only create and delete Glossary Terms and Glossary Nodes within a specific Glossary Node. Setup: 1. The user does not have "Manage Glossaries" platform privileges a. I don't want them to have global rights on glossaries. 2. The user is granted rights in a GlossaryNode specific policy with the following configuration: a. Type: Metadata b. Asset Types: Glossary Terms & Glossary Term Groups c. Assets: GlossaryNode X where X is the only Node I want the user to have access to manage. d. Domains: All e. Privilege: Manage Glossary Children
b
hey Scott! yeah so the Manage Children privilege is only applicable to Term Groups right now. If you give someone Manage Children over a specific term group (or all Term Groups they're owners of, however you want to manage that) then they should be able to create term/term groups in the Term Group. They should also be able to delete anything inside that group, as well as edit the names of those children. They can also move, but only if they have Manage Children for both the original term group and the one they want to move it to
it isn't recursive to apply to all the children of the children, just to the immediate children of whatever term group you have that privilege for!
this was made with the hope that users can give specific users privileges over a group but not have to give them the global "Manage Glossaries" privilege
m
Thanks - that is what I was looking for, but was seeking recursive such that the user can add nodes, etc as appropriate on their end without having to setup more permissions.
@bulky-soccer-26729 follow up, I updated the policy to setting "Applies to Owner" to true on the policy to see if this would essentially allow the user to create "recursively" addition term groups with access to manage those new term groups just like the one they were originally assigned with the policy. What I noticed was the UI (non kebab menu) has the buttons to add term group and terms, but on execute the backend fails due to authorization which appears to me the user isn't granted access to manage the glossary term groups they own. When you referenced "or all Term Groups they're owners" were you talking about what I attempted or something else? Appreciate any perspectives on this topic beyond what you already shared, thank you!
b
hmm yeah that's how it should work - if you create a policy that has the Manage Children policy on Glossary Term Groups, then on the next page toggle "Apply to owners" then any owner of a term group should be able to go into that three dot menu and click create (and then go and delete inside of those children if they wish). However, if you set a specific entity on the policy, then the policy will only apply to that one and not any of the other ones created. so in this situation you'd want to leave the entity section empty
and thus have it apply to all owners of term groups
m
Ah -- that helps -- Thank you!!
b
Nice! Keep me updated I want to make sure this is solving problems like yours as desired :)
m
will do, thanks! My guess is this will work for now, but eventually we will end up with complicated use cases where we need domain specific access management to different glossary node permissions that we want to delete that access management to the domain owner vs a centralized group. That said, this is great!!
b
oo very interesting! would you mind explaining that desired use case a little more and maybe an example of how you would want it to work in practice? this feedback helps us a ton with future work we want to do!
m
For sure.. Given our size we have different folks owning different business glossaries within a data domain. So for example we have Clinical • ADT • Labs • Immunization • etc... Payer • Claims • Benefits • etc... Pharmacy • Formulation • etc.. Etc...
and 10 more domains with sub domains which today we represent as glossary terms for tagging purposes, but would prefer to have domain and sub domain support, but that is a separate backlog item for discussion. So ideally we could grant ownership of a domain and that user could manage permission within that domain business glossary as there can be N number of "sub glossaries" for logical group that would be owned by different teams across that domain.
All said, the use of ownership should meet the need even with the scale mentioned above.
b
@miniature-eve-21984 - Thank you for sharing this feedback! This is incredibly useful for us as we think about evolving the Glossary feature. Definitely let us know how your approach here pans out for the immediate term 🙂 Also happy to hop into a design call around the Glossary more broadly at some time