| Age | Commit message (Collapse) | Author |
|
Refs #8620.
If we allow any value to remove form fields then we get name clashes
with method names, media classes etc. There was a backwards
incompatibility introduced meaning ModelForm subclasses with declared
fields called media or clean would lose those fields.
Field removal is now only permitted by using the sentinel value None.
The docs have been slightly reworded to refer to removal of fields
rather than shadowing.
Thanks to gcbirzan for the report and initial patch, and several of the
core team for opinions.
Backport of 9fb0f5dddc4cf7f2d294af1bcde2c359cffd90a5 from master
|
|
Added ModelForm and NON_FIELD_ERRORS imports.
Backport of 64ee097b3b from master
|
|
Backport of 7271f5db78 from master
|
|
cb5dd99bb4 from master.
|
|
|
|
Thanks Tim Graham for the report and recommendations
|
|
Overriding the error messages now works for both unique fields, unique_together
and unique_for_date.
This patch changed the overriding logic to allow customizing NON_FIELD_ERRORS
since previously only fields' errors were customizable.
Refs #20199.
Thanks leahculver for the suggestion.
|
|
|
|
I updated the documentation, that the modelform now includes the 'slug' field.
|
|
|
|
|
|
Thanks treysta at gmail.com for the suggestion.
|
|
shadowing them.
|
|
scenarios.
Thanks apollo13, funkybob and mjtamlyn for the reviews.
|
|
The ModelForm docs suggested that fields defined declaratively override
default fields generated from the form Meta.
This is conceptually wrong, especially with inheritance in mind. Meta is
usually defined on the topmost ModelForm subclass, while fields can come
from anywhere in the MRO, especially base classes; therefore we suggested
that something defined in a base class override something from a subclass.
This patch rephrases the docs around the idea that Meta is used to generate
*missing* fields.
Refs #8620, #19617.
Thanks @mjtamlyn and @timgraham for the review.
|
|
|
|
Sphinx generates left single quotes for apostrophes after
code markup, when right single quotes are required. The
easiest way to fix this is just by inserting the unicode
character for a right single quote.
Instances of the problem were found by looking for
">‘" in the generated HTML.
|
|
Thanks laureline.guerin@ and Wedg.
|
|
|
|
Thanks johnsmith for the suggestion.
|
|
Thanks Marc Tamlyn and Tim Graham for the review.
|
|
error_messages
|
|
There was an inconsistency between how the label_tag for forms were
generated depending on which method was used: as_p, as_ul and as_table
contained code to append the label_suffix where as label_tag called on a
form field directly did NOT append the label_suffix. The code for
appending the label_suffix has been moved in to the label_tag code of
the field and the HTML generation code for as_p, as_ul and as_table now
calls this code as well.
This is a backwards incompatible change because users who have added the
label_suffix manually in their templates may now get double label_suffix
characters in their forms.
|
|
Thanks sane4ka.sh@ for the report.
|
|
|
|
|
|
added '__all__' shortcut
This also updates all dependent functionality, including modelform_factory
and modelformset_factory, and the generic views `ModelFormMixin`,
`CreateView` and `UpdateView` which gain a new `fields` attribute.
|
|
This is provided as a new "validate_max" formset_factory option defaulting to
False, since the non-validating behavior of max_num is longstanding, and there
is certainly code relying on it. (In fact, even the Django admin relies on it
for the case where there are more existing inlines than the given max_num). It
may be that at some point we want to deprecate validate_max=False and
eventually remove the option, but this commit takes no steps in that direction.
This also fixes the DoS-prevention absolute_max enforcement so that it causes a
form validation error rather than an IndexError, and ensures that absolute_max
is always 1000 more than max_num, to prevent surprising changes in behavior
with max_num close to absolute_max.
Lastly, this commit fixes the previous inconsistency between a regular formset
and a model formset in the precedence of max_num and initial data. Previously
in a regular formset, if the provided initial data was longer than max_num, it
was truncated; in a model formset, all initial forms would be displayed
regardless of max_num. Now regular formsets are the same as model formsets; all
initial forms are displayed, even if more than max_num. (But if validate_max is
True, submitting these forms will result in a "too many forms" validation
error!) This combination of behaviors was chosen to keep the max_num validation
simple and consistent, and avoid silent data loss due to truncation of initial
data.
Thanks to Preston for discussion of the design choices.
|
|
This is a security fix. Disclosure and advisory coming shortly.
|
|
|
|
modelformset_factory
|
|
Thanks wim@ for the suggestion.
|
|
Thanks ingenieroariel for the suggestion and slurms for the review.
|
|
|
|
|
|
Also fixes #9045.
|
|
|
|
validation fails.
|
|
|
|
the form is invalid.
Thanks Ben Sturmfels for the patch.
|
|
ModelForm fields.
Thanks Pieter Swinkels for the patch.
|
|
|
|
Thanks Audrey Roy for the patch.
|
|
Thanks Florian Apolloner for the patch.
|
|
|
|
The deprecation schedule was slightly accelerated because of possible security ramifications.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17847 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17428 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
formsets.
This make them consistent with the similar capability of regular
formsets. Thanks to simon29 form the report and to Claude Paroz for the
patch.
Fixes #14574.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17373 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
[16955]
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16983 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|
|
git-svn-id: http://code.djangoproject.com/svn/django/trunk@16875 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|