Model:
class ProjectType(models.Model):
project_type_id = models.AutoField(primary_key=True)
name = models.CharField(max_length=45, help_text='Type of project', verbose_name='Project Type')
slug = models.SlugField(max_length=45, blank=True)
description = models.CharField(max_length=400, help_text='Description of the main purpose of the project', verbose_name='Project Type Description')
default = models.BooleanField(default=False)
owner = models.ForeignKey(User)
class Meta:
...
unique_together = (('slug', 'owner'),('name', 'owner'))
I need a form to create/update ProjectType's. Please note the owner field - it is supposed to be current logged-in user. The question is how to ensure that constraints in the unique_together are validated correctly.
I do not want to show owner field on the form - it's the current user, so it should be set automatically by the system. But no matter how I try to do this, either validation does not work, or there are other errors.
Among approaches I tried (individually or in combination):
Creating a hidden field in the related ModelField
Defining init in ProjectTypeForm (in various ways), for example:
def __init__(self, *args, **kwargs):
self.user = kwargs.pop('user', None)
super(ProjectTypeForm, self).__init__(*args, **kwargs)
self.fields['owner'].initial = self.user
Setting values in the view like:
...
if request.method == 'POST':
project_type = ProjectType(owner=request.user)
form = ProjectTypeForm(request.POST, instance=project_type, user = request.user.pk) # also tries w/o pk
...
Overriding clean() method of the form in various ways, along these lines:
def clean(self):
cleaned_data = super(ProjectTypeForm, self).clean()
slug=cleaned_data.get('slug')
owner = cleaned_data.get('owner')
if slug:
user = User.objects.get(pk=owner)
...
Many of these approaches are based on various answers found on stackoverflow.com. However, no matter what I try, I cannot find a way to accomplish what I need: (1) auto-setting of the owner field and (2) validation for uniqueness: owner/type_name and owner/type_slug. Typical errors I have is that (a) owner is not recognized as a User (it's treated as a PK), (b) incorrect validation (like lack of it or it misses the fact that it's the same record being edited, etc.), (c) owner is a required field.
For the record - if the owner is a regular field in the form, everything works as expected, but I cannot allow users to set the owner value.
Is there any, hopefully elegant, solution to this?
Thanks!
Exclude the owner field from your form, and save the user in your form's init method - then you can use it to validate the form, eg
class ProjectTypeForm(...):
...
def __init__(self, user, *args, **kwargs):
super(ProjectTypeForm, self).__init__(*args, **kwargs)
self.user = user
def clean(self):
user_projects = ProjectType.objects.filter(owner=self.user)
if user_projects.filter(slug=self.cleaned_data['slug']):
raise forms.ValidationError('...')
elif user_projects.filter(name=self.cleaned_data['name']):
raise forms.ValidationError('...')
else:
return self.cleaned_data
Then in your view, do something like this when creating a new ProjectType:
if request.method == 'POST':
form = ProjectTypeForm(request.user, request.POST)
if form.is_valid():
ptype = form.save(commit=False)
ptype.owner = request.user
ptype.save()
You shouldn't need that to save existing ProjectType objects though.
As I mentioned in my comment, one possible solution is essentially to go along with Django forms and use the owner field on the form. So, what I've done is modified init in this way:
def __init__(self, user, *args, **kwargs):
super(ProjectTypeForm, self).__init__(*args, **kwargs)
self.fields['owner'] = forms.ModelChoiceField(
label='Owner*',
queryset=User.objects.filter(username=user.username),
help_text="Project types are unique to logged-in users who are set as their owners.",
required=True,
empty_label=None)
Basically, what it does it is still using ChoiceField but sets it to one option - current user. In addition, empty_label=None ensures that there is no "empty" choice. The effect is (since username is unique) that current user name appears visible and is the only choice in the otherwise dropdown list with more choices.
In the view I follow this approach:
...
if request.method == 'POST':
project_type = ProjectType()
form = ProjectTypeForm(request.user,request.POST, instance=project_type,)
if form.is_valid():
project_type.save()
return HttpResponseRedirect(reverse('project_types'))
else:
form = ProjectTypeForm(request.user)
...
Basically, that's it - validation of unique constraints (and the whole thing) works like a charm.
Do I like this solution? No. I consider it a hack (ironically, even if it goes along with standard Django approaches). But it requires something that is totally unnecessary. One benefit of this approach is that it clearly communicates to the current user that s/he is set as the project type owner. But even with this in mind I would rather show a message (instead of a field) that Current user X will be set as the owner of the project type being created. So, if someone has a better solution, please submit it to illustrate the full power and flexibility of Django.
Related
As far as I know it is quite a burden to create a form that is safe and required an extra related field.
Example how I do this:
1. Create form.
class Myform(ModelForm):
def __init__(self, *args, **kwargs):
relatedfieldinstance = kwargs.pop('relatedfield')
super(CustomActivityTypeForm, self).__init__(*args, **kwargs)
self.fields['relatedfield '].widget = forms.HiddenInput()
self.fields['relatedfield '].instance = relatedfieldinstance
THIS STILL ENABLES THE USER TO HIJACK YOUR POST!!!
2. create view:
form = MyForm(request.POST or None, instance=None, relatedfield =relatedfield )
if form.is_valid:
mynewinstance=form.save(commit=False)
mynewinstance.relatedfield = relatedfield
mynewinstance.save()
Is there no better way to this? As it is easy to forget to set it again in the form.is_valid clause and think it is working (IT IS!), and thereby creating a huge security loophole.
And I need the relatedfield, because it is necessary for my model validation (clean methods on the model).
I have a modelform:
class UserPreferencesForm(ModelForm):
"""
Form for storing user preferences.
"""
class Meta:
model = UserPreferences
exclude = ('user')
the model:
class UserPreferences(models.Model):
"""
Model for user project preferences.
"""
user = models.OneToOneField(User)
...
and in the views:
...
form = UserPreferencesForm(request.POST or None)
if form.is_valid():
# save the form
prefs = form.save(commit=False)
prefs.user = request.user
prefs.update()
messages.add_message(
request, messages.INFO, 'Your preferences have been updated.'
)
...
I want to ensure that each user only has one set of preferences, so I would like to refactor the view code to use something along the lines of the update() model method instead of checking for object existence and then saving, which would incur more queries.
What is the most efficient way of 'create-or-updating' the model?
Any help much appreciated.
Are you interested in saving the query to detect if a row exists?
In the case, you could do as you describe.. do an update and check if 0 rows were updated, which implies the profile doesn't exist.
updated = Preferences.objects.filter(user=request.user).update(**form.cleaned_data)
if updated == 0:
# create preference object
But an even simpler design pattern is to ensure there is always a preferences table for every user via a signal listening on models.signals.post_save sent by the User class.
Then, you can assume it always exists.
def create_prefs(sender, instance, created, **kwargs):
if created:
# create prefs
models.signals.post_save.connect(create_prefs, sender=User)
I'm using Django 1.4 with Python 2.7 on Ubuntu 12.10.
I have a form where I need to populate a few drop-downs dynamically (using jQuery) but need 2 of them to be required and the 3rd to be optional.
I'm using Tastypie to help with the API to get the options. Basically the first drop-down is populated with industry level codes for schools. Once a code is selected a category drop-down is populated for all categories for that code. Once the category is chosen a subcategory drop-down is populated for all subcategories for that combination of code and category.
I'm able to require the code drop-down (it's not dynamically populated). However, I'm having a tough time getting the category drop-down to be required. There are basically 2 routes I can take - front-end validation or back-end validation. I'm trying to go with back-end validation so I can easily create further validation if needed.
Here is the form:
class SchoolProductForm(forms.ModelForm):
cip_category = forms.ChoiceField(required=True,
choices=(('', '----------'),))
def __init__(self, *args, **kwargs):
super(SchoolProductForm, self).__init__(*args, **kwargs)
self.fields['short_description'].widget = TA_WIDGET
self.fields['salary_info'].widget = TA_WIDGET
self.fields['job_opportunities'].widget = TA_WIDGET
self.fields['related_careers'].widget = TA_WIDGET
self.fields['meta_keywords'].widget = TI_WIDGET
self.fields['meta_description'].widget = TI_WIDGET
self.fields['cip'].queryset = models.CIP.objects.filter(
parent_id__isnull=True)
class Meta:
model = models.SchoolProduct
exclude = ('campus',)
I've tried to override the clean method. I've tried to create a field specific clean method. Neither seem to work.
Variations of the following:
def clean(self):
super(SchoolProductForm, self).clean()
if cip_category in self._errors:
del self._errors['cip_category']
if self.cleaned_data['cip_category'] == '----------':
self._errors['cip_category'] = 'This field is required.'
return self.cleaned_data
This gives an error that there is no cip_category in cleaned_data, which makes sense because it didn't validate.
I've tried variations with the field specific clean:
def clean_cip_category(self):
data = self.cleaned_data['cip_category']
self.fields['cip_category'].choices = data
return data
But get a validation error on the page stating my choice is not one of the available choices.
I've tried to create a dynamic field type (several variations):
class DynamicChoiceField(forms.ChoiceField):
def valid_value(self, value):
return True
class SchoolProductForm(forms.ModelForm):
cip_category = DynamicChoiceField(required=True,
choices=(('', '----------'),))
But it accepts ---------- as a valid option (which I don't want) and causes an error since the ORM tries to match a value of ---------- in the database (which it won't find).
Any ideas?
I was able to solve this with a little overriding of a method in ChoiceField.
I added the field to the form and handled the pre-population with the self.initial:
class SchoolProductForm(forms.ModelForm):
cip_category = common_forms.DynamicChoiceField(
required=True, choices=(('', '----------'),))
def __init__(self, *args, **kwargs):
super(SchoolProductForm, self).__init__(*args, **kwargs)
self.fields['short_description'].widget = TA_WIDGET
self.fields['salary_info'].widget = TA_WIDGET
self.fields['job_opportunities'].widget = TA_WIDGET
self.fields['related_careers'].widget = TA_WIDGET
self.fields['meta_keywords'].widget = TI_WIDGET
self.fields['meta_description'].widget = TI_WIDGET
self.fields['cip'].queryset = models.CIP.objects.filter(
parent_id__isnull=True)
# Get the top parent and pre-populate
if 'cip' in self.initial:
self.initial['cip'] = models.CIP.objects.get(
pk=self.initial['cip']).top_parent()
class Meta:
model = models.SchoolProduct
exclude = ('campus',)
Where DynamicChoiceField is:
class DynamicChoiceField(forms.ChoiceField):
def valid_value(self, value):
return True
Then, in the view I added handling in the form_valid override:
def form_valid(self, form):
self.object = form.save(commit=False)
# Handle the CIP code
self.object.cip_id = self.request.POST.get('cip_subcategory')
if self.object.cip_id == '':
self.object.cip_id = self.request.POST.get('cip_category')
self.object.save()
I have field in my Model which indicates whether a user wants to receive emails
receive_invites = models.BooleanField(default=True, help_text="Receive an invite email from friends")
I also have a view with an option:
[ x ] I do not want to receive emails...
By default receive_invites is True therefore the checkbox is ticked. However, I'd like the user to tick the checkbox in order to change receive_invites to False. I did the following in my ModelForm to achieve this. Does anybody have a more elegant way of doing this?
class UnsubscribeForm(forms.ModelForm):
class Meta:
model = Entrant
fields = ('receive_invites')
def __init__(self, *args, **kwargs):
if kwargs.has_key('instance'):
instance = kwargs['instance']
if instance.receive_invites:
instance.receive_invites = False
else:
instance.receive_invites = True
super(UnsubscribeForm, self).__init__(*args, **kwargs)
and in the view I have this:
if request.method == 'POST':
unsubscribe_form = UnsubscribeForm(request.POST, instance=me)
if unsubscribe_form.is_valid():
receive_invites = unsubscribe_form.cleaned_data['receive_invites']
if receive_invites:
user.receive_invites = False
else:
user.receive_invites = True
unsubscribe_form.save()
return redirect('index')
else:
unsubscribe_form = UnsubscribeForm(instance=me)
Adding on to #DrTyrsa, it's unreasonable to go through so much convolution just to follow a field naming convention. If you're attached to that field name, you can always add a property to the model that maps the data field to a value you care about:
dont_receive_invites = models.BooleanField(default=False, help_text="Don't receive an invite email from friends")
#property
def receive_invites(self):
return not self.dont_receive_invites
You can't alter the model? If you can, create dont_receive_invites field instead and save a lot of time.
Why not just remove the words "do not" from the view?
[ x ] I want to receive emails...
Otherwise, I'd recommend changing UnsubscribeForm from a ModelForm to a plain Form. Then you can invert booleans all you want without resorting to trickery. It's more work, but it'll work if you can't just change the label.
I have a Django form with a username and email field. I want to check the email isn't already in use by a user:
def clean_email(self):
email = self.cleaned_data["email"]
if User.objects.filter(email=email).count() != 0:
raise forms.ValidationError(_("Email not available."))
return email
This works, but raises some false negatives because the email might already be in the database for the user named in the form. I want to change to this:
def clean_email(self):
email = self.cleaned_data["email"]
username = self.cleaned_data["username"]
if User.objects.filter(email=email, username__ne=username).count() != 0:
raise forms.ValidationError(_("Email not available."))
return email
The Django docs say that all the validation for one field is done before moving onto the next field. If email is cleaned before username, then cleaned_data["username"] won't be available in clean_email. But the docs are unclear as to what order the fields are cleaned in. I declare username before email in the form, does that mean I'm safe in assuming that username is cleaned before email?
I could read the code, but I'm more interested in what the Django API is promising, and knowing that I'm safe even in future versions of Django.
Update
.keyOrder no longer works. I believe this should work instead:
from collections import OrderedDict
class MyForm(forms.ModelForm):
…
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
field_order = ['has_custom_name', 'name']
reordered_fields = OrderedDict()
for fld in field_order:
reordered_fields[fld] = self.fields[fld]
for fld, value in self.fields.items():
if fld not in reordered_fields:
reordered_fields[fld] = value
self.fields = reordered_fields
Previous Answer
There are things that can alter form order regardless of how you declare them in the form definition. One of them is if you're using a ModelForm, in which case unless you have both fields declared in fields under class Meta they are going to be in an unpredictable order.
Fortunately, there is a reliable solution.
You can control the field order in a form by setting self.fields.keyOrder.
Here's some sample code you can use:
class MyForm(forms.ModelForm):
has_custom_name = forms.BooleanField(label="Should it have a custom name?")
name = forms.CharField(required=False, label="Custom name")
class Meta:
model = Widget
fields = ['name', 'description', 'stretchiness', 'egginess']
def __init__(self, *args, **kwargs):
super(MyForm, self).__init__(*args, **kwargs)
ordered_fields = ['has_custom_name', 'name']
self.fields.keyOrder = ordered_fields + [k for k in self.fields.keys() if k not in ordered_fields]
def clean_name(self):
data = self.cleaned_data
if data.get('has_custom_name') and not data.get('name'):
raise forms.ValidationError("You must enter a custom name.")
return data.get('name')
With keyOrder set, has_custom_name will be validated (and therefore present in self.cleaned_data) before name is validated.
The Django docs claim that it's in order of the field definition.
But I've found that it doesn't always hold up to that promise.
Source: http://docs.djangoproject.com/en/dev/ref/forms/validation/
These methods are run in the order
given above, one field at a time. That
is, for each field in the form (in the
order they are declared in the form
definition), the Field.clean() method
(or its override) is run, then
clean_(). Finally, once
those two methods are run for every
field, the Form.clean() method, or its
override, is executed.
There's no promise that the fields are processed in any particular order. The official recommendation is that any validation that depends on more than one field should be done in the form's clean() method, rather than the field-specific clean_foo() methods.
The Form subclass’s clean() method. This method can perform any
validation that requires access to multiple fields from the form at
once. This is where you might put in things to check that if field A
is supplied, field B must contain a valid email address and the like.
The data that this method returns is the final cleaned_data attribute
for the form, so don’t forget to return the full list of cleaned data
if you override this method (by default, Form.clean() just returns
self.cleaned_data).
Copy-paste from https://docs.djangoproject.com/en/dev/ref/forms/validation/#using-validators
This means that if you want to check things like the value of the email and the parent_email are not the same you should do it inside that function. i.e:
from django import forms
from myapp.models import User
class UserForm(forms.ModelForm):
parent_email = forms.EmailField(required = True)
class Meta:
model = User
fields = ('email',)
def clean_email(self):
# Do whatever validation you want to apply to this field.
email = self.cleaned_data['email']
#... validate and raise a forms.ValidationError Exception if there is any error
return email
def clean_parent_email(self):
# Do the all the validations and operations that you want to apply to the
# the parent email. i.e: Check that the parent email has not been used
# by another user before.
parent_email = self.cleaned_data['parent_email']
if User.objects.filter(parent_email).count() > 0:
raise forms.ValidationError('Another user is already using this parent email')
return parent_email
def clean(self):
# Here I recommend to user self.cleaned_data.get(...) to get the values
# instead of self.cleaned_data[...] because if the clean_email, or
# clean_parent_email raise and Exception this value is not going to be
# inside the self.cleaned_data dictionary.
email = self.cleaned_data.get('email', '')
parent_email = self.cleaned_data.get('parent_email', '')
if email and parent_email and email == parent_email:
raise forms.ValidationError('Email and parent email can not be the same')
return self.cleaned_data