Adding user to readers field in multiple documents
Dennis
I have taken over a small Lotus Notes network for a company. The problem is,
most of the documents in the database were created before I arrived and the
readers and authors fields in the documents contain the old administrators
name instead of mine. I have edited the formula used to calculate these
fields to now include my name, but I don't have access to the old documents
(and can't replicate them) unless I log on with the old admins ID. I can
open each document and re-save it to update the fields but there are several
thousand documents. Is there a way to add myself to the fields of all the
old documents at once?
Thanks,
Denns J. Devlin
dr...@mindspring.com
Stefan Deutzmann
write a agent (use the old admin ID) which adds your name to the reader
fields.
Or better:
Create a userrole [ReadAll] and add this role (with an agent) to the reader
field. This will give a user with this role access to all documents. No
problems with new admins ...
--
*********************************************
Cheers!
Stefan
stefan.d...@NO-SPAM-gmx.de
*********************************************
Dames
@Command([ToolsRefreshAllDocs]) in a button. I don't think there is a
good way around updating all the documents for reader/author fields in
my experience. I suggest running it right before you leave for the day,
because it will take a while for several thousand docs.
However, before you update every document, I suggest you stay away from
using names, and use groups and [UserRoles]. Add your name (and any
other needed Administrators) to a group. Add the group to the ACL and
put them into the role. Then you add the role(ie [Readers]) to the
author field of the form, so in the future if you add an Administrator,
you would simply need to add their name to the group. They will have
immediate access to all the documents. Also, by removing a person from
the group, the access is removed.
You can also create an agent to update just the readers and authors
fields with the [UserRole]. Using the @Command is more simple if you
don't mind letting it run over night. The Agent method would run
faster, because you are only updating a couple fields. The @Command
will update all fields in the document, which is a nice bonus if you've
made other changes to the form.
--
Dames, CLP
"Dennis" <dr...@mindspring.com> wrote in message
news:a40bk2$r51$1...@nntp9.atl.mindspring.net...
John Aylmer
You could use a group name but a role allows the group name to change
without having to update all the readers fields.
Look at simple action agent.
You will also have to clear the replication history and replicate with
options.
Jo...@Aylmer.com.au
"Dennis" <dr...@mindspring.com> wrote in message
news:a40bk2$r51$1...@nntp9.atl.mindspring.net...
Dennis
Here is the way that the old admin has it set up. Certain people can see
certain documents depending on who the document was assigned to via the
AssignedTo field. It's a mess and I'm not too sure how to convert it over to
User Roles (though I'd love to use them instead!!!). I'm not even sure I
understand how this whole IF/THEN statement works.
@If(
AssignedTo = "Fred Grigsby" | AssignedTo = "Dennis Devlin" | AssignedTo =
"Daniel Smith";
"Fred Grigsby":"Dennis Devlin":"Daniel Smith";
AssignedTo = "John Melia" | AssignedTo = "Ronald Burke";
"Fred Grigsby":"Dennis Devlin":"Daniel Smith":"John Melia":"Ronald
Burke";
AssignedTo = "Alba Carter" | AssignedTo = "Linda McDaniel" | AssignedTo =
"Mark Lamb" | AssignedTo = "Greggory Lamb" | AssignedTo = "Kathy Robarts";
"Fred Grigsby":"Dennis Devlin":"Daniel Smith":"Margie Lamb":AssignedTo;
"Fred Grigsby":"Dennis Devlin":"Daniel Smith":AssignedTo)
If there is an easier way to do it with Roles, I'd love to learn how to do
it. If anyone has time to decipher this mess and come up with an idea, I
would be grateful. If not I guess I'll just have to run the refresh command.
By the way, thanks for taking the time to respond.
Dennis
"Dames" <dame...@REMOVEsio.midco.net> wrote in message
news:3c63...@nntp01.splitrock.net...
Dames
Cool. A story problem. I used to like those in school (even though I
usually solved them the unconventional way). :) Okay, let's
see how to break this down...
[Roles] and Groups are used to prevent this type of coding. It may
take a little thinking, but hopefully we can get rid of the names.
The first statement checks for Fred, Dennis, or Daniel... if found, then
all are added to the AssignedTo field. We can start by substituting the
last part with a [Role].
So:
@If(AssignedTo = "Fred Grigsby" | AssignedTo = "Dennis Devlin" |
AssignedTo = "Daniel Smith"; "Fred Grigsby":"Dennis Devlin":"Daniel
Smith";
Becomes:
@If(AssignedTo = "Fred Grigsby" | AssignedTo = "Dennis Devlin" |
AssignedTo = "Daniel Smith"; "[FG_DD_DS]";
In the ACL, if you assign Fred, Dennis, and Daniel to the [FG_DD_DS]
role, then the above part of the statement works. That makes it a
little better, but now we need to go further by eliminating the names
completely. Unfortunately, Notes Formula Language doesn't provide a
method to test whether someone other than the current user is in a Role.
I may be wrong on that, but I couldn't find a method to do so. If you
wanted to use LotusScript, then we could do this entirely with Roles.
Using Formula we can do this with groups. There are plusses and minuses
to both.
In the Pub. NAB, create a new group "FG_DD_DS" as an Access Control List
group type. Add your 3 people to the group. Add the group to the ACL
of your database, and assign your [FG_DD_DS] role to the group. Then
your statement becomes:
@If(@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache"
; "86256A6B:0068E913" ; "($VIMGroups)" ; "FG_DD_DS" ; "Members" );
","))); "[FG_DD_DS]";
The "86256A6B:0068E913" would be your Pub. NAB's replica ID.
"($VIMGroups)" is the view. That should be a standard view in your NAB.
"Members" is the column. This looks up the NAB to see if AssignedTo is
in the FG_DD_DS group.
The next part of the Statement:
AssignedTo = "John Melia" | AssignedTo = "Ronald Burke"; "Fred
Grigsby":"Dennis Devlin":"Daniel Smith":"John Melia":"Ronald Burke";
Becomes:
@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache" ;
"86256A6B:0068E913" ; "($VIMGroups)" ; "JM_RB" ; "Members" ); ",")));
"[JM_RB]:[FG_DD_DS]";
"JM_RB" is another group to add to the NAB.
The next part adds a new twist:
AssignedTo = "Alba Carter" | AssignedTo = "Linda McDaniel" | AssignedTo
= "Mark Lamb" | AssignedTo = "Greggory Lamb" | AssignedTo = "Kathy
Robarts"; "Fred Grigsby":"Dennis Devlin":"Daniel Smith":"Margie
Lamb":AssignedTo;
Becomes:
@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache" ;
"86256A6B:0068E913" ; "($VIMGroups)" ; "AC_LM_ML_GL_KR" ; "Members" );
","))); "[FG_DD_DS]":"[ML]":AssignedTo;
The [ML] role would only be assigned to Margie Lamb in the ACL. The
"AC_LM_ML_GL_KR" group wouldn't even need to be in the ACL (or at least
not assigned any roles).
This final part of the statement:
"Fred Grigsby":"Dennis Devlin":"Daniel Smith":AssignedTo)
becomes:
"[FG_DD_DS]":AssignedTo)
The end result is:
@If(@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache"
; "86256A6B:0068E913" ; "($VIMGroups)" ; "FG_DD_DS" ; "Members" );
","))); "[FG_DD_DS]";
@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache" ;
"86256A6B:0068E913" ; "($VIMGroups)" ; "JM_RB" ; "Members" ); ",")));
"[JM_RB]:[FG_DD_DS]";
@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache" ;
"86256A6B:0068E913" ; "($VIMGroups)" ; "AC_LM_ML_GL_KR" ; "Members" );
","))); "[FG_DD_DS]":"[ML]":AssignedTo;
"[FG_DD_DS]":AssignedTo)
Now I see there is a bit of redundancy in the statement. Because
[FG_DD_DS] will always be assigned, the first part of the statement can
be eliminated while keeping the same results.
Here is the new and final statement:
@If (@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" :
"NoCache" ;
"86256A6B:0068E913" ; "($VIMGroups)" ; "JM_RB" ; "Members" ); ",")));
"[JM_RB]:[FG_DD_DS]";
@IsMember(AssignedTo ; @Name([CN];@Explode(@DbLookup( "" : "NoCache" ;
"86256A6B:0068E913" ; "($VIMGroups)" ; "AC_LM_ML_GL_KR" ; "Members" );
","))); "[FG_DD_DS]":"[ML]":AssignedTo;
"[FG_DD_DS]":AssignedTo)
The Groups in your NAB are:
FG_DD_DS = Fred Grigsby, Dennis Devlin, and Daniel Smith
JM_RB = John Melia and Ronald Burke
AC_LM_ML_GL_KR = Alba Carter, Linda McDaniel, Mark Lamb, Greggory Lamb,
and Kathy Robarts
In your ACL:
FG_DD_DS group is assigned the [FG_DD_DS] role
JM_RB group is assigned the [JM_RB] role
Margie Lamb is assigned the [ML] role
Wow, this has turned into quite a story. Anyway, this method should
work. I would choose more descriptive names for your groups and roles
if possible. (i.e. [AP Supervisors], [Administrators], rather than
[FG_DD_DS], etc.) Or use existing groups if they are already set up.
Making this change will make life much easier when personnel changes are
made in the future. When a supervisor leaves, you can simply remove
them from the group in the NAB, and add the replacement's name. (Or in
the case of Margie Lamb, rename her ACL entry to the new person while
leaving them assigned to her [ML] role). You won't have to update any
of the documents.
Unfortunately, after making the change, you will still need to update
all the old documents once to reflect the change. *
@Command([ToolsRefreshAllDocs]) * Of course, make sure you test it
thoroughly before doing so. :^)
If you have any questions, let me know.
--
Dames, CLP