If an event track had a speaker assigned who had an email, and the
email field in the track itself was empty, Odoo was suggesting the
user to send an email to an empty recipient, making an error
Now it only suggests the email if there's one.
Fixesodoo/odoo#35941
Signed-off-by: Martin Trigaux (mat) <mat@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>
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>
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 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>
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>
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>
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>
Steps to reproduce the bug:
- Install stock_dropshipping module and enable Routes on SO lines
- Create a storable product P with a supplier S
- Create a SO with P and set this line with the route dropship
- Confirm the SO ( a PO has been created to S with P)
- Change P on the SO with an other product
Bug:
The product P stayed on the PO.
So a product linked to a PO line cannot be changed on a SO.
Do not forward-port in 12.0 and upper
opw:2040249
closesodoo/odoo#35454
Signed-off-by: Simon Goffin (sig) <sig@openerp.com>
Make a transfer payment from bank to cash
validate, check the journal entries
You see that there are two moves, each with the name
given by their journal's sequence (one in bank, one in cash)
Now, unreconcile, and cancel the payment
set it to draft, re-confirm it
Before this commit, the entries created had the same name which was
the name of the previous journal entry
This was because, at cancel time, the move_name of the payment was not reset
After this commit, the move name is reset on cancel, and both
journal entries have a new sequence based name when
confirming the payment the second time
OPW 2046412
closesodoo/odoo#35478
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Before this commit, the field intrastat_country_id was not propagated when refunding an invoice
After this commit, the refund invoice takes the same values for that field
as the invoice it is refunding
OPW 2028333
closesodoo/odoo#35309
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
In the planner the url are generated by prepare_backend_url that takes
an action's xml id as argument. The id passed should have the format
'module_name_where_the_action_is.action_name'. In this case the id passed
was product.product_template_action_product but the action is defined in
stock thus the prepare_backend_url was not able to find the associate action
and return a wrong(default) url.
This commit change the action id passed with the correct module.
closesodoo/odoo#18812
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>
https://docs.python.org/3/library/stdtypes.html#truth
By default, an object is considered true unless
its class defines either a __bool__() method that returns False
or a __len__() method that returns zero
Since etree elements are iterator, they define a len function.
However it turns out that customerProfileId has always no children.
So bool(find(x)) is always False; the intended meaning was find(x) is None.
opw 1999427
closesodoo/odoo#34922
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
closesodoo/odoo#35246
Signed-off-by: Nans Lefebvre (len) <len@odoo.com>
Before this commit, for the following view tree:
P (active)
|
I (inactive)
|
II (active)
When calling `customize_template_get()` on 'P', it would wrongly return 'II'.
It shouldn't, since its parent 'I' is inactive.
Step to reproduce:
- Go to /shop
- Enable ecommerce categories
- Enable Collapsible Cateogories
- Disable ecommerce categories
- Collapsible categories is still shown even if its parent got archived
Test writen in 12.0 with #35154closesodoo/odoo#35155
Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>
Since 5c9cea4ee7, it was not possible to remove an applied promo code
pricelist by adding an empty promo code on checkout (eg removing the one shown
in the promo code input).
Indeed, when sending an empty promo code, the `search()` done in the controller
would not find any pricelist as promo would be en empty string. For the rest,
check code on mentionned commit.
See `sale_get_order()` method docstring about `code` param: "If empty, it's a
special case to reset the pricelist with the first available else the default.".
Fixes#34633
On mobile devices, by default Odoo will uses a kanban view instead of a
list view if avaiable.
In the case of "Point of Sale > Reporting > Sale Details", we can select
the list of point of sale configs. It works fine on desktop, but on
mobile we had the kanban view that does not allow to remove selected
configs (and there is "New Session", "Resume" and so on buttons that
make little to no sense).
With this changeset we force in the case usage of the list view.
opw-2040954
closes#35104
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Jairo Llopis