Document locking basics

Hi, this is hopefully the last problem for a while (famous last words!), and hopefully fairly simple.  The Notes help is not particularly helpful on this (or anything for that matter).  If I use @DocLock ([LOCK]) in a button formula and set the database properties to allow locking, who gets locked out when the button is pressed?  Everyone but the author?  And does it only work while the document is open for editing?  I know this feature is meant to prevent replication conflicts, but what I want to do is to lock all the fields in the form against editing once a final button is pressed (the button also closes the form - I've done that bit already).  When the document is reopened, only those people in a specific role ([SysAdmin]) will have edit access.  Everyone else including the author can only view.  I don't think @Doclock is the way to do that, since it doesn't seem to be working (and I suspect that is only works while a document is open for editing).  Can you recommend a simple formula (rather than Script) way to do this.  Thanks!  Maggie  nb, if this turns out to be more complicated than I think it will be, I'll put up the points.  
maggieballAsked:
Who is Participating?
 
Sjef BosmanGroupware ConsultantCommented:
You're right, that's not locking, that's Author rights. You need at least 1000 lines of LotusScript to ...

Kidding. What you need is what's called Authors fields. An Authors-field contains the names of people who can edit a document. Those people must already have Author-rights in the ACL. People not mentioned won't get edit access, unless they have Editor or higher access to the database.

I advise you to use two Authors-fields:
- a field Authors with the people allowed to edit while the document has status Open; the contents of this field may change during the lifetime of the document
- a computed (when composed) field AuthorsInternal, that contains only the role [SysAdmin]

The default formula for the Authors-field could be
    @UserName
0
 
maggieballAuthor Commented:
Thanks sjef, and good joke (I almost believed you after the last question)!  I've got an author field already (with @Username as the default). Just let me clarify what you're suggesting.  I add another computed author field that contains the role [SysAdmin].  Then I add another field for status which defaults to "Open" but changes when the button is pressed to "Closed".  How do I get the second one to override the first when when the status changes?  Wouldn't it be better to add the status field but just have one computed author field with an @If formula like this: @If(Status = "Open"; @UserName; "[SysAdmin]")?

The only problem with that is that I also want to limit access to those with edit (not just author) access to the database.  Perhaps (and I apologise for thinking outloud here) I could just use a role for author access rather than @UserName and include all potential editors in that role and just limit edit access to those who I want in the SysAdmin role.  That would probably work wouldn't it?  Thanks again!  I know this is basic stuff.  Maggie
0
 
maggieballAuthor Commented:
Actually doing it that way I wouldn't even need the "[SysAdmin]" role in the authornames field since they would be the only ones with edit access from the NAB and that would give them edit access even if the author field is blank.  So the formula would be @If(status = "Open"; @Name([Canonicalize]; @UserName : "[RptEditors]"; "").  Is that right?  Anyway I've accepted the answer, because I wasn't even thinking about using the authornames field for this, and of course that is the solution, which you've pointed me in the direction of.  Thanks again.  Maggie

0
 
Sjef BosmanGroupware ConsultantCommented:
If you want to limit Editors in their rights, you have several ways open:
- add some LotusScript to the QueryOpen event, that will prevent unauthorized people from opening the document (can be bypassed)
- add a Readers-field in which their name isn't present (they won't even see the document)
- make them Authors... (as you found out yourself!)

Normally (by my definition), in an operational database, there are
- 2 or 3 Managers
- 0 to 2 Designers (better use a template, and an approval mechanism so a Manager knows the design has changed)
- 1 to 2 Editors per office, who can correct or adapt whenever required
- the users have Author rights
- 0 Readers or Depositors

Last tip: one Authors-field is doable, I still prefer two. One Readers-field is asking for trouble, because when it has the wrong values nobody might get access to the document anymore! I always have two Authors and/or two Readers fields, one of them computed, with the role "[Manager]" in it. A server would then need this role to be able to replicate all documents. Without that role in a Readers field, it won't even see the document.
0
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.