The various attempts to fix this error without duplicating the node
have all caused other errors. Having a duplicate process node has
no consequence on business operations, so it is an acceptable
workaround until the node can be moved to the sale module.
bzr revid: odo@openerp.com-20131217104301-t8fsf28jgjqq9q7k
Short of signaling the other workers, the (new) automated
rule may be randomly ignored, depending on which worker
handles the request (until the workers all reload
their registries).
bzr revid: odo@openerp.com-20131216142049-xh9gxy5cir3p2i09
is_overdue_quantity is a stored function field which was updated only when analytic lines where updated. Or, when the quantity_max field is updated, this field should be recomputed and restored. This is now the case
bzr revid: dle@openerp.com-20131216111218-zcz8qwa7zn3iwvye
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
Denis Ledoux