Change history shows value stored instead of human readable string on choices fields at adding

[juanj.marin@…]

class Detalle_Visita(models.Model):
    OFERTAS = (
        (1, 'ARQUEOLOGIA (guia)'),
        (2, 'BELLAS ARTES (guia)'),
        (3, 'TIA NORICA (guia)'),
        (4, 'TODO EL MUSEO (guia)'),
        (5, 'ARQUEOLOGIA'),
        (6, 'BELLAS ARTES'),
        (7, 'TIA NORICA'),
        (8, 'TODO EL MUSEO'),
    )
    detalle_visita = models.ForeignKey(Visita,edit_inline=models.TABULAR,max_num_in_admin=3,num_extra_on_change=3)
    oferta = models.PositiveSmallIntegerField(verbose_name="Area a visitar",max_length=2,choices=OFERTAS,core=True)

This misbeahiour happens only at adding, not at deleting

March 21, 2008, 2:40 p.m.  	administrador  	Deleted Itinerario visita "ARQUEOLOGIA (guia)".
March 21, 2008, 2:40 p.m. 	administrador 	Added Itinerario visita "2".

[Malcolm Tredinnick]

Fixed description formatting. I keep hoping that one day people will use the preview button.

[juanj.marin@…]

Sorry for the format, I was going to fix it but you did it faster. Thank you !.

[James Bennett]

Marking newforms-admin since that's where it should be fixed.

[Karen Tracey <kmtracey@…>]

I'd like to verify this will work properly in newforms-admin when #6117 is implemented but am having trouble recreating on current trunk admin. Could you post a few more details of your models here? In particular the __unicode__ method for Detalle_Visita seems relevant to what the admin logs record, but the whole model definition would be best/easiest for me to diagnose. Would be good to see Visita as well so I don't have to just make things up. Also how are you adding/deleting the objects? I assume from the page where they are edited inline but I'd like to clarify that.

[Karen Tracey <kmtracey@…>]

Per note from Juanjo Marin __unicode__ for the inline-edited object is using get_oferta_display, so _get_FIELD_display. Problem occurs because when the old manipulator code creates a new object, the field value is not an integer type but rather the unicode representation of the integer. Thus lookup in the choices dictionary (where keys are integers) fails to find a match and _get_FIELD_display falls back to returning the input value. This problem doesn't exist in the newforms-admin code path -- at the point where the log message is created the new object is able to display itself correctly. I verified the problem does not occur with the latest patch for #6117, but there is nothing in that code specifically to fix the problem, it's been fixed by the surrounding infrastructure changes. So I'm going to mark this "fixed on a branch" even though that's fudging a bit since change history isn't actually implemented yet in newforms-admin. Point is nothing needs to be done in newforms-admin to fix this problem.

[Juanjo Marin]

I try with Django version 0.97-pre-SVN-7397 and I've found again this behaviour. ¿Is this patch applied to this version?
Sorry for my ignorance.

[Karen Tracey <kmtracey@…>]

No, the fix is not in yet. This won't be fixed directly on trunk, since all admin effort these days is going into newforms-admin. The code causing the problem is old manipulator code unused by newform-admin, so newforms-admin won't have the problem, but newforms-admin today also does not implement change history. That missing function will be added when #6117 goes in. So, if you wanted a way to run with a fix for this today you would have to both switch to using newforms-admin plus apply the patch from #6117. Or you could wait until newforms-admin is merged back to trunk.

[Karen Tracey <kmtracey@…>]

Change history has been implemented in nfa, this is now really fixed on the branch.

[Brian Rosner]

This is no longer a problem since the merge of newforms-admin in [7967].