Instead of 'Euro' hardcoded.
As the currency complete name is not available in res.curreny model, exceptions are made for currencies EUR, USD and BRL, the mosts used currencies for checks (+75% of cases)
bzr revid: dle@openerp.com-20131223154631-21oenwn8mxszyo5t
is already assigned into contract and that is deleted, it will affet the Payslips which were already created and will have [False] value.
bzr revid: rha@tinyerp.com-20131223101841-6fbwfm90gn7sj17m
email_recipients is a char fields holding a comma separated list of partner_ids
that are the email recipients. This field is correctly handled in the composer
but was not taken into account in the send_mail method email_template.
However due to model limitations, this field can only be taken into account
when sending the email directly using force_send. When the email is
queued, no field is available to hold the value of email_recipients.
This is already fixed in trunk/v8 as a field has been added to handle
this value.
[FIX] mail: when sending email to some recipients_ids, filter to have only
the existing partner_ids. Trusting email template to generate valid
partner_ids is a bit risky.
[TESTS] email_template: added tests for send_mail
bzr revid: tde@openerp.com-20131220144652-h18yam60vpedbh7x
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
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
Foram Katharotiya (OpenERP)