lp://staging/~bstanciu/openobject-client-web/bstanciu@openerp-web

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #891951: [6.1 trunk] [web] disruptive behaviour of the 'loading' message since rev. 1481

Undecided

Invalid

Link a bug report

Related blueprints

1509. By Bogdan Stanciu on 2011-11-18

[FIX] div with 'loading' message generates an up-down movement of the main application frame.

1508. By Fabien Meghazi (OpenERP) on 2011-11-17

[IMP] Improve listview styling

1507. By Fabien Meghazi (OpenERP) on 2011-11-17

[FIX] Also apply @context and @domain to original action of dashboards

1506. By Fabien Meghazi (OpenERP) on 2011-11-17

[FIX] Dashboard actions does not honor @context and @domain

Currently naive implementation because it does not evaluate the domain & context.
The dashboard is already overloaded with XHRs.
We should use the xmo's python evaluator for context and domains if possible.

1505. By Xavier (Open ERP) on 2011-11-17

[FIX] synchronization of o2m widget saving, avoid race condition when clicking on button of unsaved record

After saving, the formview would both refresh the form and lauch the
action itself, which launches a refresh of its own.

Issue is that o2m's filling of themselves (a read) is async and
triggered by the set_value on the o2m field, so the second reload of
the form would be interspersed (between the first reload and the end
of the o2ms loading), resulting in corrupted state for the o2ms if the
button's action somehow changed the contents of the o2m (it would
remove the old records and return brand new ids during the refresh):
the set_value on the o2m would empty the o2m's dataset cache, and the
returning fetch request would try to find in cache values removed from
it, or something, blowing up everything.

Anyway, this was fixed by ensuring the button action is only executed
after the form is completely done doing its post-save reload (using
the new async set_value). This is a tiny bit brittle in that onchanges
are synchronous but call set_value, so a set_value on an o2m from an
onchange may have issues. It also increases the flicker of the view,
as the o2m is reloaded twice in quick succession.

1504. By Xavier (Open ERP) on 2011-11-17

[FIX] issues with asynchronous set_value handling

* field could be changed from under the closure, use _.each
* There's a bug in Deferred.queue() when passing synchronous deferred
  (including non-deferred) it's instantanously resolved

1503. By Fabien Meghazi (OpenERP) on 2011-11-17

[FIX] dashboard does not honor action/@view_mode

1502. By Fabien Meghazi (OpenERP) on 2011-11-17

[FIX] callers of on_record_loaded to use promises

1501. By Fabien Meghazi (OpenERP) on 2011-11-17

[FIX] Fixed data#read_index() so it returns same argument to callback and to .then()

1500. By Fabien Meghazi (OpenERP) on 2011-11-17

[IMP] Core callbacks always return value of original method

instead of last callback in the stack