Tuesday, January 21, 2025
51 changes · saas-18.1
Resolved issues and error corrections
This fixes an internal test setup issue in the point-of-sale self-ordering flow. The test now uses table data that is always available, helping prevent false failures when demo data is not installed.
Original PR description
Before the test `test_preset_eat_in_tour` was using the table 103 which is created in demo data. This table is not created in the test data so the test was failing when trying with no demo. Now the test use the table 1 which is created in the test data. Runbot error: 112371
This fixes an access problem that could prevent Ecuadorian sales orders from loading their default payment method correctly. It helps keep automated checks and normal setup flows from failing unexpectedly for users with limited permissions.
Original PR description
This commit fixes an AccessError on a failing test in runbot, by granting a `sudo` on the default record search for EC Payment Method field. runbot: [102689](https://runbot.odoo.com/odoo/action-573/102689)
Leaving a live chat from Discuss now avoids sending the same leave request more than once. This reduces unnecessary background actions and helps keep chat membership updates cleaner and more reliable for users.
This update adjusts internal performance test expectations after related accounting changes increased the number of database queries during menu loading. It helps keep automated validation aligned with the current system behavior without changing user-facing features.
Original PR description
Following the changes in the related enterprise PR, query counters must be adapted. Some overrides in accounting modules causes the query counter to go up. Runbot Error: 109492
A minor issue in automated accounting menu checks was fixed so results stay consistent whether the reporting app is installed or not. This helps keep the release validation pipeline reliable and avoids false failures during testing.
Original PR description
This commit fixes the second query count in `test_visible_menu_ids` where it is sometimes 1 if `account_reports` is not installed (the xmlid is never cached since it does not exist yet) Runbot Error 109492
Miscellaneous changes
Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific message, i.e. a string, not an Error instance). As a consequence, those errors are no longer swallowed as they're expected to be, and are thus wrongly identified as CORS errors. Those errors are shown to the user in debug mode. This happens for instance in the ir.ui.view form view, which contains
Original PR description
Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific…
Since chrome 132, the shape of error events for the `ResizeObserver loop completed with undelivered notifications.` error changed: the `error` key is now set in the event (its value is this specific message, i.e. a string, not an Error instance). As a consequence, those errors are no longer swallowed as they're expected to be, and are thus wrongly identified as CORS errors. Those errors are shown to the user in debug mode. This happens for instance in the ir.ui.view form view, which contains an AceEditor field. His CodeEditor component listens on the `resize` event to redrawn itself, which causes this error. This also happens with the website builder, which does not involve the CodeEditor. It probably happens at other places as well. We thus need a global solution, like we had before. This commit thus fixes the condition in the error service to keep swallowing that error. opw-4500350 opw-4496862 opw-4496782 opw-4495448 opw-4493209 opw-4495309 opw-4472997 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194483
Product variant with creation type "always" would not be printer on the preparation receipt. Steps to reproduce: ------------------- * Create a product and add a variant with creation type "always" * Add a preparation printer to the point of sale * Create a new order and add the product with the variant * Validate the order and check the preparation receipt > Observation: the product variant is not printed on the receipt Why the fix: ------------ The product variant was not printed
Original PR description
Product variant with creation type "always" would not be printer on the preparation receipt. Steps to reproduce: ------------------- * Create a product and add a variant with creation type "always" * Add a preparation printer to the point of sale * Create a new order and add the product with the variant * Validate the order and check the preparation receipt > Observation: the product variant is not printed on the receipt Why the fix: ------------ The product variant was not printed on the preparation receipt because the variant is added to the display name of the product and doesn't appear in the attribute list. This fix also add the first test for the preparation receipt. This should be improved in the future to cover more cases. opw-4450217 Forward-Port-Of: odoo/odoo#193776
In the onboarding wizard, we create a cash journal for different scenarios. However the names of these journals were not translatable. We make them translatable in this commit. Forward-Port-Of: odoo/odoo#194428 Forward-Port-Of: odoo/odoo#194337
Original PR description
In the onboarding wizard, we create a cash journal for different scenarios. However the names of these journals were not translatable. We make them translatable in this commit. Forward-Port-Of: odoo/odoo#194428 Forward-Port-Of: odoo/odoo#194337
# Description The 'See Records' icon was missing when attempting to open `AccountMoveLines` records from the context menu in the spreadsheet. Task: 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194464
Original PR description
# Description The 'See Records' icon was missing when attempting to open `AccountMoveLines` records from the context menu in the spreadsheet. Task: 0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194464
Before this commit: Once receveiving Mercado Pago callback, a JS traceback would occur: ```js TypeError: Cannot read properties of undefined (reading 'payment_method') at Proxy.get_payment ``` opw-4349957 Forward-Port-Of: odoo/odoo#194112
Original PR description
Before this commit: Once receveiving Mercado Pago callback, a JS traceback would occur: ```js TypeError: Cannot read properties of undefined (reading 'payment_method') at Proxy.get_payment ``` opw-4349957 Forward-Port-Of: odoo/odoo#194112
OIOUBL (which is not a Peppol format) uses the fields from peppol. So it should be visible to be edited too. Even more, we will make it always visible, as the Peppol may be proposed more, and so, the fields should be more easily modifiable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194513
Original PR description
OIOUBL (which is not a Peppol format) uses the fields from peppol. So it should be visible to be edited too. Even more, we will make it always visible, as the Peppol may be proposed more, and so, the fields should be more easily modifiable. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194513
Before this commit PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be useful to cases where "there is a receipt for the order XXX-YYY-ZZZ, but it does not appear in the backend!" After this commit: To ease the investigation of such cases, logs are added with various information to better understand customer flows and tracability when a PoS order is synced. The main
Original PR description
Before this commit PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be…
Before this commit
PoS orders synchronisation can sometime happen in parallel. When it is the case, we can end up with situation of duplicated PoS orders stored in the backend. This can also be useful to cases where "there is a receipt for the order XXX-YYY-ZZZ, but it does not appear in the backend!"
After this commit:
To ease the investigation of such cases, logs are added with various information to better understand customer flows and tracability when a PoS order is synced.
The main idea was added to the "PoS order" capture PR: https://github.com/odoo/odoo/pull/174562
But this one is waiting for other PR to be deployed due to the heavy PoS refactoring in 17.4. In the mean time, the logs part can be easily pushed in 17.4
Logs example:
New PoS order logs:
```
2024-12-16 16:55:32,254 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 started for PoS orders references: [{'name': 'Order 00007-003-0001', 'uuid': '838043cb-8324-4b52-a45e-c8707f8975ff'}]
2024-12-16 16:55:32,413 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 order {'name': 'Order 00007-003-0001', 'uuid': '838043cb-8324-4b52-a45e-c8707f8975ff'} created pos.order #38
2024-12-16 16:55:32,414 49677 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #89627943 finished
2024-12-16 16:55:32,434 49677 INFO oes_17.4_pos werkzeug: 127.0.0.1 - - [16/Dec/2024 16:55:32] "POST /web/dataset/call_kw/pos.order/sync_from_ui HTTP/1.1" 200 - 90 0.070 0.114
```
Updated PoS restaurant order:
```
2024-12-16 16:36:27,190 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 started for PoS orders references: [{'name': 'Restaurant/00004', 'uuid': '9653201c-1c04-4679-99b8-61d2ae91fc87'}]
2024-12-16 16:36:27,331 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 order {'name': 'Restaurant/00004', 'uuid': '9653201c-1c04-4679-99b8-61d2ae91fc87'} updated pos.order #12
2024-12-16 16:36:27,331 43869 INFO oes_17.4_pos odoo.addons.point_of_sale.models.pos_order: PoS synchronisation #99444056 finished
2024-12-16 16:36:27,348 43869 INFO oes_17.4_pos werkzeug: 127.0.0.1 - - [16/Dec/2024 16:36:27] "POST /web/dataset/call_kw/pos.order/sync_from_ui HTTP/1.1" 200 - 101 0.059 0.425
```
opw-3650239
Forward-Port-Of: odoo/odoo#191046
Forward-Port-Of: odoo/odoo#190734Forward-Port-Of: odoo/odoo#194034 Forward-Port-Of: odoo/odoo#193775
Original PR description
Forward-Port-Of: odoo/odoo#194034 Forward-Port-Of: odoo/odoo#193775
Before this commit, selecting an order from the order list and attempting to load it would result in an error. opw-4251717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193441 Forward-Port-Of: odoo/odoo#184754
Original PR description
Before this commit, selecting an order from the order list and attempting to load it would result in an error. opw-4251717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193441 Forward-Port-Of: odoo/odoo#184754
Steps to reproduce: --- Go in the Time Off app Click on an allocation or a leave Click on the action gear Issue: --- The gear action shows 2 times the "Multiple Requests", this comes from the fact that the wizard is in the xml and defined in the action_generate_allocations. So it is displayed twice in the form. Fix: --- Since the issue is only appearing in the form view, added the condition on viewType. --- I confirm I have signed the CLA and read the PR guidelines at www.od
Original PR description
Steps to reproduce: --- Go in the Time Off app Click on an allocation or a leave Click on the action gear Issue: --- The gear action shows 2 times the "Multiple Requests", this comes from the fact that the wizard is in the xml and defined in the action_generate_allocations. So it is displayed twice in the form. Fix: --- Since the issue is only appearing in the form view, added the condition on viewType. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188182
Fixes an issue on the partner view where a compute would try to read the proxy user, while not all users who can read the partner would have read access to the proxy user. Also fix a similar case in the action used to validate the ID, which tries to read the proxy user. error-105104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194459
Original PR description
Fixes an issue on the partner view where a compute would try to read the proxy user, while not all users who can read the partner would have read access to the proxy user. Also fix a similar case in the action used to validate the ID, which tries to read the proxy user. error-105104 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194459
The placeholder was empty in some places, leading to an annoying behavior because it isn't even possible anymore to open the related journal entry. The fix is done directly in the widget `open_move_widget` to avoid modifying the definition of the related field and having to change it into a computed field. Also, it wouldn't make sense to store the placeholder on the journal item but not on the journal entry. Forward-Port-Of: odoo/odoo#194433
Original PR description
The placeholder was empty in some places, leading to an annoying behavior because it isn't even possible anymore to open the related journal entry. The fix is done directly in the widget `open_move_widget` to avoid modifying the definition of the related field and having to change it into a computed field. Also, it wouldn't make sense to store the placeholder on the journal item but not on the journal entry. Forward-Port-Of: odoo/odoo#194433
**Current behavior:** The rounding applied during the cost split of a landed cost's cost computation can yield undesirable/unexpected results. **Expected behavior:** Sensible rounding. **Steps to reproduce:** 1. Create some product with arbitrary cost, with avg and real_time costing and valuation, respectively 2. Create a purchase order with 6 lines, all for that product 3. Confirm order & receive products, create bill and add a landed cost line with cost=6.85 4. Post bill a
Original PR description
**Current behavior:** The rounding applied during the cost split of a landed cost's cost computation can yield undesirable/unexpected results. **Expected behavior:** Sensible rounding. **Steps to…
**Current behavior:**
The rounding applied during the cost split of a landed cost's
cost computation can yield undesirable/unexpected results.
**Expected behavior:**
Sensible rounding.
**Steps to reproduce:**
1. Create some product with arbitrary cost, with avg and
real_time costing and valuation, respectively
2. Create a purchase order with 6 lines, all for that product
3. Confirm order & receive products, create bill and add a
landed cost line with cost=6.85
4. Post bill and create the landed cost:
* link to the receipt
* set split method to `equal`
5. Validate the LC, see that the val adjustment lines are
rounded unexpectedly- *specifically all the lines are rounded up
(beyond the per-adjustment-line value) which means the final
adjustment line cost-split share will reflect the cumulative
rounding loss of every adjustment line rounded prior*
E.g.,
<pre>
[ 1.15, 1.15, 1.15, 1.15, 1.15, 1.11 ]
^
</pre>
**Cause of the issue:**
We currently use `rounding_method='UP'`.
**Fix:**
Round HALF-UP. This will minimize the difference between the
true, unrounded split-value and the post-rounding value.
Semi-related fix: try to use consistent `ResCurrency.round()`
methods between `compute_landed_cost()` and `_check_sum()`.
opw-4200916
Forward-Port-Of: odoo/odoo#193861
Forward-Port-Of: odoo/odoo#190449This PR changes the behavior of the /file powerbox command in the following aspects: - it no longer opens the media dialog, and skips it directly to the system's file selector - the resulting download box has gone through visual changes, mainly: - it no longer takes the whole width of the screen, and multiple file boxes can be placed on the same line - it has blue color an the looks of a bootstrap alert-info banner - the same command is also available as a powerbutton. This PR also a
Original PR description
This PR changes the behavior of the /file powerbox command in the following aspects: - it no longer opens the media dialog, and skips it directly to the system's file selector - the resulting download box has gone through visual changes, mainly: - it no longer takes the whole width of the screen, and multiple file boxes can be placed on the same line - it has blue color an the looks of a bootstrap alert-info banner - the same command is also available as a powerbutton. This PR also allows the user to upload a file (also skipping the media dialog) from the link popover, thus creating a link to the created attachment. https://github.com/odoo/enterprise/pull/75045 task-3522395 Forward-Port-Of: odoo/odoo#189203
Re-exported because: - To take into account PRs that were merged after the freeze - A couple pot files were missing/empty (i.e. empty = deleted) - Just in case there was anything out of date Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
Re-exported because: - To take into account PRs that were merged after the freeze - A couple pot files were missing/empty (i.e. empty = deleted) - Just in case there was anything out of date Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally. This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them. Forward-Port-Of: odoo/odoo#194393
Original PR description
It's not *entirely* clear which and when, but some tours apparently trigger downloads, which by default will make a mess of the user's Downloads folder when running tests locally. This has mostly been observed in 18.0 / master with Studio exports but there are a few others as well (e.g. a few reports). Either way, seems like a good idea to just configure chrome to block them. Forward-Port-Of: odoo/odoo#194393
When using an auto fifo product as part of the repair, the COGS won't be based on the used product To reproduce the issue: 1. Setup auto fifo product 2. Receive 1@10 and 1@20 3. Process a RO: - Invoice method: After repair - Parts: - Add 1 x fifo product 4. Create and post the invoice 5. Open its journal items Error: Cogs are $20 instead of $10 When posting the invoice, we generate the COGS: https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/
Original PR description
When using an auto fifo product as part of the repair, the COGS won't be based on the used product To reproduce the issue: 1. Setup auto fifo product 2. Receive 1@10 and 1@20 3. Process a RO: -…
When using an auto fifo product as part of the repair, the COGS
won't be based on the used product
To reproduce the issue:
1. Setup auto fifo product
2. Receive 1@10 and 1@20
3. Process a RO:
- Invoice method: After repair
- Parts:
- Add 1 x fifo product
4. Create and post the invoice
5. Open its journal items
Error: Cogs are $20 instead of $10
When posting the invoice, we generate the COGS:
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L47-L48
We therefore compute the "anglo saxon unit price":
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L133
However, there isn't any override to handle the RO case, so it leads
to the default mechanism, i.e. the standard price of the product:
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L294-L295
https://github.com/odoo/odoo/blob/4df156164cf1d2764ba23682beee588777457fd6/addons/stock_account/models/account_move.py#L294-L295
https://github.com/odoo/odoo/blob/7cd7563f6708331bb6baf0e06d07a9f9ee329e38/addons/stock_account/models/product.py#L753-L757
And, since the first product is out, its standard price is now based
on the next candidate: $20
About the `sudo`: an accountman has not any access to `repair`, so
posting such an invoice would raise an error. Since this diff is
specific to Odoo 16, the idea is not to impact any security rules
and rather minimize the changes.
Note: Indeed, `repair` does not depend on `stock_account`, so this
commit could lead to a traceback if the bridge is removed. I delegate
this issue to the error of dependencies. Anyway, removing the bridge
would lead to other bugs. Hopefully, this has been fixed on master [1].
[1] https://github.com/odoo/odoo/commit/f7dbdec11b74f8c7d969763d8c5cf09542a47f86
OPW-4166570
Forward-Port-Of: odoo/odoo#193826
Forward-Port-Of: odoo/odoo#193076**Before this PR:** Steps to reproduce: - In an empty paragraph write something, press shift + enter - Write something in new line break - Select whole text in second line - Paste any text, notice that an extra <br> is added above pasted text. In other words, `<p>abc<br>[def]</p> + insert('x')` becomes `<p>abc<br><br>x[]</p>` instead of `<p>abc<br>x[]</p> `. **Desired behaviour after PR:** Now, pasting something at line-break doesn't add an extra an extra `<br>` . task-4231
Original PR description
**Before this PR:**
Steps to reproduce:
- In an empty paragraph write something, press shift + enter
- Write something in new line break
- Select whole text in second line
- Paste any text, notice that an extra <br> is added above pasted text.
In other words,
`<p>abc<br>[def]</p> + insert('x')` becomes `<p>abc<br><br>x[]</p>` instead of `<p>abc<br>x[]</p> `.
**Desired behaviour after PR:**
Now, pasting something at line-break doesn't add an extra an extra `<br>` .
task-4231290
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#185854Chart.js can be really slow when rendering a large number of datasets. So this commit limits the amount of datasets displayed by default on the graph. However a button is present to display all datasets even if it can take a moment to render them. task-4351783 Forward-Port-Of: odoo/odoo#194170 Forward-Port-Of: odoo/odoo#192892
Original PR description
Chart.js can be really slow when rendering a large number of datasets. So this commit limits the amount of datasets displayed by default on the graph. However a button is present to display all datasets even if it can take a moment to render them. task-4351783 Forward-Port-Of: odoo/odoo#194170 Forward-Port-Of: odoo/odoo#192892
Portal chatter now uses discuss, thus it relies on translation of Discuss in `mail` module. Frontend translations need to be available, they aren't by default unless the module is prefixed by `website`. This isn't the case for `mail`, and the module `website_mail` does not share the translations. This commit fixes the issue by enabling `mail` in the translations of available translations in the frontend Task-4423556 Forward-Port-Of: odoo/odoo#191534
Original PR description
Portal chatter now uses discuss, thus it relies on translation of Discuss in `mail` module. Frontend translations need to be available, they aren't by default unless the module is prefixed by `website`. This isn't the case for `mail`, and the module `website_mail` does not share the translations. This commit fixes the issue by enabling `mail` in the translations of available translations in the frontend Task-4423556 Forward-Port-Of: odoo/odoo#191534
Before this commit, when accessing a shared chatter from a portal user that has edit access, chatter messages could not be loaded when a partner added at least one emoji reaction on a message. Steps to reproduce: - Share a project with Joel Willis with edit access - Create a task with Joel Willis on this project - Post a message as Joel Willis on the new task - Let Mitchell Admin add a reaction on the new message => Joel Willis cannot load messages: ``` An error occurred while fetc
Original PR description
Before this commit, when accessing a shared chatter from a portal user that has edit access, chatter messages could not be loaded when a partner added at least one emoji reaction on a message. Steps…
Before this commit, when accessing a shared chatter from a portal user that has edit access, chatter messages could not be loaded when a partner added at least one emoji reaction on a message. Steps to reproduce: - Share a project with Joel Willis with edit access - Create a task with Joel Willis on this project - Post a message as Joel Willis on the new task - Let Mitchell Admin add a reaction on the new message => Joel Willis cannot load messages: ``` An error occurred while fetching messages. ``` This happens because the custom mail message formatter of portal chatter messages was crafting the reaction data of the messages to return. When providing people that have reacted to the message, Access to reacted partners was denied due to ACL. This commit fixes the issue by sudo() the partners of message reaction to retrieve their data to the portal user. This is ok because the portal has access to the message, therefore access to the reaction and related data are fine. Note that data of partner that have reacted is very limited: only the name is returned. opw-4454427 Forward-Port-Of: odoo/odoo#193296
When creating a new working schedule, the duration (days) was not computed correctly. This was due to a missing field in the depends of the compute method. This commits fixes the issue by adding the hours per day in the depens of the duration days compute method. That way, the duration days will be computed after that the hours per day are computed. task-4457200 Forward-Port-Of: odoo/odoo#193715
Original PR description
When creating a new working schedule, the duration (days) was not computed correctly. This was due to a missing field in the depends of the compute method. This commits fixes the issue by adding the hours per day in the depens of the duration days compute method. That way, the duration days will be computed after that the hours per day are computed. task-4457200 Forward-Port-Of: odoo/odoo#193715
Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user ca
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a user with only access to "Sales User: Own Documents Only"; 2. open a product variant page; 3. add a comment in the chatter. Issue ----- Access Error Cause ----- Commit 35a07975deb0 added `_mail_post_access = 'read'` to the `product.template` model. This allows users with read-only access to still comment on `product.template` records. This was not done for product variants, leading to an inconsistency where an internal user can comment on product templates, but not variants. Solution -------- Add `_mail_post_access = 'read'` to `product.product` as well. opw-4189326 Forward-Port-Of: odoo/odoo#194048 Forward-Port-Of: odoo/odoo#194005
Steps to reproduce: - Open the "Menu Editor" dialog. - Add a "Mega Menu Item". - Save the "Menu Editor" dialog. - Enter "Edit Mode". - Open the "Mega Menu". - Select "Images Subtitles" as the "Mega Menu" template option. - Click on the largest image on the right side of the "Mega Menu". - Click the "Create Link" button in the image options. - Leave the input URL empty for this new link. - Save the page. - A link without an "href" attribute is now present in the "Mega Menu". - Edit
Original PR description
Steps to reproduce: - Open the "Menu Editor" dialog. - Add a "Mega Menu Item". - Save the "Menu Editor" dialog. - Enter "Edit Mode". - Open the "Mega Menu". - Select "Images Subtitles" as the "Mega…
Steps to reproduce: - Open the "Menu Editor" dialog. - Add a "Mega Menu Item". - Save the "Menu Editor" dialog. - Enter "Edit Mode". - Open the "Mega Menu". - Select "Images Subtitles" as the "Mega Menu" template option. - Click on the largest image on the right side of the "Mega Menu". - Click the "Create Link" button in the image options. - Leave the input URL empty for this new link. - Save the page. - A link without an "href" attribute is now present in the "Mega Menu". - Edit the browser URL to redirect to a page that is not present in the menu; for example, add "/test" to the current URL. It does not matter whether the page exists or not. - Bug: A traceback occurs. The bug occurred because the function "_updateActiveMenuLinks" (introduced by this commit [1]) called "new URL" on an empty string, as it attempted to process a link without an href attribute. [1]: https://github.com/odoo/odoo/commit/5be12800a59e912997fff39cec57ab70914f2485 opw-4480958 Forward-Port-Of: odoo/odoo#194089
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR resolves the issue by ensuring the responsible user is s
Original PR description
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR resolves the issue by ensuring the responsible user is set to empty when validation is `hr` or `Both` and no Time Off Officer is configured. task-4351688 Forward-Port-Of: odoo/odoo#194278 Forward-Port-Of: odoo/odoo#190193
**Issue:** when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice. **Steps To Reproduce:** On POS, for an order totaling $120. - Add a customer and ensure the "Invoice" box is checked. - pay using two payments methods bank 100$ Cash 50$ - the change is $30, everything looks fine on the ticket on the pos. - Notice on the invoice on the db backend the $30 change is inco
Original PR description
**Issue:**
when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice.
**Steps To Reproduce:**
On POS, for an order totaling $120.
- Add a customer and ensure the "Invoice" box is checked.
- pay using two payments methods bank 100$ Cash 50$
- the change is $30, everything looks fine on the ticket on the pos.
- Notice on the invoice on the db backend the $30 change is incorrectly deducted from the bank payment. As a result, the invoice displays: bank : $70 cash: $50
**Soltution:**
- In the `_create_payment_moves` method, ensure that cash payment method creates an `account.move` including the change amount.
opw-4076246
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194299
Forward-Port-Of: odoo/odoo#187727When an error occurs on IAP side for Peppol we display the content of `message` while we have a more friendly-user text stored in `display_message`. Use the latter when logging in Odoo. See: https://github.com/odoo/iap-apps/blob/5dde71627dfd6c6168935346bece0018d4701ce3/iap_services/peppol_proxy/exceptions.py#L14 task-no Forward-Port-Of: odoo/odoo#194352
Original PR description
When an error occurs on IAP side for Peppol we display the content of `message` while we have a more friendly-user text stored in `display_message`. Use the latter when logging in Odoo. See: https://github.com/odoo/iap-apps/blob/5dde71627dfd6c6168935346bece0018d4701ce3/iap_services/peppol_proxy/exceptions.py#L14 task-no Forward-Port-Of: odoo/odoo#194352
When receiving an ubl file by mail, we need to ensure that the company from where we retrieve the product is the same as the invoice company, otherwise we end up with an UserError ("Incompatible companies on records"). Steps: - Have 2 company (X being id == 1 and Y being id == 2) - Create a product "Locations et leasing opérationnel" with X setas company_id - Create an alias on company Y vendor bills journals - Sent the `bis3_bill_example.xml` located in `addons/account_edi_ubl_cii/tests/tes
Original PR description
When receiving an ubl file by mail, we need to ensure
that the company from where we retrieve the product is the same as
the invoice company, otherwise we end up with an UserError ("Incompatible companies on records").
Steps:
- Have 2 company (X being id == 1 and Y being id == 2)
- Create a product "Locations et leasing opérationnel" with X setas
company_id
- Create an alias on company Y vendor bills journals
- Sent the `bis3_bill_example.xml` located in `addons/account_edi_ubl_cii/tests/test_files/`
to the email alias
- Open the created bill
-> Error in the chatter: "Error importing attachment ... as invoice
(decoder=_import_invoice_ubl_cii)
opw-4444747
Forward-Port-Of: odoo/odoo#194019
Forward-Port-Of: odoo/odoo#193786The invoice edi format should be take from the parent of the partner instead of the partner himself. Steps: - Create an individual partner X and set an edi format - Create a company partner Y and set a different edi format - Make X child of Y - Create an invoice for X, confirm and click on 'Send and print' button -> The edi file is in the format set on X instead of the format set on Y opw-4480527 Forward-Port-Of: odoo/odoo#193981
Original PR description
The invoice edi format should be take from the parent of the partner instead of the partner himself. Steps: - Create an individual partner X and set an edi format - Create a company partner Y and set a different edi format - Make X child of Y - Create an invoice for X, confirm and click on 'Send and print' button -> The edi file is in the format set on X instead of the format set on Y opw-4480527 Forward-Port-Of: odoo/odoo#193981
Before this commit, 'trigger_field_ids' were already computed from the filter_domain, but using a default_filter_domain didn't work due to the '_onchange_trigger' method emptying 'trigger_field_ids' in the case of on_create_or_write. After this commit, we made '_onchange_trigger' take into account the filter_domain for this case. This addition fixes a window action from Documents to Automation Rules. see odoo/odoo#193206 see odoo/enterprise#75719 task-4481308 --- I confirm I hav
Original PR description
Before this commit, 'trigger_field_ids' were already computed from the filter_domain, but using a default_filter_domain didn't work due to the '_onchange_trigger' method emptying 'trigger_field_ids' in the case of on_create_or_write. After this commit, we made '_onchange_trigger' take into account the filter_domain for this case. This addition fixes a window action from Documents to Automation Rules. see odoo/odoo#193206 see odoo/enterprise#75719 task-4481308 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193576
The docstring of `@route` states that it accepts any iterable for the `methods` argument, but several places in the source code wrongly expected a list, and break if it is a tuple. Forward-Port-Of: odoo/odoo#193869 Forward-Port-Of: odoo/odoo#193621
Original PR description
The docstring of `@route` states that it accepts any iterable for the `methods` argument, but several places in the source code wrongly expected a list, and break if it is a tuple. Forward-Port-Of: odoo/odoo#193869 Forward-Port-Of: odoo/odoo#193621
When we implemented shared accounts, a design decision was that all the branches of a root company should have the same code for an account. However, updating the code for a company doesn't update it for the other companies with the same root. #### Steps to reproduce: - Create a company and a branch. - With both companies active, try to modify the code of an account. - Notice the ValidationError that pops up. #### Analysis: When writing on `code`, `_inverse_code` writes on `code_store`
Original PR description
When we implemented shared accounts, a design decision was that all the branches of a root company should have the same code for an account. However, updating the code for a company doesn't update it…
When we implemented shared accounts, a design decision was that all the branches of a root company should have the same code for an account. However, updating the code for a company doesn't update it for the other companies with the same root. #### Steps to reproduce: - Create a company and a branch. - With both companies active, try to modify the code of an account. - Notice the ValidationError that pops up. #### Analysis: When writing on `code`, `_inverse_code` writes on `code_store`, which is a dependency of `code`. However, because `code` is protected at that point, it isn't invalidated + recomputed for the other companies. As a result, the old, incorrect value persists in cache. #### Solution: I don't think there is a nice neat solution to this. Ideally, we would like to remove the cache values for all the companies other than the active company. However, there isn't a cache function for doing that on context-dependent fields. We try to simulate that by first invalidating, then eagerly recomputing the code again just for the active company. task-none Forward-Port-Of: odoo/odoo#188686
* Import orders from multiple accounts and shops * Match products based on their internal reference (`item_id` or `model_id` in Shopee) * Support both Fulfillment by Shopee (FBS) and Fulfillment by Merchant (FBM): * FBS: import the completed orders * FBM: fetch the delivery information from Shopee, track and synchronize the stock level to Shopee task-3623720 Forward-Port-Of: odoo/enterprise#71610
Original PR description
* Import orders from multiple accounts and shops * Match products based on their internal reference (`item_id` or `model_id` in Shopee) * Support both Fulfillment by Shopee (FBS) and Fulfillment by Merchant (FBM): * FBS: import the completed orders * FBM: fetch the delivery information from Shopee, track and synchronize the stock level to Shopee task-3623720 Forward-Port-Of: odoo/enterprise#71610
Before this commit, selecting an order from the order list and attempting to load it would result in an error. opw-4251717 X-original-commit: 2cd72396d9f96cd7770154c56355ec864e0926e9 Forward-Port-Of: odoo/enterprise#77097
Original PR description
Before this commit, selecting an order from the order list and attempting to load it would result in an error. opw-4251717 X-original-commit: 2cd72396d9f96cd7770154c56355ec864e0926e9 Forward-Port-Of: odoo/enterprise#77097
steps to reproduce: -Go to an indian company -Open the payroll application. -try to create salary register -the end date is current date issue: The end date should be set to the last day of the current month. solution: changed the code for '_get_default_date_to' to set default date to the last day of the current month task-4432414 Forward-Port-Of: odoo/enterprise#76246
Original PR description
steps to reproduce: -Go to an indian company -Open the payroll application. -try to create salary register -the end date is current date issue: The end date should be set to the last day of the current month. solution: changed the code for '_get_default_date_to' to set default date to the last day of the current month task-4432414 Forward-Port-Of: odoo/enterprise#76246
**Specifications:** When creating a spreadsheet in My Drive, access should be restricted to the owner only. When creating a spreadsheet in a Company folder, it should inherit the access permissions of the parent folder. **Task**-4297505 Forward-Port-Of: odoo/enterprise#74179
Original PR description
**Specifications:** When creating a spreadsheet in My Drive, access should be restricted to the owner only. When creating a spreadsheet in a Company folder, it should inherit the access permissions of the parent folder. **Task**-4297505 Forward-Port-Of: odoo/enterprise#74179
**Issue:** In 17.0 and saas-17.2, The Cost of Scrap section does not appear in the the Cost Analysis Report despite having scrapped some components during manufacturing. **Steps to reproduce:** 1. Create a product with a BoM 2. Manufacture the product 3. Scrap some components during manufacturing 4. print the Cost Analysis Report 5. Notice the cost of scrap section does not appear in the report. **Solution:** - I added `raw_material_production_id` t
Original PR description
**Issue:**
In 17.0 and saas-17.2, The Cost of Scrap section does not appear
in the the Cost Analysis Report despite having scrapped some components
during manufacturing.
**Steps to reproduce:**
1. Create a product with a BoM
2. Manufacture the product
3. Scrap some components during manufacturing
4. print the Cost Analysis Report
5. Notice the cost of scrap section does not appear in the report.
**Solution:**
- I added `raw_material_production_id` to the search criteria to ensure scrap stock moves linked to raw materials are also included.
- I replaced `product_qty` with the `quantity` field for handling scrap quantities.
opw-4183097
Forward-Port-Of: odoo/enterprise#75221This commit makes sure that, in tax report, when tax_period is used to determine the report date, and when the tax_period periodicity matches one of the 3 standard filters (month, quarter, or year), that the correponding standard filter is selected with the right date set on it. Before this commit, the default date filter of the tax report would make use of the tax_period to set its date. The date was set properly, but the tax_period date filter would be hidden in case the periodicity matches
Original PR description
This commit makes sure that, in tax report, when tax_period is used to determine the report date, and when the tax_period periodicity matches one of the 3 standard filters (month, quarter, or year), that the correponding standard filter is selected with the right date set on it. Before this commit, the default date filter of the tax report would make use of the tax_period to set its date. The date was set properly, but the tax_period date filter would be hidden in case the periodicity matches monthly, quarterly, or annually. When its hidden, the date filter dropdown menu would show 3 standard filters with none of them selected, which was confusing. task-4373943 Forward-Port-Of: odoo/enterprise#75366
Before this Commit: -------------------------------------- - If only one failure location was available during quality checks (with control per quantity), it was not automatically selected by default. - This lack of default selection caused confusion, and as a result, products were mistakenly sent to the normal stock location instead of the failure location. After this Commit: -------------------------------------- - When only one failure location is available, it is now automatically pr
Original PR description
Before this Commit: -------------------------------------- - If only one failure location was available during quality checks (with control per quantity), it was not automatically selected by default. - This lack of default selection caused confusion, and as a result, products were mistakenly sent to the normal stock location instead of the failure location. After this Commit: -------------------------------------- - When only one failure location is available, it is now automatically pre-selected by default to enhance the user experience. - This change simplifies the user onboarding process by reducing the risk of products being sent to the normal stock location instead of the failure location. Task-id: 4348525 Forward-Port-Of: odoo/enterprise#74665
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. W
Original PR description
Issue Before This Commit: -------------------------------- The delivery label generated by the Shiprocket delivery method displayed an incorrect total when a discount or free delivery was applied, which caused confusion for users. Steps to Produce: -------------------------------- 1. Apply a discount or free delivery for a Shiprocket shipment. 2. Validate the delivery. 3. The total on the delivery label will show an incorrect value, not accounting for the discount or free delivery. With This Commit: -------------------------------- The issue is fixed by ensuring the correct data is sent to the API, which now reflects the accurate total value on the delivery label, even when a discount or free delivery is applied. Task-id: 4395054 Forward-Port-Of: odoo/enterprise#75660
This PR, alongside its community counterpart, changes the behavior of the /file command and its visual aspects. The new result of /file in html field is a static blue box with a link to a file attachment. In order to preserve the original behavior in Knowledge (editable file name, previewable file etc.), this PR makes sure the EmbeddedFile plugin is used instead, which modifies the /file command so that it renders the uploaded file as an embedded component. https://github.com/odoo/odoo/pul
Original PR description
This PR, alongside its community counterpart, changes the behavior of the /file command and its visual aspects. The new result of /file in html field is a static blue box with a link to a file attachment. In order to preserve the original behavior in Knowledge (editable file name, previewable file etc.), this PR makes sure the EmbeddedFile plugin is used instead, which modifies the /file command so that it renders the uploaded file as an embedded component. https://github.com/odoo/odoo/pull/189203 task-3522395 Forward-Port-Of: odoo/enterprise#75045
Re-exported because: - To take into account PRs that were merged after the freeze - A couple pot files were missing/empty (i.e. empty = deleted) - Just in case there was anything out of date
Original PR description
Re-exported because: - To take into account PRs that were merged after the freeze - A couple pot files were missing/empty (i.e. empty = deleted) - Just in case there was anything out of date
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR requires adding responsible_ids in the test cases. The ch
Original PR description
Steps: - Install the hr_holiday module - Configure Time Off Type with validation set to `Approved by Time Off Officer` or `Both` - Create a Time Off request without setting a Time Off Officer. --- Description of the issue/feature this PR addresses: When the validation type is set to `hr` or `both` and no Time Off Officer is configured, an activity is incorrectly generated upon creating a Time Off request. --- Fix: This PR requires adding responsible_ids in the test cases. The changes made in this task remove activities when responsible_ids is not set, causing the test cases to fail. Adding responsible_ids will ensure the tests pass successfully. task-4351688 Forward-Port-Of: odoo/enterprise#77385 Forward-Port-Of: odoo/enterprise#75828
This commit's purpose is to make the profitability test works without demo data. The issue is that without some specific groups, the 'workorder_ids' field is not visible inside the views, making the creation of record impossible. Adding these groups in the config of the test fixes the issue version 18.0-master Forward-Port-Of: odoo/enterprise#77350
Original PR description
This commit's purpose is to make the profitability test works without demo data. The issue is that without some specific groups, the 'workorder_ids' field is not visible inside the views, making the creation of record impossible. Adding these groups in the config of the test fixes the issue version 18.0-master Forward-Port-Of: odoo/enterprise#77350
In this commit, we add 2 additionnal check steps to ensure the tour take the good way. runbot-error-id~109456 Forward-Port-Of: odoo/enterprise#77417
Original PR description
In this commit, we add 2 additionnal check steps to ensure the tour take the good way. runbot-error-id~109456 Forward-Port-Of: odoo/enterprise#77417
This reverts commit 6d00d4da05af71f17139cdb5a3a25ae9e0c10afb That commit was causing an exception in the code handling the response from the API call to the Ecuadorian Tax Agency (SRI), causing a transaction rollback and the loss of the information sent to the SRI as well as the SRI's response. Users with affected invoices need to take care to not reset the invoices to draft. After this fix is merged, the API handling code will be able to recover the invoice status from the SRI, so no data
Original PR description
This reverts commit 6d00d4da05af71f17139cdb5a3a25ae9e0c10afb That commit was causing an exception in the code handling the response from the API call to the Ecuadorian Tax Agency (SRI), causing a transaction rollback and the loss of the information sent to the SRI as well as the SRI's response. Users with affected invoices need to take care to not reset the invoices to draft. After this fix is merged, the API handling code will be able to recover the invoice status from the SRI, so no data-fix should in principle be needed. task-none Forward-Port-Of: odoo/enterprise#77461