When a COA is installed being loaded for current company, the
translations of taxes, account name, ... (in l10n_be, l10n_ca, l10n_ch,
l10n_sa) are copied from the templates to the accounting records.
This is done in `post_init_hook` which is correct since then
translations are available to be copied.
But when an accounting localization is already installed and we set it
to a company, the translations are not copied.
eg. install l10n_be for company1: accounts name are translated in
french and dutch, set company2 to belgian accounting: only original
language is available.
With this changeset, the translation copy is also performed when an
accounting localization is loaded for a company after it has been
installed.
note: if we install language for first times after setting accounting
localizations, chart of account are translated in that language.
opw-2047013
closes#35985
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
usecase to reproduce:
- Set the warehouse with manufacturing 3 steps
- Create a BoM with a Components that use a Sub BoM
- Set Both product MTO + Manufacture
- Create a MO
You have only 2 picking for the first MO with the SFP
that contains both the finished product and the intermediate
component. However they are created and moved at two different times
since you could not create the finished product withtout the
component, so there is no meaning to put them both in the same picking.
It happens because the _assign_picking will merge moves with the same
procurement group. In our case, it's the wanted behavior to have the
2 differents SFP linked to the same MO. So the solution would be to
add a condition to _assign_picking and don't merge moves if they come
from different MO, at this point the field created_production_id would
fit. However this solution is not robust if a customer creates a
new rule that add a 4th steps to the production process.
opw-2055688
closesodoo/odoo#35915
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Co-authored-by: Andrea Grazioso (agr-odoo) <agr@odoo.com>
Let's assume an action with 'create': 0 in the context, and a non
inline subview in the form view. Before this rev., the 'create': 0
was applied to both the form view and the subview.
This rev. applies the same logic as what the server does for inline
subviews: the rule is applied to the subview iff its model is the
same as the one of the form view (with key 'base_model_name' set
in the context).
Task 2035653
closesodoo/odoo#36109
Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>
- In stock, create a new transfer (stock.picking);
- Enter a source location ('A'), a destination location ('B') and an
operation type;
- Add product (whit out packaging);
- Change the source ('C') and the destination ('D') location;
- Hit save.
Before this commit, when opening the details of the move, the source and
destination location where setted as 'A' and 'B', the locations that
were setted before adding the product.
Now, the source and destination location of the move line are 'C' and
'D', the current location at the time we save the picking.
opw-2058240
closesodoo/odoo#36089
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Display your website in Right To Left
Go see the phone number of the company
Make that number in the form
```
123[space]456[space]789
```
Before this commit, the blocks of that number were inverted
(intra-group order did not change)
Leaving us with
```
789[space]456[space]123
```
After this commit, we introduce a little class to force Left To Right
display
OPW 2059917
closesodoo/odoo#36115
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
- Product category: FIFO (real_time) / Automatic
- Product: storable, nvoicing based on delivered quantity, FIFO category
- Receive 3 units @ 30
- Create and confirm a SO for 1 unit
- Deliver requested qty to customer
- Unlock the picking, update the qty done to 3, lock.
- Invoice delivered qty
In the journal entry of the customer invoice, the COGS entry is 180
instead of 90.
The root cause of this is the incorrect price unit on the modified stock
move, which equals to -60 instead of -30.
The price unit should compute the weigthed average of the already
delivered quantity with the extra quantity.
opw-2047719
closesodoo/odoo#36065
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
Before this commit, the code that was supposed to close the dropdown in the
navbar when scrolling was not working anymore.
Indeed, it would removes the `show` class from the `nav-item dropdown`
(dropdown menu entry) but not from the `dropdown-menu` (dropdown content).
Fixes#35320closesodoo/odoo#36069
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Before this commit, crm_reveal always pushed a stocky warning to the
bus on rule creation, even if GeoIP was rightly set
(i.e. python package AND the database in /usr/share/GeoIP)
This was because the file imported the variable from another one
that copy was not updated with the initialization of the session
After this commit, we call the variable at runtime rather than import it
at init time
There is no more sticky message
OPW 2052995
closesodoo/odoo#35906
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Create two models, `object` and `category`. The object have a Many2One
to the category. Override the `search` on the category so it returns a
subset of the records if a context key is present. Create an IR Rule on
object with the following pseudo-domain: `categ_id in category.search([])`.
Search on object with the context key present. Even if the context
should only be applied to category, it is applied to object too thus
there are some object missing.
When evaluating the domain of IR Rules, the current user is propagated
with the current environment context. API calls triggered by the domain
are called with the given context, possibly populating the cache with
different records than it would normally does without the context (i.e.
at `addons/point_of_sale/models/account_journal.py#L19-L23`). Following
requests do use that invalid cache thus return invalid results.
Forcing an empty context on the user used during the evaluation of the
context ensures the IR Rules are working as they should and is
future-proof (cf `load_company` v13 context key)
opw-2041667
closes#35123closes#35125closesodoo/odoo#35667
Signed-off-by: Julien Castiaux <Julien00859@users.noreply.github.com>
Co-authored-by: Hugo Adan <hugo@vauxoo.com>
Rewrite the product associated to a serial number.
There is a check to forbid this if some move lines already exist.
This check does not actually care what value is written,
so it can raise uselessly (and forbid a legitimate write).
opw 2049717
closesodoo/odoo#35736
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Because of a whitespace character present at the beginning of the message_id of some mails,
they were fetched twice.
From the SQL side, we see that Outlook is formatting the header following the RFC822
by allowing the header to look like:
Header:<CRLF>
<whitespace><hash_of_msg_id>
From RFC822:
"Each header field can be viewed as a single, logical line of ASCII characters.
For convenience, the field-body portion of this conceptual entity can be split
into a multiple-line representation" (abr.)
It was also possible to find out by checking the logs.
One or two whitespace(s) can be seen before the hash of the msg_id.
The following commit is making sure we use and save the message_id without the whitespace
by stripping them off on the coming mail.
OPW-2006806
Applying CHS solution to avoid crash on empty header.
closesodoo/odoo#35682
Signed-off-by: bve-odoo <Abridbus@users.noreply.github.com>
Use category sequence to order them instead of their order of appearance in
the list of sequence ordered attributes
closesodoo/odoo#35610
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
If there is no product on an invoice line, there is an onchange to ease tax
input that prefills the line with the account default taxes.
Because this is a relational field (a many2many), field = recordset
is as valid as field = recordset.ids, but the semantics is different.
In the second case, the id list is added with 4 commands, not a 6.
So the default taxes are only added, and none are ever removed.
Note that the ORM behaviour changed; this .ids was historical,
but before (v10) it did remove other taxes.
opw 2046112
closesodoo/odoo#35657
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
In other words, when a field F depends on a non-stored field G, it also depends
on G's dependencies. This guarantees that whenever a dependency of G is
modified, F will be invalidated and marked to recompute (if necessary).
The transitive closure of dependencies is not computed over stored fields.
Anyway stored fields already trigger the recomputation of their dependent
fields during their recomputation. The performance impact on the loading of a
registry is negligible (less than 1%), and the increase of recomputation
triggers is small (less than 10%).
(cherry picked from commit 3fbd86bcbe)
opw-2033493
closesodoo/odoo#35636
Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
The local events snippets is an empty HTMLElement which is filled by
JavaScript on page loading. Before this commit, the filled content was
saved in database. This does not create a real problem as the content
is reloaded as soon as the page loads but you can see old events
flickering before the new events are actually loaded.
Now the snippet is cleaned before saving. This also allows to add
default content with a custo so that it is shown during the events
loading (as we are currently doing on odoo.com...).
closesodoo/odoo#35597
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Backport from 12.0, commit : 1b753b0d53
note: there was also report of PDF content blocking that when indexed
blocked an instance worker indefinitely
Since PyPDF2 gives bad results for PDF indexing, stop using it since it
raises more issues than it helps users.
opw-2044679
closesodoo/odoo#35310closesodoo/odoo#35525
Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
If you change the color of a link with the editor without using the link
edition menu, this do not work (which might be expected), but if the
text outside the font had been colorized, the font will be applied
outside of the link only.
This is unexpected since if we have: "hello <a>cruel</a> world!", if we
select only "cruel" and change color, the change only happen to "hello"
and "world!".
With this changeset, an anchor in the ancestor prevent to use an
ancestor font tag to change color (which prevent the issue).
opw-2044551
closes#35862
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Same cause, error, rationale and fix than 0ec0a4a32e
#OneCharacterPatch, reloaded
opw-2056251
closesodoo/odoo#35857
Signed-off-by: Richard Mathot (rim) <rim@openerp.com>
Edit journal entries (account.move).
Create a new line. Credit and debit values are filled in with the default get.
Conveniently, if lines_ids is given in context this computes the right value to
balance existing move lines. However, this is done by float operations.
Let e be the resulting epsilon in balance.
As a result a new line may contain e, 0 for credit, debit (or respectively).
If the user fills in the 0 value with v, then the new line contains e, v.
This violates the constraint that exactly one of the two values should be nonzero.
We get the currency from the journal to round adequately the balance.
opw 2046137
closesodoo/odoo#35815
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Backport of 50ee1c964b.
Previous version was buggy, as it was already patched by 54c2c0874 and 862c2455.
When creating a journal entry manually, the computed value for the next line
was not taking into consideration all existing lines.
Was PR #25298. Courtesy of Pieter Paulussen (Dynapps)
Install the module "Product Comparison". Go to
Website>Configuration>Attribute Categories, then create or edit a category.
No translate button is present when editing the field, there should be one
on the right edge to enter the translation menu.
Adding the missing option in the model.
opw-2052331
closesodoo/odoo#35838
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
The lxml.html.fromstring method does not accept an encoding parameter, so the
preview crash if the going through this branch, i.e. if the root is an empty tag.
opw 2054368
closesodoo/odoo#35817
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Backport of 4da82776ff.
Because of e38ed7c7 the code moved between versions, but is otherwise identical.
- Set an internal location as a return location
- Create a SO with a dropship product, validate and deliver
- Return the product, and choose the internal location as the return
location.
The received quantity on the PO is counted twice.
Since the return is an 'in' move linked to a PO, it is automatically
counted as incoming quantity.
This case is quite specific, so we explicitly add an exception in case
the origin move was a dropship, but the return is not a returned
dropship.
opw-1958228
opw 2045685
closesodoo/odoo#35831
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Open a livechat session between a visitor and a user
That is, open the / controller as public user, and click,
on the bottom right corner, on "Have a question ? Chat with us."
Exchange at least one message to open the session
From the visitor side, close the window. There is a proposal to rate the discussion
Assign either the green face or the yellow one
(The red one is a bit trickier)
Now, on the user side, check the list view of LiveChat sessions
Before this commit, the rating of those sessions were 0
This is because:
The rating.rating < Many2One > mail.channel link is not a foreign key
(rather, it is composed by char::res_model; Integer::res_id)
and doesn't make the reciprocal field recompute, which in turn doesn't make
our relevant field compute
After this commit, the last_rating field field is recomputed and appear in the list view
OPW 2052964
closesodoo/odoo#35830
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
The following rounding is incorrect:
```
>>> float_round(6.6 * 0.175, precision_digits=2)
1.15
```
Indeed, 6.6 * 0.175 = 1.155 ≈ 1.16.
In this specific case, the `epsilon` computed is not sufficient. A
precision of 53 gives:
normalized_value = 115.49999999999997
epsilon = 1.2823075934420547e-14
=> new normalized_value = 115.49999999999999
Bad luck, this is just not enough to tip the value in the right
direction.
However, a precision of 52 is sufficient:
normalized_value = 115.49999999999997
epsilon = 2.5646151868841094e-14
=> new normalized_value = 115.5
The value of 53 was chosen from the `binary64` number format precision.
In case of Python, the corresponding machine epsilon is 2^-52 [1].
Therefore, using 52 instead of 53 does make sense.
It is worth noting that the value of the machine epsilon
2^-52 = 2.2204460492503131e-16, which is still 2 orders of magnitude
below our dynamic estimation.
[1] https://en.wikipedia.org/wiki/Machine_epsilon
[2] `numpy.finfo(float).eps = 2.2204460492503131e-16`
opw-2047368
closesodoo/odoo#35565
Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>
qsm-odoo