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>
Steps to reproduce:
- Enable show detailed operation in delivery setting on Invetory overview
- Create an SO and validate the delivery order
- Create a return -> Click on the smart button on the SO for transfers
- Click "New" from the list to create a new delivery order
- Add a product on the detailed operation and return to the SO
- The new picking isn't linked to the SO
Bug:
when adding a Product on the operation tab the move is created first
with the correct procurement group and then sets the correct group on the
picking however when adding to the detailed operation (SML) the picking
is created first (no group_id) and sets its group_id(False) the move
Fix:
apply the default group_id to the picking in both cases
opw-3470090
closesodoo/odoo#142424
X-original-commit: 2add5b4020b63a1018ddbf10a55854beffadf532
Related: odoo/enterprise#50871
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
The purpose of this change is to be able to get the price of the
products from external APIs.
closesodoo/odoo#142402
X-original-commit: 420406d392dd3764f08ac698b67440a86abb2ca5
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>
Steps to reproduce:
- Enable multi steps route for manufacturing (in Inventory settings)
- Crete and confirm an MO with a kit and a non kit manufactured components
(eg: table kit and desk combination)
- Validate the created transfer
- Print the delivery slip
Bug:
the manufactured product is absent from the delivery slip
Fix:
apply the correct filter on the move lines
opw-3502881
closesodoo/odoo#142380
X-original-commit: 8c57a4f039549f4bb02a6794eda90de66c74ad28
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>
This commit contains a few small improvements to the Expense app.
- "View Report" button moved to the left if an attachment has been uploaded.
- Reports are auto saved when created from an expense.
- "Attach Receipt" button now sets the uploaded attachment as the main attachment.
- Expense lines in a report are no longer editable. When a line is clicked, the main attachment for that expense (if any) is shown in the attachment previewer.
task-3539382
closesodoo/odoo#138387
Related: odoo/enterprise#50136
Signed-off-by: Habib Ayob (ayh) <ayh@odoo.com>
5921343c2a removed values that didn't
include taxes but section subtotals were forgotten.
task-3562904
closesodoo/odoo#142303
X-original-commit: 3198c74409fa9778d493a0802dc57f7f7062c800
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Joren Van Onder (jov) <jov@odoo.com>
Steps to reproduce:
- In edit mode, drop the "Masonry" snippet.
=> There are spaces on the left and the right of the snippet. It should
not be the case as it is supposed to take the whole space, since its
container width is full (`container-fluid` class).
This happens because since commit [1], the rule setting the `--gutter-x`
CSS variable (which manages the row margins) to 30px when the container
is full width is now overridden by the general `.o_grid_mode` rule that
sets it to 0px, making the negative margins disappear.
Indeed, in commit [1], in order to disable the grid mode when used in a
mega menu that is in an extra menu (because the layout was broken), the
CSS selector managing the `.o_grid_mode` class has been modified. This
change caused the specificity of the rule to increase (x3), which made
it override the container rule.
This commit reverts this change and disables the grid mode in the extra
menu in a better way, by adding a proper rule for this specific case.
[1]: https://github.com/odoo/odoo/commit/709bffcb6de8883b679c0fc942f45cb293621c30
task-3593697
closesodoo/odoo#142189
X-original-commit: 8381af7d9898d7502c82a6b5622b0e91734267d8
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>
The "reset password" feature does not take into account
multi-website.
steps to reproduce:
- create a website A
- uncheck 'Shared Customer Accounts' on website A
- create a portal user user@example.com on website A
- create a website B
- uncheck 'Shared Customer Accounts' on website B
- create a portal user user@example.com on website B
- reset password for user@example.com on any website
before this commit:
An error is raised "No account found for this login"
(which is false, actually 2 accounts are found)
after this commit:
Only the user linked to the current website is properly
selected
opw-3551540
closesodoo/odoo#142110
X-original-commit: a2196253d6cf90dca3042a777703e0679f74f542
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
In commit [1], the media dialog has been improved in order to have a
better UX when using it. However, its code is quite complex and could be
simplified.
This commit modifies again the UX of the media dialog to only consider
the addition of the "scroll button" and leaves the "Load more" button
after the attachments without making it fixed. The scroll button still
disappears once the load more button appears in the modal.
This commit also addresses the remaining review comments that were not
resolved, as it was merged in a rush.
[1]: https://github.com/odoo/odoo/commit/d1c7e371491b06176c2f5a432dccdc87b7002296
task-3580707
closesodoo/odoo#141356
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Since 81fe11fabb, the field
`expense_sheet_id` was converted from a One2many to a Many2one,
making it a stored field.
Since then opening the form view of an expense report can be quite
slow (around +-1.6s) in a database with a lot of `account.move`, as
the whole table needs to be scanned to match the `id` of the
`expense_sheet_id`.
We add a partial not null index on the field (since not a lot of
`account.move` are linked to an expense) and it speeds up the read
to 60ms.
Reference:
task-3572440
closesodoo/odoo#142260
X-original-commit: edefee03110c63b152148b7599aed250dc9978df
Signed-off-by: William André (wan) <wan@odoo.com>
Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>
Current behavior:
When you sell a kit made of kit, the COGS are not registered correctly
in the invoice.
Steps to reproduce:
- Create Kit A with product A
- Create Kit B with product B
- Create Kit Final with kit A and kit B
- Make sure the Category of the products is in FIFO automated
- Open PoS, and sell Kit Final and invoice it.
- Go in the backend, and check the invoice lines of the order.
- The COGS of the products are not registered correctly.
Note:
This was happening because the price unit of the kit was not calculated
correctly. Because when the product was a kit made of kit, the bom was
not exploded to consider all the components of the kit.
opw-3548604
closesodoo/odoo#142246
X-original-commit: b8b3945ee0e4a82e18f85d8bbeb1a32654088308
Signed-off-by: Vlad Stroia (vlst) <vlst@odoo.com>
Signed-off-by: Robin Engels (roen) <roen@odoo.com>
Lucas Perais