locked
two user edit infopath form same time. RRS feed

  • Question

  • infopath form with 2 field. Field1 and Field 2.

    User 1 open the form and fill in Field1 ,but not yet click submit.

    User 2 open the form and fill in Field2.

    User 2 click submit. User 2 open the form and see the value of Field2.

    User 1 click submit.

    When open the infopath form, Field 1 was there ,but Field 2 was not. It is because xml of User 1 override xml of user 2.

    On the submit event, i just basiclly do Dataconnections["SharePoint Library Submit"].Execute().

    How to get around this?

    Tuesday, May 10, 2011 11:43 PM

Answers

  • 2 people cannot edit the same form at the same time.  If one user opens a form, it should be locked, and anyone else who opens that same form would get it in Read-Only mode.  What you've described above should not be possible.  There is no way to modify the same InfoPath file at the same time.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:31 AM
    Wednesday, May 11, 2011 4:45 AM
  • What Clayton said above is true.  Infopath puts a lock on a form when a user has it open in edit mode, so that any other user can only open it in read-only mode until the form is closed. 

    How are you naming the form? To me this almost sounds like a case of two users opening a new form, but their saves overwrite eachother's form because the form's name is not unique...

     

    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:31 AM
    Wednesday, May 11, 2011 12:34 PM
  • I have run into the exact same issue as Dealkk and can verify that it's real.

    It happens in scenario's where you have a browser-enabled form and you 'save' the form by actually submitting it to the library again with the same file name. I'm sure that when using the filler to complete the form it does lock it, it may even lock it when using the standard ribbon/toolbar save commands to save it. But in the scenario above where you update the form by resubmitting and overwriting you can definitely run into this issue.

    To solve this issue I used some managed code in the form. On load of the form I attempt to find the forms xml file in the sharepoint library and check it out. If I can check it out I let the user proceed as normal. If I can't check it out, I switch to a read-only view I created which gives a summary of the form and displayes a message saying who currently has the form locked out. When a user submits/closes the form I then check it back in as well.

    This works really great except when a user leaves the form using the back button or by closing the IE window or something. To counteract this I edited FormServer.aspx and put in some javascript to try and prevent this. *NOTE* editing FormServer.aspx is not a great idea, it's not supported by Microsoft and may be overwritten in updates/service packs, and if you screw it up you screw up all of your forms. In my case I had to stick with FormServer.aspx for certain reasons but if possible it's much better to copy it to say "CustomFormsServer.aspx" or something like that and to use that instead.

    Anyway, the changes I made were to put a function in the head section

    function confirmLeave(obj){
    	if(document.URL.indexOf("hostsitename") != -1){
    		if(g_objCurrentFormData[9] != "Summary" && PostbackBody.intPostbacksInProgress == 0){
    			return 'Closing this page will leave the form locked to you, please close the form using one of the forms buttons';
    		}
    	}
    }
    

    Basically I'm checking the URL so that it only applies to this particular form (we have other forms where there's no chance of multiple users editing and I don't need this to affect them). I then check g_objCurrentFormData[9], g_objCurrentFormData is an array of objects provided by forms services with info about the currently loaded form, [9] contains the curreently displayed view's title. In my case if "Summary" is the current view then the user doesn't have the form checked out and can exit however they'd like. I also check if there's a postback in progress, otherwise it'd stop the form posting back to itself when it needs to update.

    I then put the following into the body tag of the page

    onbeforeunload="return confirmLeave();"
    

    Onbeforeunload fires whenever the user tries to leave the current page, such as by hitting the back button, typing in a new URL, or closing the window. This calls my javascript function which carries out the above checks to determine if the user should be warned or not. If they should be it pops up the warning text which is returned, and gives the user an Ok and a Cancel button. (you can't actually prevent the user closing their browser or navigating away, and rightly so, but you can warn them and have the ok/cancel button).

    The combination of check out/in and javascrip tto try and prevent peopl leaving without checking back in has been working really well.

     

    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:30 AM
    Thursday, May 19, 2011 1:55 PM
  • I handled this a different way. I did input validation on the last modified date on the document in the document library. When the user opens the form, it does a CAML query to the SP Document library to get the lastmodified date.  When the user clicks save, it does another query to the Doc Library to get the current modified date. If the dates don't match, it will raise a validation error. The only way to clear the error is to close the form and re-open it. 

    I recently wrote a blog post about how I did it:

     

    http://sharepointchic.blogspot.com/2011/05/infopath-2007-validating-whether-form.html


    Meredith Blog: http://sharepointchic.blogspot.com
    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:30 AM
    Thursday, May 19, 2011 5:32 PM

All replies

  • Is this a browser based form or does the form opens in Infopath client? Not sure about the browser, but in my case, in Infopath client (version 2007), it already the form as "Read-Only" if the form is already opened by someone/somewhere else. So, this takes care of editing both at the same time as I can't submit it when it's in Read-Only.

    Regardless, what's your expected behaviour? When the 2nd user submits the form, should it not override the values that existed before, as that's what is happening in your case, I think.

    Are you wanting to keep information edited by multiple users on the same form?

     


    Pman
    http://www.pmansLab.com/
    Wednesday, May 11, 2011 1:38 AM
  • 2 people cannot edit the same form at the same time.  If one user opens a form, it should be locked, and anyone else who opens that same form would get it in Read-Only mode.  What you've described above should not be possible.  There is no way to modify the same InfoPath file at the same time.
    SharePoint Architect || Microsoft MVP || My Blog
    Planet Technologies || SharePoint Task Force
    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:31 AM
    Wednesday, May 11, 2011 4:45 AM
  • What Clayton said above is true.  Infopath puts a lock on a form when a user has it open in edit mode, so that any other user can only open it in read-only mode until the form is closed. 

    How are you naming the form? To me this almost sounds like a case of two users opening a new form, but their saves overwrite eachother's form because the form's name is not unique...

     

    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:31 AM
    Wednesday, May 11, 2011 12:34 PM
  • I guess i wasn't detail enough. Here is more detail of my case.

    requester1 fill out a web form and submit for approval. In my code behind, i send out two email to User1 and User2 for approval.

    User 1 open the form,but not yet click approve. [I create a View1 so when User 1 open, it will show this view to User 1]

    User 2 open the form and click approve while User 1 have the web form open.[I create a View2 so when User 2 open, it will show this view to User 2]

    User 1 then click approve.

    So there are basicly two approval event click. One for View1 and Other for View2.

    In View1_Click [i basicly save the name of User 1 "/my:myFields/my:Approval1" and call Dataconnections["SharePoint Library Submit"].Execute().]

    In View2_Click [i basicly save the name of User 2 "/my:myFields/my:Approval2" and call Dataconnections["SharePoint Library Submit"].Execute().]

    Afte User 1 click approve. User 1 name is save ,but wipe out User 2 name.

    Is it possible to save both name in this situation or away around this?

    Wednesday, May 11, 2011 3:44 PM
  • In the scenario you described above User2's approval actually never happened (so it didn't get wiped out - it never actually saves).  User2 would have actually been opening the form in read-only mode.  Since you're using code behind for the submit they're probably not getting the built-in submit error that the form cannot be saved because it's in read-only mode.  Therefore, User2 thinks they have successfully approved the form, but their approval got overwritten by User1.

    It is not possible to save both at the same time.  What I would suggest is have your flow go:

    Requestor Submits > User1 is notified that form requires approval > When User1 has approved notify User2 that the form is waiting for their approval 

    (instead of sending the form to User1 and User2 simultaneously)

    Wednesday, May 11, 2011 3:49 PM
  • Melli111,

    It not true. User2 approval did happen because when user 2 open the form after approve the name of user 2 is there. I think when user 1 have the form open it load xml ,but when user two approve. the xml never get reload to user 1 because page never refresh. I need to find a way to refresh the MainDatasource or somehow set a flag to allow only one user approve at same time. Part of requirement is parrallel approval so user 1 can approve first or user 2 can approval first.

    Thursday, May 12, 2011 9:20 PM
  • Are you able to recreate the issue using a simple basic form on a new form library? As others mentioned above, basically a form cannot be edited at the SAME TIME. It will open in "Read-Only" mode if the form is open already. When the form opens in "Read-Only" mode, you can change values of various fields on the form, but you just won't be able to Submit it, which means the changes won't be saved.
    Pman
    http://www.pmansLab.com/
    Saturday, May 14, 2011 2:54 PM
  • Hi dealkk,

     

    Would you please let us know how is your problem going? Is the suggestion helpful for your issue?

    If you need further assistance, please feel free to let us know.

     

    Thanks,

    Wayne

    TechNet Subscriber Support in forum

    If you have any feedback on our support, please contact tngfb@microsoft.com

    Thursday, May 19, 2011 2:26 AM
  • I have run into the exact same issue as Dealkk and can verify that it's real.

    It happens in scenario's where you have a browser-enabled form and you 'save' the form by actually submitting it to the library again with the same file name. I'm sure that when using the filler to complete the form it does lock it, it may even lock it when using the standard ribbon/toolbar save commands to save it. But in the scenario above where you update the form by resubmitting and overwriting you can definitely run into this issue.

    To solve this issue I used some managed code in the form. On load of the form I attempt to find the forms xml file in the sharepoint library and check it out. If I can check it out I let the user proceed as normal. If I can't check it out, I switch to a read-only view I created which gives a summary of the form and displayes a message saying who currently has the form locked out. When a user submits/closes the form I then check it back in as well.

    This works really great except when a user leaves the form using the back button or by closing the IE window or something. To counteract this I edited FormServer.aspx and put in some javascript to try and prevent this. *NOTE* editing FormServer.aspx is not a great idea, it's not supported by Microsoft and may be overwritten in updates/service packs, and if you screw it up you screw up all of your forms. In my case I had to stick with FormServer.aspx for certain reasons but if possible it's much better to copy it to say "CustomFormsServer.aspx" or something like that and to use that instead.

    Anyway, the changes I made were to put a function in the head section

    function confirmLeave(obj){
    	if(document.URL.indexOf("hostsitename") != -1){
    		if(g_objCurrentFormData[9] != "Summary" && PostbackBody.intPostbacksInProgress == 0){
    			return 'Closing this page will leave the form locked to you, please close the form using one of the forms buttons';
    		}
    	}
    }
    

    Basically I'm checking the URL so that it only applies to this particular form (we have other forms where there's no chance of multiple users editing and I don't need this to affect them). I then check g_objCurrentFormData[9], g_objCurrentFormData is an array of objects provided by forms services with info about the currently loaded form, [9] contains the curreently displayed view's title. In my case if "Summary" is the current view then the user doesn't have the form checked out and can exit however they'd like. I also check if there's a postback in progress, otherwise it'd stop the form posting back to itself when it needs to update.

    I then put the following into the body tag of the page

    onbeforeunload="return confirmLeave();"
    

    Onbeforeunload fires whenever the user tries to leave the current page, such as by hitting the back button, typing in a new URL, or closing the window. This calls my javascript function which carries out the above checks to determine if the user should be warned or not. If they should be it pops up the warning text which is returned, and gives the user an Ok and a Cancel button. (you can't actually prevent the user closing their browser or navigating away, and rightly so, but you can warn them and have the ok/cancel button).

    The combination of check out/in and javascrip tto try and prevent peopl leaving without checking back in has been working really well.

     

    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:30 AM
    Thursday, May 19, 2011 1:55 PM
  • I handled this a different way. I did input validation on the last modified date on the document in the document library. When the user opens the form, it does a CAML query to the SP Document library to get the lastmodified date.  When the user clicks save, it does another query to the Doc Library to get the current modified date. If the dates don't match, it will raise a validation error. The only way to clear the error is to close the form and re-open it. 

    I recently wrote a blog post about how I did it:

     

    http://sharepointchic.blogspot.com/2011/05/infopath-2007-validating-whether-form.html


    Meredith Blog: http://sharepointchic.blogspot.com
    • Marked as answer by Wayne Fan Friday, June 3, 2011 6:30 AM
    Thursday, May 19, 2011 5:32 PM
  • What would be the error message in the event log if one would have this issue. We do run infopath forms that mutiple people use but we have never had any users complaining about this. So i wonder if i could see if this issue happens by looking in the event log
    Monday, May 23, 2011 5:27 AM
  • It probably won't present in the event log, it's not really a technical error as such, there's no invalid event to write to a log. It's just undesired behaviour in most cases.
    Monday, May 23, 2011 1:55 PM
  • In case anyone else comes across this and needs a nice solution, I found what I needed here: <sorry, I can't submit this reply with a URL link.  But Google "Hilary Stoupa Check that Form Out (or in) Automatically". you'll find it>

    The solution makes use of the Lists.asmx web service using 3 data connections: CheckInFile, CheckOutFile and UndoCheckOut operations of the web service.  I turned on require checkout for the library, added OnLoad rules to checkout the file when form is opened, and checks it back in after the submit.  If user wants to exit the form, I've hidden the default Close button and implemented my own button with rules so that I can Undo Checkout, then close the form with an action.

    Tuesday, October 6, 2015 4:05 PM