Opened 15 years ago

Closed 14 years ago

Last modified 13 years ago

#11726 closed Bug (fixed)

FormWizard sanity check on step number performed before dynamic steps can be inserted

Reported by: Eric Friesen <ericfriesen@…> Owned by: esper256
Component: contrib.formtools Version: dev
Severity: Normal Keywords: FormWizard
Cc: michal.modzelewski@… Triage Stage: Ready for checkin
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

If you are making a FormWizard to have dynamically created steps, where the number of steps depends on the form input of the previous steps, you run into a problem with the sanity check inside FormWizard's __call__ method.

        # Sanity check.
        if current_step >= self.num_steps():
            raise Http404('Step %s does not exist' % current_step)

        # For each previous step, verify the hash and process.
        # TODO: Move "hash_%d" to a method to make it configurable.
        for i in range(current_step):
            form = self.get_form(i, request.POST)
            if request.POST.get("hash_%d" % i, '') != self.security_hash(request, form):
                return self.render_hash_failure(request, i)
            self.process_step(request, form, i)

Your cleaned_data to determine if you need to add more steps isn't available until process_step is called on the earlier steps. However it will never get that far because the current step will be over the number of steps the FormWizard was initially constructed with (in the urls.py for example).

Currently I have worked around this in my code by constructing FormWizard with enough dummy steps that are removed and replaced with real ones just so the formcount is always greater than the dynamic count will ever be in the very beginning.

My proposed solution would be to do a sanity check each iteration of the forloop ensuring that there's at least enough forms to process the next one.

Attachments (2)

django-11726.diff (1.0 KB ) - added by esper256 14 years ago.
Fix as described in the original comment
ticket11726.diff (2.8 KB ) - added by Michał Modzelewski 14 years ago.
Alternative fix, patched against trunk, includes failing testcase

Download all attachments as: .zip

Change History (14)

comment:1 by Russell Keith-Magee, 15 years ago

Triage Stage: UnreviewedAccepted

comment:2 by anonymous, 14 years ago

Owner: changed from nobody to anonymous
Status: newassigned

comment:3 by esper256, 14 years ago

Owner: changed from anonymous to esper256
Status: assignednew

comment:4 by esper256, 14 years ago

Status: newassigned

by esper256, 14 years ago

Attachment: django-11726.diff added

Fix as described in the original comment

comment:5 by esper256, 14 years ago

Has patch: set
Needs documentation: set
Needs tests: set
Version: 1.1SVN

by Michał Modzelewski, 14 years ago

Attachment: ticket11726.diff added

Alternative fix, patched against trunk, includes failing testcase

comment:6 by Michał Modzelewski, 14 years ago

Cc: michal.modzelewski@… added
Easy pickings: unset
milestone: 1.4
Needs documentation: unset
Needs tests: unset
Severity: Normal
Type: Bug

This ticket is ageing, but is still valid after the fixes to FormWizard in [15196].

I propose fixing this by moving the sanity check into the get_form method. I've added a patch with this fix and a regression test.

comment:7 by anonymous, 14 years ago

Michael, your solution looks good. I am new to Django contribution, do I need to do anything to this ticket?

in reply to:  7 comment:8 by esper256, 14 years ago

Replying to anonymous:

Michael, your solution looks good. I am new to Django contribution, do I need to do anything to this ticket?

Oops, this was me, I just never remember to log in.

comment:9 by Michał Modzelewski, 14 years ago

If you've reviewed the patch you can set Triage Stage to "Ready for checkin". After that we just wait until one of the core developers reviews the patch.

comment:10 by esper256, 14 years ago

Triage Stage: AcceptedReady for checkin

Thanks, looks good!

comment:11 by Luke Plant, 14 years ago

Resolution: fixed
Status: assignedclosed

In [16119]:

(The changeset message doesn't reference this ticket)

comment:12 by Jacob, 13 years ago

milestone: 1.4

Milestone 1.4 deleted

Note: See TracTickets for help on using tickets.
Back to Top