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
- hr_holidays: renamed My Leaves filter by My Requests, more accurate
- hr_recruitment: string of name field is not Subject / Application Name, more accurate; this string is used in the search view also.
bzr revid: tde@openerp.com-20131212104612-2fbn9130emyvxg7s
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
Task 4941
Extracted relevant section from One2ManyList which already implemented
it previously, then created and hooked in m2m list using (inheriting
from) extracted code.
bzr revid: xmo@openerp.com-20131210164443-ur44b8g5gdrt8jt1
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
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
- new module organisation: model-related files in models/, demo in demo/, view data in views/
- code cleaning to lessen the code size
bzr revid: tde@openerp.com-20131206163911-qx1k1edogqxg52kv
don't create new analytic lines at move creation, will do it once the move is balanced
don't remove analytic lines (to avoid duplicates) at the begining of the validation of a move, will do it once we create the new correct analytic lines (opw 597719)
bzr revid: mat@openerp.com-20131206131125-fvzy62qqx3gnwmw5
IME are ways to input language which can't trivially map to a keyboard
(e.g. CJK language) with a standard-ish keyboard. For japanese IME
this is done by entering text phonetically: text is entered in romaji
and automatically converted to hiragana (or katakana) when it matches
the transcription a japanese syllable (~phoneme?) e.g. to (と). The
text is then split and reprocessed with sequences of hiragana being
converted to kanji (or not), and the possibility to pick the right
kanji when multiple kanji match e.g. for "Tokyo" toukyou -> とうきょう
-> 東京.
But to do the edition, keyboard keys are used. For the japanese IMEs
(tested on Windows, OSX and Linux) [Space] will do the initial
conversion from kana to kanji (and allow selecting an other conversion
or a different kana split) and [Return] will validate the current
conversion (removing the underline marking "unvalidated" kana or kanji
groups).
And that's where the problem hit: IME + browser combinations may or
may not suppress part of all of the event. Firefox will trigger a
keydown of the key which "starts" IME input (e.g. "t") and will
trigger a keyup for the validation key (return), except on Linux where
the initial keydown is suppressed. Inbetween these, it will fire no
keydown, keyup or keypress event but will fire input events (at least
on an input element) every time the displayed text changes.
Meanwhile webkit browsers will, for each press on the keyboard during
IME,
* trigger a keydown with the keyCode 229
* trigger a keyup event with the keycode of the key which was actually
hit
* trigger input events every time the displayed text changes
This include meta-operation uses of [Space] and [Return].
MSIE has the same behavior (including triggering the input event), but
the keydown event is augmented with ``key`` and ``char`` attributes
providing the character matching the key hit to trigger the change.
Although the triggering of the input even is useless for the purpose
of the editable list (especially here, the purpose of validating a
list row with [Return] one fact stands out: keypress is never
triggered during IME operations, hitting the [Return] key outside of
IME will trigger keydow, keypress, keyup but doing so during IME will
only trigger the first and last.
Thus by changing the binding from keyup (return) to keypress (return)
for a line validation, spurious validation during IME text entry
should be avoided. This seems to work correctly on MSIE (Windows),
Firefox (Windows, OSX, Linux), Chrome (Windows, OSX, Linux) and Safari
(OSX), after testing in IE9, IE10, Chrome 31, Firefox 25 and Safari 7,
and a quick test on a task's o2m did not reveal any regression.
note: not all differences between various browser/os combinations were
inspected in details, there may well be further differences which were
not noticed or not relevant to this precise issue.
bzr revid: xmo@openerp.com-20131206124431-q4a9l1gn9wjtmlvz
Deliveries to invoice in sales menu should display delivery order only (no incoming shipment). This was already the case thanks to the domain [('type','=','out')], but since the refactor of the module stock, and the division of stock.picking to stock.picking.in and stock.picking.out, the model of this view should be stock.picking.out instead of stock.picking (for instance, to get the actions binding (ir.values) of stock.picking.out model).
+ typo fix in action binding
bzr revid: dle@openerp.com-20131206111336-dg01y92jvjnxy5oi
remove analytic lines (to avoid duplicates) only when create new one instead of each validation of the account move
don't create new analytic lines at move creation, will do it once the move is balanced (unbalanced move should not create analytic lines yet)
bzr revid: mat@openerp.com-20131206104659-vct8a5l9o4nmhwqs
Including:
- sales team members are displayed
- fixed sparklines whose numbers were incorrect
- sparklines now redirect to a correct report view, filtered for the sales team, grouped by month, in order to have matching results between the vignette links and the displayed reports
- custom css in crm put in a sass file
- sale_crm extend the crm reports, to add the section_id field in the reports, allowing to filter / group by salesteam. The analysis view has been put into several methods to allow extension.
bzr revid: tde@openerp.com-20131205160029-1tljp52ovcavwxel
- sales report: the group by salesteam was wrongly placed in the view
- sale_crm: fixed computation for sparklines, now bar graph should display the same
result as the sales analysis
- added a forgottent cursor: pointer for a gauge
- moved the gauges in the dom
- sale_crm: report: removed extra content not necessary
bzr revid: tde@openerp.com-20131205144505-jfsd8lh91r1b13a1
- moved css into sass file to standardize the process
- commented some records added in the xml file of crm.case.section that do not seem necessary
bzr revid: tde@openerp.com-20131205124749-3a1quhetgxq2d224
When processing an incoming email, we try to find a parent for the email based on references. Before this merge, it was done using openerp-<model-<res_id> pattern. However it is buggy. Indeed having two OpenERP sending emails to each other leads to messages being inserted in a wrong thread (model and res_id of the first OpenERP for both instances).
Now we search for an exact match between the references and the stored message_ids. As each message_id can be considered as unique the number of collisions is lessened. This won't cause any issues with OpenERP >= 7.0.
A compatibility mode is implemented for <= 6.1: as in those versions the message_id is not stored, we fall back on the previous behavior for records having messages without message_id. This indicates that the record was created before 7.0.
Tests have been updated accordingly, and a test added for the compatibility mode.
bzr revid: tde@openerp.com-20131205100534-2rlyun8wqng3qa6f
- removed a debug print statement
- now searching all references once instead of each reference one at a time
to lessen the number of queries; as the newest message will be the first
in the search result, it's ok.
bzr revid: tde@openerp.com-20131205093921-h7sits57vqc51c8p
case: web_kanban_gauge has been added in the dependance of sale_crm. This module used to auto install when module sale and crm were installed. With this new dependance, the module sale_crm auto install when sale, crm and web_kanban_gauge are installed. We auto install kanban gauge so sale_crm auto install on installation of crm and sales, as web_kanban_gauge will be already installed
bzr revid: dle@openerp.com-20131205093615-1c9z0g5439xokdbt
Because defaults get function of partner_id of wizard read the partner_id of the opp and return the first item of the tuple, but if there isnt a partner on the opp, the read return a false for this field, not a tuple.
No return the first item of the tuple if the partner_id is set, else False
bzr revid: dle@openerp.com-20131204133633-t7wfbnipv3jtss82
In im_session model, field channel_id was a many2one to im_user, or, obviously, this should be a many2one to im_livechat.channel
Well, obviously, this is a copy/paste error (or distraction, your choice!). This fix should normally not be pushed on a stable branch (like the current one, saas-2), but considering the severity of the problem, and the few changes in database (alter foreign key only), this is acceptable. Why such a big mistake has not been seen earlier ? Do you even test or read back what you write ?
bzr revid: dle@openerp.com-20131204122727-q0ch5j2v8rrli41e
Thibault Delavallée
Frédéric van der Essen
Launchpad Translations on behalf of openerp
jke-openerp
Martin Trigaux
Xavier Morel
Xavier ALT
Denis Ledoux
Cecile Tonglet
Olivier Dony
Gery Debongnie
Christophe Simonis
Antony Lesuisse
Michel Meyer