Opened 12 years ago
Closed 11 years ago
#20228 closed Bug (fixed)
Admin interface doesn't prevent duplicates with unique_for_date
Reported by: | Marek Onuszko | Owned by: | Deepak |
---|---|---|---|
Component: | Documentation | Version: | 1.4 |
Severity: | Normal | Keywords: | |
Cc: | Triage Stage: | Accepted | |
Has patch: | yes | Needs documentation: | no |
Needs tests: | no | Patch needs improvement: | no |
Easy pickings: | no | UI/UX: | no |
Description
I'm using Python 2.7.3 and Django 1.4.5-1 from Debian repositories. I can add multiple entries with identical values and the admin interface doesn't complain. I tried with both 'slug' and 'title'.
It sounds just like the bug from 4 years ago: https://code.djangoproject.com/ticket/10134
Note that while my field is DateTimeField (with time), the wording of the description at
https://docs.djangoproject.com/en/dev/ref/models/fields/#unique-for-date leads me to believe it should consider only the .date component of the DateTimeField.
# models.py from django.db import models from django.utils.timezone import now as utcnow now = utcnow() # replacing - date.now() causes problems with auto_now_add class Entry(models.Model): created_at = models.DateTimeField(default=now, editable=False) title = models.CharField(max_length = 50) content = models.TextField() slug = models.SlugField(unique_for_date='created_at') def __unicode__(self): return self.title class Meta: ordering = ['-created_at'] # admin.py from news.models import Entry from django.contrib import admin class EntryAdmin(admin.ModelAdmin): prepopulated_fields = {'slug': ('title',)} list_filter = ['created_at'] date_hierarchy = 'created_at' admin.site.register(Entry, EntryAdmin)
Change History (9)
comment:1 by , 12 years ago
Triage Stage: | Unreviewed → Accepted |
---|
comment:2 by , 12 years ago
Either way, functionality should match the documentation. To my understanding of English, it currently doesn't. An extra sentence for clarification of DateTimeField would be nice. I can't evaluate how important backwards compatibility is in this case, but from programmer convenience point of view it would be very nice to have unique_for_date only consider the .date component. "unique_for_datetime" can already be achieved with unique_together.
comment:3 by , 12 years ago
This seems similar to #18427; fixing one may also provide a stepping stone to fixing the other.
comment:4 by , 12 years ago
Component: | Uncategorized → contrib.admin |
---|
It looks like valid bug. Fortunately, it's limited to contrib.admin. I was unable to repeat this in ModelForms, Forms and Model Validation.
comment:5 by , 12 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
comment:6 by , 12 years ago
The reason for this is validate_unique skips "created_at" because it's internally in excluded fields since it's not rendered in admin UI.
@aaugustin Shouldn't we check f.name instead of f.unique_for_* in https://github.com/django/django/blob/master/django/db/models/base.py#L800-L804 ? If not then we should mark it as documentation bug and add a note in documentation that field should not be excluded.
comment:7 by , 12 years ago
Component: | contrib.admin → Database layer (models, ORM) |
---|
comment:8 by , 12 years ago
Component: | Database layer (models, ORM) → Documentation |
---|---|
Has patch: | set |
comment:9 by , 11 years ago
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
I guess it currently does
unique_for_datetime
when used on a DateTimeField.Changing to operate only on the date part is backwards incompatible, but I've already made a bunch of similar cleanups, I suppose we can do one more.