Opened 8 years ago

Closed 8 years ago

#7051 closed (duplicate)

Problem with booleanfield and hashing in the form wizard

Reported by: anonymous Owned by: nobody
Component: contrib.formtools Version: master
Severity: Keywords: formtools contrib form wizard formwizard
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:


I have encountered a problem with the way that newforms BooleanFields are represented that causes hashes to fail whenever a previous form had a BooleanField that was set to False.

How to reproduce:
Create a newforms form with a booleanfield in it, then create a formwizard page that has three or four of these test forms.

When you visit the page you put your formwizard at, try one setting all the booleanfields to True, and it should go through fine.

However, if you set any if them to false, the hashing will fail the next time you submit a form.

If you print out the data running through the source code, you will find out why:

Assume there are just two passes for now, the first one where yo set the BF to false and te hashing function is called from render() and the next where the data you submit doesn't matter, and the hashing function is called from call()

Edit the source by sticking a "print data" just after line 149

On the first pass, you will see the following (where test_boolean is whatever you decided to call your boolenafield): ('test_boolean', False)

On the second pass, you will see something slightly different: ('test_boolean', u'False')

When the hash is first calculated, it is being treated as a False object, and when it is tested, it is being treated as a unicode string that contains the text "False".

When tested with the booleanfield set to True, the value will be u'on' for both passes.

My solution for this would just be to pull the data for hashing from form.cleaned_data. There's no situation in which it would be okay that the data wasn't valid, so if the form isn't valid then it's probably a good thing that the form would end up failing there anyways.

According to a short discussion elsewhere however, calling form.is_valid() a is a potentially very slow operation and could cause some problems if there were 10 forms to validate each time someone submits something.

So, someone more knowledgeable in the way newforms handles uncleaned data will have to figure out why they're represented differently, and it may turn out that this is a newforms bug rather than a formwizard bug.

Change History (2)

comment:1 follow-up: Changed 8 years ago by anonymous

  • Needs documentation unset
  • Needs tests unset
  • Patch needs improvement unset

I should clarify that by line 149, I meant line 149 of in django/contrib/formtools

comment:2 in reply to: ↑ 1 Changed 8 years ago by thejaswi_puthraya

  • Resolution set to duplicate
  • Status changed from new to closed

Replying to anonymous:

I should clarify that by line 149, I meant line 149 of in django/contrib/formtools

Closing it. Duplicate of #7038.

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