submit once

bea

Active Member
Hi,
I noticed another issue and don't know how solve:

I've a form with several script running on final submit. When a user now has 2 tabs open with the same form, he can submit both. One of the script generates the next record and the results are 2 new next records.

In F2 there was the plugin submitonce to prevent double submit.

Cheers,
Bianka
 
Hi troester,
I've checked my old F2 files. submitonce was part of the form.js plugin:
Code:
//class name needs to be the same as the file name
var submitonce = new Class({

    initialize: function(form)
    {
        this.form = form; //the form js object
    },
 
    //called when a repeat group is duplicated
    onSubmit: function(event){
        $('fabrikSubmit'+this.form.id).disabled = true;
        $('fabrikSubmit'+this.form.id).value = 'Speicherung läuft....';
    }
});

I needed this in the past, to prevent running script twice on double click.

Also I've found this on J2.5 Fabrik forums: http://fabrikar.com/forums/index.php?threads/submit-once-a-form.22360/

The lockrow doesn't work for the same user, if he opens 2 tabs with same form.

Cheers,
Bianka
 
I think in Fabrik3 you have a form option in Form processing "Show loader" which prevents double submission on double click.

But I don't know if this will do if the user has two browser tabs open with the same form (why is he doing this).
 
I could probably tweak lockrow so the second form wouldn't submit, after the first submit unlocks it.

-- hugh
 
BTW, that "submitonce" JS you found doesn't stop submissions across different instances of the form across browser tabs. It just prevents "bouncing", by disabling the Save button as soon as it's pressed, so it can't be pressed again and trigger a second submit on the same form.

OK, so with 'lockrow' ... what I could do (the "cheap" way that requires very little work) is to add an option to the lockrow element for "Allow Owner to Edit Locked" (or some such), for which "Yes" is the current behavior. The lock owner can edit a locked row. It's only locked to others. If the lock owner edits an already locked row, it simply re-starts the lock clock (so sets the lock time to "now", which extends the TTL).

So being able to set that to "No" would then not allow a lock owner to re-edit the row, so if they try and open a second tab while the lock is still in force - ie. a form has been opened, and not submitted, and the lock has not yet timed out, then they can't re-edit the row (although they could unlock it in list view). If their other tab has timed out, they would be able to edit, then if they tried submitting the original tab, it should automatically fail, as the lock is timed out.

That should prevent most cases of the scenario you describe. Although I think there might be corner cases where it might not work ... I can't think of one but have a sneaky feeling.

The more "expensive" (more work to implement) is to actually check on submit. At the moment, it just looks at the submitted data for the lock (appended to the form as readonly, hidden data), and validates the owner and TTL. What it doesn't do is re-load the original data from the row and compare the two, to make sure it's the same lock (hasn't been unlocked and/or relocked). It just relies on the lock having been validated when the form was loaded. So what I could / should do is check the lock data in the database, and see if that's been cleared (by another copy of the form being submitted, or unlocked in list view), or re-locked (by another copy of the form being opened).

Or I could do both, which would probably be the best way.

-- hugh
 
OK, I got it going here, as follows ...

The new "Allow Re-Edit" option has three settings:

Yes - the current behavior. The lock owner can re-edit at will - so open as many copies of the same record for edit as they want, and they can all be submitted. Which of course means potentially overwriting changes between instances of a form.

No - Can only have one form open for edit on a given record. It won't let them open a second one for edit, and it checks on submit to make sure the lock token in the form data === the one in the database for that row (so the form being submitted is the instance that has the lock), to prevent any spoofing or corner cases where they might somehow manage to get two forms open.

Exclusive - they can re-edit (open as many forms on the same record as they want), but only the last one opened can be submitted. Basically, when you open a form for editing and get a lock, we write a token (actually just the microtime and userid) into that row for the lockrow element data, and we also include that token in the hidden form data. So we know on submission if the submitted data belongs to the from that got the lock.

In all cases, submission is also subject to the timeout, so even if you have the lock, if the TTL for the lock has expired, the submit will fail. That's because once the lock is expired, someone else could have edited and submitted the record.

I've added a whole bunch of informative messages, which I'm open for suggestions as to how to word.

On form load, you'll get one of these, depending on what "reedit" mode, and whether you have a lock, etc.

Anywhere with %s shows the minutes left on the lock.

PLG_ELEMENT_LOCKROW_RELOCKED_MSG="You already had a lock on this record for editing. The record has been re-locked, but if you have it open in another browser tab, you will still be able to submit it from there. NOTE that this can cause data loss, if you submit multiple forms for the same record, as subsequent submits will overwrite data."

PLG_ELEMENT_LOCKROW_OWN_LOCKED_MSG="You already have a lock on this record, probably because you have previously edited it and haven't submitted it, so you cannot edit it until the lock is released. You must either submit the open copy of the form (if it exists), unlock this record in the list view (if your admin allows this), or you must wait till the lock times out"

PLG_ELEMENT_LOCKROW_LOCK_EXPIRED_MSG="This record had an expired lock, probably because someone edited it, didn't submit it, and the lock has expired. The record has now been re-locked for you. Any other forms open for this record can no longer be submitted."

PLG_ELEMENT_LOCKROW_LOCK_LOCKING_MSG="This record is being locked for your use. Nobody else can edit this record till you submit it. The record will stay locked for %s minutes. If you don't submit within that time, the record will become unlocked and editable others, and you will no longer be able to submit this form."

On submission, you'll get one of these (or nothing, if no problem):

PLG_ELEMENT_LOCKROW_SUBMIT_TIMEOUT_MSG="This record was locked for edit by you, but the lock has timed out. Your form has not been submitted."

PLG_ELEMENT_LOCKROW_SUBMIT_NOT_OWNER_MSG="This record was locked for edit by another user. Your form has not been submitted."

PLG_ELEMENT_LOCKROW_SUBMIT_WRONG_LOCK_MSG="This record was locked for edit by you, but in a different instance of this form, probably because you opened it for edit in another tab and didn't submit it. That lock has not yet expired. Your form has not been submitted. You can unlock the record by submitting the other form (if it exists), or unlocking it in the list view (if your admin allows this), or by waiting for the lock to expire in %s minutes."

PLG_ELEMENT_LOCKROW_SUBMIT_WRONG_LOCK_EXPIRED_MSG="This record was locked for edit by you, but in a different instance of this form, probably because you opened it for edit in another tab and didn't submit it. Your form has not been submitted. The lock expired %s minutes ago, so you can re-load the record for edit now, and will be able to submit it."

PLG_ELEMENT_LOCKROW_SUBMIT_ERROR_MSG="Record locking is enabled on this data, but your submitted form does not have the correct lock token, so your form has not been submitted. Please contact the administrators."
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top