[patch] ChangeManipulator does not correctly display <select> when the data is an id type

[wgunadi@…]

When a field in a Change Manipulator form is a relation to another object/table, the __dict__ stores:

field_name + "_id"

as the key to the dictionary entry. For example:

{'name': 'CCN_PRJ1_PROD_R2', 'appname_id': 2, 'id': 5}
Notice that the appname field is keyed as 'appname_id'

So, when the Change Manipulator code in formfields.py:getitem() tries to get the data, it won't find it.

[wgunadi@…]

Suggested fix

[wgunadi_at_nextcoder.net]

SUGGESTED FIX:
When the data is percieved as None, I've inserted a simple check if using the "fieldname_id" will yield a different result than blank. If it is, then we know that this data is a relation to an existing object. So the <select> will be rendered correctly.

Diff containing the fix is attached.

[rjwittams]

This is fixed correctly in new-admin.

[wgunadi@…]

Yes but applications that uses the Change Manipulators will still have this problem if not fixed on the formfield.py. This patch (or something else) need to be applied.

[rjwittams]

Yes, the plan is to merge the new-admin branch back to trunk.
There is no point adding an incompatible fix to trunk before that.

[rjwittams]

Fixed in new-admin merge.