I've been writing at some length about configuring features using Domino's Formula language. Another area of particular interest to developers is access control of documents.
Often customers don't have access controls well-in-hand. And often developers try to make up for this fact using roles, or even more-heavily managed code to set the access on documents.
Ultimately, the access management structure isn't built to handle unexpected changes. A new business team arrives and has their own ideas, splitting up roles differently in the new organization. And mass mayhem results, as the managers decide, then progressively refine their decisions, and dole out tasks differently to new groups of users.
How to cope?
As I mentioned earlier, it's possible to profile Formulas. Well, it turns out this includes Readers and Authors fields, Sections, and also Hiding Formulas. Formula language itself provides @Eval(), which executes text as a Formula.
Now, all that said, you have to take special precautions for Access Management. It's easy to lose control of documents if you do not protect people from entering nonsense formulas or formulas that generate errors. Plus, it is critical that, in order to reassign accesses, you must have some role for controlling access to all documents. That's the only way you're going to be able to reassign accesses, when The Management changes, and reassigns tasks to new groups.
So in this case, the concept is the same, but the implementation is different:
1. Always set up the authors fields so that any profiled Formula is always converted to @Text(). That'll convert an error or any numeric or date values in the profile Formula to text, and save you should the Formula have problems.
2. Always add an [Admin] role to the database, and always add it to the authors field.
3. Always set the authors and readers fields to multivalue fields.
4. If access to the information isn't downright critical -- consider appending a "*", that is, "universal author", when the profile formula returns no result or returns an error.
Often customers don't have access controls well-in-hand. And often developers try to make up for this fact using roles, or even more-heavily managed code to set the access on documents.
Ultimately, the access management structure isn't built to handle unexpected changes. A new business team arrives and has their own ideas, splitting up roles differently in the new organization. And mass mayhem results, as the managers decide, then progressively refine their decisions, and dole out tasks differently to new groups of users.
How to cope?
As I mentioned earlier, it's possible to profile Formulas. Well, it turns out this includes Readers and Authors fields, Sections, and also Hiding Formulas. Formula language itself provides @Eval(), which executes text as a Formula.
Now, all that said, you have to take special precautions for Access Management. It's easy to lose control of documents if you do not protect people from entering nonsense formulas or formulas that generate errors. Plus, it is critical that, in order to reassign accesses, you must have some role for controlling access to all documents. That's the only way you're going to be able to reassign accesses, when The Management changes, and reassigns tasks to new groups.
So in this case, the concept is the same, but the implementation is different:
1. Always set up the authors fields so that any profiled Formula is always converted to @Text(). That'll convert an error or any numeric or date values in the profile Formula to text, and save you should the Formula have problems.
2. Always add an [Admin] role to the database, and always add it to the authors field.
3. Always set the authors and readers fields to multivalue fields.
4. If access to the information isn't downright critical -- consider appending a "*", that is, "universal author", when the profile formula returns no result or returns an error.