Otherwise, the user who creates the allocation request by employee tag will benefit of the leaves he just entered, twice if he has the employee tag, once if has not the employee tag(and in this last case, he should not have this leave allocation, as he do not have the tag
bzr revid: dle@openerp.com-20131211180025-pg8kf13bt6d1vk9l
default_model and default_res_id were not present when doing this fix, because in the web client, we prevented the propagation of the context keys beginning with "_default" in some cases.
The fact is that, in this specific case, the keys "default_" should not have been removed. This has been fix in web client in
rev 3892 revid:chs@openerp.com-20131211163609-i3s2mlncf5n91uda
Besides, active_model cannot be used here, as active_model is not 'sale.order' but the model of the wizard.
bzr revid: dle@openerp.com-20131211171429-6bxuh7o4ueiy9dd1
Since 7.0, signaling has changed, and the change was not wrongly done here, on the wrong model (self.signal_ instead of self.pool.get('stock.picking').signal_)
Therefore, created chained picking were not confirmed and were left in draft.
For instance, push rules were creating internal moves in draft state instead of confirmed state
bzr revid: dle@openerp.com-20131210173828-bah4lllgvi61r1s3
- [FIX] mass_mailing: fixed model used for the mass mailing itself when creating a new wave. It was receiving active_model aka mass.mailing.create instead of the correct target model (ex res.partner when mailing partners). Also updated a field string to be clearer.
- [FIX] mass_mailing: wave creation wizard: fixed closing button jumping after setting the wave name
- [FIX] mass_mailing: fixed label for template choice when creating a new wave of mass mailing
- [IMP] mass_mailing: added a link to create a wave directly from the kanban view
lp bug: https://launchpad.net/bugs/1239937 fixed
bzr revid: tde@openerp.com-20131210150649-f07vkb7xu4dyc4s4
Save a few time by not not trying to apply ir.rule for superuser, that will
anyway be skipped within ir.rule's ``_compute_domain`` method.
bzr revid: xal@openerp.com-20131210140330-oui4oy8pez12xkxv
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.
lp bug: https://launchpad.net/bugs/1257753 fixed
bzr revid: xmo@openerp.com-20131210124755-ugr3ehf744qoh1o5
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.
lp bug: https://launchpad.net/bugs/1253899 fixed
bzr revid: xmo@openerp.com-20131210093055-207fevqc1npy7fwr
The create() method implicitly creates parent records on objects of the _inherits.
Therefore, in order to make the trigger on the linked field works, we should
include all the _inherits values (fields that make the link to the parent
record) because they are created implicitly.
The write() method does not need this change, as any update of the parent
fields has to be explicit.
bzr revid: odo@openerp.com-20131209184718-wczdefzo9evc0cgc
The create() method implicitly creates record on objects of the _inherits.
Therefore, in order to make the trigger on linked field works, we should
include all the _inherits values (field that makes the link to the rel
record) because they are created implicitly.
bzr revid: cto@openerp.com-20131209154857-788f94w0kh6ef5pp
Returns were partially ignored when typing keystrokes, thanks to a return; when event which equaled 13, but the default behaviour (press on the focused input/button) was not prevented. This is now the case thanks to preventDefault. For instance, just after a discount set, the focused input was pressed and the associated value was added when scanning a new product with the scanner. Therefore, if we entered a discount of 30%, scanning a new product added '0', the last pushed button, to the discount, and then added the product.
bzr revid: dle@openerp.com-20131209145652-3g9rgnfz1w8k0whw
The set method of the field, set_followers, is now using message_subscribe and message_unsubscribe to have only one access point to adding or removing followers. Previously to this fix it was directly creating entries in the mail_followers table, neglecting the calculation of subtypes and default subtypes.
bzr revid: tde@openerp.com-20131209100822-f19udgfuubshhrg3
Web client returns (4, ) operations for unchanged line in one2many widgets.
This allows to skip orm write on object where potentially has no access (eg: timesheet line with another user). (opw 599494)
bzr revid: mat@openerp.com-20131206144301-k6ugjota873nz75d
Thibault Delavallée
Denis Ledoux
Christophe Simonis
Martin Trigaux
Launchpad Translations on behalf of openerp
Xavier ALT
Xavier Morel
Antony Lesuisse
Cecile Tonglet
Michel Meyer