| Age | Commit message (Collapse) | Author |
|
Thanks Tim Graham for the review.
Backport of 7557207983 from master.
|
|
fields
|
|
as the exception bubbles up
|
|
error_messages
|
|
Thanks margieroginski for the report.
|
|
|
|
Don't try to be smart about building a good-looking help string
because it evaluates translations too early, simply use the same old
strategy as before. Thanks Donald Stufft for the report.
Also, actually fix the case reported by the OP by special-casing
CheckboxSelectMultiple.
Added tests.
Refs #9321.
|
|
fields.
This is backward incompatible for custom form field/widgets that rely
on the hard-coded 'Hold down "Control", or "Command" on a Mac, to select
more than one.' sentence.
Application that use standard model form fields and widgets aren't
affected but need to start handling these help texts by themselves
before Django 1.8.
For more details, see the related release notes and deprecation timeline
sections added with this commit.
|
|
|
|
|
|
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.
|
|
Also fixed plural messages for DecimalField.
|
|
|
|
In any case, setting those variables to non-ascii utf-8 bytestrings
is now considered a programming error.
|
|
The commit of 266de5f9ae9e9f2fbfaec3b7e4b5fb9941967801 included only
tests, this time also code changes included...
|
|
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.
|
|
return a QuerySet.
|
|
Thanks Loic Bistuer for the report and the patch.
|
|
|
|
Thanks Simon Charette for the review.
|
|
Thanks facundo.olano at gmail.com for the report and thikonom for
the initial patch.
|
|
Thanks theaspect at gmail.com for the report and volrath for the
patch.
|
|
Fixes #17663
|
|
Thanks c.pollock at bangor.ac.uk for the report.
|
|
|
|
Refs #16612. Thanks Aymeric Augustin for the suggestion.
|
|
modelformset_factory
|
|
Refs #19399. Thanks to Track alias KJ for the patch.
|
|
Thanks ingenieroariel for the suggestion and slurms for the review.
|
|
Thanks qcwxezdas for the report. Refs #13839.
|
|
Thanks to Patryk Zawadzki for the patch.
|
|
When calling model_to_dict, improve performance of the generated SQL by
using values_list to determine primary keys of many to many objects. Add
a specific test for this function, test_model_to_dict_many_to_many
Thanks to brian for the original report and suggested fix.
|
|
value
|
|
We can do that now that cleaned_data is guaranteed to be
present. Related to [121fd109].
Thanks Simon Charette for his work on the ticket.
|
|
Fixed #18837. Refs #18791.
|
|
|
|
In Python 3, the str type has an __iter__ attribute. Therefore, the
presence of an __iter__ attribute is not sufficient to distinguish
'standard' iterables (list, tuple) from strings.
|
|
* Renamed smart_unicode to smart_text (but kept the old name under
Python 2 for backwards compatibility).
* Renamed smart_str to smart_bytes.
* Re-introduced smart_str as an alias for smart_text under Python 3
and smart_bytes under Python 2 (which is backwards compatible).
Thus smart_str always returns a str objects.
* Used the new smart_str in a few places where both Python 2 and 3
want a str.
|
|
|
|
cleaned_data is no longer deleted when form validation fails but only
contains the data that did validate.
Thanks to the various contributors to this patch (see ticket).
|
|
This is a useful trick when Python 2 awaits byte strings and
Python 3 Unicode (regular) strings.
|
|
|
|
|
|
|
|
Thanks Vinay Sajip for the support of his django3 branch and
Jannis Leidel for the review.
|
|
This is a preparation for unicode literals general usage in
Django (Python 3 compatibility).
|
|
Thanks Clueless for the initial patch.
Note that unittest has been purposely left out (external package only used by Python 2.6).
|
|
relying on the fact that the initial form is already set. Thanks, tswicegood.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17434 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
|
|
git-svn-id: http://code.djangoproject.com/svn/django/trunk@17007 bcc190cf-cafb-0310-a4f2-bffc1f526a37
|