Avoid getting the following warning when validating an XRechnung on
https://erechnungsvalidator.service-bw.de/ :
"[BR-DE-21] Das Element "Specification identifier" (BT-24) soll
syntaktisch der Kennung des Standards XRechnung entsprechen."
issue-142127
closesodoo/odoo#142716
X-original-commit: 82d05070d1199a035d93f155580fbef5786dc030
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
cancel their SO
Steps:
Sales user (no purchasing permissions) create SO and confirm it, then
cancel it
Issue:
Sales user cannot cancel their SO without permissions in the purchasing
Analyze:
Because the method `_compute_display_purchase_orders_alert` has a read
the SO's purchase_order_count, it causes an error
Fix:
Add a group on the field to not display it in the view instead. Anyway
if the user doesn't have the right to correct it, he will probably just
ignore the warning and another mechanism should exist to warn the
purchase representative.
closesodoo/odoo#142602
X-original-commit: 77a614d63c64a075db009d8c3acaf19db0fc7cd0
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
When a product has been unbuilt and also (mistakenly) scrapped, it's
impossible to reuse the serial number in production again, even if the
product is unscrapped.
This fixes the sanity check in a similar way to the _check_sn_uniqueness
function, not just checking for removed stock move lines, but also unremoved
stock move lines. A test case is also added to check this scenario.
This is a similar fix to a previous commit we did
(4f07b260807053586ac6c01cf92ac3d5e37b1041) where we bumped into a
problem with the duplicate serial sanity check.
closesodoo/odoo#142574
X-original-commit: 1761b95d9fda5d5355f35effd1f345a25ded1197
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Before this commit, the user got a traceback saying:
```txt
TypeError: Cannot read properties of undefined (reading 'apply')
at EventAdditionalTourSteps._get_website_event_steps
```
the reason of that issue is because a [recent generic change reviews](#125716)
`patch` function and so `this._super` no longer exists and has to be
replace by `super` as we extend a method of a class extended.
This commit adapts the additional steps adding via `patch` function
to be able to add those steps and start the tour as expected.
closesodoo/odoo#142653
Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>
OpenPeppol released a new extension of its BIS 3 format for
international use: PINT BIS Billing. It serves as a base for per-country
specialization, while keeping a standard core for data being used across
countries. This is not meant to be used directly, but rather to be
extended by country-specific modules.
Japan has implementated PINT and published its specific rules:
https://docs.peppol.eu/poac/jp/pint-jp. A new module is created to add
this format.
task-3469718
closesodoo/odoo#136025
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Follow-up of https://github.com/odoo/odoo/pull/134277
This reverts commit 91b80fbb5c as it adds some unwanted visual
effect. In other words, the "block UI" is never unblocked when some
actions are triggered. this is specific to the mobile app when the
URL is outside of the webview scope ("/web" or "/pos"). Even if
the target is self, the mobile app forces a new tab because opening
something else that the backend in the webview could disturb users.
Steps to reproduce:
- Open "Field Service"
- Choose a task and start it
- Stop it and confirm time spent
- Sign report
=> A new tab is openened in the mobile app and the block UI is
never unblock in the app.
To fix this, we simply decided to avoid to use the block UI for
act_url actions. this is consistent with what we did previously:
See https://github.com/odoo/odoo/commit/ebe64aafacec8eaa69a5a1781fc159ff77bc884a
We will only use `BlockUI` when really necessary and not by default.
Note that this commit will also remove the block UI when you do
some operations on apps like installing it. For now, we consider
that is OK. This means that the user will be able to continue his
work during installation. Also note that if the user navigates to
another application during the process, the page will not be refreshed
at the end. He will have to do it himself by pressing "F5" to be able
to see the app in the home menu.
In the future, the idea should be to better notify the user at the end
of this king of background operations but we will see...
closesodoo/odoo#142656
Signed-off-by: Romain Estievenart (res) <res@odoo.com>
Steps to reproduce the bug:
- Create a storable product with two attribute “P1”:
- Color: Red and Blue
- Create a BoM:
- Product template: P1
- BoM lines:
- C1: 1 unit -> apply on variant P1 red
- C2: 1 unit -> apply on variant P1 blue
- Create a MO:
- 1 unit of P1 red
- Only the component C1 is added, which is correct.
- Change the product to P1 blue.
Problem:
The C1 component is not removed because to clear the move_raw_id,
we only check if the BoM is changed. However, in this case, it doesn't
change.
opw-3591800
closesodoo/odoo#142631
X-original-commit: 2a31cdb67338dd065b1aeb2d5e8c57724e8af236
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>
Issue:
======
When choosing product with attributes that have attributes which have
variant creation mode never it will not take into account the extra
price.
Steps to reproduce the issue:
=============================
- Install pos , restaurant
- Create a product which have `Size` attribute and add some values in
it, 'S' and 'M' for example , then add extra prices in each one of
them. Enable available in POS setting in Sales page of the product.
- Got to point of sala , click on 3 dots in restaurant and open mobile
menu.
- Added the created product to cart and click review.
- The price shown is the original price of the product and not taking
into account the extra price of the attribute.
Origin of the issue:
====================
This was not supported before
Solution:
=========
Using the attribute_value_ids value in the line we can calculate the
extra_price of those attributes and add it to the price_unit so we can
get taxed_amount and untaxed_amount correctly.
opw-3511374
closesodoo/odoo#142485
X-original-commit: a54fddd9270b3431a8cde0a6bf30349c5671b0ac
Signed-off-by: David Monnom (moda) <moda@odoo.com>
Signed-off-by: Mahdi Cheikh Rouhou (macr) <macr@odoo.com>
Steps:
- Open Projects
- Go to Tasks
- Create a SOL on the fly
- Create a new product on the fly (click on 'create', not on 'create and edit')
- There is a field for delivered quantity which is editable
Issue:
-The 'delivered quantity' is editable when it shouldn't be. It should only be
editable when Invoice policy is Based on Delivered quantity.
Cause:
- The readonly attribute was only given when delivered_quantity method is not manual.
Fix:
- By making delivered quantity field readonly for project task form view.
Task-3522113
closesodoo/odoo#142348
X-original-commit: 0b5d197e0690e49948b848b2addffeb0e57b5db7
Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>
Co-authored-by: Prakash Prajapati <ppr@odoo.com>
In Odoo, incoming contracts are defined as having state == 'draft' and
kanban_state == 'done'.
Currently, the employee contract calendars are synced when incoming
contracts are created, and incoming contracts' calendars are changed.
However, in many cases the incoming contracts are made for the future
and do not reflect the current employee's working schedule. This causes
there to be a calendar mismatch whenever incoming contracts are
created/updated, despite being set only for the future.
This fix checks the contracts_count field on the employee before
syncing the calendar, since the only time an incoming contract should
reflect the *current* calendar is if it's the only contract for the
employee.
closesodoo/odoo#142142
X-original-commit: 885f554c80028539415c294120c379ded33cd9ae
Signed-off-by: Bertrand Dossogne (bedo) <bedo@odoo.com>
Steps to reproduce:
-------------------
- create several product categories on the ecommerce;
- do not add products to these categories
- go on a category;
- go on an other category;
Issue:
------
The message is the same for both categories:
```
No product defined in category "First Category".
```
Cause:
------
When we go to the first category, the template is cached
according to the existing `t-cache` key containing the products.
In this case, we have no products.
When we go to the second category, which has no products,
the current `t-cache` key doesn't detect changes and therefore
uses the cached template from the first category.
Solution:
---------
Remove the category name because adding `category` to existing
`t-cache` key to detect a difference between categories
that may have the same t-cache key would add
complexity to the key and have a cost in terms of performance.
opw-3572953
closesodoo/odoo#142595
X-original-commit: b1eba0972de2adbfcc0b6fe40252db5a7fcf74f9
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Thomas Lefebvre (thle) <thle@odoo.com>
Node `/cac:Party/cac:PartyTaxScheme/cbc:CompanyID` should be filled with
the VAT rather than the Peppol Endpoint.
Otherwise, a Peppol Bis 3 validator will raise:
"[BR-CO-09]-The Seller VAT identifier (BT-31), the Seller tax
representative VAT identifier (BT-63) and the Buyer VAT identifier
(BT-48) shall have a prefix in accordance with ISO code ISO 3166-1
alpha-2 by which the country of issue may be identified. Nevertheless,
Greece may use the prefix ‘EL’."
opw-3589263
closesodoo/odoo#142487
X-original-commit: f06535e99f4735407c1b9808bb6acd9596726872
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>
Signed-off-by: Julien Van Roy (juvr) <juvr@odoo.com>
Before this commit, if the value of an image/sign field is modified by an
onchange and the record is saved manually, the old image is displayed.
Why:
ImageField's rawCacheKey, which is used to know if the image has been updated,
is not updated. So we will reuse the old image.
Solution:
rawCacheKey becomes a getter that always returns the current value of __last_updated.
How to reproduce:
- Go to a form view with a char field and an image field
- Edit the char field
- An onchange is performed and modifies the value of the image field
- The new image is displayed
- Click on the save button
Before this commit:
The old image is displayed
After this commit:
The new image is displayed
closesodoo/odoo#142471
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Signed-off-by: Francois Georis (fge) <fge@odoo.com>
Using the OdooEditor, the following use case arises often:
- create an Element with document.createElement.
- append that node into the DOM tree of an iframe.
- spawn a popover with that node as target.
The spec (https://developer.mozilla.org/en-US/docs/Web/API/Document/importNode) considers this a malpractice:
`Before they can be inserted into the current document, nodes from external documents should either be:
cloned using document.importNode(); or
adopted using document.adoptNode().
Note: Although Firefox doesn't currently enforce this rule, we encourage you to follow this rule for improved future compatibility.`
Before this commit, in debug mode, there was a crash because the class of the new Element
did not match the class of the element's ownerDocument defaultView.
After this commit, we keep the check that says that the target should be an instance of
the iframe's document's Element class, but we fallback onto the main Window Element class as well.
closesodoo/odoo#142464
X-original-commit: 0cdd8cf9354e494c3e56d9eefe81c3fb6a59ac09
Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>
Steps:
- Open Projects
- Go to Tasks
- Open Activity view
- There is a button to assign a new user
Issue:
- The button to assign a new user should only be visible on hover
Cause:
- There was no css class added for button in activity record.
Fix:
- By making button visibility hidden by default and should be visible only on
hover.
closesodoo/odoo#142381
Task: 3522113
X-original-commit: d60519ae4cb3c9c7d83e8143c3015c28b2a929ad
Signed-off-by: Luca Vitali (luvi) <luvi@odoo.com>
This traceback arises when the user click on return button.
To reproduce this issue:
1) Install 'stock'
2) Activate 'Multi-Step Routes' from 'Inventory/configuration/settings'
3) Create a new product with quantity 100
4) Create a new record in 'Operations/Deliveries'
5) Select the created product in 'operations' with 'Demand' as 10
6) Click on 'Validate' button and then 'Return' button
7) Again click on 'Return' button
Error: 'KeyError: 'reserved_qty''
See: https://github.com/odoo/odoo/blob/c2b160fe50c24e9f01d0d5b350f2422cfdbc72d4/addons/stock/wizard/stock_picking_return.py#L86
Because the 'reserved_qty' field is removed from this pr:- https://github.com/odoo/odoo/pull/137864
sentry-4621794958
closesodoo/odoo#142312
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Issue:
In a multi-language environment, the product description in sales
orders defaults to English, regardless of the user's language
preference. This issue occurs when the language of the partner
is not set, leading to a mismatch between the user's expected language
and the displayed language for product descriptions.
Steps to Reproduce:
1. Ensure the database supports multiple languages.
2. Set the user's preferred language to a non-English language.
3. Create a new sale order for a partner whose language is not set.
4. Add a product and observe that its description is displayed in
English instead of the user's preferred language.
Solution:
Modified the logic to default the product description to the user's
language preference when the partner's language is not specified.
opw-3586451
closesodoo/odoo#142227
X-original-commit: 29ace2569b24cbcf2ae15ca2f25e33fd1f1cd289
Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>
Signed-off-by: Kawtar Drissi El Bouzaidi (kdeb) <kdeb@odoo.com>
Purpose
-------
Allow to reconcile entries during import easily.
* Have one uniform way of doing it
- fix bugs only once
- reduce number of fields
- make it generic and not only for some imports
* avoid the need to post during imports
- faster to import, can import bigger batches, because we do neither
post or reconcile, both are among the most time consuming steps.
- still allows to check the data before posting if needed
* make splitting import into smaller batches easier because the
reconciliation is not cut/dependent on the batches anymore
* allow to reconcile entries in the future by using the same mechanism
(i.e. cut-off)
Implementation
--------------
Allow setting the matching number to `I*` manually, where `*` can be
anything. When posting the last item with the same manually set number,
we will reconcile all the lines with the same number.
task-3593885
closesodoo/odoo#142017
Related: odoo/enterprise#50627
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
How to reproduce:
* create a lot of taxes in batch
The SQL query builder will throw a max recursion depth when building the
`OR(domains)`.
The solution is simply to reduce the size of the batches to avoid that
error.
Part-of: odoo/odoo#142017
Before this commit:
The Patience diff algorithm uses the text added in the `closestBlock` node to
the node where the powerbox is opened. If the user switched to a different block
using `ArrowLeft` or `ArrowRight` keys, it would result in the algorithm not
searching for the typed text in the other block.
After this commit:
The powerbox will be closed if the keyup event occurs in a different block than
the one in which the powerbox was initially opened.
task-3212128
closesodoo/odoo#141785
X-original-commit: 272614a7b668d361d6ea4177602b249608af34bb
Signed-off-by: Antoine Guenet (age) <age@odoo.com>
Before this commit:
Power box uses Patience diff algorithm to check the text added by the user for
search, it previously used the entire editable for differences, which caused
the issue in collaborative. When one user type something on a different node,
the change would affect the editable and be considered in diff, causing updates
in other users powerbox.
After this commit:
Instead of checking the entire editable for the diff, we now check the current
block node where the power box was opened. This prevents scenarios where other
users powerbox would update when one user would type on same block node.
task-3212128
X-original-commit: 976c10b749e59963c8a27ac4764f1746d46d5e09
Part-of: odoo/odoo#141785
Prior to this commit, the alignment of the `priority` field star inside
the header of the `kanban card` was not perfect.
Adding `margin: auto` fixes this issue.
task-3586924
closesodoo/odoo#141506
Signed-off-by: Pierre Paridans (app) <app@odoo.com>
After this commit, detailed operations is no longer a tab in the picking
but under a smart button in the form.
The field `show_operations` on picking type is no longer useful and will
be removed in a later PR targeting master
closesodoo/odoo#140898
Taskid: 3486636
Related: odoo/enterprise#50805
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
pager does not need to be language dependant
steps to reproduce:
- have a lot of products on your e-commerce (more than 7 pages)
- open mobile e-commerce
before this commit:
- pager is wider than the allowed space and width depends on the
language (ex: "Siguiente" is longer than "Next")
after this commit:
- pager is always smaller and is language independent
opw-3522688
closesodoo/odoo#142623
X-original-commit: bd3c2cec314c3710c2294319a8e7605749d7fa83
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Steps to reproduce:
- Install eLearning
- Create or go to an existing course.
- Add Content
- Fill the name and use Save & Close
- Click again in the same content we have just created.
- Click on website preview.
Issue:
Saving a record from a form view that is part of an x2many field would
only reload the fields present in the list view. This led to incomplete
data being loaded into the model.
Solution:
- Pass the `viewType` option to `_fetchRecord` to ensure that the record
is reloaded in the context of the form view, thereby including all
fields.
- Add `viewType` to the `saveOptions` in the `basic_relational_model.js`
to ensure the correct view context is used during the save operation.
This ensures that all fields are reloaded into the model, providing a
complete view of the data.
opw-3330010
closesodoo/odoo#139968
X-original-commit: 3cec34e659222073b0fba36983eaec9f7bf5514f
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Was already signed in pallavisrivastavaa.md
closesodoo/odoo#142426
X-original-commit: d586acc0d08e8fc2f2221c4e8b6ff6fc2577e81b
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
When using a 'Group by' on the Accounting Dashboard, the Kanban cards representing the Journals are placed in columns. However, the columns were too narrow, causing text overflow.
task-3530756
closesodoo/odoo#142371
X-original-commit: 5463a4d34e2d6aea59e96786fe6451a39b319162
Signed-off-by: de Wouters de Bouchout Jean-Benoît (jbw) <jbw@odoo.com>
Signed-off-by: Hugo Poncelet (hupo) <hupo@odoo.com>
Since [1], dropping a form snippet generates a `TypeError: Cannot read
properties of undefined (reading 'disconnect')`.
Note that it only happens if this is the 1st snippet dropped, and if it
is dropped as a section, not as inner content of another snippet.
This is due to the SnippetEditor being destroyed before being started,
as `destroy()` is synchronous but `start()` is async. A field from
`s_website_form` (specifically the field `.s_website_form_dnone`) is
removed through `_addHiddenField()` when dropping a new form. The result
is that it gets destroyed immediately and tries to disconnect an
observer that doesn't exist yet, but the async start() ends a little
later - and creates + connects the observer that will never be
disconnected.
To solve the issue, this commit makes sure (1) in `destroy()` that the
observer was initiated and (2) in `start()` that if the SnippetEditor
was destroyed, it should not create an observer.
[1]: https://github.com/odoo/odoo/commit/f64c9f2
task-3598997
closesodoo/odoo#142291
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
Since commit [1], anchor dialog is now in OWL. During adaptation, a line
of code was forgotten which lead to a traceback when an anchor is saved
with an unchanged name.
Steps to reproduce:
- Drop a Text-Image snippet and set an anchor on it.
- On the anchor notification, click on "Edit"
- In the dialog, do not modify the anchor name (or change it but then
set the original one again)
- Click on "Save & Copy"
=> Traceback
[1]: https://github.com/odoo/odoo/commit/57ed8bc0bf9d1ae2b7542d677a4d7e8fd1899ea2
task-3576975
closesodoo/odoo#141936
Signed-off-by: Soukéina Bojabza (sobo) <sobo@odoo.com>
Before commit [1], anchors would not have a duplicate name as checks
were in place to prevent it from happening. However, after [1], those
checks were no longer valid. They would check in the global variable
document, which was no longer the editable document.
This commit fixes that by using the ownerDocument of the target, which
should always return the correct document.
Steps to reproduce:
- Drop a text snippet.
- Click on create anchor (link icon)
-> notification shows "/#Text".
- Drop another text snippet.
- Click on create anchor (link icon)
-> notification shows "/#Text".
=> It should instead show "/#Text2".
[1]: https://github.com/odoo/odoo/commit/31cc10b91dc7762e23b4bde9b945be0c4ce3fe3b
task-3576975
X-original-commit: fa75fe60b32537d3c564ddba8117207f468c1004
Part-of: odoo/odoo#141936
Similar issue have been fixed for the create in 28a9e90 .
This commits fixes the same issue for the write.
steps to reproduce:
- create a fleet.vehicule with a res.users as driver_id
- change value of plan_to_change_car
before this commit:
access error on res.users
after this commit:
field value is changed
opw-3576960
closesodoo/odoo#142591
X-original-commit: 5f7cca4a22625f1290fc612d8addad8f6312fc5c
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>
Signed-off-by: Nicolas Danhier (nda) <nda@odoo.com>
Some Odoo employees reported a traceback that appeared when saving a
task in the Project app. It turned out that this was caused by an image
having the class 'o_b64_image_to_save' even though the image was not in
Base64 format. Although we couldn't reproduce the bug, we are addressing
the result (the traceback) by preventing the saving of an image having
the 'o_b64_image_to_save' class if the image is not in Base64.
See https://github.com/odoo/odoo/commit/3bbce756c69a206d07abd31059f0392c26b36096
task-3576889
closesodoo/odoo#142571
X-original-commit: 7934aefb7d52ee20941b4583cbf0a50e28c345f6
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Suppose a price_unit of 90.0034 and a fiscal position mapping a 10% price included tax to a 15% tax.
Since the taxes computation was making a rounding, the computed price_unit was round(90.0034 / 1.10).
This commit aims to remove such rounding for the price_unit computation in case of fiscal position.
closesodoo/odoo#142565
Ticket: 3589921
X-original-commit: 11704a57349c04e579096489b346c5fa72c93f73
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Reproduce:
Install l10n_it_edi_withholding
Have an invoice with lines with two taxes:
. 4% INPS
. 0% with exoneration and exoneration kind
Post
Send to Tax Agency
Tax Agency rejects it
The Exoneration Kind tag is related to the VAT tax it is applied to, not
to the Pension Fund tax itself, so we have to modify the template.
A test has been added for the case.
Task link: https://www.odoo.com/web#model=project.task&id=3495670
opw-3495670
closesodoo/odoo#142543
X-original-commit: cbbdd974da4ce55a7b10fba39db4f9278f161808
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Paolo Gatti (pgi) <pgi@odoo.com>
Since [this commit], the color of the links in the backend is set to the
value of the variable `o-cc3-link`. This causes problems... Firstly,
this variable is defined in the website module, but it is used in the
web_editor module, which does not depend of website. Secondly, this
variable declared in website is made to be modified by the website
administrator via the edit panel (the theme tab). This commit corrects
this by replacing the use of this variable with a hardcoded color.
Steps to reproduce the bug fixed by this commit:
- Have website and project installed
- In the description of a project task, create a link
- Edit a website page
- Go to the theme tab
- Click on Colors Preset
- Open the 3rd preset
- Change the color for "Links" (to red for example)
=> Go back to the project task where you put a link. The link is now red
(this may require a page refresh). But the website option should not
change the links in the backend.
This commit removes the website builder related color o-cc-3-link
usage for editor links.
[this commit]: https://github.com/odoo/odoo/commit/5d598e4269431222ae28ac2196ff6f1f45466734
task-3275134
closesodoo/odoo#142542
X-original-commit: 6f10705e043115369ec581a83f65482ea83d25c8
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Guillaume Dieleman (gdi) <gdi@odoo.com>
Before this commit, an internal server error was shown when customers
tried to tokenize Boleto.
opw-3572673
closesodoo/odoo#142514
X-original-commit: fe9f937ce4f9bde327a7ea4f53346e2014908287
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Valentin Chevalier <vcr@odoo.com>
Just like for `assertQueryCount`, we should not take into account
queries that are not run after a warmup, for consistency.
This allows to easily interchange both context managers for debugging
purpose for instance.
closesodoo/odoo#142450
X-original-commit: aaa1d287085c8b2fe20b6591ca9f1b5bbe65d3db
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: William André (wan) <wan@odoo.com>
Sometimes the user needs to import XML invoices (e.g. factur-x)
containing lines with the following problem:
The billed quantity of the line is set to 0 but the total of the line
(plus/minus allowances) is not 0.
The imported version (in odoo) of this line will have quantity 0 and thus a
total of 0 (since the total will be computed in odoo and not stored
directly in the database).
After this commit the quantity of these line will be calculated
such that the total computation yields the correct total.
To do this an already existing similar "exception" in the parsing
logic was extended to deal with this problem.
closesodoo/odoo#137833
Signed-off-by: Laurent Smet (las) <las@odoo.com>
Remove quotes when name of a formatted email is also an email, as indicated
in tests. We still get two emails being sent for a given outgoing email
when the name part is an email but that would be difficult to avoid.
Task-3566542
closesodoo/odoo#141856
X-original-commit: odoo/odoo@d3cdaa6c18
Related: odoo/enterprise#50892
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Add test cases related to an issue found during mail gateway testing. When
an email_to is formatted like '"robert@notgmail.com" <robert@notgmail.com>'
the tool finds two emails. As it is used in IrMailServer it sends two emails
insted of one. This may happen notably when partners are automatically created
based on an email only in which case it is put in both name and email.
Task-3566542
X-original-commit: odoo/odoo@312323e0d9
Part-of: odoo/odoo#141856
When 'getadresses' fails at parsing some input and give us a result like
'gmail.com' (see previous commit adding test cases) we fallback on using
'email_re' which is better at finding email addresses in a global string.
We use it only in this specific case as fallback mechanism to rely on
'getadresses' when possible.
Task-3572208
X-original-commit: odoo/odoo@8e61a3b690
Part-of: odoo/odoo#141856
Add test cases related to issues found in various leads management. All those
email inputs lead to an email found being '@gmail.com' (or equivalent) which
is not a valid email.
A consequence of that behavior is that 'email_normalized' for several leads
is the same ('@gmail.com') and they are considered as being the same email
identity. They could be included in a pack of leads to merge (see 'crm').
Task-3572208
X-original-commit: odoo/odoo@7498b9a0a1
Part-of: odoo/odoo#141856
Be logged in multiple companies (A and B).
Be on a form view of some record which is visible only on company B via ir.rules.
With the company switcher, unlog from company B.
Before this commit, the user received an AccessError and arrived on a blank webclient.
To say the least, it was rather inelegant.
After this commit, the user ends up on the multi-record view of that model, provided that it is available for use.
Task-3029616
closesodoo/odoo#141796
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>
Julien Van Roy