I am trying to set a field (lockstatus) to “locked” when a user clicks edit button. A webqueryopen or formula with @isdocbeingedited will not work because it executes on opendocument. Goal… have lockstatus field set and form save on initial open then hide/when the edit button for all other users. The document save makes the edit button piece possible. I understand about other issues… user closes tab or entire window leaving web document in locked status. I’m addressing that with a window unload script + admins will have secret edit button for emergencies (loads in their subform only). So what is my biggest hangup? …getting the form to save after the user hits edit button!?! Please tell me this is simple… some computed element at end of document possible? I just want it to happen on initial open for edit. Thanks team…
Subject: Web & Document Lock
There is already a document locking functionality that you can apparently leverage.
Subject: RE: Web & Document Lock
I saw this posting but was a bit confused. It just seemed too complicated when (at least in our case) a hide/when formula in edit button would do the trick. This assumes that the file on initial open in edit mode is saved (lockstatus="locked)… and this should not be a problem since the document was already saved before and the only change is the lockstatus. Will look at that thread some more… just seemed too complex. 
Subject: RE: Web & Document Lock
Hide/whens are not security. You plan is easily defetable.
It may or may not be a concern to you, but don’t let the fact that it is ‘internal’ fool you into thinking it is not an issue. I run several applications on company intranets that still get probed or port scanned and whatnot. (Report it and they pretty much get a ‘hey, don’t do that’ from their bosses.)
What if a user simply changes…
‘http://yoursite/db.nsf/view/mydoc?opendocument’
to
‘http://yoursite/db.nsf/view/mydoc?editdocument’
…which any moderately astute Notes user could figure out?
At the VERY least I’d put a check on your flag in the Querymodechange event in your forms.
Subject: RE: Web & Document Lock
Thanks for the feedback… and I understand 100%. This is 100% internal and our users cannot spell “Notes.” They are not Notes users + the URL is masked (doesn’t have …?opendocument, etc.). I realize that users could right-mouse and find out the exact URL then add …?editdocument. They technically have rights to edit a document so it would not be viewed as security risk. An inconvenience… yes. If we see a replication/save conflict in the web view then we know. Just correct that 1… remove the child. We have been doing that w/o issues BUT it is a pain. There is no doubt that the hide/when option (though simple) would ~eliminate the ones we see today. Can I use the querychange… in a web app? I’ll research now… thanks for your comments.
Subject: RE: Web & Document Lock
I have done this on couple of apps for locking docs for web to web, web to notes and notes to web. the latter is eaiser because of notes built in lock mech. – 1. for locking out web user from notes first – if you have a hide when on the web edit button that does a lookup if the notes doc is locked then the button will not be available. 2. if both notes and web user are in read mode of the same doc & notes edit first, then the edit button will still be avail. for the web user, on the edit code you need to run some javascript with the available ajax dblookup code to check if the notes client have the doc lock and then prompt the user. 3 & 4. now to lock out the notes client and another web user if you have the doc in edit mode. first 3. locking out notes – when you edit the web doc yes you can use the webqueryopen and check if doc is being edited and run a agent which creates a another doc/form which you will use for your web locking doc(for more than one reason I don’t want to mimick the notes locking and write to a field that you are currenting opening, therefore create a new doc/different form). Once the form is created you have the doc lock. if a notes user or web user tries to edit the doc they have to do a lookup to see if a web lock doc exist for that doc based on unid. For example, if you have it lock and notes tries to edit, add code in the postopen and querymode change to do a lookup to a view to your lock doc, this will stop the notes user. 4. locking out the web user, same thing on the edit button use the javascript and ajax to do a lookup to your lock doc view and prompt them if a doc exist.Cleaning up your doc lock, you need code on the querysave to delete the lock doc if the user saves the doc. But if the user uses a close button on your app add code javascript that calls an agent to delete the lock doc. If the user uses the browser back button in the form event onOnload have javascript check if it in edit mode and if it is call your agent to delete the lock doc.
If your app is in a frameset and the form is on the right and the outline is on the left the user can click away to the outline and try to go to another view, this is the same if the user closes the browser – to delete the web lock doc you will need a settings field that you initialze when you open the doc in edit mode so say you set the field to “N” when you save or closes the doc you set it “Y”, if the user tries to click on the outline or closes the browser, in the onUnload write javascript that check the field if it’s “N”, prompt them with a messge and do a history.back twice which will run your delete agent. the javascript prompt allow your code to run even if the user tries to close the browser because the user have to press ok to the alert and your web lock doc gets deleted.
On my apps i also have a time out if the doc is edit mode for more that a certain time, which calls a javascript function that do a history.back which allows the onunload event to run which calls my delete web doc lock function.
To answer the comment if the user changes the url to ?edit mode, if your apps in a outline and the user opens the document they should not see the doc unid # and therefore should not be able to just type editdoc, also you can force users to user your edit button but that is a diff. discussion… sorry for the long message, may have left out a couple of steps also. let me know if you have any question.