Django Model Field Metadata - django

I have a Django model and I wish to denote that some of the model fields are private so that when I display a ModelForm based on this model I can display these fields marked as such.
I'd like this to be specified on the model rather than the form as I think that's where it belongs.
I'm wondering what the best way to do this is. Can I write a decorator #private to do this? Can anyone point me at an example?
Thanks

There's no one feature that perfectly fits your problem, but here's a couple of suggestions:
Add the information to the model's Meta class, which you can then access from your form via the _meta attribute on the model
Utilise the help_text option on your model fields (obviously this won't help you to "decide programatically which fields I should be displaying to other users")
I do agree that it's debatable as to whether this belongs at the model layer; it seems like business logic to me.

Related

Where is ID saved in django ModelAdmin autocomplete_fields?

I am rewriting some administration interface to django 2.2, currently using django autocomplete_fields admin feature. Simply said I have ModelAdmin object OrderAdmin, which has nested TabularInline ProductAdmin: variable-length table of products which might be added to order. Each of these ProductAdmin holders just contains ForeignKey to actual product class, with some other attributes.
Now I wonder: where does django store id - ForeignKey - of item selected with autocomplete field? It doesn't mark OPTION in selectbox as selected, and although there is suspicious hidden input field with #cashregisterproduct_set-0-id on page, it doesn't have any value. Or is there some special way how to access it? I was thinking about adding id to __str__ method of model and parsing, but thats just ugly.
Thanks for tip.
EDIT: to make it 100% clear, where from does django get ForeignKey of object selected through autoselect_field, when creating new object from ModelAdmin?
I got misguided thinking that this is managed by django. Selected data might be accessed by using select2 framework:
selected_value = $('.myselectbox').select2().val();
related: https://stackoverflow.com/a/47451658/16268461

Is there any possibility to add fields inside the fields of a Model

Assume I have a model named MyModel and I have a Field Named field Now I want to add three more fields inside the prescription like one field_a , field_b and field_c .
Does Django Allow that in any way or we have to make another model for this purpose and then link with Foreign Key to MyModel?
Well I think it is an idea that could lead to some really hard to maintain code and should be well thought through.
That aside If you have a look at:
https://docs.wagtail.io/en/stable/topics/streamfield.html
It's a special field meant for cms applications that uses json in the field to model dynamic fields and validations for it.
Also if you run postgres this might help. https://docs.djangoproject.com/en/3.2/ref/contrib/postgres/fields/#jsonfield

Django: Inject form validation on ModelForm, not Model

Question: Is there a way to inject form field validation on the ModelForm instead of the Model?
Justification: I have three ModelForm's that update the same Model instance, which have default conditions for blank. I should have designed three different Models for each form, but I'm to far in to make a change.
Please assist!
Thanks,
Neel
ModelForm is a kind of Form (as it inherits from BaseForm), so you can use Form field validation methods to do it because clean() method is inheried from BaseForm. So for field named foo you use clean_foo() method to do cleanup
leotrubach's answer is the way to go, I just want to add that the django documentation on the subject is a good read.

django generic view update/create: update works but create raises IntegrityError

I'm using CreateView and UpdateView directely into urls.py of my application whose name is dydict. In the file forms.py I'm using ModelForm and I'm exluding a couple of fields from being shown, some of which should be set when either creating or updating. So, as mentioned in the title, update part works but create part doesn't which is obvious because required fields that I have exluded are sent empty which is not allowed in my case. So the question here is, how should I do to fill exluded fields into the file forms.py so that I don't have to override CreateView?
Thanks in advance.
Well, you have to set your required fields somewhere. If you don't want them to be shown or editable in the form, your options are to set them in the view (by using a custom subclass of CreateView) or if appropriate to your design in the save method of the model class. Or declare an appropriate default value on the field in the model.
It would also work to allow the fields into the form, but set them to use HiddenInput widgets. That's not safe against malicious input, so I wouldn't do that for purely automated fields.
You cannot exclude fields, which are set as required in the model definition. You need to define blank=True/null=True for each of these model fields.
If this doesn't solve your issue, then please show us the model and form definitions, so we know exactly what the code looks like.

Different validation for different actions

Here's the situation. I have a BlogPost model wich has a title, content, category_name, published_at date, some other fields and some presence validations.
What I want to do is to let the user save a post as a "draft" (withought publishing it). In that case I need to skip most of the validations (pretty much all of them, except for the title and category_name). What is the best Rails 4 way to do that?
Being more precise:
Should I leave it one model, or create another model like DraftPost and inherit BlogPost from it, adding validations?
Or should I leave it in one model and implement the validations in the controller (what I can think of is validating the title and category_name manualy on the draft save and saving the model with save!)
Or some other way?
Ended up adding a draft field to the model and validationg with :if => :draft? Seems it's the best way to work with it.