Re: Force "required" fields to be included in a ModelForm

2019-04-17 Thread Will Gordon
Well shoot...this definitely seems like something only I'm running into. Appreciate y'alls feedback. Thanks  -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop

Re: Force "required" fields to be included in a ModelForm

2019-04-17 Thread Tobias Kunze
On 19-04-16 17:34:11, Will Gordon wrote: >In the same way that editable fields are forced to not be included in a >ModelForm ( >https://github.com/django/django/blob/master/django/forms/models.py#L146), >I would like to propose that "required" fields (`blank=False`) be forced to >be included in

Re: Force "required" fields to be included in a ModelForm

2019-04-17 Thread PARTH PATIL
Yes I agree with others, that this should not be implemented. As I find this too much specific to just your case. There are many cases, like what if there is some required field which the developer wants to set by themselves and don't want user to edit that (transaction details maybe for a

Re: Force "required" fields to be included in a ModelForm

2019-04-17 Thread Harro
I'm against, there are lots of cases where a modelform is used to edit an exitsting object and thus the required fields are already set and you don't want them to be editable. If it's a trivial patch then you should think about extending modelform in your own project enforce it there and then

Re: Force "required" fields to be included in a ModelForm

2019-04-17 Thread Matthias Kestenholz
Please don't do this. There are very good reasons for NOT including blank=False fields by default such as batch-editing some field with a formset or inlineformset or just offering different forms to users with different access levels (as Tobias wrote). Django started recommending using `fields`

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread James Bennett
Python has a warning system, and Django already uses it for things like deprecation notices. I don't like error by default as an approach to this, but a warning (which is easy to ignore -- it doesn't break your code) would be fine. -- You received this message because you are subscribed to the

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread Will Gordon
Would it be weird to just make it so that the "required" field *must* be present in exclude? This way, if you *accidentally* leave off a required field, you're quickly notified about itbut if you explicitly mark it as something to exclude, it makes it clear to everyone exactly what you're

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread Will Gordon
I can certainly agree that there may be some use cases where it should be possible to disable this functionality, but I would argue that erroring on a missing, required field should be the default, and allow for a way to override...as opposed to allowing missing fields and requiring a

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread Tobias McNulty
There are plenty of use cases when this behavior wouldn't be desired, such as editing the same model object with 2+ different model forms. Such a pattern might be more common when editing an existing object, but isn't out of the question for creating new objects, either (think of a multi-step form

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread Will Gordon
Sorry if I wasn't more clear, but using a warning was exactly what I was proposing. In the same way that a FieldError is raised when an editable field is listed in fields, I was essentially planning on doing the exact same check on the blank attribute. I agree that this should be ignorable, and

Re: Force "required" fields to be included in a ModelForm

2019-04-16 Thread James Bennett
As the documentation points out, ModelForm avoids implicitly adding fields to a form when you haven't told it to, and does so for security reasons. Mass-assignment bugs have caused significant security issues in the past for other systems which *did* implicitly support/add fields, and I'd like to