1305 sections across all versions Narrow to Django 6.0 (current) →
Release notes Django 1.2 release notes
… protection against Cross-Site Request Forgery (CSRF) attacks. This type of attack occurs when a malicious website contains a link, a form button or some JavaScript that is intended to perform some action on your website, using the credentials of a …
Release notes
Django 1.2.1 was released almost immediately after 1.2.0 to correct two small bugs: one was in the documentation packaging script, the other was a bug that affected datetime form field widgets when localization was enabled.
Release notes Django 1.3 release notes
The django.contrib.auth.views.password_reset() view now accepts a from_email parameter, which is passed to the password_reset_form’s save() method as a keyword argument.
Release notes Django 1.4 release notes
To avoid conflicts with other common CSS class names (e.g. “button”), we added a prefix (“field-”) to all CSS class names automatically generated from the form field names in the main admin forms, stacked inline forms and tabular inline cells.
Release notes Django 1.4 release notes
The password_reset view in django.contrib.auth now accepts a subject_template_name parameter, which is passed to the password save form as a keyword argument.
Release notes Django 1.4.14 release notes
In older versions of Django it was possible to reveal any field’s data by modifying the “popup” and “to_field” parameters of the query string on an admin change form page.
Release notes Django 1.5 release notes
Django 1.5 introduces support for Python 3 - specifically, Python 3.2 and above. This comes in the form of a single codebase; you don’t need to install a different version of Django on Python 3.
Release notes Django 1.5.9 release notes
In older versions of Django it was possible to reveal any field’s data by modifying the “popup” and “to_field” parameters of the query string on an admin change form page.
Release notes Django 1.6.6 release notes
In older versions of Django it was possible to reveal any field’s data by modifying the “popup” and “to_field” parameters of the query string on an admin change form page.
Release notes Django 1.7 release notes
The enter argument was added to the setting_changed signal. The model signals can be now be connected to using a str of the 'app_label.ModelName' form – just like related fields – to lazily reference their senders.
Release notes Django 1.8 release notes
There is a corresponding form field. Django now has a DurationField for storing periods of time - modeled in Python by timedelta.
Release notes Django 1.8 release notes
ModelChoiceField and ModelMultipleChoiceField took an undocumented, untested option cache_choices. This cached querysets between multiple renderings of the same Form object. This option is subject to an accelerated deprecation and will be removed in Django 1.9.
Release notes Django 1.9 release notes
ModelForm accepts the new Meta option field_classes to customize the type of the fields. See Overriding the default fields for details.
Release notes Django 1.9.2 release notes
A regression in Django 1.9 prevented that form submission from raising a “Permission Denied” error for users without the “add” permission.
Release notes Django 2.0 release notes
The new date_attrs and time_attrs arguments for SplitDateTimeWidget and SplitHiddenDateTimeWidget allow specifying different HTML attributes for the DateInput and TimeInput (or hidden) subwidgets. The new Form.errors.get_json_data() method returns form errors as a dictionary suitable for including in a JSON response.
Release notes Django 2.1 release notes
With the new “view” permission, existing custom admin forms may raise errors when a user doesn’t have the change permission because the form might access nonexistent fields.
Release notes Django 2.1.2 release notes
If an admin user has the change permission to the user model, only part of the password hash is displayed in the change form.
Release notes Django 4.0 release notes
DeleteView now uses FormMixin, allowing you to provide a Form subclass, with a checkbox for example, to confirm deletion. In addition, this allows DeleteView to function with django.contrib.messages.views.SuccessMessageMixin.
Release notes Django 4.0 release notes
DeleteView now uses FormMixin to handle POST requests. As a consequence, any custom deletion logic in delete() handlers should be moved to form_valid(), or a shared helper method, if required.
Release notes Django 4.1 release notes
The default template used to render forms when cast to a string, e.g. in templates as {{ form }}, is now configurable at the project-level by setting form_template_name on the class provided for FORM_RENDERER.