DateTimeField doesn't show in admin system

How come my "date" field doesn't come up in the admin system?

In my admin.py file i have

from django.contrib import admin
from glasses.players.models import *
admin.site.register(Rating)

and the Rating model has a field called "date" which looks like this

date = models.DateTimeField(editable=True, auto_now_add=True)

However within the admin system, the field doesn't show, even though editable is set to True.

Does anyone have any idea?

If you really want to see date in the admin panel, you can add readonly_fields in admin.py:

class RatingAdmin(admin.ModelAdmin):
    readonly_fields = ('date',)

admin.site.register(Rating,RatingAdmin)

Any field you specify will be added last after the editable fields. To control the order you can use the fields options.

Additional information is available from the Django docs.

I believe to reason lies with the auto_now_add field.

From this answer:

> Any field with the auto_now attribute > set will also inherit editable=False > and therefore will not show up in the > admin panel.

Also mentioned in the docs:

> As currently implemented, setting > auto_now or auto_now_add to True will > cause the field to have editable=False > and blank=True set.

This does make sense, since there is no reason to have the field editable if it's going to be overwritten with the current datetime when the object is saved.

Major Hack:

If you really need to do this (as I do) you can always hack around it by immediatley setting the field to be "editable" defining the field as follows:

class Point(models.Model):
  mystamp=models.DateTimeField("When Created",auto_now_add=True)
  mystamp.editable=True

This will make the field editable, so you can actually alter it. It seems to work fine, at least with the mysql backing engine. I cannot say for certian if other backing stores would make this data immutable in the database and thus cause a problem when editing is attempted, so use with caution.

Depending on your specific needs, and any nuances in difference in behavior, you could do the following:

from django.utils.timezone import now

class MyModel(models.Model):
    date = models.DateTimeField(default=now)

The default field can be used this way: https://docs.djangoproject.com/en/dev/ref/models/fields/#default

The default value for the field. This can be a value or a callable object. If callable it will be called every time a new object is created.

This does not set editable to False

It might have to do with the auto_now_add being true. Perhaps instead of that parameter to capture the date on add, you could override the model save method to insert the datetime when the id is null.

class Rating(models.Model):
    
    ....
    def save(self, *args, **kwargs)
        if not self.id: 
            self.date = datetime.datetime.now()

If you want any field to be visible in the list of all your entries (when you click on a model in the admin people) and not when you open that particular entry then -

class RatingAdmin(admin.ModelAdmin):
    list_display = ('name', 'date') 

admin.site.register(Rating, RatingAdmin)

'name' being your main field or any other field you want to display in the admin panel.

This way you can specify all the columns you want to see.

You can not do that, check the documentation

auto_now and auto_now_add are all non-editable fields and you can not override them...

Can be displayed in Django admin simply by below code in admin.py

@admin.register(model_name)
class model_nameAdmin(admin.ModelAdmin):
 list_display = ['date']

Above code will display all fields in django admin that are mentioned in     'list_display', no matter the model field is set to 'True' for 'auto_now' attribute

I wanted to create an editable time field that defaults to the current time.

I actually found that the best option was to avoid the auto_now or auto_add_now altogether and simply use the datetime library.

MyTimeField = models.TimeField(default=datetime.now)

The big thing is that you should make it's the variable now instead of a function/getter, otherwise you're going to get a new default value each time you call makemigrations, which will result in generating a bunch of redundant migrations.