No, it isn't a bug; there's maybe an argument that the default behaviour could be improved, but the existing implementation is a reasonable first pass (as evidenced by the fact that it works on integers, strings, foreign keys, etc). There's enough metadata about the model, and enough deserialization code that it would be possible to do slightly better handling here, but I don't think it's a straight up bug.
The good news is that there is an official way to handle this; on your ModelAdmin
class, define:
def get_changeform_initial_data(self, request):
This method takes the request, and converts that request into the value that will be passed in as the initial
argument to the form on a change list (i.e., an add or edit page in Admin). As you might expect, the default implementation of this method is "take the GET arguments and convert into a dictionary"; if you do some additional handling for the fields that you know to be datetimes, then
Alternatively, you don't have to use the request object at all. If you know that "Person" objects will always have an initial name of "Unknown", and an initial start date of 1 Jan 2014, then you can just write:
class PersonAdmin(ModelAdmin):
...
def get_changeform_initial_data(self, request):
return {
'name': 'Unknown',
'start_date': date(2014, 1, 1)
}
i.e., don't pay any attention to the request data, just populate the initial data manually. Since it's initial data to the form, any existing data on the object will override the value provided in initial
, and that initial data will be used without the user needing to provide any GET
arguments in their request.