RT Ticket #65: Duplicate form-submission preventer

[phinjensen]

Created: Thu Jul 05 21:15:21 2007
Requestors: Davor Ocelic

---

I talked to Stefan about the way to prevent duplicate form submissions.

I think, roughly, the idea was that we need to write code that would
track form submissions.

That code should somehow accept options, so that you can specify that:

• form is not to be submitted again ever during the session, or
• form is not to be submitted again until at least some data is
  different, or
• form is not to be submitted again for some time interval

This idea can take some more refinements, of course. So please comment
here to prepare the material for the implementer who takes it.

[phinjensen]

Date: Fri Jul 06 23:16:45 2007
Author: Kevin Walsh

---

When I need to do that, I just use JavaScript.

That's what I do on the Interchange IRC pastebin (www.paste.me.uk), anyway.

I've never come across a "form is not to be submitted again ever during
the session" requirement. The "form is not to be submitted again until
at least some data is different" requirement can be met by moving the
function outside of the onclick and creating a controller attached to
each of the fields in the form.

Occasionally, switching JavaScript off is a concern. In that case, the
above can be done with a mv_click callback assigned to the form. A
scratchpad variable can be set and checked to prevent duplicates. the
CGIs can be saved into the scratchpad variable if you need to check
whether any data is different from the last submission.

If you do want it in the core then I suggest creating a UserTag that
does the following:

1. Output submit button HTML (possibly with JavaScript)
2. Output a "hidden" form field with unique form_id value (specified as
   a UserTag parameter).
3. Output a mv_click form field to call a callback routine supplied in a
   profile somewhere.
4. Output as many further "hidden" form fields as are required to define
   the rules. Perhaps prefix each of these with the form_id value to avoid
   clashes.

The callback target would then take care of the rules - as specified in
parameters to the original form UserTag call, which are passed as in #4

The result would be that mv_nextpage is either left untouched, or is set
to the original page (from the history), thus returning the user to the
original form.

The only change to the core I can see is if you don't consider mv_click
to be up to the task for some reason. In that case, you'd create a new
mv_gate (or whatever) function in the core, which is always guaranteed
to be executed before any other mv_click callbacks. Mv_gate would be
passed the form_id, thus getting rid of the #2 value.

This is so easily done, on a case-by-case basis, that I don't consider
it to be worth building it into the core with any sort of priority,
Perhaps it could be considered when all of the other bugs and requests
have been cleared, and we all have nothing else to do. :-)

Rough ideas should probably be discussed on the core list (or the users'
list) before they are raised as "issues to be resolved" in here. It'd
be a bad move to let facility turn into some sort of discussion forum,
when we already have plenty of venues for that.

[phinjensen]

Date: Tue Jul 14 15:43:18 2009
Author: Gert van der Spoel

---

So what would be the next step for this one?

[jlav1n]

This is a template-level issue.