Make a field editable only by a certain role?

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.

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.

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...

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?

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.

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.

The only thing I am duping like that is tests.  They can have up to 20 tests on plastic samples that have specs and values...so 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.

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:
http://www-10.lotus.com/ldd/bpmpblog.nsf/dx/dynamic-table-1?opendocument&comments

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?

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.

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...

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.

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...