The case seemed simple: I had a document that may only be edited by a bunch of people. So I added an authors field. Only that group (and application administrators) are allowed to view that document. So I added a readers field for the administrators role. I don’t need to add the group from the authors field to the readers field, since author access also allows reader access. All good.
The admins wanted an option to disallow editing the document for the people in the authors field, so I added a function that changes the authors field into a readers field. Simple. On the document I simple called:
doc.setReaders(true); doc.save();
Didn’t work…
Result was that the people in the (former) authors field could still edit the documennt. What?
It turned out that calling setReaders(true) on an authors field creates a field that is a readers field as well as an authors field! I never knew that was even possible and I wonder who does/ did. I know that it can’t be done in the Designer UI.
With this you can have a single field on a document that restricts reader access to the people in it AND allows that people to also edit the document. This isn’t how a (normal) authors field works: it can extend the readers, but an authors field on its own doesn’t restrict reader access.
You might think: great, lets use this. Well… I wouldn’t recommend that. I never read anything about this and don’t know if it’s supported (probably isn’t). Also, this requires further testing. What will happen if you edit the document using a form in the Notes client? (UPDATE: the field remains a combined readers/ authors field after editing a document through the Notes client, it doesn’t seem to matter if the field is or isn’t on the form or what the type is set to – text, readers or authors).
Want to try it out? Use this (don’t forget to add you own name to that field – got me the 1st time 😉 )
Document doc = dbCurrent.createDocument();
Item name = doc.replaceItemValue("name", "Mark Leusink");
name.setReaders(true);
name.setAuthors(true);
doc.save();
BTW: the fix in my app was easy: call a setAuthors(false) as well as a setReaders(true).
(this is either an actual field type on an actual document or I’m pretty good with Photoshop)
What happens if the field is defined in the form (visible placeholder, maybe hidden too), you edit the document and save it from the UI? Will it lose these double properties? I would be this will not work and the field will behave normally and your “hack” works only in the backend.
Nice one though 😀
Interesting… I created a document in the backend with the combined field on it and edited that throught the client. The field type doesn’t change (without the field on the form or with the field on a form as a text/ readers or authors field).
That actually makes sense programatically, since setting on or the other like that doesn’t automatically change the other.
Hi,
This is really awesome but I do have doubt on it… How does it segregates the people in single field like who are all can read the document and who are all can edit the document?
Can anyone explain me clearly????
Thanx in advance…..
It doesn’t: The document is only visible to all people (or groups, roles) in a combined readers/authors field and they are the only users with author access that can edit the document. Of course this also depends on other readers and/or authors field you have added to the document, but this is what happens with a single, combined readers/authors field.
Thanx Mark Leusink . . . !!!
Can you please explain me little more clearly????… Mark…
Lets consider this scenario, I do have a combined field(reader/author) in form, no reader and author field separately. Only combined field is there. In database 3 groups are there like Public , Member and Employee. Public Group having reader access in ACL, for Member author access and for Employee editor access. Now all these groups are in combined field. Now tell me who can read the documents and who can edit the documents?
Thanx in advance
Regards,
Manikandan M
Hi Manikandan,
ACL access always overrides document access. So in your scenario Public, Member & Employee can read the document, Member & Employee can edit it. No one that has access to the database and isn’t in one of those groups can read it.