Authors field using multiple values from roles and field names

i have a database where documents should only be editable by the document author and the project manager.  I can't seem to get the author field right; whenever i release it to the users, they can only read the documents.

I have a computed field called AccessList, set to Authors allow multivalues.  Here is the latest code I've tried.

FIELD ProjectMgr := ProjectMgr;
DocMaker := @Name([CN];@Author);
ProjectMgr :

All users have author access to the DB and all fields are set to "must have at least editor access to use"

What's the easiest way to set the author field to the names specified in the ProjectMgr field as well as the author of the project document?
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

I notice that you're using [CN] in your field formula. Unless the common name is listed first in the NAB's person documents under "user names", you should use the canonical or abbreviated format.
You also use @Author. You are aware that this function only returns the values in the 1st authors field on the document?
Do check that field and ProjectMgr as well for common names!
Sjef BosmanGroupware ConsultantCommented:
Indeed, the internal value of an Author-field is in canonical form. Suggested field and formula:

      Author names, computed when composed


For this to work, the project manager field needs to be copied over from a previous document. The Admin-role is more for Reader fields actually, but it might come in handy if you also have a Reader-field on the form.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
everetjoAuthor Commented:
I'm still so green.  so, computed when composed with @username includes the author and locks the field so the next @username doesn't get added.

Is there a way that I could use @isdocbeing saved and @set field to append the projectmgr names after the author saves his draft ?
Cloud Class® Course: Microsoft Windows 7 Basic

This introductory course to Windows 7 environment will teach you about working with the Windows operating system. You will learn about basic functions including start menu; the desktop; managing files, folders, and libraries.

There's no need for @IsDocBeingSaved. The Author field is only checked when the document is opened, so it doesn't matter if the value changes a dozen times while being edited. Only the value that was current when it was being saved matters anyway! So just let it compute whether being saved or not.

Computed when composed on any field just means that the fields value never changes once it is calculated the first time. Normally this happens as the form is being opened the first time for each new document... though it could also calculate if you added the field to a form after a document had already been saved with the previous version of the form. Since the previous version of the form did not have the field, it doesn't exist on the older documents. The next time the document is oepned, it calculates. If that value is ever saved, it stops calculating it. Computed when composed would also execute again on a document if you used a macro to remove the field from a document.

In your case, yes, once it is calculated the first time the doucment is opened, it never recalculates, so your author or project manager changes are not refelected in the field. if you use a regular computed field instead, then that problem goes away. true, the field calculates every time the document calculates, and probably needlessly (since the underlying fields don't change), but it is a really tiny calculation.

Another way you can handle this is to have two separate fields of type AUTHOR. Let the project manager field itself be an author field, and let there be another field, computed when compsed, containing the current user name. The user name field never changes, since you want that to be the person who created the document.  So it can be computed when composed, type AUTHOR, formula @Username. The project manager field can be whatever you currently have, but instead of being type NAMES, it is type AUTHOR, which allows the project manager to edit the document.
everetjoAuthor Commented:
This is great stuff.  

so assuming I have two authors fields: one is editable for the project manager, one is computed when composed for the @username, how do i set the field security to enforce the author access?  do I grant author access to the database for my restriction group and set the fields to " must have at least editor access to use"?
Sjef BosmanGroupware ConsultantCommented:
Author fields limit only users with Author rights in the database. Editors or higher can always modify the documents they see.

Now what exactly do you want? Do you want the creator of a document to be able to modify the project manager field in a document? I suppose not, so indeed you'd need that "editor access" option enabled on that field. A consequence of this would be that the current project manager can give documents away to anyone he likes (or dislikes). Is that also what you want? Or is there some project hierarchy in your database, where you specify the project manager at the top, and all depending documents should be marked with his name? I know I might make things a bit complex here, but I think it's essential.
Set everyone in the ACL to Author, except system administrators. The creator will still have the ability to edit his own stuff, because he is in one of the author fields (the unchanging, computed when composed one). The manager will also be able to edit the appropriate stuff, because the other author field lists him. So, for each appropriate document, they are both authors in the ACL and authors of the document... Notes matches the two up, and grants access.

(In contrast, if the ACL shows Reader and you are in the author field, you still only have reader access, because the ACl limits your scope throughout the database. And if you have Author in the ACL, but you aren't in any of the author fields, you can't edit that document, because as an ACL Author, you are specifically granted rights only to those documents where you are in an AUTHOR type field.

(In further contrast, if you are in the ACL as Editor, then the Author fields don't matter to you. You automatically have the ability to edit every document regardless of the listed AUTHOR field values. There are also some additional rights you will have as Editor that Authors may never have. However, if you have code that changes the way the application behaves to a user listed in the field or not listed in the field, your applications controls will be separate from how Notes grants access. That setup is fairly sophisticated, and probably not what you have to deal with.

(I would NOT grant the manager EDITOR access in the ACL, unless all managers are to have access to all documents. Normally, you would have several managers, and each is repsonsible for the documents of the employees each is responsible for, and no others.)
Sjef BosmanGroupware ConsultantCommented:
Ah, problem solved.

BTW what more does it take to get an A ??  ;-))
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Lotus IBM

From novice to tech pro — start learning today.