Think of Inherit as "no-decision" when it comes to permissions:
"I'm not explicitly granting or denying permissions on this task/capability - make the authorization decision based on membership (if any) in OTHER groups".
If the user happens to be a member of another group which grants or denies the permisson, then "inherit" respects that. If the there is no permission granted/denied by another source, then inherit becomes an implicit "deny".
Clear as mud?
Thanks Russell. That clears things up for me. So I guess best practice would be to set all permissions to either Allow or Deny at the Project-Level to clearly define default permissions for users?
1 of 1 people found this helpful
Yup! For an "Enterprise" deployment, here are some good rules of thumb:
- Before any users or content are unleashed on the server, strip ALL permissions from the Default Project.
- Since new projects inherit their permissions from "Default", you're making sure that all new projects and information deposited in them cannot be viewed by anyone by default
- Now, circle back to each project and add your permissions
- Don't forget to click the "Assign Permissions To Contents" hyperlink afterwords or changes you make at the project level won't be applied to pre-existing workbooks in the project
Thanks Russel, that clarifies things for me.
this is great info. If a user is part of 3 projects (a, b, c) and a given right is set to allow for A, deny for B, and inherit for C, what will it inherit? Also does inheritance depend on whether the user is a viewer, interactor, or publisher at all? Thank you.
Rights will be inherited from the Site level for a Project. That's my understanding. Permissions from other Projects have no bearing.
I think what you said is correct support user has publisher role for Site A and Viewer role for Site B. User can only publish to Project A but not Project B (Even though user has "Publisher" for Project for Content)