WebQueryOpen vs. onLoad & Lock Status

HCL Domino Domino Forum
1

I have an edit button that sets a “lockstatus” field to locked or null. If a user clicks the edit button, it passes a URLQueryString that sets the field. This is fine… but am a bit confused on the best method to save. I’m assuming that WQO is no good because it saves prior to the setting of the field. I was getting duplicate web docs (same serial #, different docIDs) when using a mydoc.save… in the WQO. What about onLoad… after form loads but before user input. Could I call a JS funtion to save the form. The goal… once the lockstatus field is set, the doc should save. If not, other users will be able to see the edit button and save/replication conflicts will occur. The edit button has a hide/when that equals lockstatus=“locked”.

2

Subject: WebQueryOpen vs. onLoad & Lock Status

Well the approach which I followed is slightly different from yours -

  1. Created a new form (call it as lockform) which maintains the following details -

  2. Document Unique id

  3. Person Name who opened the document first

  4. Date and Time

  5. When the user opens a form and gets into edit mode then create an agent is launched from WQO which will create a new document based on “lockform” #1 above).

  6. OnLoad event of the form remove the Person Name or lockform document from database which indicates that no one is editing that document.

So, if either the Person Name is empty or if the lockform document itself is not present then allow the user to edit the document or otherwise alert the user of the same.

Date and Time gives me the handle of removing the Person Name (or probably delete the document after some time) as users may forget to close the browser window for several hours or days. So, this is just a precaution to free up the document for editing to other users.

All this is done on hub server.

Just an idea of whether this will suit your needs.

–Phani

3

Subject: RE: WebQueryOpen vs. onLoad & Lock Status

I’m still trying to figure out why 3 @commands cannot be used in the “edit document” button on the web. It complains about @function being out of context or something. Just wanted to do the following…

filesave - setfield then filesave… all in 1 button formula.

4

Subject: RE: WebQueryOpen vs. onLoad & Lock Status

I haven’t done this, but here’s an idea to simulate document locking:

  1. Have your edit document button call an agent (“/db.nsf/EditDocumentRequest?OpenAgent&View=YourView&DocUNID=1234556539459385”).

  2. The agent either:

  • stamps the doc as being edited and redirects the user to the true EditDocument url (“db.nsf/View/1234556539459385?EditDocument”)

or

  • redirects the user to a page or form that says somebody else is editing the document “db.nsf/DocAlreadyBeingEdited?OpenForm”. You could pass along the doc’s UNID and pull various fields for display such as who it thinks is editing the document, when they started editing, etc. Add a button there to allow appropriate users to unlock the document and voila - document locking.

You could obviously show the field in views, etc. If working across replicas is a large concern, you could track the locking via a hub server, as Phani suggested.

Now that I think about it, you might want to have the redirection actually take place via the view’s Form formula, so that anybody who just bookmarks or hand-types a “?EditDocument” url will still be redirected to the “locked” form as appropriate.

5

Subject: RE: WebQueryOpen vs. onLoad & Lock Status

Thanks for your feedback… tried adding a funtion in form’s onload and it is in an endless loop!