lp:~camptocamp/ocb-web/7.0-ContextGroupByPropagationIssue-1101840

Branch merges

Propose for merging

No branches dependent on this one.

Merged into lp:ocb-web at revision 4128

Stefan Rijnhart (Opener): Approve on 2014-01-21

arthru (community): Approve on 2014-01-21

Alexis de Lattre (community): Approve (tests only) on 2014-01-21

Pedro Manuel Baeza: Approve (code review) on 2013-12-11

Nicolas Bessi - Camptocamp (community): Approve (no test, code review) on 2013-12-11

Diff: 59 lines (+36/-2)

1 file modified

addons/web/static/src/js/views.js (+36/-2)

api

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Bug #1101840: [trunk/7.0] kanban link not working proper after Group By.	Undecided	Fix Released
Bug #1263888: Context keys *_view_ref of one2many propagated to buttons	Undecided	Fix Released

Link a bug report

Related blueprints

4099. By Guewen Baconnier @ Camptocamp on 2014-01-21

remove the first version of the patch

4098. By Mohammed Shekha(OpenERP)<email address hidden> on 2014-01-07

[MRG] keep in sync with the upstream branch: lp:~openerp-dev/openerp-web/7.0-opw-601491ContextGroupByPropagationIssue-msh

4097. By Guewen Baconnier @ Camptocamp on 2014-01-07

[MRG] from lp:ocb-web/7.0

4096. By Mohammed Shekha(OpenERP)<email address hidden> on 2013-12-11

[FIX]Web: Fixed the issue of group and search_default propagated in context to next action while executing button action.

4095. By xmo on 2013-12-10

[FIX] prevent field going to be misplaced when going from readonly to writable in editable list view

4094. By Xavier (Open ERP) on 2013-12-10

[FIX] weird behavior when drag&dropping a row during edition in editable listview

When dropping, would simultanously stop the edition and try a write
(so 2 writes on the same record) and generally screw up the state of
all the things, ending up with an empty row and a weird (and
incorrect) warning.

This can be fixed by preventing resequencing during the creation or
edition of a record (row) inline.

For simplicity, implemented by looking up .ui-sortable descendants —
there are no utility methods for handling that and, aside from the
class, there's no good way to know if sortability was enabled on a
list body or not (as far as I can see, jquery-ui's sortable has no API
to query that) — and using jquery-ui's sortable API for enabling and
disabling sortable on the fly.

4093. By Martin Trigaux (OpenERP) on 2013-12-10

[FIX] css: avoid tabs in row below to move when selected (opw 601379)

4092. By Xavier (Open ERP) on 2013-12-10

[FIX] issue when tabbing too much at end of editable list row

Tabbing is intercepted by keydown_TAB, which — if the current cell is
the last active field of the row — will then call _next:476. _next
then calls save_edition:300 which "takes a lock" (more precisely
serializes access to its body) and within its body checks if an
edition is active (:303) and returns immediately if not (:304).

The problem here is when a second tab event arrives during the
potentially extremely long save_edition body (since for toplevel lists
it needs to perform a complete RPC call): the overall state of the
list has not changed so the second event *also* goes into _next, then
into save_edition. There it's serialized with the ongoing call and
thus inactive until said ongoing call's termination, and reaches the
body after the current edition has been wound down. As a result, the
body of _next (:408) gets the resolution of ``$.when()``, which is
``null`` and the first condition blows up.

There are 3 possible ways to fix this:

* adding a check in keydown_TAB's handler to see whether a _next call
  is ongoing. This requires adding a state flag to the object and does
  not protect (or cooperate with) _next calls from outside this
  specific handler, unless they are modified in turn.

* alter save_edition to *fail* in case there's no ongoing edition:
  this part was originally in ensure_saved which does not care whether
  a save was necessary or not and does not propagate save information,
  so ``$.when()`` made sense. In save_edition, there are really 3
  different outcomes: the save succeeded, the save failed (or
  potentially part of save's postprocessing failed, for the current
  implementation) and the save was unnecessary. But deferred only
  provide 1 bit of state (success or failure), so the last state has
  to be merged into either success or failure.

  Both make sense, to an extent. Changing from one to the other (as
  necessary here) could break existing code and have more extensive
  effects than expected.

* the simplest and least far-raging change is to just alter the
  save_edition().then handler to ignore cases where save_edition()
  results in no saveinfo, this can be assumed to be a
  bailed-out/unnecessary save call.

For simplicity, the 3rd solution was picked here although with more
extensive tests &al I'd have preferred trying out 2nd.

4091. By Michel Meyer on 2013-12-09

[FIX] events handling ordering courtesy of Michel Meyer

lead to errors during the validation of rows in list o2ms.

See https://bugs.launchpad.net/openerp-web/+bug/1182101/comments/20
for an extensive description of the events and issue.

4090. By Launchpad Translations on behalf of openerp on 2013-12-08

Launchpad automatic translations update.