Code

Opened 6 years ago

Closed 6 years ago

#5878 closed (fixed)

Customize is_empty exceptions in a formset or inline formset

Reported by: brosner Owned by: nobody
Component: Forms Version: newforms-admin
Severity: Keywords: nfa-blocker
Cc: Triage Stage: Accepted
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description

With the removal of core (thank goodness) the FormSet class relies on the Form object to give back a boolean value for an is_empty method call. is_empty accepts an argument exceptions to prevent specific fields from being considered not empty. The problem here is whenever I assign a default value to a field that gets rendered in an inline formset it will always return that it is not empty and try to save it. I am not sure where this customization can fall in, but it seems pretty critical that it needs to be somewhere accessible to prevent this minor headache ;)

Attachments (0)

Change History (5)

comment:1 Changed 6 years ago by brosner

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

This problem comes full circle back to what is referenced in #5828 about widgets responding to "are you empty?". I am wondering that what is considered empty values should include the default value for a model field?

comment:2 Changed 6 years ago by brosner

  • Keywords nfa-blocker added
  • Triage Stage changed from Unreviewed to Accepted

This functionality will need to be included before the merge to trunk since it will break inlines for anyone with default values in their models (That are editted inline)

comment:3 Changed 6 years ago by akaihola

One could argue that default values might be provided for all required fields, so all extra forms should be saved if none of the fields are cleared by the user. That would be disastrous user interface design though.

Anyway, here's how the needed logic looks to me:

  1. If a field isn't required, it shouldn't be taken into consideration at all when checking if the form is empty. It's up to the developer to ensure there's at least one required field with no default value.
  1. If a field is required, the default value should be considered an empty value if all required fields with no default value are empty. The developer must ensure there's at least one required field with no default value.
  1. If the default value is invalid, it should always be considered an empty value.

Examples of the three cases in a form with 'name', 'e-mail' and 'occupation' fields, when we know 95% of the users will be blacksmiths:

  1. The 'occupation' field defaults to 'blacksmith', but can also be changed to a null or blank value (for ForeignKey or CharField, respectively). The name and e-mail fields have no default values, so they are used to determine if the form has been filled, the 'occupation' field doesn't affect that.
  1. We require occupation information for all users, and 'blacksmith' is still the default. If both the name and e-mail fields are blank, 'blacksmith' is considered blank as well and the form is not saved. If either the name or e-mail (or both) are filled, 'blacksmith' is considered a valid value and the form is either saved or an error is displayed for the missing name/e-mail field.
  1. The 'occupation' CharField initially displays "(fill your occupation here)", which is not a valid occupation. This default value should always be considered a blank value, since it means the user hasn't touched that field. If the occupation is not required, the user should blank the field to indicate no occupation.

comment:4 Changed 6 years ago by Karen Tracey <kmtracey@…>

#6762 was opened reporting the same problem.

comment:5 Changed 6 years ago by jkocherhans

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

This was fixed in [7270]

Add Comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
as The resolution will be set. Next status will be 'closed'
The resolution will be deleted. Next status will be 'new'
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.