Wednesday, January 15, 2025
41 changes · saas-18.1
Enhancements to existing features
This update adds simple developer commands to temporarily disable selected IoT box features or device actions during development. It helps teams test and iterate faster without changing source code, with no direct impact on normal business users.
Original PR description
While developing, we often disable features like the db checkout and the IoT handlers download to save some time. Now, instead of going in the code and comment the lines we want to remove, we can just type: - `devtools disable general`: to disable general features (checkout, handlers download), - `devtools disable actions <optional action name>`: to disable a device action (printing for example). **Note:** by default, if you don't specify `<action name>`, it will disable all actions. Task: 4291487
The IoT box image version is now generated automatically from the build date instead of being updated by hand for each release. This reduces manual release work and lowers the chance of publishing an image with an outdated or incorrect version number.
Original PR description
Before this PR, the IoT box version (e.g 25.01 for an image built in January 2025) was changed manually whenever a new image was released. After this PR, the version string is generated automatically based on the date at build time. Also, an unused `VERSION` variable was removed from the build script. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The IoT box setup now makes common text editors keep files under the expected Odoo ownership. This reduces the risk of configuration or maintenance issues caused by files accidentally changing ownership during edits.
Original PR description
In order to ensure file ownership does not change, we updated `nano` and `vim` aliases to force perform as `odoo` user.
Resolved issues and error corrections
Restores the recruitment applicant unarchive process to its expected behavior after a previous change caused it to rely on an incorrect result. This helps prevent issues when reopening archived job applications.
Original PR description
The `action_unarchive` returns None by default. Rollback the change from odoo/odoo#183691 on this file which is incorrect. task-4453279 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Interfaces/Drivers inherit from an `Interface`/`Driver` class. These parent classes should not be registered as an actual interface/driver. This is now filterered at instanciation in order to avoid looping over useless elements later. Forward-Port-Of: odoo/odoo#193510
Original PR description
Interfaces/Drivers inherit from an `Interface`/`Driver` class. These parent classes should not be registered as an actual interface/driver. This is now filterered at instanciation in order to avoid looping over useless elements later. Forward-Port-Of: odoo/odoo#193510
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add em
Original PR description
Steps to reproduce ================== - Open any project - Create many project stages (80+) - Switch to the list view - Group by stage - Switch to to next page => The pager keeps increasing Cause of the issue ================== `stage_id` has a group_expand: `_read_group_stage_ids` This method is used to include empty stages in the result for the kanban view, so that we can drag tasks to an empty stage. Solution ======== Add a context key `project_kanban` and only add empty stages in that case. opw-4408061 Forward-Port-Of: odoo/odoo#193488 Forward-Port-Of: odoo/odoo#192492
The cloc_exclude entry of the manifest was activated for data modules*, and it works for records with a new id. But it fails for records with external ids from another module, as it tries to lookup for a record with an xmlid like `new_module.external_module.id`, which is not a valid xmlid. This commit fixes the issue by first checking if the record to exclude from cloc is from another module or not, before creating the ir_model_data entry. *https://github.com/odoo/odoo/commit/a47de680de149
Original PR description
The cloc_exclude entry of the manifest was activated for data modules*, and it works for records with a new id. But it fails for records with external ids from another module, as it tries to lookup for a record with an xmlid like `new_module.external_module.id`, which is not a valid xmlid. This commit fixes the issue by first checking if the record to exclude from cloc is from another module or not, before creating the ir_model_data entry. *https://github.com/odoo/odoo/commit/a47de680de149a60dd479c4c0b14f2c1bf5afcbe opw-4472893 Forward-Port-Of: odoo/odoo#193592
### Description of the issue/feature this PR addresses: This error could be raised if oAuth session has expired before Odoo gets a chance to close the IMAP connection: ``` <class 'imaplib.IMAP4.abort'>: \"socket error: [Errno 32] Broken pipe\" while evaluating\n'model._fetch_mails() ``` We get this error from time to time when fetching emails from a Gmail account configured with Google oAuth. ### Current behavior before PR: Fetchmail scheduled action hangs when this happens, and
Original PR description
### Description of the issue/feature this PR addresses: This error could be raised if oAuth session has expired before Odoo gets a chance to close the IMAP connection: ``` <class…
### Description of the issue/feature this PR addresses: This error could be raised if oAuth session has expired before Odoo gets a chance to close the IMAP connection: ``` <class 'imaplib.IMAP4.abort'>: \"socket error: [Errno 32] Broken pipe\" while evaluating\n'model._fetch_mails() ``` We get this error from time to time when fetching emails from a Gmail account configured with Google oAuth. ### Current behavior before PR: Fetchmail scheduled action hangs when this happens, and no email are fetched anymore (dangling connection still in worker process, until this worker is recycled? Is it possible?). ### Desired behavior after PR is merged: Catch properly the exception and have a scheduled action terminating nicely. We did this patch on v14, but we are not entirely sure it is fixing the encountered issue as this happened randomly, and very rarely. But I guess it is anyway a good thing to catch such errors to get a WARNING log, like it has been done by catching `OSError` for timeout issues. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190319
Since the [document layout redesign](odoo/odoo@e19efd2f54014425b14defd6015b9a71c1142385), the incoterms in rfq are wrongly displayed. This is due to the dynamic title which breaks the xpath, xpathing the incoterms in the `<h2>` instead of after it. This commit fixes the xpath to properly display the incoterms. opw-4380886 task-4453695 <h3>Steps to reproduce</h3> - Choose any document layout - Have purchase & Inventory installed - Create a request for quotation - In the "o
Original PR description
Since the [document layout redesign](odoo/odoo@e19efd2f54014425b14defd6015b9a71c1142385), the incoterms in rfq are wrongly displayed.
This is due to the dynamic title which breaks the xpath, xpathing the incoterms in the `<h2>` instead of after it.
This commit fixes the xpath to properly display the incoterms.
opw-4380886
task-4453695
<h3>Steps to reproduce</h3>
- Choose any document layout
- Have purchase & Inventory installed
- Create a request for quotation
- In the "other information" tab, choose an incoterm
- Print the RFQ
| Issue | Fix |
|--------|--------|
|  |  |
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#192503Steps to reproduce: - Open planning app and click on New. - A form is opened and searched for a material resource in the Resource field ex. Crane - An empty photo icon is displayed in the selection bar. Issue: - An empty photo icon is being displayed instead of a wrench. Cause: - Many2XAutocomplete which adds an image in the many2one selection field is not modified to display - the wrench icon in the many2one_avatar_resource_field. Solution: - A similar modification is do
Original PR description
Steps to reproduce: - Open planning app and click on New. - A form is opened and searched for a material resource in the Resource field ex. Crane - An empty photo icon is displayed in the selection bar. Issue: - An empty photo icon is being displayed instead of a wrench. Cause: - Many2XAutocomplete which adds an image in the many2one selection field is not modified to display - the wrench icon in the many2one_avatar_resource_field. Solution: - A similar modification is done in many2many_avatar_resource_field through class which extends Many2XAutocomplete which can be imported and added into components of many2one_avatar_resource_field. fix the alignment between of icon and text in many2many_avatar_resource. task-3801551 Forward-Port-Of: odoo/odoo#193083 Forward-Port-Of: odoo/odoo#157968
Purpose of this commit: When an operator mentions someone in an ongoing live chat conversation and the guest clicks on it, a traceback error is raised. This occurs because clicking on the mention attempts to execute an action to open the mentioned partner's record. Since the guest user lacks access to the action services in the services registry, the error is triggered. This commit resolves the issue. task-4459050 --- I confirm I have signed the CLA and read the PR guidelines at
Original PR description
Purpose of this commit: When an operator mentions someone in an ongoing live chat conversation and the guest clicks on it, a traceback error is raised. This occurs because clicking on the mention attempts to execute an action to open the mentioned partner's record. Since the guest user lacks access to the action services in the services registry, the error is triggered. This commit resolves the issue. task-4459050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192834
Steps to reproduce: - Go to the "/blog/astronomy-2/what-if-they-let-you-run-the-hubble-5" page. - Click on the "Mobile Preview" button. - Bug: The breadcrumb is broken. In stable versions, we fixed this in the least intrusive way possible to avoid making significant layout changes to existing databases. **BEFORE:** <kbd></kbd> **AFTER:** <kbd>![2025-01-14_09-53](https://github.com/
Original PR description
Steps to reproduce: - Go to the "/blog/astronomy-2/what-if-they-let-you-run-the-hubble-5" page. - Click on the "Mobile Preview" button. - Bug: The breadcrumb is broken. In stable versions, we fixed this in the least intrusive way possible to avoid making significant layout changes to existing databases. **BEFORE:** <kbd></kbd> **AFTER:** <kbd></kbd> In master version, in mobile view, we replaced the breadcrumb with a "< All Blogs" button to return to the blogs list, similar to what is done in "website_sale" and "website_event". opw-4457408 Forward-Port-Of: odoo/odoo#193508
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193722
Original PR description
Update the OWL lib. Release notes: https://github.com/odoo/owl/releases/tag/v2.6.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193722
Steps: - Go to the 'Activity Plans' section. - Select a company in the company widget. - Activity plans were not filtered based on the selected company. Issues: - Activity plans were not filtered correctly by the selected company, showing plans from unrelated companies. Fix: - Added domain to display activity plans assigned to the selected company. - Added domain to display global activity plans when no company is selected. Task - 4441838 Description of the issue/feature this P
Original PR description
Steps: - Go to the 'Activity Plans' section. - Select a company in the company widget. - Activity plans were not filtered based on the selected company. Issues: - Activity plans were not filtered correctly by the selected company, showing plans from unrelated companies. Fix: - Added domain to display activity plans assigned to the selected company. - Added domain to display global activity plans when no company is selected. Task - 4441838 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: Forward-Port-Of: odoo/odoo#192171
### Steps to reproduce: - Create a project with a few tasks -> add a portal user as a follower - Go to the user's portal -> the user sees the project, but no tasks - Give user access to another project so that he has multiple projects in his portal. - Open the first project with 0 visible task and use arrows to navigate between the projects. - Go back to the first project all tasks are visible ### Cause: This is happening because when fetching tasks that will be shown we are passin
Original PR description
### Steps to reproduce: - Create a project with a few tasks -> add a portal user as a follower - Go to the user's portal -> the user sees the project, but no tasks - Give user access to another…
### Steps to reproduce: - Create a project with a few tasks -> add a portal user as a follower - Go to the user's portal -> the user sees the project, but no tasks - Give user access to another project so that he has multiple projects in his portal. - Open the first project with 0 visible task and use arrows to navigate between the projects. - Go back to the first project all tasks are visible ### Cause: This is happening because when fetching tasks that will be shown we are passing the SU parameter as true if we have access token https://github.com/odoo/odoo/blob/0b315ded0928372d2349b25699f440f4bf969814/addons/project/controllers/portal.py#L38 which leads that we will not create a domain for fetching tasks as SU will by default has access to all tasks. https://github.com/odoo/odoo/blob/0b315ded0928372d2349b25699f440f4bf969814/addons/project/controllers/portal.py#L372-L373 ### Fix: We are gonna pass the parameter of SU as true only if the env of the request is SU env only. opw-4410717 Forward-Port-Of: odoo/odoo#192552
The tax tags are translatable but never translated automatically because they are generated dynamically from the tax report. This commit aims at improving this by translating automatically the tags that match exactly the name of the tax report line, for instance in Israel. Forward-Port-Of: odoo/odoo#192233
Original PR description
The tax tags are translatable but never translated automatically because they are generated dynamically from the tax report. This commit aims at improving this by translating automatically the tags that match exactly the name of the tax report line, for instance in Israel. Forward-Port-Of: odoo/odoo#192233
Steps to reproduce (db with Accounting installed): - create a child company - give a user (e.g. Marc Demo) access to the child company, set their "Accounting" rights to "Accountant" and "Administration" to None. - log as this user and select only the child company in the company selector. - try to access "Accounting/Configuration/Accounting/Currencies" -> Access Error It is happening as in the `res.currency` model, several methods try to access the root company, but there's only the c
Original PR description
Steps to reproduce (db with Accounting installed): - create a child company - give a user (e.g. Marc Demo) access to the child company, set their "Accounting" rights to "Accountant" and "Administration" to None. - log as this user and select only the child company in the company selector. - try to access "Accounting/Configuration/Accounting/Currencies" -> Access Error It is happening as in the `res.currency` model, several methods try to access the root company, but there's only the child company in `allowed_company_ids` from the context. The fix here is to: 1) When accessing the root company in order the get its currency, just access the currency of the child company, as it is the same. 2) Use sudo when accessing other fields from the root company. opw-4352595 Forward-Port-Of: odoo/odoo#192982 Forward-Port-Of: odoo/odoo#192632
Steps to reproduce the issue: - In Website edit mode, drag and drop an "Image Gallery" block onto the page. - Select "Full" as the "Content Width" option for the "Image Gallery" block. - Click on the image. - Add a link to the image. - Zoom the page to 50% using the browser tool. - Bug: the image is aligned to the left instead of being centered. - Remove the link: the image is correctly centered. opw-4458747 Forward-Port-Of: odoo/odoo#193585
Original PR description
Steps to reproduce the issue: - In Website edit mode, drag and drop an "Image Gallery" block onto the page. - Select "Full" as the "Content Width" option for the "Image Gallery" block. - Click on the image. - Add a link to the image. - Zoom the page to 50% using the browser tool. - Bug: the image is aligned to the left instead of being centered. - Remove the link: the image is correctly centered. opw-4458747 Forward-Port-Of: odoo/odoo#193585
Steps to reproduce ================== - Use a mobile viewport - Go to Inventory > Delivery Orders - Open any record - Click on a product - Click on add => TypeError: ml.data.quant_id is undefined Cause of the issue ================== On mobile, the quant_id field is not present in the view opw-4288556 Forward-Port-Of: odoo/odoo#193452 Forward-Port-Of: odoo/odoo#192732
Original PR description
Steps to reproduce ================== - Use a mobile viewport - Go to Inventory > Delivery Orders - Open any record - Click on a product - Click on add => TypeError: ml.data.quant_id is undefined Cause of the issue ================== On mobile, the quant_id field is not present in the view opw-4288556 Forward-Port-Of: odoo/odoo#193452 Forward-Port-Of: odoo/odoo#192732
Renaming session to __session leverages Python's name mangling and ensures the attribute is treated as a private to the class. Forward-Port-Of: odoo/odoo#193501
Original PR description
Renaming session to __session leverages Python's name mangling and ensures the attribute is treated as a private to the class. Forward-Port-Of: odoo/odoo#193501
The get_text_content is not powerful enough to extract translated attributes. As a result, get_text_content will return empty string '' for terms whose translated contents are only in attributes. When the result is used to build the mapping text2terms, users will get strange result after write. opw-4147913 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 g
Original PR description
The get_text_content is not powerful enough to extract translated attributes. As a result, get_text_content will return empty string '' for terms whose translated contents are only in attributes. When the result is used to build the mapping text2terms, users will get strange result after write. opw-4147913 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#193574
**Description of the issue/feature this PR addresses:** When odoo is deployed with Reverse Proxy , like cloudflare, and cache rule is enabled. The login page is cached by cloudflare, "Cf-Cache-Status" is set to "HIT" in the reponse header  But in the html content, csrf_token is unavailable.  Error when try to
Original PR description
**Description of the issue/feature this PR addresses:** When odoo is deployed with Reverse Proxy , like cloudflare, and cache rule is enabled. The login page is cached by cloudflare, "Cf-Cache-Status" is set to "HIT" in the reponse header  But in the html content, csrf_token is unavailable.  Error when try to login.  **Current behavior before PR:** User can not login. **Desired behavior after PR is merged:** User can login. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191453
**Affects** 16.0+ **Steps to reproduce:** - Render the Contact qweb widget with fields ["phone", "website"] ```py Contact = self.env["ir.qweb.field.contact"] partner = self.env["res.partner"].create( { "name": "Test Partner", "phone": "1234567890", "website": "https://www.example.com", } ) result = Contact.value_to_html(partner, {"fields": ["phone", "website"]}) ``` **Result:** - The website is not shown --- This is a regression int
Original PR description
**Affects**
16.0+
**Steps to reproduce:**
- Render the Contact qweb widget with fields ["phone", "website"]
```py
Contact = self.env["ir.qweb.field.contact"]
partner = self.env["res.partner"].create(
{
"name": "Test Partner",
"phone": "1234567890",
"website": "https://www.example.com",
}
)
result = Contact.value_to_html(partner, {"fields": ["phone", "website"]})
```
**Result:**
- The website is not shown
---
This is a regression introduced in 9e53aea9, in combination with some buggy behavior in the qweb compilation.
Somehow the `t-elif` condition is applying on the next element instead on itself, hiding the website item. I did not investigate this further.
ping @lvsz @ryv-odoo
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#193461
Forward-Port-Of: odoo/odoo#191201When changing the destination location of a picking, the destination location of the stock moves are not updated and the user may not even notice it. To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Receipt, New - Add an operation - Change the destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move Error: the destination location of the stock move is still the initial one On the picking model, the
Original PR description
When changing the destination location of a picking, the destination location of the stock moves are not updated and the user may not even notice it. To reproduce the issue: 1. In Settings, enable…
When changing the destination location of a picking, the destination location of the stock moves are not updated and the user may not even notice it. To reproduce the issue: 1. In Settings, enable "Storage Locations" 2. Inventory > Operations > Receipt, New - Add an operation - Change the destination location of the picking 3. Save 4. Mark as Todo 5. Open the created move Error: the destination location of the stock move is still the initial one On the picking model, there are two fields that contain the stock moves: https://github.com/odoo/odoo/blob/17a63a6cda41a44e3d4ff8b5a9042e93ba956bc8/addons/stock/models/stock_picking.py#L612-L614 Where `move_ids_without_packages` is a subset of `move_ids` When editing the operations of a picking, we are actually dealing with the field `move_ids_without_packages`. So, when changing the destination location of the picking, the webclient sends the SMs via the field `move_ids_without_packages`, i.e.: the web client does not provide any value for `move_ids`. Server side, when creating a `new` record based on the provided values, we will handle the inverse of `move_ids_without_packages`, i.e.: we will make sure that the stock moves have the field `picking_id` correctly defined: https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L6366-L6374 **But** we don't define any value for the siblings of the field. It means that we don't set any value for the field `move_ids`. This will lead to the bug: later on in the onchange, we flag all fields that will have to be recomputed: https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/addons/web/models/models.py#L983 And here we would hope that the field `location_dest_id` of the stock moves will be flagged, as mentioned in the dependencies: https://github.com/odoo/odoo/blob/68ae97bd27fbdc874922e03f52f8b0c7953df801/addons/stock/models/stock_move.py#L206-L207 But... In `_modified_triggers`, at some point, we are here https://github.com/odoo/odoo/blob/a4c2f66700dd98487ac6bb8f0f25fdc4abffd0bf/odoo/models.py#L7200-L7203 Where `field` is `stock.move.picking_id`. So, we iterate on the inverse field of `field`, i.e.: `move_ids` and `move_ids_without_packages`. However, as explicitly mentioned in the comment, we "use an inverse of field without domain", i.e.: `move_ids`. We therefore read the value of this field on the picking which is, because of the bug explained in the previous paragraph, an empty record. As a result, the ORM considers that it does not have to recompute any `location_dest_id`. The ORM team is aware of the issue. They have tried to write a generic solution (cf PR [191318](https://github.com/odoo/odoo/pull/191318)) but it led to a lot of other errors. So, the issue has been considered as a limitation and added to a todo list on their side. In the meantime, it is possible to patch the issue with a stock-specific fix. Note: the issue will also happen when editing an existing picking. Suppose a picking with one move SM01. The user adds a second move SM02, does not save and edits the destination location of the picking: for the same reasons, the ORM will only see SM01 and, therefore, will call the compute method for SM01 only. OPW-4379509 Forward-Port-Of: odoo/odoo#191934
**Current behaviour before PR:** In website, when trying to apply color or any style on a link from toolbar whole link gets selected. This happens because in `wysiwyg.js` `destroyLinkTools` method gets called when user clicks on toolbar to apply color. **Behaviour after PR:** Now, any style can be applied on a link without selecting whole link. task-4072867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#1
Original PR description
**Current behaviour before PR:** In website, when trying to apply color or any style on a link from toolbar whole link gets selected. This happens because in `wysiwyg.js` `destroyLinkTools` method gets called when user clicks on toolbar to apply color. **Behaviour after PR:** Now, any style can be applied on a link without selecting whole link. task-4072867 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192760 Forward-Port-Of: odoo/odoo#180616
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193571 Forward-Port-Of: odoo/odoo#193358
Original PR description
Steps to reproduce: - Start a Viva wallet payment - Immediately cancel and remove the payment line - After a few seconds, a traceback occurs This commit fixes the issue by ensuring that the Viva Wallet status polling only runs if it is still the current payment line. task-4472269 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193571 Forward-Port-Of: odoo/odoo#193358
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move. Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not bei
Original PR description
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session. But the PoS move does not use the…
The reconciliation of move lines creates a cash basis (caba) move under some conditions. This can i.e. happen for the PoS move during the closing of a session.
But the PoS move does not use the transition account of any used caba taxes but the "real" account directly (see commit a011dcc0bdbe892b0a505a6a4169c5168bd018f6). So there is no need for a caba move.
Further an exchange difference move for the tax amount may be created. The issue is that the tax amounts from the cash basis are not being matched correctly with the tax amounts from the PoS move (since we only look for the transition account on the PoS move).
Reproduce on runbot for l10n_mx
1. Install l10n_mx
2. Set the 'IVA 16% VENTAS' tax as Customer Taxes on a product. Set the Sales Price to 100.
3. Create a payment method and journal for the PoS
* Payment method: Cash on journal CSH1
* Journal: POS
5. Create a PoS using the payment method and journal from the previous step.
6. Start a PoS session
7. Sell the product from step 2 via the Cash payment method.
8. Close the Session
9. The following journal entries will be created: (All the tax lines use the same tax account; the "final" and not the caba transition account)
```
* 1 entry in the POS journal (order)
base: | - 100.0 $
tax: | - 16.0 $
receivable: | + 116.0 $
* 1 entry in the CSH1 journal (cash / payment)
cash: | + 116.0 $
receivable: | - 116.0 $
* 1 entry in the CBMX journal (caba)
base: | - 100.0 $
base: | + 100.0 $
tax: | - 16.0 $
tax: | + 16.0 $
* 1 entry in the EXCH journal (exchange difference)
for the cash basis rounding difference
tax: | - 16.0 $
tax: | + 16.0 $
```
This commit fixes the issue by just skipping the creation of caba moves during the reconciliation of the PoS move lines. Further we make sure no exchange difference entry is created for the (not even created) cash basis entries.
opw-4355124
Forward-Port-Of: odoo/odoo#193492
Forward-Port-Of: odoo/odoo#193195Currently, a traceback occurs when the user tries to generate a payment link and tries to refresh it. To reproduce this issue: 1) Install `Accounting` 2) Create a confirmed Customer Invoice 3) Generate a Payment link from `Actions` 4) Change the `Amount` and refresh the tab 5) You can see the error in the terminal Error:- ``` KeyError: 'installment_state' ``` This traceback occurs because when the user refreshes the tab, it executes the `default_get` method, with self as `p
Original PR description
Currently, a traceback occurs when the user tries to generate a payment link and tries to refresh it. To reproduce this issue: 1) Install `Accounting` 2) Create a confirmed Customer Invoice 3)…
Currently, a traceback occurs when the user tries to generate a payment link and tries to refresh it. To reproduce this issue: 1) Install `Accounting` 2) Create a confirmed Customer Invoice 3) Generate a Payment link from `Actions` 4) Change the `Amount` and refresh the tab 5) You can see the error in the terminal Error:- ``` KeyError: 'installment_state' ``` This traceback occurs because when the user refreshes the tab, it executes the `default_get` method, with self as `payment.link.wizard`. https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/odoo/models.py#L1897-L1899 In that `payment.link.wizard`, we have overridden the `default_get` and updated the values from the `_get_default_payment_link_values` method with the model as `account.move`. https://github.com/odoo/odoo/blob/4787c91c434c7e22ca030bc7a62588482c24b2ab/addons/payment/wizards/payment_link_wizard.py#L21-L23 The method mentioned above will return a dict containing the `installment_state` key-value pair. https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/account_payment/models/account_move.py#L128-L132 But `installment_state` is not a field. It is just a variable that gets its value from the `_get_invoice_next_payment_values`. https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/addons/account_payment/models/account_move.py#L104 So eventually it leads to the above traceback from the below line. https://github.com/odoo/odoo/blob/be6b327c17435947fc3f10d30fc8c4730c182aed/odoo/models.py#L1897-L1899 sentry-6058398917 Forward-Port-Of: odoo/odoo#191764
Currently, when buying a product in pos and using a new lot id, the quantities do not reflect this lot id. Steps to reproduce: ------------------- * Create a product: * Storable * Available in POS * Tracked by lots * Open shop session * Select the product just created * Enter anything as the lot number * Finalize order * Close session * In the back-end, navigate to the product page * Select the smart button **On hand** > Observation: The lot is not reflected Why the fix:
Original PR description
Currently, when buying a product in pos and using a new lot id, the quantities do not reflect this lot id. Steps to reproduce: ------------------- * Create a product: * Storable * Available in POS * Tracked by lots * Open shop session * Select the product just created * Enter anything as the lot number * Finalize order * Close session * In the back-end, navigate to the product page * Select the smart button **On hand** > Observation: The lot is not reflected Why the fix: ------------ When the session in closed, `stock.lot` are created but not reflected on the inventory quantity updates. We can add the `lot_id` when creating move lines as where we mention it, it will always have a related existing lot as per: https://github.com/odoo/odoo/blob/ba21b59d1234d13b5d4460facd60c586648048b8/addons/point_of_sale/models/stock_picking.py#L290 opw-4359435 Forward-Port-Of: odoo/odoo#193450
Due to an error in the condition, `ProprietaryID` was always used, even if IBANID should be used instead. That lead to customers missing information (`ProprietaryID` is not always picked up by other software, while IBANID is). Ticket link: https://odoo.com/odoo/69/tasks/4414985 opw-4414985 Forward-Port-Of: odoo/odoo#192519
Original PR description
Due to an error in the condition, `ProprietaryID` was always used, even if IBANID should be used instead. That lead to customers missing information (`ProprietaryID` is not always picked up by other software, while IBANID is). Ticket link: https://odoo.com/odoo/69/tasks/4414985 opw-4414985 Forward-Port-Of: odoo/odoo#192519
Steps to reproduce: -------------------------- - Install the point_of_sale module. - Set up any payment terminal. - Attempt payment using the terminal. - Cancel the transaction request. Issue: -------- - Payment method button remains in progress mode after canceling the transaction. - In mobile view, the payment status message lacks a visible background. Cause: --------- - Transaction progress state is not reset after a successful cancellation. - Missing responsive classes for m
Original PR description
Steps to reproduce: -------------------------- - Install the point_of_sale module. - Set up any payment terminal. - Attempt payment using the terminal. - Cancel the transaction request. Issue: -------- - Payment method button remains in progress mode after canceling the transaction. - In mobile view, the payment status message lacks a visible background. Cause: --------- - Transaction progress state is not reset after a successful cancellation. - Missing responsive classes for mobile view. Fix: ---- - Reset the payment method progress state after a successful cancellation. - Add appropriate classes to ensure the payment status background is visible across all views. Task: 4427387 Forward-Port-Of: odoo/odoo#191618
CLA change. Added new resource to corporate CLA file --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193539
Original PR description
CLA change. Added new resource to corporate CLA file --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193539
After commit odoo/odoo@6e4a036, the activity date component breaks onto a new line. This fix ensures that the activity date remains on the same line and no longer wraps. opw-4402682 **Description of the issue/feature this PR addresses:** - In the Accounting dashboard, when an activity is set on an account journal of type `Miscellaneous`, the `date` component of the `activity` is not aligned properly. - The date component breaks into a new line, causing a misalignment in the display. -
Original PR description
After commit odoo/odoo@6e4a036, the activity date component breaks onto a new line. This fix ensures that the activity date remains on the same line and no longer wraps. opw-4402682 **Description of…
After commit odoo/odoo@6e4a036, the activity date component breaks onto a new line. This fix ensures that the activity date remains on the same line and no longer wraps. opw-4402682 **Description of the issue/feature this PR addresses:** - In the Accounting dashboard, when an activity is set on an account journal of type `Miscellaneous`, the `date` component of the `activity` is not aligned properly. - The date component breaks into a new line, causing a misalignment in the display. - This fix aims to fix the display issue by ensuring the activity date remains properly aligned on the same line as the rest of the content. - It prevents the date component from wrapping onto the next line, thereby improving the visual consistency of the dashboard. **Current behavior before PR:** The `activity date` falls onto the next line.  **Desired behavior after PR is merged:** The `activity date` stays on the same line.  **Steps to reproduce activity date display issue :** - Install the Accounting module. - Navigate to the Accounting dashboard. - Create a new account journal of type `Miscellaneous` - Set an `activity` on that journal. - Return to the dashboard. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193173
Steps to reproduce: 1. Switch to mobile view. 2. The magnifier button is not working. 3. when adding a member through the share panel, 'people with access' section shows weirdly. 4. Send and discard button display issue on the share panel. Technical Reason: SearchBar is being handled in the control panel and was not passed the searchBarToggler in the toggler attribute, and add a condition on the 'searchBarToggler.component' only shows if documents are not selected. After this Commit:
Original PR description
Steps to reproduce: 1. Switch to mobile view. 2. The magnifier button is not working. 3. when adding a member through the share panel, 'people with access' section shows weirdly. 4. Send and discard button display issue on the share panel. Technical Reason: SearchBar is being handled in the control panel and was not passed the searchBarToggler in the toggler attribute, and add a condition on the 'searchBarToggler.component' only shows if documents are not selected. After this Commit: 1. The magnifier button will hide/display the search bar and the magnifier button will be hidden if we select a document. 2. In the share panel, the 'people with access' section, will show properly. 3. Buttons will be in a proper width. Task-4419375 Forward-Port-Of: odoo/enterprise#76039
Steps to reproduce: 1. press 'Cntrl+a' will select and deselect. 2. after one operation of selecting/deselecting it loses focus. 3. focus moved to the search bar. 4. due to this the 'Cntrl+a' is not working until you click somewhere. 5. select/deselect not working properly. It also fixes issues related to the 'shift+arrow' selection flow 1. Go to the documents list view 2. Select any not-the-last record 3. Hold Shift and hit down arrow 4. The record below is not selected as it should
Original PR description
Steps to reproduce: 1. press 'Cntrl+a' will select and deselect. 2. after one operation of selecting/deselecting it loses focus. 3. focus moved to the search bar. 4. due to this the 'Cntrl+a' is not working until you click somewhere. 5. select/deselect not working properly. It also fixes issues related to the 'shift+arrow' selection flow 1. Go to the documents list view 2. Select any not-the-last record 3. Hold Shift and hit down arrow 4. The record below is not selected as it should Technical Reason: In the Search bar, the attribute autofocus was evaluating 'true' every time because of sending 'undefined' due to this default props set it to 'true'. After this Commit: 1. focus will not be lost. 2. select/deselect will work properly. Task-4413608 Forward-Port-Of: odoo/enterprise#75866
Since https://github.com/odoo/odoo/commit/d0e7be7832672d476f1b289af52d3a425990d719 we're trying to access some keys in `account.document_tax_totals_template` that are not present in the subtotals dict from the withhold tax summary. Steps: - Create and confirm a bill - Add a withhold and open it - Try to print it -> TB: 'KeyError' opw-4433279 Forward-Port-Of: odoo/enterprise#76330
Original PR description
Since https://github.com/odoo/odoo/commit/d0e7be7832672d476f1b289af52d3a425990d719 we're trying to access some keys in `account.document_tax_totals_template` that are not present in the subtotals dict from the withhold tax summary. Steps: - Create and confirm a bill - Add a withhold and open it - Try to print it -> TB: 'KeyError' opw-4433279 Forward-Port-Of: odoo/enterprise#76330
Changes in enterprise related to PR https://github.com/odoo/odoo/pull/157968 Added the resource_color as dependency for the widget to display the color task-3801551 Forward-Port-Of: odoo/enterprise#76835 Forward-Port-Of: odoo/enterprise#70453
Original PR description
Changes in enterprise related to PR https://github.com/odoo/odoo/pull/157968 Added the resource_color as dependency for the widget to display the color task-3801551 Forward-Port-Of: odoo/enterprise#76835 Forward-Port-Of: odoo/enterprise#70453
This commit change the account_move field we use to compute mod349 report. Before, we used amount_total. Now we use amount_untaxed, as the mod349 only need to show taxable bases. opw-4320487 Forward-Port-Of: odoo/enterprise#76516
Original PR description
This commit change the account_move field we use to compute mod349 report. Before, we used amount_total. Now we use amount_untaxed, as the mod349 only need to show taxable bases. opw-4320487 Forward-Port-Of: odoo/enterprise#76516
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - Th
Original PR description
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish…
Since [1], this flow is broken: 1. Install website_helpdesk => You have a "Help" menu with an helpdesk team as url (/helpdesk/customer-care-1) which is created 2. Check: if you publish or unpublish your team, that menu is visible or invisible as a public user. 3. Create a new menu for your website, with that same URL (/helpdesk/customer-care-1) 4. Check: that menu is always invisible as a public user. Even if you remove the first menu. Multiple mistakes were made with [1]: - The website menu visibility override code was added twice in two different files. - The override advertises that this is for "always showing the helpdesk team menus even if they are unpublished" but it is actually meant to be the exact opposite of that. - The implementation is based on the menu that are linked to the helpdesk teams, not on their URL **. - The implementation actually bypass the normal visibility computation for all menu URL that start with "/helpdesk", meaning a custom page "/helpdesk-hello" from the user is just broken, so as existing controllers not linked to an helpdesk team (such as /helpdesk/rating). **: actually this could mean that this feature is just not meant to be given the current state of the codebase: creating a menu with a team URL should just make it so it is forcefully linked to that team or should be prevented if it cannot (?). [1]: https://github.com/odoo/enterprise/commit/a888fb57ebd2458bc8479e187088cb2e96b811fa opw-3931376 Forward-Port-Of: odoo/enterprise#76797 Forward-Port-Of: odoo/enterprise#63105
An error occurs while preparing monster data because in code mistakenly uses the attribute name 'is_flexible_hours' instead of the correct attribute name 'flexible_hours' to check the flexible hours of the resource calendar. `AttributeError: 'resource.calendar' object has no attribute 'is_flexible_hours'` To resolve this issue, Give a valid attribute name 'flexible_hours' instead of 'is_flexible_hours'. Sentry-6150854320 Forward-Port-Of: odoo/enterprise#75730
Original PR description
An error occurs while preparing monster data because in code mistakenly uses the attribute name 'is_flexible_hours' instead of the correct attribute name 'flexible_hours' to check the flexible hours of the resource calendar. `AttributeError: 'resource.calendar' object has no attribute 'is_flexible_hours'` To resolve this issue, Give a valid attribute name 'flexible_hours' instead of 'is_flexible_hours'. Sentry-6150854320 Forward-Port-Of: odoo/enterprise#75730
The aim of this commit is changing 36000 banks for the real number (~26000 banks). no task id Proof:  Forward-Port-Of: odoo/enterprise#77047
Original PR description
The aim of this commit is changing 36000 banks for the real number (~26000 banks). no task id Proof:  Forward-Port-Of: odoo/enterprise#77047