diff --git a/docs/releases/1.6.txt b/docs/releases/1.6.txt
index a7448e0..34dc307 100644
|
a
|
b
|
security problem described in the section above, because they can automatically
|
| 1061 | 1061 | create a ``ModelForm`` that uses all fields for a model. |
| 1062 | 1062 | |
| 1063 | 1063 | For this reason, if you use these views for editing models, you must also supply |
| 1064 | | the ``fields`` attribute, which is a list of model fields and works in the same |
| 1065 | | way as the :class:`~django.forms.ModelForm` ``Meta.fields`` attribute. Alternatively, |
| 1066 | | you can set set the ``form_class`` attribute to a ``ModelForm`` that explicitly |
| 1067 | | defines the fields to be used. Defining an ``UpdateView`` or ``CreateView`` |
| 1068 | | subclass to be used with a model but without an explicit list of fields is |
| 1069 | | |
| | 1064 | the ``fields`` attribute (new in Django 1.6), which is a list of model fields |
| | 1065 | and works in the same way as the :class:`~django.forms.ModelForm` |
| | 1066 | ``Meta.fields`` attribute. Alternatively, you can set set the ``form_class`` |
| | 1067 | attribute to a ``ModelForm`` that explicitly defines the fields to be used. |
| | 1068 | Defining an ``UpdateView`` or ``CreateView`` subclass to be used with a model |
| | 1069 | but without an explicit list of fields is deprecated. |
| 1070 | 1070 | |
| 1071 | 1071 | .. _m2m-help_text-deprecation: |
| 1072 | 1072 | |