c2c-oerpscenario team mailing list archive

[Don Kirkby <530307@xxxxxxxxxxxxxxxxxx>]

Hi DHS,
Are you sure the behaviour you describe is normal? If moving from one contact to the next on a partner screen discards any unsaved changes, then shouldn't it warn the user? Moving from one partner to the next will warn the user before discarding any unsaved changes, why shouldn't contacts be the same?

I like the behaviour in trunk. It holds the changes in memory for all
the partner's contacts until you hit save. If that's not possible in the
5.0 branch, then I would prefer the previous behaviour where it thinks
the record has changed just because you moved to another contact record.
That's annoying, but at least it doesn't risk users accidentally losing
data.

** Changed in: openobject-client
       Status: Fix Released => New

-- 
Showing next address marks partner as modified
https://bugs.launchpad.net/bugs/530307
You received this bug notification because you are a member of C2C
OERPScenario, which is subscribed to the OpenERP Project Group.

Status in OpenObject GTK Client: New

Bug description:
Steps to reproduce:
1. Open a partner that has at least one address. In the sample data, use Agrolait.
2. Click the arrow icon to move to the next partner contact.
3. Close the Partners screen.

Expected behaviour: when I close the Partners screen, I have not made any changes, so it should just close.
Actual behaviour: it prompts me, "This record has been modified do you want to save it?"

Analysis:
The record is marked as modified when you move to the next contact. Put a break point in client/bin/widget/screen/screen.py line 584 in display_next(). From there, it calls record.validate_set(), record.reload(), record._reload(), and record.set(). In record.set(), it signals the 'record-changed' event. That fires some code at client/bin/widget/model/group.py line 254 in _record_changed(). That signals the 'model-changed' event, and that fires some code at /bin/widget/model/field.py line 343 in _model_changed(). And that is where the modified flag gets set.

My guess is that the reload() method somehow needs to determine whether or not the set() method should send the 'record-changed' event. Maybe it's as simple as adding a signal parameter with default value True, but I'm not sure.