Wednesday, January 15, 2025
25 changes · saas-17.4
Resolved issues and error corrections
Restaurant point-of-sale users can now split order lines with decimal quantities without the split amount increasing endlessly. The split bill screen stops additions once the selected quantity reaches the original order line amount, preventing incorrect bill splits.
Original PR description
Fixes an issue where splitting an order line with a decimal quantity (e.g., 2.5) would cause indefinite increments in the split bill screen. This adds a check to ensure the split quantity does not exceed the original order line quantity. task-id: 4461861 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
Module imports now correctly handle code-count exclusion rules when excluded records come from another module. This prevents import failures caused by invalid record identifiers and helps data modules install more reliably.
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
This change reverses a previous update that linked helpdesk tasks to customers based on the email entered in a website form. It helps avoid incorrect customer assignments when visitors submit helpdesk requests online.
Original PR description
task-4295363
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
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
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: - Go to a form view with a one2many with a handle widget - Move a line in the one2many that make Odoo crash with the onchange To generate a faulty view, create a form view with a one2many and add an automation "On UI change" to make the resequence crash. Current behaviour ----------------- After the error being thrown, the user will not be able to resequence this line again. Expected Behaviour ------------------ After the error, the user will still be able to r
Original PR description
Steps to reproduce: - Go to a form view with a one2many with a handle widget - Move a line in the one2many that make Odoo crash with the onchange To generate a faulty view, create a form view with a one2many and add an automation "On UI change" to make the resequence crash. Current behaviour ----------------- After the error being thrown, the user will not be able to resequence this line again. Expected Behaviour ------------------ After the error, the user will still be able to resequence this line Forward-Port-Of: odoo/odoo#189785 Forward-Port-Of: odoo/odoo#157539
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#193464 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#193464 Forward-Port-Of: odoo/odoo#193358
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 Forward-Port-Of: odoo/odoo#192930 Forward-Port-Of: odoo/odoo#192359
Original PR description
Two lines that were missing from the "REAGYP - Agricultura" Fiscal Position Tax Mapping have been added. task-4342206 Forward-Port-Of: odoo/odoo#192930 Forward-Port-Of: odoo/odoo#192359
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done Description of the iss
Original PR description
* = stock * PROPBLEM: when viewing purchase or vendor dashboard (under logistic section) , viewing the scoreboard for purchased or order it calculate all record from purchase.report but when clicking on it, redirect to view of 'purchase order' only which is wrong compare to the number display on the scoreboard * SOLUTION: This commit fix by edit the domain of related pivot which the scoreboard use to display data to the domain having state in either Purchase or Done 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#191985
Use fully qualified names as columns in related table can have a same name and this query could raise an error. Like the one below error below was shown in 18.0 ``` psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 3: AND state = 'validate' ``` Note: error occured in 18.0 will be fixed in forward port, using fully qualified names was the purpose so made sense to start from 16.0 and fix for all versions after Description of the issue/
Original PR description
Use fully qualified names as columns in related table can have a same name and this query could raise an error. Like the one below error below was shown in 18.0 ``` psycopg2.errors.AmbiguousColumn: column reference "state" is ambiguous LINE 3: AND state = 'validate' ``` Note: error occured in 18.0 will be fixed in forward port, using fully qualified names was the purpose so made sense to start from 16.0 and fix for all versions after 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#193568
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
After modifying the price of an order line, going to floorplans, selecting the previous table and setting a customer now keep the price previously manually set. As the attribute `order_line.price_manually_set` is not saved in backend, when loading an order from the backend its value is always False. Now we recompute this attribute by comparing the default price of the product and the unit price of the orderline. opw: 4393328 Description of the issue/feature this PR addresses: Current
Original PR description
After modifying the price of an order line, going to floorplans, selecting the previous table and setting a customer now keep the price previously manually set. As the attribute `order_line.price_manually_set` is not saved in backend, when loading an order from the backend its value is always False. Now we recompute this attribute by comparing the default price of the product and the unit price of the orderline. opw: 4393328 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#193390 Forward-Port-Of: odoo/odoo#191053
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
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
task-4285805 Forward-Port-Of: odoo/enterprise#77089 Forward-Port-Of: odoo/enterprise#76950
Original PR description
task-4285805 Forward-Port-Of: odoo/enterprise#77089 Forward-Port-Of: odoo/enterprise#76950
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#76959 Forward-Port-Of: odoo/enterprise#76819
Original PR description
Before this commit, when editing a default value for a field, it was always setting th default on the company of the user (as set on the user), not on the current company the user is logged into. This was largely misleading. After this commit, we get and set the default on the current company. Some work need to be done in master to improve those flows. opw-4427384 Forward-Port-Of: odoo/enterprise#76959 Forward-Port-Of: odoo/enterprise#76819
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
Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An err
Original PR description
Currently, an error occurs when opening a preview of an invoice without an invoice date Step to produce: - Install the `l10n_ec_edi` module (with demo data). - Change a current company to 'EC Company', which has an 'Ecuador' country. - Create a new invoice, add a customer name, payment terms, and invoice line, save the record, - Click on the 'Preview' button (ensure that the invoice has no date). ```TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.date'``` An error occurs when the system attempts to calculate payment term days at [1], with using an invoice date, but it is not available. Link [1]: https://github.com/odoo/enterprise/blob/26aa95079af2a868c2991c7f19daee5328d5bb01/l10n_ec_edi/models/account_move.py#L440C22-L440C93 To resolve this issue, Provide a default day zero(0) for the payment term, if invoice date is not available. Sentry-6015854429 Forward-Port-Of: odoo/enterprise#76560 Forward-Port-Of: odoo/enterprise#72864