Absolutely - avoid Deny if at all possible; use only as an exception.
I got so confused (and fed up) with all the permissions that I literally spent a whole week (a years ago) on a test system doing the following:
- OTB install (9.1)
- Created a product and library from each OTB product / library template; recorded all the ACL's in each, then removed every single one
- Created a few test users
- Added the test users to the Product / Library Team
- One by one, added back each ACL and observed the effect on all the Actions available to the users (including Read access to Data)
Conclusions
- This is one of the world's best puzzles, worthy of an international challenge (and good T-shirts for those who participate)
- Watch out a lot for "Team Members" which is different from "Members"
- Watch out for all the ACL's that come along with a product / library created from the OTB templates; create your own templates and carefully manage them
- Put all possible ACL's at Org level and remove from product / library where they are common. Note: For those Products / libraries that need to be different, make them "Private" and create all needed ACL's in that context.
- Use each ACL only once where possible and work hard to have the fewest possible total statements (e.g. use "ALL" states where possible instead of a separate statement for each state)
- Watch out for what seems like inconsistent behavior by object type but in fact is not. Example: Modify Content requires Modify as a prerequisite for Documents, so you can freely give everyone Modify Content without allowing them to do anything, and just control where you provide Modify. But - For Change Objects (e.g. Change Requests), Modify Content is all that is needed to change an attachment; Modify does not apply for Change objects.
- Use Deny only where needed.
