Agent to change allowed reader field value ?? 1

[dc2502]

Is there a simple agent which could change the value of the allowed reader field in a notes database.

We have a customer management database and have decided to change the name of the groups who have access to certain areas. This means changing the value in the allowed readers field for every single customer. It has to change the values in response documents as well.

Can anyone help ????

 

[fishkake]

OK, I'm a beginner myself, but here's my attempt...

If the allowed reader field for the customer document has the same name as the allowed reader field for the response/activity documents, then all you need to do is create a server-side agent which selects all records, and set the following code in the "initialize" Part of the agent:

SERIOUS DISCLAMIER!! Don't take this code as gospel!! I'm a beginner myself, and I haven't tested it, this is just off the top of my head. Please please please don't release this amateur code into a real system, make a copy! And anybody else who reads this, please correct it if it is wrong!

dim s as new notesSession
dim db as notesDatabase
dim col as notesDocumentCollection
dim doc as notesDocument

set db = s.currentDatabase
set col = db.AllDocuments
set doc = col.GetFirstDocument

For iV = 1 To col.Count
doc.YOUR_READER_FIELD_NAME = "NEW_GROUP_OR_ROLE"
set doc = col.GetNextDocument
Next

This should do the trick, the only things you need to change are the capitalised bits, to be replaced with your own data. Personally I recommend setting a "Role" to configure the rights, as this is far more efficient the next time this happens!

 

[LNotesGuy]

Be careful if the current reader field contents contains multiple values, such as 'Notes Administrators', LocalDomainServers, OtherDomainServers, or some other sort of Admin group or role IN ADDITION to the groupname that you're wanting to replace. If it does - and you simply replace the multiple existing contents of this reader field with only the new groupname - you might end up locking yourself out of being able to view the document(s) after your agent is finished running. Ouch! Release 6 has a new feature that allows the Notes Admin to assign special rights a group of People or specific individuals to prevent this form of foopa from happening, but if this is a pre-release 6 implementation, you can burn yourself quickly, i.e. not be able to see your documents to correct them if you mess up. I would highly recommended you have a backup of the entire db BEFORE executing this form of an agent. If there are replicas of the db, I would first force replication to get all documents in sync with other replicas, maybe hold off until the end of the production day or weekend when there is no or little activity before executing this agent. Then, as another precaution, I'd even temporarily disable the replication of the target db during this process JUST in case you need to restore the db. You don't need to replicate your mistakes around if your agent goes south and cause yourself more headaches. This form of process can be very unforgiving if you botch it up. If you use Roles, don't forget to include the left and right brackets within the role name. If there are multiple values in the field, make sure you concatenate the values correctly before committing them back. Finally, I would write the agent to run only on selected documents first and test it on a few documents only before turning it loose against the entire db. Not knowing what your application security requirements are, you might want to consider even creating a hidden, computed, multi list Readers field with entries like LocalDomainServers:OtherDomainServers:"Notes Administrators" (or whatever your Notes Admin groupname might be)and add that to your document(s) first. That way, your Notes administrators (or server ID's at the console) can at least get access to the document if you inadvertantly mis-code your agent and have to run it again. Notes will concatenate all multiple Reader fields it finds automatically to determine the effective ACL for a given doc. One last thing, if a Notes username is contained within this Reader's field, make sure it goes back (assuming you do any form of string extraction stuff in your agent) as a fully qualified user name, i.e CN=Joe User/OU=OrgUnit1/O=ABC, not the abbreviated or common name format. Readers fields need fully qualified names in order for them to work correctly. I realize this post involves no code solution offerings, but these points need to be considered none the less. Let's just say that I've 'been there, done that'. Good luck!

 

[fishkake]

That is some seriously good advice in there!

I had rather stupidly forgotten that my code above would remove any existing readers. What a good thing it is that there are people like you out there to correct me!

Perhaps instead of using the dot notation, this would make more sense :

For iV = 1 To col.Count
doc.AppendItemValue("YOUR_READER_FIELD", "NEW_ROLE")
set doc = col.GetNextDocument
Next

Mr. Notesguy? Opinions?

 

[pmonett]

As far as Reader Access is concerned, my experience has taught me these rules :

1) Seperate access types and assign a field to each type
2) Always include a "super access", in case you have to recover from a mistake.

So, here comes the lengthy explanation. Bear with me - for your own good !

Notes is a great document management system. Reader fields give an enormous amount of flexibility, and are very powerful in defining groupes of people who can access a document.
There are very good reasons to use Reader fields. Limiting access to client profile documents, preventing users from viewing other users HR information, or simply preventing a document from being accessed before it has been approved for publication.
All these scenarios are quite common, and Reader fields are what makes them possible.

The Reader field is quite simple to understand : if it exists and is not empty, then only the users listed in it have access to the document.
But there is one little detail : ONLY those users listed in it have access !
Indeed, Notes is a unique system in that it is the only existing system that can COMPLETELY LOCK OUT everyone INCLUDING the administrator ! No user has default access to all documents - not even the server !

So, when implementing ANY kind of reader access, you need to ALWAYS include a reader field with "LocalDomainServers", as well as ANOTHER field, a "super-access" field, in addition to the normal working fields (the ones giving reader access to the users that need it). Now, following the sensitivity of the users, the super-access field can have different types of definitions :
- If the information is not of the HR kind, nor top-secret-company-confidential-code-red stuff, then the super-access field can simply hold the Administrator groupe, or any other groupe name dedicated to high-level technical tasks (ie users who have a clue and are reliable).
- If the information is more sensitive and should not bear a default "back door", then you can put a role name in there - without creating the corresponding role in the ACL. So, the access will be there, but only the db manager will, in effect, be allowed to create and assign the role if and when the need arises, deleting it when the job is finished.
- If the data is really top secret, then assign a non-existing user name, like Super Man or something. Document this feature and have the users - or client - agree to it. The advantage of this is that as long as the administrator has not created the corresponding ID, the access is useless. And it should be easy to set up a protocol requiring at least one managerial approval before the admin is allowed to create that specific ID file - which can obviously be destroyed after use.

With these precautions, your form should therefor contain :
1 server access Reader field
1 emergency access Reader field
1 (or more) normal function Reader field

Why more than 1 "normal function" Reader field ? Say the application requires the original author of the document to retain access to the document throughout the life of the document, but he must lose Editor access to it after a certain status. Typical example would be a Vacation Request - the author creates it, but once it is submitted for approval, he should obviously not be able to modify it. Yet, he needs to know if it has been approved or not.
In this kind of situation, we have an author and an approver, but we also have the HR department that needs to know (yet has no authority to approve or refuse the request).
In this case, I would have a Reader field get the name of the author on creation, and a Reader field with HR access. The approver would obviously be in an Author field.

Of course, for documents that are public before/after being private, the server access and emergency access fields need to be empty when the document needs to be public (as do all other Reader fields).
That means that you, as developer, must think of controlling the status of these fields in the functions that change the public/private status of the document. it all depends on the workflow that has been defined, so I cannot list all possible configurations.

But one thing is sure : if you do not correctly manage your Reader fields, then one day the documents will fall prey to the Exclusion Syndrome. Everyone knows the document was there, but NOBODY can see it because there is a Reader field in there that was incorrectly set, and no backup access to correct the situation.

And there is NO WAY to recover from that if you have not followed the rules above.

Pascal.

 

[ABOzIT]

Great advice Pascal.

Have a star!