Opened 15 years ago

Closed 14 years ago

Last modified 14 years ago

#10229 closed (invalid)

Can't see values of PositiveSmallIntegerField in admin after adding the field to list_display.

Reported by: minder Owned by: nobody
Component: contrib.admin Version: 1.0
Severity: Keywords:
Cc: Triage Stage: Unreviewed
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no

Description

Django 1.0.2, Python 2.5.2
I have a model with PositiveSmallIntegerField. I added this field to list_display in model's admin but I can't see any values in the column, only "(None)". I know I can write a simple function to convert the type, but this should not be required imho. Strings, dates and boolean are handled good - why numbers are not?

models.py:

from django.db import models

MEALS=(
('0','Own'),
('1','1'),
('2','2'),
('3','3'),
)

class Person(models.Model):
	first_name = models.CharField(max_length=20)
	last_name = models.CharField(max_length=30)
	email = models.EmailField()
	meals = models.PositiveSmallIntegerField(default=0, choices=MEALS)
	verified = models.BooleanField()

	def __unicode__(self):
		return self.first_name + ' ' + self.last_name

admin.py:

from django.contrib import admin
from myproject.myapp.models import Person


class PersonAdmin(admin.ModelAdmin):
	list_display = ('first_name', 'last_name', 'email', 'meals', 'verified',)
	list_display_links = ('first_name', 'last_name',)
	search_fields = ('first_name', 'last_name', 'email',)
	list_filter = ('verified',)

admin.site.register(Person, PersonAdmin)

Attachments (1)

list_display.diff (1.2 KB ) - added by Scot Hacker 14 years ago.
Documentation of need to use real integers in CHOICES tuples for list_display.

Download all attachments as: .zip

Change History (6)

comment:1 by arien, 15 years ago

Resolution: invalid
Status: newclosed

You're storing strings that look like integers (the first element of each MEALS tuple) in a PositiveSmallIntegerField. Fix this inconsistency and the problem goes away.

For fields with choices, the admin will try to use the "human-readable" representation of the field's value. If the admin doesn't find the field's value (an integer in your case) as the first element in one of the tuples in the list of choices (strings in your case), it will use (None) as the human-readable representation.

(See django.contrib.admin.templatetags.admin_list.item_for_result for the details if you're curious.)

comment:2 by Scot Hacker, 14 years ago

Has patch: set
Resolution: invalid
Status: closedreopened

This could really use a mention in the list_display documentation. Patch attached.

by Scot Hacker, 14 years ago

Attachment: list_display.diff added

Documentation of need to use real integers in CHOICES tuples for list_display.

comment:3 by James Bennett, 14 years ago

Resolution: invalid
Status: reopenedclosed

I'd prefer that we leave it as assumed that stuffing strings into a numeric field type can cause problems.

comment:4 by Scot Hacker, 14 years ago

I think it's worth documenting because strings are valid keys in CHOICES, so this catches people unexpectedly. The reality is that you can't use a string that happens to look like an integer even if you want to. The docs don't say that, so the developer ends up thinking something is wrong with they way they've set up list_display when the problem really is that Django doesn't allow any old string as a CHOICES key.

comment:5 by James Bennett, 14 years ago

Any Python data type can, technically, be used here. What you're supposed to do is use values of the type that's appropriate for the field they go in. If your database accepts other types of data there, that's your DB's fault in part, but really the lesson here is that the values need to be valid for the field type. Which, hopefully, is obvious.

Note: See TracTickets for help on using tickets.
Back to Top