diff options
| author | Tim Graham <timograham@gmail.com> | 2013-09-13 09:34:12 -0400 |
|---|---|---|
| committer | Tim Graham <timograham@gmail.com> | 2013-09-13 09:34:12 -0400 |
| commit | ec89e1725a29076d37b36f85de983b8a7cf7c329 (patch) | |
| tree | 9547ee8aaaa2c90a718d79e716da42b3277b08d9 | |
| parent | e4aab1bb8db24e226891556f072968625a68abdf (diff) | |
Fixed #21100 -- Noted that Create/UpdateViews.fields is new in 1.6
Thanks AndrewIngram for the suggestion.
| -rw-r--r-- | docs/releases/1.6.txt | 12 |
1 files changed, 6 insertions, 6 deletions
diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt index a7448e0da1..34dc307527 100644 --- a/docs/releases/1.6.txt +++ b/docs/releases/1.6.txt @@ -1061,12 +1061,12 @@ security problem described in the section above, because they can automatically create a ``ModelForm`` that uses all fields for a model. For this reason, if you use these views for editing models, you must also supply -the ``fields`` attribute, which is a list of model fields and works in the same -way as the :class:`~django.forms.ModelForm` ``Meta.fields`` attribute. Alternatively, -you can set set the ``form_class`` attribute to a ``ModelForm`` that explicitly -defines the fields to be used. Defining an ``UpdateView`` or ``CreateView`` -subclass to be used with a model but without an explicit list of fields is -deprecated. +the ``fields`` attribute (new in Django 1.6), which is a list of model fields +and works in the same way as the :class:`~django.forms.ModelForm` +``Meta.fields`` attribute. Alternatively, you can set set the ``form_class`` +attribute to a ``ModelForm`` that explicitly defines the fields to be used. +Defining an ``UpdateView`` or ``CreateView`` subclass to be used with a model +but without an explicit list of fields is deprecated. .. _m2m-help_text-deprecation: |
