Thanks Luke for writing this up and representing all views. I am the proponent of "we are all adults here".
On Thu, Jun 14, 2012 at 6:48 AM, Anssi Kääriäinen <anssi.kaariai...@thl.fi> wrote: > ... > I hadn't realized all fields present on the Python form but not in the > HTML form will get overwritten to NULL... The above makes me a tad > more "-" on the require fields always proposal. The problem is there > only for forms used for model creation. If you use the form both for > update and creation, you will soon enough see that something funny is > going on as part of your fields are getting set to NULL on > form.save(). > > So, to hit the problem the user would need to: > 1. Have a ModelForm with no field restrictions in Python. > 2. Render only part of the fields. > 3. All non-rendered fields must be null/blank=True for the form to > work at all. > 4. Not use the form in update views. Exactly - the combination of things that need to happen for this is so complicated that I am perfectly ok with leaving things as they are. (add 5. No tests for the form/view) I believe exclude is way more useful than fields (I do see the security advantage but in my mind this is the case where convenience beats security, also still afraid of the fields = [f.name for f in ...]). I would be most happy with a modified Option 1 - require exclude OR fields on ModelForm.Meta. This should force the user to think about this issue, when these attributes are missing we can throw a reasonable error and refer the user to the docs for more info on how their choices affect the overall security of the app. so: -1 on options 2 and 3, +1 on option 1 + require exclude or fields -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
