Make a field editable only by a certain role?

Please tell me there is a way to make specific fields in lotus notes editable only by certain roles.  As in, anyone else can still SEE the field, but not update it.  I have a large form and the small company I am building it for wants this functionality.  I know how to hide by role, etc...but they still need to SEE the fields.  There are a zillion fields too.

I know a patchwork resolution would be to create two fields for every field and have the one be computed, but good lord that will take me forever.  Help!
Who is Participating?
mbonaciConnect With a Mentor Commented:
Here it is (from designer 6.5 help):

You can control access to parts of documents by creating access-controlled sections on forms that allow specified users to see restricted parts of documents.
To create a controlled-access section
  1.      Highlight the text, fields, and other design elements on a form that make up the section.
  2.      Choose Create - Section - Controlled Access.
  3.      (Optional) In the Section Properties box on the Section Title and Border tab, edit the section title.
  4.      (Optional) Enter a Section Field Name.
  5.      (Optional) Choose a border style and border color for the section.

You can insert fields and other design elements into the section after creating it. To append design elements to the bottom of the section, set the border style as a box. When you have finished appending design elements, set the border style to no border.

To name the editors for a controlled-access section
  1.      Click the section title.
  2.      Choose Section - Section Properties.
  3.      Click the Formula tab.
  4.      Select Editable as the section type to allow the document creator to specify the section editors.
  5.      Select one of the Computed types to use a formula to define the section editors.
  6.      (Optional for an editable field; Required for a computed field) In the Properties box, write a formula to define who can edit the field, and click the check mark.

Note  When you specify names for section editors, use the full hierarchical name for each user if there is a chance this database will be copied or replicated to another domain. Within a domain, an abbreviated, or common name, is sufficient for user authentication, but between domains, you must supply the full hierarchical name or authentication will fail.

To make a controlled-access section collapsible
  1.      Click the section marker and choose Section - Section Properties.
  2.      Click the Expand/Collapse tab and select options for showing the section expanded or collapsed, depending on whether a document is being previewed, printed, or opened.
  3.      On the same tab, click the "For Editors" list and select "For Non-editors." A list of options appears for displaying the section to users who can read but not edit the section.
  4.      (Optional) Select "Hide title when expanded" if users who are non-editors don't need to see the section title when the fields are displayed.
  5.      Save and close the form.

Hope this helps,
You have to use "Controlled access section".
That's form design element that allows you to specify user names or roles that can edit its contents.

Locate it in Designer help, it's explained very comprehensible.
Sjef BosmanGroupware ConsultantCommented:
That would be the proper way to handle this indeed.

Now for the old-fashioned way, that will do what 99% of the designers want, at the expense of a less secure document. I'll explain later why.

Create two paragraphs (paragraphs are separated by a linefeed or column border) with different hide-when formulas. Give the first an editable field, and a hide-when formula to show the paragraph only when the user has the required role. The other paragraph can have a display-only field or computed text, with the inverse hide-when formula.

Example of two paragraphs, e.g. in one table cell:
      FIELD abcd
      Computed text showing abcd

As to the "why": a user can still update the fields using an agent; this is impossible using a controlled access section. It's less safe, yet much easier to implement.
Free Tool: IP Lookup

Get more info about an IP address or domain name, such as organization, abuse contacts and geolocation.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

onederwomynAuthor Commented:
Hi sjef....that is what I was referring to as my patchwork solution.  They do pretty much want things in sections (they already are in sections, just no access controlled).  So, the proper way may actually be the easier way.

Thanks both of you for your help...
I will hopefully be back in a few days to close this one out...
Sjef BosmanGroupware ConsultantCommented:
You're right then, you'd need Controlled Access sections. But beware: the existing documents won't follow the rules you define for the form with the CA-sections. Why not? The implementation of a CA-section includes a special Author-field that governs access to the CA-section. If such a field doesn't exist (which it doesn't in existing documents), no special access rules are applied to the section...

And, errr... a zillion fields, you say? Forgive me, but that smells like a poorly designed database. I hope it's not yours... Is there anything you/we can do about that?
onederwomynAuthor Commented:
Ok, it isn't a zillion fields.  I guess that was an exaggeration...but I have no doubt it is poorly designed, as I am a hack at this and have never claimed otherwise:)

Luckily, this hasn't been put in production yet, so it is the perfect time to do the access controlled sections.
Sjef BosmanGroupware ConsultantCommented:
Why so many fields then?

What is rather common in some forms is the duplication of fields of more or less identical type, e.g. User_1, User_2, User_3, until User_100. That can be avoided, by cleverly using multi-value fields.
onederwomynAuthor Commented:
The only thing I am duping like that is tests.  They can have up to 20 tests on plastic samples that have specs and I have test1, test2 up to 20...along with all the fields associated with that test.  Most of the other fields are single value, one time input.
Sjef BosmanGroupware ConsultantCommented:
And these tests-fields should not be in a separate document? As a response document to the main document? That would clean up things nicely. It would also deprive you of the possibility to use the content of those fields on the same line as the main document in a view.

Or else, if the document is in fact a tests document, you could use multi-value fields and a dialog-box to handle those fields and values. For instance, there are these fields test1-20, result1-20, comment1-20, quantity1-20, colour1-20, etc1-20. Instead, you could have the multi-value fields test, result, comment, quantity, colour, etc. It requires a dialog-box and some code to handle these fields in a practical way.

I developed my own code before I found this:

I use it all the time for orders and invoices. Each invoice line is an entry in several fields, with identical indexes, so one "record" consists of: test(3), result(3), and so on.

For the rest, there are no fields that, logically speaking, are in the wrong place? Meaning, all fields on the form are all related to the same entity? If you had to use an SQL-database, would you have stored all data likewise, in a single table?
onederwomynAuthor Commented:
Yeah -- the rest of the stuff goes together as one instance of a complaint.  Customer, product, comments from various  departments, and corrective action type stuff.  But, it all has to do with that one complaint instance.  I pull the lists through dialog boxes from other views dedicated to them.

Like I said, I am a hack;)  I do what I know how to do.  I am going to read up on the multi-value fields now.  I am always adding to my arsenal of stuff I can do...

Thanks for your help.
Sjef BosmanGroupware ConsultantCommented:
But isn't it so that there is one complaint, with possibly multiple comments, tests and multiple corrective actions? Thinking out loud, and also thinking in terms of access rights to documents (instead of fields), wouldn't it be a lot more practical to separate that one complaint into many separate documents? Each document can have its proper authors, readers, reviewers, approvers and status. It might make things too complex, of course...
onederwomynAuthor Commented:
Yeah, that would actually make it too complex.  It is a pretty simple form with very few actions, it just has different sections for people to put their comments in.  That's all.

My big problem now is that two of the groups that have sections to fill out only use lnotes pulled across the internet and not the thick client.  They didn't tell me this when giving me requirements.  I have never dealt with that and am pretty sure I cannot make it work for those people.  They can see the document, but cannot update it.
Sjef BosmanGroupware ConsultantCommented:
When working with Domino/Notes databases, try to avoid updates, and certainly updates done by multiple people. Sometimes it is far better to keep data is it is, so you could have a whole discussion related to one complaint, with many remarks etc. Writing and analysing requirements for a Notes database is not a trivial matter, due to the many pitfalls that lie ahead...
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.