Group Names and Readers Fields - Design a form

I have researched this site and have not found exactly what I am looking at or if I did, I didn’t realize it. I have done a “little design work in Notes”.

We have a database that we would like to post various reports/attachments for users to see. I have a form with various text fields(mainly), this form will then be emailed with a document link for others to open the databae to READ the documents.

One field is called REPORTTO, the user selects a GROUP from our PAB address book to receive this mail document.

What I want to be able to do is say that whoever is in the field REPORTTO is the only people/group that can READ the document. The REPORTTO could be various GROUPS setup in our PAB. Also, the 1 user generating these documents, needs to be able to see all documents in database. How can I do this?

Example: Financial Statements should be seen only by ACCTGRP, Manufacturing Reports should be seen only by MFGGRP. Both groups will use the same database, but I only want each group to see their own documents.

Could anyone point me in the right direction. I have tried Readers Fields and setup roles, but I’m thinking my logic is not correct.

Any suggestions, direction would greatly be appreciated. Thanks Much!

Subject: Group Names and Readers Fields - Design a form

The REPORTTO field could be defined as your readers field. Group names do work in readers fields. For the one or more people or groups that would need access to everything, I normally set up an Admin role to be assigned to them in the ACL. Then add a hidden Readers or Authors field onto the form with that role.

Hope that helps.

Subject: Group Names and Readers Fields - Design a form

What I would do is create a Computed Field of the Type Readers. Also I would create a Role in the ACL and call it say [DBAdmin] (or whatever is appropriate) Now assign that role to the person that you want to always read everything and give them Editor rights or whatever is needed. I would not put this person in the ACL explicitly but via a group, this will save many headaches if the person leaves. Now in the Computed Readers field if ReportTo is null leave the computed field = “”. If ReportTo contains some information then Concatenate [DBAdmin]: ReportTo this way you will never strand any documents so that no one can read them but yet easily work with the Readers field. Unfortunately I have seen the Readers field jump up and bite far to many times and documents are lost forever because the Readers field has a spelling error in it. Also if the database is to be replicated and or manipulated by a server based agent you might need to do something like “LocalDomainServers:[DBAdmin]:ReportTo”, working with the ACL is not hard but you really need to think through what you are trying to accomplish.

Subject: RE: Group Names and Readers Fields - Design a form

Hi Bill,

I followed your directions and now the DBAdmin person can now see the documents, along with myself, however the other “test” person in the GRP cannot see the document in the view. The user gets the email, but then gets Not Authorized to document. I noted that if I look at the document properties of that particular test document and look at the READERS field, it has of [DBAdmin], my name which looks like this “CN = FN LN/O = Organizationname”, however the other test person in the documents name is like this "CN = FN LN/O = Orgazniationname@ourdomain. I’m suspecting that the Notes client is looking at the user id in the Notes.ini which would be like mine above and is not finding hers because of how her name appears in the Reader field, any suggestions to this?

Subject: RE: Group Names and Readers Fields - Design a form

appending @domainname is the problem. OK for email not reader fields. use canonical format (like how yours is showing)

Subject: RE: Group Names and Readers Fields - Design a form

Mike,

I apologize, but I’m still learning, do you mean @Name([CN])? Where and how do I use this?

thanks much.

Subject: RE: Group Names and Readers Fields - Design a form

No, that would return the common name portion (FN LN) of the name, only.

The question is how you fill the field right now. What makes the @domainname appear behind the name? If you get rid of it, you’re probably done.

However, let me suggest, that it might be more future-proof to keep the [DBAdmin] Role in a separate readers field (computed when composed). This would be more robust in the case that you might have to manipulate the readers field later on, because even if anything goes wrong, [DBAdmin] will still always be able to read the document. Not that important, but I prefer this approach.

Subject: RE: Group Names and Readers Fields - Design a form

So can anyone tell me where to look to determine why this field is returning @domainname.com when I use a Group that is on our server, and has 3 members in the list. My name is correct, but not the others and I believe this is why the form is not correct.