Search
Navigate
Branch
Friday, April 26, 2024
82 changes
2 changes
Resolved issues and error corrections
Fixed an issue where email marketing messages could fail to send when a template contained social media icons or buttons without a web link. This helps users send standard marketing templates reliably without hidden errors blocking delivery.
Original PR description
Currently, an exception is generated when the user sends a template to a mailing that contains icons like Facebook, LinkedIn, etc. Steps to produce an exception: 1. Create a database without demo…
Currently, an exception is generated when the user sends a template to a mailing that contains icons like Facebook, LinkedIn, etc. Steps to produce an exception: 1. Create a database without demo data > install 'Email Marketing'. 2. Go to Email Marketing > Create New > Select the `Welcome Message` template. 3. Click 'Send' >> An error will occur in the log, and there is nothing to send. Error: `AttributeError: 'NoneType' object has no attribute 'startswith'` This is because at [1], we don't have `href` in 'link_node', so we receive `False` in 'original_url', and as a result, it generates an error while accessing 'original_url.startswith'. With the recently refactored code with commit https://github.com/odoo/odoo/commit/6349051e5e4442cfabc899520c5708081dc0be31, line [1] was added. Before this change, Line [2] was filtering out elements from `html` that did not have 'href'. This commit will fix the above issue by not processing to find the absolute URL if we do not have `original_url`. [1]- https://github.com/odoo/odoo/blob/b6629bbdb53d9a4bacee2032190e30a848bb6d6d/addons/link_tracker/tools/html.py#L25 [2]- https://github.com/odoo/odoo/blob/c9644a086b294e69b69e52e8ccfd5292bde815da/addons/link_tracker/models/mail_render_mixin.py#L39 sentry-5140192785
Miscellaneous changes
The recent commit https://github.com/odoo/enterprise/commit/b12fc61af033f8914529d86a3edb464fc951f7dc changed the way a move is created during the import of a new peppol document. Before, we were passing a default value for `extract_can_show_send_button`, but now we try to set this field to `False` directly in create values. However, this field only exists in enterprise and thus things break if a user is only using community. Also, it's a computed readonly field, so it is better to use `is_in_ext
Original PR description
The recent commit https://github.com/odoo/enterprise/commit/b12fc61af033f8914529d86a3edb464fc951f7dc changed the way a move is created during the import of a new peppol document. Before, we were passing a default value for `extract_can_show_send_button`, but now we try to set this field to `False` directly in create values. However, this field only exists in enterprise and thus things break if a user is only using community. Also, it's a computed readonly field, so it is better to use `is_in_extractable_state` for this purpose. no task, fixing the error highlighted by tests --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163507
26 changes
Enhancements to existing features
The document spreadsheet test suite was adjusted to stay compatible with an updated spreadsheet library. This helps ensure document spreadsheet features continue to be validated reliably without changing day-to-day user workflows.
54 changes
New functionality added to Odoo
This update introduces financial reporting capabilities for Rwanda, including balance sheet and profit & loss statements. These new reports are now available for businesses operating in Rwanda to ensure accurate financial compliance and balanced reporting.
Original PR description
This commit adds the financial reports of Rwanda and make sure they are balanced. task: 3627705
Payroll users can now open an employee contract directly in the main page from a payslip instead of a smaller pop-up window. This makes it easier to review detailed contract information and prevents creating contracts on the fly from payroll screens, reducing accidental or inappropriate records.
Original PR description
This commit adds a new widget to open a many2one field in current mode from a form view instead of a modal view. This is useful when the view to load is too heavy/big and the user wants to quickly check some information. task-3818439
Odoo now checks for circular relationships in records using a more efficient database query. This helps prevent invalid loops in areas like payroll, knowledge articles, and marketing automation while improving reliability and performance behind the scenes.
Original PR description
Implement checking recursion using a single recursive SQL query. The query starts from self.ids and follows a relationship. We can use the same query for both many2many and many2one relationships. _has_cycle now will not return False if some reachable records are part of a loop and are not in self.ids. This is acceptable because this method is called after modifications with ids of changed records and we can suppose that unchanged records did not introduce a loop. https://github.com/odoo/odoo/pull/162656
Barcode commands and demo barcodes were updated to use shorter, easier-to-read values without special characters. This makes barcode sheets and shop floor workflows easier for staff to understand, remember, and scan consistently.
Original PR description
*: stock_barcode{_mrp,_picking_batch}, mrp_workorder
Revamp the barcodes of commands and demo data to be shorter and with no special characters. So that they are more readable and easier to remember.
COM PR: odoo/odoo#158827
Task-3774096Resolved issues and error corrections
Spreadsheet previews in Documents now show the latest visual changes when users return to the folder view. This avoids confusion from stale thumbnails and removes the need to manually reload the page to see updates.
Original PR description
steps to reproduce: - create a new spreadsheet - change the background color of some cells (so that it's well visible in the thumbnail) - go back to Documents with the breadcrumb - open the spreadsheet again - change the background color - go back again to Documents with the breadcrumb => the thumbnail is not up-to-date with the new background color. You need to reload the page to see it. Technical note: for regular documents, `unique` is the attachment checksum. It doesn't work for spreadsheets since the attachment actually doesn't change when a spreadsheet is updated. A revision is dispatched. The last revision uuid can be used as `unique` discriminant instead Task: 3887916
Employees who do not have a system login will now be automatically subscribed to their appraisal records and related meetings. This helps ensure they stay represented in the appraisal process and that communications reach the right contact.
Original PR description
With this commit, an employee no-user will be by default subscribed to his appraisal and his meeting task-3870088
Miscellaneous changes
In [1] we added a domain on appointment actions to prevent a traceback when users visit the gantt appointment views when resources from different companies appear at the same time. However appointment_resource_id was deprecated in favor of appointment_resource_ids in stable since then. `appointment_resource_ids` should now be used in the domain. [1] ab7addece528d887f062e70732f96fde2ed76dca task-3893256 Forward-Port-Of: odoo/enterprise#61568 Forward-Port-Of: odoo/enterprise#61439
Original PR description
In [1] we added a domain on appointment actions to prevent a traceback when users visit the gantt appointment views when resources from different companies appear at the same time. However appointment_resource_id was deprecated in favor of appointment_resource_ids in stable since then. `appointment_resource_ids` should now be used in the domain. [1] ab7addece528d887f062e70732f96fde2ed76dca task-3893256 Forward-Port-Of: odoo/enterprise#61568 Forward-Port-Of: odoo/enterprise#61439
In the case of a MultiRecordSelector, when modifying the filter and clicking out of the popup, the filter should be updated. However, since the dirtyFilter is not reactive it isn't the case. By using a useState on the variable the filters works as expected. task-3864795 Forward-Port-Of: odoo/enterprise#60745
Original PR description
In the case of a MultiRecordSelector, when modifying the filter and clicking out of the popup, the filter should be updated. However, since the dirtyFilter is not reactive it isn't the case. By using a useState on the variable the filters works as expected. task-3864795 Forward-Port-Of: odoo/enterprise#60745
To make correspondences between accounting entries and attachments, we need a new file and guid for the entries. Documentation can be found at https://developer.datev.de/datev/platform/en/node/6344 task-3888995 Forward-Port-Of: odoo/enterprise#61481 Forward-Port-Of: odoo/enterprise#61378
Original PR description
To make correspondences between accounting entries and attachments, we need a new file and guid for the entries. Documentation can be found at https://developer.datev.de/datev/platform/en/node/6344 task-3888995 Forward-Port-Of: odoo/enterprise#61481 Forward-Port-Of: odoo/enterprise#61378
This commit adds the financial reports of Rwanda and make sure they are balanced. task: 3627705 Forward-Port-Of: odoo/enterprise#57099
Original PR description
This commit adds the financial reports of Rwanda and make sure they are balanced. task: 3627705 Forward-Port-Of: odoo/enterprise#57099
Bug === Create in this order - 1 normal document - 1 link document - 1 normal document Select the first and second documents, the link button is not visible. Select the second and third documents, the link button is visible and shouldn't be. Similarly, the share button should be visible if at least one document is not archived, and not if the first document is not active. Task-3874111 Forward-Port-Of: odoo/enterprise#61449 Forward-Port-Of: odoo/enterprise#61118
Original PR description
Bug === Create in this order - 1 normal document - 1 link document - 1 normal document Select the first and second documents, the link button is not visible. Select the second and third documents, the link button is visible and shouldn't be. Similarly, the share button should be visible if at least one document is not archived, and not if the first document is not active. Task-3874111 Forward-Port-Of: odoo/enterprise#61449 Forward-Port-Of: odoo/enterprise#61118
To reproduce: ============= - create an employee having night shift from 21:30 to 06:00 configured as 21:30 -> 24:00 and 00:30 -> 06:00 (break of 30 minutes) - in planning create a role for this employee - create an open shift for that role from 21:30 to 06:00 - click auto plan -> shift is not assigned to the employee Problem: ======== when computing the rate of allocated hours for this shift we find out that it exceeds 100%, because the hour 24:00 is represented as 23:59:59.999999 w
Original PR description
To reproduce: ============= - create an employee having night shift from 21:30 to 06:00 configured as 21:30 -> 24:00 and 00:30 -> 06:00 (break of 30 minutes) - in planning create a role for this employee - create an open shift for that role from 21:30 to 06:00 - click auto plan -> shift is not assigned to the employee Problem: ======== when computing the rate of allocated hours for this shift we find out that it exceeds 100%, because the hour 24:00 is represented as 23:59:59.999999 which creates rounding issues. Solution: ========= round the allocated rate opw-3874283 Forward-Port-Of: odoo/enterprise#61438
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the va
Original PR description
**Steps to reproduce:** 1- Install Accounting, Fleet modules 2- Create a bill in accounting with a different currency than the company's default, and add a line with a chosen vehicle_id. 3- Go to the chosen vehicle in Fleet module 4- Navigate to the service created for this bill **Current behavior before PR:** If we create a bill for a vehicle using a different currency than the company's default. The fleet service that will be created will be having the company's currency but the value will be the amount in the currency used in the bill **Desired behavior after PR is merged:** We now create the fleet service using the value in debit not the unit price or the price subtotal. opw-3734743 Forward-Port-Of: odoo/enterprise#61427 Forward-Port-Of: odoo/enterprise#57639
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for
Original PR description
Current behavior: When an order is invoided after the session has been closed, a reversed payment is created. This payment is not reconciled correctly with the invoice. This is creating an aged receivable for the partner. Steps to reproduce: - Change the bank payment method to "Identify customer" - Create an order in the PoS and pay with bank and specify a partner - Close the session - Open the session again, and create an invoice for the order - Go to the accounting module and look for the aged receivable report you should see some entries under the partner you selected. - You can also go to the partner form and see that he has some due invoices. opw-3678298 Forward-Port-Of: odoo/enterprise#61321 Forward-Port-Of: odoo/enterprise#60248
Current behavior: When you add too much internal notes to an order line, the preparation display will not display them correctly. And the notes will be undreadable. Steps to reproduce: - Open PoS restaurant - Add a product to the order - Add some internal notes on the line (4-5 notes) - Go in the backend and open the preparation display linked to the PoS you just used - You will see the notes, but they are overlapping eachother and are undreadable Before the fix  - Go in the backend and open the preparation display linked to the PoS you just used - You will see the notes, but they are overlapping eachother and are undreadable Before the fix  After the fix:  opw-3878256 Forward-Port-Of: odoo/enterprise#61224
This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release. Avatax has different endpoints for submitting and cancelling service invoices. These two endpoints have fairly similar payloads so various overrides were made to remove/add information from the goods payloads to make them compatible with the service endpoints. A new account.external.tax.mixin l10n_br_is_service_transaction field i
Original PR description
This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release. Avatax has different endpoints for…
This adds tax calculation and EDI support for service transactions. All new functionality was added in new modules because this is taking place in a stable release. Avatax has different endpoints for submitting and cancelling service invoices. These two endpoints have fairly similar payloads so various overrides were made to remove/add information from the goods payloads to make them compatible with the service endpoints. A new account.external.tax.mixin l10n_br_is_service_transaction field is used to determine whether to follow the old, existing goods flow or go through the new service flow. The biggest difference is that service invoices go through an extra, asynchronous validation step. To achieve this, invoices that are successfully submitted end up in a new "pending" state. After this, their status can be checked with button_l10n_br_edi_get_service_invoice(). This function is also called periodically with a cron. In master, these modules will be merged into the already existing modules and deleted. task-3660574 Forward-Port-Of: odoo/enterprise#61413 Forward-Port-Of: odoo/enterprise#57868
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the vendor document had to be adapted while keeping the result the same. This test helps in making sure nothing went wrong. The reason was that the electronic invoice and vendor document share some common code / logic but the shared parts had to be changed for an update to the electronic invoice
Original PR description
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the…
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the vendor document had to be adapted while keeping the result the same. This test helps in making sure nothing went wrong. The reason was that the electronic invoice and vendor document share some common code / logic but the shared parts had to be changed for an update to the electronic invoice spec (Anexo 1.9). (See the next commit for details) ### [FIX] l10n_co_edi: update for anexo 1.9 The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This commit updates the electronic invoice to meet the new spec A bit part of the new spec is the conversion of many fields from document to company currency / COP. There is also a vendor document. But it follows a different spec. Thus some shared logic / section with the electronic invoice was updated so that the vendor document remains unchanged. The following sections were removed since they are obsolete and also (basically) dead code: * OVT section: dead code * FE1 section: content is dead code Previously when creating a credit note from an invoice with the reversal wizard (account.move.reversal) there was the following bug. The Credit Note Concept (l10n_co_edi_description_code_credit on account.move) was set after posting. This was corrected in this commit (since a validation on post was added to check that the concept is there). ### task task-3639271 ### related PRs forward-port of https://github.com/odoo/enterprise/pull/54086 (15.0) https://github.com/odoo/enterprise/pull/55268 (16.0) https://github.com/odoo/enterprise/pull/55274 (saas-16.3) https://github.com/odoo/enterprise/pull/55279 (17.0) https://github.com/odoo/enterprise/pull/55280 (17.1) Forward-Port-Of: odoo/enterprise#61145
Runbot-56122 Forward-Port-Of: odoo/enterprise#61468
Original PR description
Runbot-56122 Forward-Port-Of: odoo/enterprise#61468
Purpose: -------- Add a button in the front end view that allows users to end the current booking (to make the room appear as free), as the only way to do it for now is to delete the booking, which is not suitable if one would like to track the bookings in the backend view. The "book now" button is reworded to "start now" and the "schedule booking" button to "Add a booking" because it was observed that users were sometimes confused with these two buttons. The "booked room" icon has be
Original PR description
Purpose: -------- Add a button in the front end view that allows users to end the current booking (to make the room appear as free), as the only way to do it for now is to delete the booking, which is not suitable if one would like to track the bookings in the backend view. The "book now" button is reworded to "start now" and the "schedule booking" button to "Add a booking" because it was observed that users were sometimes confused with these two buttons. The "booked room" icon has been changed to not use the same as in the new "end booking "button. Colors of the buttons have been updated. The remaining time is now centered vertically in all display formats (it was not always the case). Task-3792497 Forward-Port-Of: odoo/enterprise#61421 Forward-Port-Of: odoo/enterprise#61300
## Pull Request HOOT (PROOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10:
Original PR description
## Pull Request HOOT (PROOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4:…
## Pull Request HOOT (PROOT) - part 15 Part 1: https://github.com/odoo/odoo/pull/152930 Part 2: https://github.com/odoo/odoo/pull/153018 Part 3: https://github.com/odoo/odoo/pull/153023 Part 4: https://github.com/odoo/odoo/pull/153203 Part 5: https://github.com/odoo/odoo/pull/153425 Part 6: https://github.com/odoo/odoo/pull/153700 Part 7: https://github.com/odoo/odoo/pull/154054 Part 8: https://github.com/odoo/odoo/pull/154579 Part 9: https://github.com/odoo/odoo/pull/155073 Part 10: https://github.com/odoo/odoo/pull/155639 Part 11: https://github.com/odoo/odoo/pull/156255 / https://github.com/odoo/enterprise/pull/58135 Part 12: https://github.com/odoo/odoo/pull/156869 Part 13: https://github.com/odoo/odoo/pull/158384 / https://github.com/odoo/enterprise/pull/59019 Part 14: https://github.com/odoo/odoo/pull/158916 Community: https://github.com/odoo/odoo/pull/160292 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#59971
We make this module uninstallable until the certification is done. This commit will be reverted later. Forward-Port-Of: odoo/enterprise#50109
Original PR description
We make this module uninstallable until the certification is done. This commit will be reverted later. Forward-Port-Of: odoo/enterprise#50109
The way the chart templates refs work had changed in 16.2, but this test was never adapted (it never ran before as the needed environment variables were not set on runbot... They are now and this raises an error). Forward-Port-Of: odoo/enterprise#61385
Original PR description
The way the chart templates refs work had changed in 16.2, but this test was never adapted (it never ran before as the needed environment variables were not set on runbot... They are now and this raises an error). Forward-Port-Of: odoo/enterprise#61385
"here" = "aquí" in Spanish Forward-Port-Of: odoo/enterprise#61474
Original PR description
"here" = "aquí" in Spanish Forward-Port-Of: odoo/enterprise#61474
This should have been done using a bridge module to allow uninstalling SMS but hey. Runbot-27909 Forward-Port-Of: odoo/enterprise#61462
Original PR description
This should have been done using a bridge module to allow uninstalling SMS but hey. Runbot-27909 Forward-Port-Of: odoo/enterprise#61462
### Steps to reproduce 1. Activate "l10n_account_customer_statements" 3. Register payment for a large amount of invoices (6+) to the same customer 4. Tick the Group Payments box 5. Go to the customer's contact 6. Action / Print Customer Statements You should see that most of the information is outside the page ### Cause The whole table has the `text-nowrap` class. opw-3820027 Before: ![Screenshot from 2024-04-15 20-44-47](https://github.com/odoo/enterprise/assets/1731605
Original PR description
### Steps to reproduce 1. Activate "l10n_account_customer_statements" 3. Register payment for a large amount of invoices (6+) to the same customer 4. Tick the Group Payments box 5. Go to the customer's contact 6. Action / Print Customer Statements You should see that most of the information is outside the page ### Cause The whole table has the `text-nowrap` class. opw-3820027 Before:  After:  Forward-Port-Of: odoo/enterprise#60808
Purpose ======= Prevent the horizontal scrolling of the inspector but allow the vertical scrolling for small screen sizes. Specifications ============== Reverting the addition of the "overflow-hidden" class on the documents inspector as it is preventing its horizontal but also its vertical scrolling. On lower screen sizes, a vertical scrolling is needed or else the inspector becomes pratically unusable. related PR: odoo/enterprise#59652 Task-3884149 Forward-Port-Of: odoo/enterprise
Original PR description
Purpose ======= Prevent the horizontal scrolling of the inspector but allow the vertical scrolling for small screen sizes. Specifications ============== Reverting the addition of the "overflow-hidden" class on the documents inspector as it is preventing its horizontal but also its vertical scrolling. On lower screen sizes, a vertical scrolling is needed or else the inspector becomes pratically unusable. related PR: odoo/enterprise#59652 Task-3884149 Forward-Port-Of: odoo/enterprise#61399 Forward-Port-Of: odoo/enterprise#61220
Odoo now includes a complete localization package for Rwanda, enabling businesses operating in Rwanda to use the system with local compliance. This package includes the chart of accounts, tax configurations, tax reporting, fiscal positions, and default settings tailored to Rwandan accounting standards.
Original PR description
Add the basic package to the Rwanda localisation. -COA -Taxes -Default settings -Tax report -Fiscal position task-3584127 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Enhancements to existing features
A helpful tooltip has been added to the 'Withhold Agent Number' field in Ecuador's accounting settings to clarify its purpose and usage. This improvement addresses user confusion and support issues by providing clear guidance directly in the system, enhancing the overall user experience for Ecuadorian businesses using Odoo.
Original PR description
Adding tooltip to Withhold Agent for l10n_ec localization in accounting settings under Ecuadorian Localization Reason is to give the user tip about what this field actually hold and enhance the user experience as some users raising some issues because of the lack of knowing this field Task [link](https://www.odoo.com/web#model=project.task&id=3819108) Task-3819108
The UNSPSC (United Nations Standard Products and Services Code) list has been updated to include previously missing product codes. This ensures that the product classification system is more complete and accurate, allowing better product categorization and compliance with international standards.
Original PR description
Some codes in UNSPSC list were reported as missing, updated missing codes and added them to our list. Task Id: 3871714
The BACS payment module will now automatically install and activate for UK-based databases. This ensures that UK companies have the necessary payment processing capabilities enabled by default, eliminating the need for manual setup and reducing configuration time.
Original PR description
[IMP] account_bacs: auto install bacs for uk db auto install bacs for uk db by depending on l10n_uk module and auto_install it when it's in-place for uk Reason: It should be in-place for uk databases Task-3880681
This update improves the German accounting export functionality by adding document metadata file support for DateV integration. The enhancement enables better correspondence tracking between accounting entries and their attachments through new file and identifier mechanisms, improving compliance with German accounting standards and DateV platform requirements.
Original PR description
To make correspondences between accounting entries and attachments, we need a new file and guid for the entries. Documentation can be found at https://developer.datev.de/datev/platform/en/node/6344 task-3888995 Forward-Port-Of: odoo/enterprise#61481 Forward-Port-Of: odoo/enterprise#61378
This update improves how taxes are calculated and displayed on Mexican electronic invoices (EDI documents). The system now properly includes tax information in the base line items, ensuring more accurate and compliant tax reporting for Mexican businesses using Odoo.
This update separates warning message handling into a dedicated function, making it easier for developers to customize and translate field-related warnings. This improvement enhances the flexibility of the core system for localization and customization purposes.
Original PR description
**In this pr, i want separate the warning into a separate function so that developers can easily customize the translation of the related field** --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update brings the Colombian electronic invoice system into compliance with the new Anexo 1.9 specification, which requires converting invoice amounts to Colombian Pesos (COP). The changes also fix a bug where credit note concepts were being set after posting instead of before, and add test coverage for vendor documents to ensure quality.
Original PR description
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the…
### [FIX] l10n_co_edi: add a test for the vendor document Previously there was no test for the vendor document. This commit adds a (simple) test.c In the next commit of the same PR the code for the vendor document had to be adapted while keeping the result the same. This test helps in making sure nothing went wrong. The reason was that the electronic invoice and vendor document share some common code / logic but the shared parts had to be changed for an update to the electronic invoice spec (Anexo 1.9). (See the next commit for details) ### [FIX] l10n_co_edi: update for anexo 1.9 The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This commit updates the electronic invoice to meet the new spec A bit part of the new spec is the conversion of many fields from document to company currency / COP. There is also a vendor document. But it follows a different spec. Thus some shared logic / section with the electronic invoice was updated so that the vendor document remains unchanged. The following sections were removed since they are obsolete and also (basically) dead code: * OVT section: dead code * FE1 section: content is dead code Previously when creating a credit note from an invoice with the reversal wizard (account.move.reversal) there was the following bug. The Credit Note Concept (l10n_co_edi_description_code_credit on account.move) was set after posting. This was corrected in this commit (since a validation on post was added to check that the concept is there). ### task task-3639271 ### related PRs forward-port of https://github.com/odoo/enterprise/pull/54086 (15.0) https://github.com/odoo/enterprise/pull/55268 (16.0) https://github.com/odoo/enterprise/pull/55274 (saas-16.3)
This update improves how Odoo handles invoice cancellations with Mexico's SAT (tax authority). Previously, invoices would be marked as cancelled even if the SAT rejected the cancellation request. Now the system properly tracks cancellation requests separately and automatically handles cases where the SAT cancels documents directly, ensuring the invoice status accurately reflects the SAT's approval or rejection of cancellation requests.
Original PR description
Case 1: The user can cancel the document directly from the SAT. In that case, in odoo, the user needs to "Request Cancel" first even if the SAT state becomes 'cancelled'. To improve that, this case is now managed by adding a new cancel document automatically on the invoice. Case 2: The user can request a cancellation from the SAT. Currently, the invoice is marked as "cancel" even if the SAT rejects the cancellation. In order to manage that, let's introduce a new document: 'invoice_cancel_requested'.
This fix resolves test failures in the Shop Floor module when running in databases without demo data. The issue occurred because a required setting (group_mrp_routings) was disabled, causing automated tests to fail at their first step. The fix automatically enables this setting during test setup and ensures required test data (an employee named 'Marc Demo') is created when not present.
Original PR description
### Issue: Tours from `tour_shopfloor.js` fail in "No demo" databases. ### Explanation: This is due to the setting `group_mrp_routings` being disabled. When it is enabled, a pop-up appears when…
### Issue: Tours from `tour_shopfloor.js` fail in "No demo" databases. ### Explanation: This is due to the setting `group_mrp_routings` being disabled. When it is enabled, a pop-up appears when entering Shop Floor and the tours take it into account since the setting is enabled with Demo Data. When it is disabled, the pop-up does not appear, and the tests fail at the first step because of it. https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L107 https://github.com/odoo/enterprise/blob/4b34efc77b57562e4c92956c63c8c20e6de53bf0/mrp_workorder/static/src/mrp_display/mrp_display.js#L114-L119 ### Fix: Due to both tests failing for the same reason, the setting will automatically be enabled in `setUpClass`. `test_shop_floor` also needs an employee named 'Marc Demo', adding the creation of the employee for "No demo" databases. https://github.com/odoo/enterprise/blob/74e0f4fec69d6512e213312bf42f3d743f7a27b3/mrp_workorder/static/tests/tours/tour_shopfloor.js#L28-L31 error-60565 error-58036
Fixed an issue where completing a field service task incorrectly updated the delivery quantity for products using milestone-based invoicing. Now, delivery quantities for milestone-based products are only updated when milestones are actually reached, not when tasks are marked as done.
Original PR description
To Reproduce: ============= - create a service Product with **invoicing policy** based on milestones and **create on Order** a task in fsm - create Sale order with this product and confirm it - a task is created, mark the task as done (with the button 'Mark as Done') -> the delivered quantity of the sale order line is updated to 1 Problem: ======== - marking the task as done should not update the delivered quantity of the sale order line of product based on milestones Solution: ========= add condition to check if the product invoicing policy is based on milestones before updating the delivered quantity of the sale order line as it will be done when the milestones are reached opw-3850167
This update fixes technical issues in the appointment scheduling system's gantt view that were preventing it from displaying correctly when multiple resources from different companies are involved. The fix updates outdated code references and improves how the system handles resource assignments and access permissions, making the gantt view more reliable for scheduling appointments.
Original PR description
In [1] we added a domain on appointment actions to prevent a traceback when users visit the gantt appointment views when resources from different companies appear at the same time. However appointment_resource_id was deprecated in favor of appointment_resource_ids in stable since then. `appointment_resource_ids` should now be used in the domain. [1] ab7addece528d887f062e70732f96fde2ed76dca task-3893256
This update fixes a usability issue in the Documents app where the inspector panel was not scrollable on smaller screens, making it difficult or impossible to use. The fix allows vertical scrolling when needed while preventing unwanted horizontal scrolling, ensuring the inspector remains accessible on all device sizes.
Original PR description
Purpose ======= Prevent the horizontal scrolling of the inspector but allow the vertical scrolling for small screen sizes. Specifications ============== Reverting the addition of the "overflow-hidden" class on the documents inspector as it is preventing its horizontal but also its vertical scrolling. On lower screen sizes, a vertical scrolling is needed or else the inspector becomes pratically unusable. related PR: odoo/enterprise#59652 Task-3884149 Forward-Port-Of: odoo/enterprise#61399 Forward-Port-Of: odoo/enterprise#61220
This fix resolves an issue where recurring subscription invoices were not generating pickings (shipments) when the subscription product used a bill of materials with kit type. The fix ensures that pickings are now correctly created for each subscription invoice, allowing orders with kit-based products to be properly fulfilled on an ongoing basis.
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#56121
Fixed an issue where Peruvian invoices were always displaying "RUC" as the customer identification type, regardless of the actual identification type selected (such as DNI). The invoice PDF now correctly shows the identification type that was chosen for each customer.
Original PR description
Problem: For a peruvian company, there is many choices of identification type and when creating an invoice, the identification type is always "RUC" whatever the identification type really is Steps to reproduce: - Install the "contacts" and the "accounting" apps - Add a peruvian company from the settings and set the "fiscal localization" as "Peru" for this company - Create a new contact from Peru and set the "Identification Number" as DNI and fill in the number - Create an invoice for this customer and preview the invoice - You will see written on top right "RUC:" instead of "DNI:" Cause: The identification type shown on the invoice is the default one for the country and then is not updated depending on the selection Solution: Replace the field to the selected one for Peru opw-3846814 Forward-Port-Of: odoo/enterprise#61123
This fix resolves a layout issue in the EU OSS tax report where using multiple column groups caused misalignment between data rows and column headers. The report was displaying too many cells per country line, breaking the visual structure. The fix corrects how column groups are processed to ensure proper alignment with headers.
Original PR description
Before, using a column group on the OSS report broke the layout, as each country line displayed more cells than it should, and they hence mismatched the column headers. This was due to bad management of the column groups: when there was more than one column group, the tax_sums variable contained more than one value, and we were then looping on each column for each tax sum to generate the columns of the country line, which was wrong, since options['columns'] already contained the columns of each column group.
This update corrects how the Gantt view handles grouping when using date and datetime fields. Previously, the system would encounter errors when trying to group by date fields with time granularity options (like grouping by year). The fix ensures these field types are properly recognized and processed without errors.
Original PR description
Issue:
------
The commit[^1] filters groupby in the gantt view according to whether it is a propertie or not.
However, fields of type `date` and `datetime` use `:` to refer to the granularity (example `check_in:year`).
To avoid const { type } = metaData.fields[fieldName:granularity]; to trigger an error, it is therefore necessary
to adapt the diff of commit[^1].
opw-3893042
[^1]: https://github.com/odoo/enterprise/commit/6ee5fe8220d692173187402a7361f77883dca921This update corrects the Spanish translation of a link text in the Peru EDI module from "here" to the proper Spanish word "aquí". This ensures that Peruvian users see accurate, localized text in their interface when using the electronic invoicing features.
Original PR description
"here" = "aquí" in Spanish Forward-Port-Of: odoo/enterprise#61474
This fix corrects a module installation issue in the Dutch tax reporting system (ICP part). A previous update accidentally referenced the wrong module name, preventing the feature from working properly. This change ensures the correct module is installed so Dutch companies can properly handle their tax reporting requirements.
Original PR description
The commit https://github.com/odoo/enterprise/commit/cf61f05e78e40f03f4d1d4ba2692b8b5426759cc forgot to change the name of the module that needs to be installed to make the feature work correctly for the ICP part. Forward-Port-Of: odoo/enterprise#61470
Fixed an issue where comments entered during Belgian tax closing were not appearing in the generated VAT XML export files. Users can now see their comments properly reflected in the XML output, improving record-keeping and compliance documentation for Belgian tax reporting.
Original PR description
When generating VAT XML by posting a tax closing entry, the `<ns2:Comment>` tag in the ML is empty despite specifying a comment during the closing process. ### Steps to reproduce 1. Install `l10n_be_reports_post_wizard`. 2. Switch to a Belgian company. 3. Open the tax report. 4. Create a tax closing. 5. Post the tax closing, ensuring a comment is defined in the appearing wizard. 6. Review the generated XML file. Expected behavior: The `<ns2:Comment>` tag in the XML should display the comment entered during the tax closing. Actual behavior: The `<ns2:Comment>` tag is found to be empty. opw-3859928 Forward-Port-Of: odoo/enterprise#60917
This update fixes a broken test in the Dutch tax reporting module that was failing due to changes in how chart templates work. The test wasn't running before because required environment variables weren't configured, but now that they are enabled, the test needed to be updated to work with the current system.
Original PR description
The way the chart templates refs work had changed in 16.2, but this test was never adapted (it never ran before as the needed environment variables were not set on runbot... They are now and this raises an error). Forward-Port-Of: odoo/enterprise#61385
Odoo has updated its Colombian electronic invoicing system to comply with the new Anexo 1.9 specification. This fix updates the base Colombian localization module with necessary changes to support the new electronic invoice format requirements, ensuring your invoices remain compliant with Colombian tax regulations.
Original PR description
The spec for electronic invoices in Colombia was updated and is now known as Anexo 1.9. This was done in the related enterprise PR (module l10n_co_edi). This commit introduces some changes in the base module that are needed for the Anexo 1.9 update. task-3639271 ### related PRs FW-port of https://github.com/odoo/odoo/pull/148953 (15.0) https://github.com/odoo/odoo/pull/151407 (16.0) https://github.com/odoo/odoo/pull/151418 (saas-16.3)
Fixed a display issue where miscellaneous operations amounts were shown in the wrong currency on the bank journal dashboard. When a bank journal uses a different currency than the company's main currency, the miscellaneous operations amount will no longer be displayed to avoid showing incorrect converted amounts. Users will still see the "Misc. Operations" label so they know there are unlinked journal entries.
Original PR description
Steps: ------ 1. Have accounting installed. 2. Have a bank journal with a currency different from company's currency, use a bank account with no currency set for this bank journal. 3. Make a misc operation in the bank account used by the journal. 4. On the dashboard, the "Misc. Operations" amount will not be converted to the journal's currency, even though the currency's symbol is correct, the amount is in the company's currency. Fix --- Do not show the total amount of misc operations if the bank journal and bank journal's bank account currencies are not matching. The user still knows there are journal entries not linked to a bank transaction thanks to the "misc operations" text, but we avoid doing a currency conversion that may not make sense. **opw-3767010**
Fixed a crash that occurred when processing payments with currency exchange differences if the exchange difference journal wasn't configured. Now users receive a clear error message instructing them to set up the required journal, preventing system failures and improving the payment experience.
Original PR description
The issue: when you make a payment and there is an exchange difference, since the post exchange difference is not set, it will throw a traceback To reproduce: - Enable 2 currencies - Have the exchange difference journal set to NULL (empty) - Create an invoice with a different currency than the one set for the company - then register a payment. The fix: Throw a user error indicating to set the post exchange difference journal opw-3783917 opw-3768202
Odoo has been updated to support Indonesia's new VAT tax ID regulation, which now requires 16 digits instead of 15 by adding a leading zero. The system automatically removes the leading zero to validate tax IDs correctly under the new regulation, ensuring Indonesian businesses can continue using the tax validation feature without manual adjustments.
Original PR description
The issue: Currently, in Indonesia, the regulation for tax ID is 15 digits. But a new regulation is coming where Tax ID is now 16 digits by adding 0 in front The fix: Remove the first zero and leave the rest for the _run_vat_test function Related PR: odoo/odoo#146111 opw-3782636
This update fixes several data consistency issues with how binary and image files are stored and retrieved in the system. The changes ensure that when users upload or modify binary files (like images), the system correctly stores and displays the actual file content rather than incorrect cached versions. This is particularly important for features like web-based file saving and image resizing.
Original PR description
#### [FIX] core: add invalidation of Environment's _cache_key. Changing the environment in method create() to force bin_size=False looks harmless, but it actually breaks many tests, in particular in…
#### [FIX] core: add invalidation of Environment's _cache_key. Changing the environment in method create() to force bin_size=False looks harmless, but it actually breaks many tests, in particular in module account. The reason is that company_dependent fields are read at the wrong place in the cache. And this is because `env._cache_key` can be polluted with old data. Make sure that `_cache_key` is cleared when resetting all the lazy properties on the environment. Only the change in res_user.py makes it work, but let's not tempt the devil. Side note: I hate caches. #### [FIX] test_new_api: test's change that already works Add some test cases, and also remove useless flush/invalidate. #### [FIX] core: fix create/write on binary fields When invoking create() or write() with a binary field, the cache of the field was incorrect if bin_size=True was in context. Force context with bin_size=False when putting a binary value in cache. It is particularly important to have coherent values in the cache for `web_save`. Also, because an environment with bin_size=False won't return the same context cache key as one with bin_size=None, it leads to have a cache inconstistency when we write with bin_size=False. Change Environment method cache_key() to return the same cache key when bin_size is absent, bin_size=None or bin_size=False. Tests on binary fields have been updated to not rely on flush and invalidate. We also created specific tests for the binary write() path. #### [FIX] core: cache inconsistency when assigning related resized image field After writing or creating on a related Image field, its cache contains the full-size image instead of the resized one (according to its attributes max_width and max_height). Fix it by re-setting the the resized image on the cache at the end of the inverse method. #### [FIX] core: flush non-attachment binary field when necessary Non-attachment binary field needs to be flushed before reading their size, since the latter relies on the database's binary size function. #### [FIX] core: fix no-attachment binary for web_save When bin_size=True is in the context, the computed no-attachment binary was incorrectly saved to the database. The row is updated with the size of the binary instead of the value itself (check compute_value() + cache.set). Fix this problem by avoiding setting the cache of the bin_size value as dirty. Moreover, the binary size is computed with `pg_size_pretty` for the no-attachment binary fields. Also, in compute_value() we called b64decode on the value that was previously encoded in base64 by _compute_datas(). But in our case, we never use _compute_datas() because it is not stored as an attachment. Then b64decode() doesn't make sense in this case. These 2 bugs are now covered by testing web_save(), where cache consistency is required. It was first reported for this method. First proposal: https://github.com/odoo/odoo/pull/156673
When requesting time off for multiple employees, the system was incorrectly filtering available time off types based on the current user's allocations instead of the selected employees' allocations. This fix ensures that time off types are properly filtered based on the actual employees selected in the request, preventing unavailable time off types from appearing in the search results.
Original PR description
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time…
Currently, when requesting time off for multiple employees, the search for the leave type correspond to the search of the current user. Steps to reproduce: ------------------- * Go to the **Time Off** app * Select **Configuration** > **Time Off Type** * Create a new time off type * Approval: By Employee's Approver and Time Off Oficcer * Requires allocation: Yes * Employee Requests: Extra Days Requests Allowed * Approval: Approved by Time Off Officer * Notified Time off officer: Mitchell Admin * Select **Management** > **Allocations** * Create a new allocation * Employees: Mitchell Admin * Time off time: The one created previously * Validate the allocation * Select **Management** > **Time Off** * create a new time off * Employees: Any Employee A & Employee B * Time off type: > Observation: The new time off time is present in the name search while both employees don't have any allocation for it. Why the fix: ------------ The name search searches for time off type with ``` ['|', ['requires_allocation', '=', 'no'], '&', ['has_valid_allocation', '=', True], '&', ['max_leaves', '>', '0'], '|', ['allows_negative', '=', True], '&', ['virtual_remaining_leaves', '>', 0], ['allows_negative', '=', False]] ``` By configuration, the time off has `requires_allocation = yes` therefore it shouldn't appear here and it does not -> ok `has_valid_allocation` has a search method `_search_valid` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L109-L138 `max_leaves` has a search method `_search_max_leaves` https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_leave_type.py#L165-L192 Both use the function `_get_contextual_employee` to make their search. https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/hr_holidays/models/hr_employee.py#L386-L388 When there are more than one employee selected on the hr leave form, the context contains `employee_id: False`. Thus here we are making the search using the current user, which is Mitchell Admin. The search shouldn't be made using the current user in this case since he doesn't correspond to any of the employees we added of the form. opw-3816442
This fix resolves an issue where analytic plan applicability rules were not being applied when the company field was left empty. Now, applicability rules without a specific company assignment will correctly apply to all companies in the system, with a lower priority than company-specific rules. This ensures more flexible and consistent analytic planning across multi-company environments.
Original PR description
If you create an applicability and remove the company field, they are never used. An applicability like this should be valid for all companies. We put a 0.5 value for the company field so an applicability so it has a lesser priority than other fields. Same idea as the distribution models. opw-3847415 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update improves access control for email templates by allowing users to manage templates they are assigned to. Previously, users could not update, read, or delete templates even when assigned as responsible parties. This change aligns permissions with the new user assignment feature, making template management more intuitive and efficient.
Original PR description
Since the introduction of `user_id` field, it makes sense to allow those users to update/read/delete templates they have been assigned to. task-3748816 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
This update enhances the French Point of Sale certification module by adding detailed logging of hash string data. This makes it easier for support teams to investigate and troubleshoot issues when they occur. Additionally, a fix prevents accidental duplication of POS orders when managed from the backend system.
Original PR description
This commit add the logging of hash string data. By printing the string to hash, it becomes easier to investigate issues. opw-3839287 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where subscription products with kit-type bills of materials (BOMs) were not generating pickings after the first invoice. When a subscription product is invoiced repeatedly, the system now correctly creates the necessary pickings for fulfillment, ensuring smooth order processing for recurring subscriptions.
Original PR description
**Version:** - saas-16.3 **Step to reproduce:** - Create a subscription product with the type set to 'product' - Create a BOM for that product with the BOM type set to 'kit' - In the component, add any product with the type 'product' - Create a sale order with the products that are created and generate an invoice - Upon creating the next invoice for the subscription product, the picking was not being generated. **Issue:** Currently, if the product type is set to 'product' and recurring_invoice is true, and the product has a bill of materials (BOM) with the type 'kit' the picking was not created after the first invoice. **Solution:** If the product has a subscription, the quantity for BOM kits will not be updated. task-3681597 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153173
This fix corrects how the spreadsheet accounting function interprets date periods. Previously, when users entered a month/year (like "02/2024") in a cell and used it in a balance formula, the system would only look at the first day of that month instead of the entire month. Now it correctly processes the full month period, ensuring users see the right financial data when drilling down into account records.
Original PR description
Steps to reproduce:
- in A1, type '02/2024'
- in A2, type '=ODOO.BALANCE("100", A1)'
- right click on A2
- click the menu item "See record" => you end up with wrong records in the list view
The value of A1 is detected as a number (first of february 2024) When that number is given as the argument of ODOO.BALANCE, the number falls back as being interpreted as a single day, instead of a month period.
opw-3872445
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-prThis fix resolves a crash that occurred when users tried to apply the Syscohada accounting template to their company. The Chart of Accounts (COA) is now properly visible in the system settings, preventing errors. Users can only apply the Syscohada template to companies that already have the required COA configured.
Original PR description
The COA should be visible, so existing db won't crash. Indeed, it is used in the Selection field of the config settings. As the field does not exist, the users get an error. We instead don't let a user apply the Syscohada template to a company that does not already have the COA. opw-3893013 opw-3891587 opw-3891028 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where products would disappear from a product block after adding and then removing a product tag filter. Previously, the system couldn't distinguish between "no tags selected" and "empty tag list," causing it to apply an incorrect filter. Now the system properly resets to show the default product set when all tags are removed.
Original PR description
Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product…
Steps to reproduce: ------------------- - create a product tag (eCommerce / Product Tags); - go to a product page and open editor; - edit the page adding a "Products" block; - add the created product tag; - remove it and save; Issue: ------ No products are displayed, whereas without tags, a default product set should be displayed. Cause: ------ At first, when we don't have a tag, the domain determined for the search is `[]`, which returns a list of products. When we add the tag, a domain will be built with the products linked to this tag: `['all_product_tag_ids, 'in', []]` (in the case of the use case above, there will be none). The attribute `data-product-tag-ids="[]"` is added to the dynamic snippet section. Then, when we remove it, we will get the same domain: because the string `"[]"` is valid for the condition that checks whether `productTagIds` exists. As a result, it will no longer be possible to obtain the default set for this block. Solution: --------- Try to reduce the domain to a list in all cases and compare its length. If it is empty, the domain must be an empty domain. opw-3859482 Forward-Port-Of: odoo/odoo#161818
This fix resolves an error that occurred when viewing replenishment information for manufacturing routes with multiple warehouses. The system now correctly identifies the appropriate manufacturing rule instead of failing when multiple rules exist, ensuring users can access replenishment details without encountering errors.
Original PR description
Steps to Reproduce on Runbot: - Install MRP - Create a second warehouse - Go to Warehouse -> Routes -> Manufacturing. - Set the "Supplied Warehouse" to the first warehouse. - In Inventory > Opertaions > Replenishment - Create a new Replenishment with Manufacturing route - click on Replenishment information (small "i" button) - Expected singelton traceback error. Fix: get_lead_time in Manufacturing expects a single rule using _get_rule to determine the correct rule as the comment suggested opw-3838099
Fixed an issue where using the ODOO.BALANCE formula in spreadsheets with an invalid account code would cause an error instead of returning a proper result. The system now correctly handles cases where no matching accounts are found, preventing application crashes and providing better user experience.
Original PR description
Steps to reproduce:
- create an empty spreadsheet
- type in a cell '=ODOO.BALANCE("qsdfqsf", "02/2024")' => #ERROR
There's no account that match the given code.
The account.move.line domain ends up having a clause `('account_id', 'in', [])`
The ORM detects the domain won't match anything and early returns an empty list []
Our code expects a query object and not a list => boom
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163165This update fixes a problem where certain special characters in invoice data would cause errors when generating XML documents for electronic invoicing. The system now automatically removes these invalid characters before creating the XML file, allowing invoices to print successfully without errors.
Original PR description
Steps to reproduce:
[account_edi_ubl_cii]
- create an invoice and set a line with on the control character https://unicode-explorer.com/b/0000
- confirm it
- try to print it
Issue:
Ugly Stack Trace
Cause:
XML does not accept such characters
```
The characters to be escaped are the control characters #x0 to #x1F and #x7F (most of which cannot appear in XML)
[...] XML processors must accept any character in the range specified for Char:
`Char ::= #x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]`
source:https://www.w3.org/TR/xml/
```
opw-3773808
Forward-Port-Of: odoo/odoo#157568This fix resolves an issue where users without administrator access could not create invoices in the Spanish TicketBAI system. Previously, the system would raise permission errors when trying to set up the TicketBAI sequence for the first time. Now, the necessary system operations are performed with appropriate permissions, allowing accountants and other standard users to successfully post invoices and submit them to the Spanish tax agency.
Original PR description
Description of the issue/feature this PR addresses: Spain localization l10n_es_edi_tbai module, sudo on company when creating TicketBAI chain sequence for the first time to avoid raise of access…
Description of the issue/feature this PR addresses: Spain localization l10n_es_edi_tbai module, sudo on company when creating TicketBAI chain sequence for the first time to avoid raise of access security errors without Administration/Settings. Current behavior before PR: When creating the first invoice, TicketBAI chain sequence does not exists therefore it is created, if user does not belong to Administration/Settings group, an access error is raised and invoice is not posted. In the same time, a write operation is done in the company to set the value of the sequence on l10n_es_tbai_chain_sequence_id field, and writing in a company only is allowed for users that belongs to Administration/Settings. Desired behavior after PR is merged: We make a sudo in self (res.company) with a user with account permission but not Administration/Settings, no errors are raised, invoice is posted and TicketBAI XML file is created and posted to the agency. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#162433
This update fixes inconsistent method signatures in the accounting, purchasing, and sales modules to match the parent email notification method. While no actual bugs were reported, this change ensures all modules follow the same API standard, improving code consistency and preventing potential future issues.
Original PR description
Since 3eb96806022705f5b667e149ffa2240760097278, the signature of method `_notify_by_email_prepare_rendering_context` has been changed to provide a default values to `msg_vals` and some overrides were not adapted (or have been added afterwards). No true bug/issue has been found caused by that discrepancy, but for consistency, this commit makes sure those overrides are adapted to provide the same API as the parent method. Fixes #162742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163334
Sales users with admin access in sales but no accounting permissions were unable to view invoices due to overly restrictive access controls on invoice-related data. This fix restores read access to invoice format and document records for users who need to view invoices, while maintaining security controls for portal users.
Original PR description
### Steps to Reproduce 1. Install `sale_management` and `account_edi`. 2. Create a user with admin access in sales but no rights in accounting. 3. Log in as the new user. 4. Navigate to a Sales Order that has been invoiced and attempt to view its invoice via the 'Invoices' stat button. Expected Behavior: The user should be able to view the invoice. Actual Behavior: An access error is encountered when attempting to view the invoice. ### Cause The access error arises due to restricted permissions for `account.edi.format` and `account.edi.document`. Prior to commit 604a47ead80eb8a07102a978f364d82776f69da3, all users had access to these models. However, this commit restricted access solely to users with the `account.group_account_readonly` role, as part of a broader security enhancement to minimize unnecessary access by portal users. opw-3858685 Forward-Port-Of: odoo/odoo#163329
This fix resolves an error that occurred when customers removed all products from their shopping cart after claiming a loyalty discount reward. The system was incorrectly trying to process pricing information on an empty cart, causing the checkout to fail. Now the system properly handles empty carts after discount claims.
Original PR description
Currently, an error is generated when removing all product quantities from the cart after a claiming a reward(discount). Step to produce: - Install a 'website_sale_loyalty' module. - Navigate to the…
Currently, an error is generated when removing all product quantities from the cart after a claiming a reward(discount).
Step to produce:
- Install a 'website_sale_loyalty' module.
- Navigate to the website / eCommerce / Loyalty / Discount & Loyalty to create a record.
- Set the Loyalty Program name and Program Type as 'Loyalty Cards'.(Ensure it's available on sale and the website.)
- And add 'Rewards' and set a Reward Type as 'Discount' which is applied to on Cheapest Product.
- Go to the website shop add any product on a card, Open a cart increase the quantity of the product, and claim the discount reward.
- Again go to Loyalty Program and open Loyalty Card, Open a record and add a Balance(greater than 200 as default reward points are 200) and copy 'Code'.
- Again go to the website shop and apply this code to claim a discount after a claim discount.
- Now remove all product quantity from a cart.
See Traceback:
```
AttributeError: 'bool' object has no attribute 'price_unit'
File "odoo/http.py", line 2252, in __call__
response = request._serve_db()
File "odoo/http.py", line 1828, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1848, in _transactioning
return service_model.retrying(func, env=self.env)
File "odoo/service/model.py", line 134, in retrying
result = func()
File "odoo/http.py", line 1826, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1833, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2058, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale_loyalty/controllers/main.py", line 126, in cart_update_json
return super().cart_update_json(*args, set_qty=set_qty, **kwargs)
File "odoo/http.py", line 740, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/website_sale/controllers/main.py", line 817, in cart_update_json
values = order._cart_update(
File "addons/website_sale_loyalty/models/sale_order.py", line 174, in _cart_update
self._update_programs_and_rewards()
File "addons/website_sale_loyalty/models/sale_order.py", line 60, in _update_programs_and_rewards
return super()._update_programs_and_rewards()
File "addons/sale_loyalty/models/sale_order.py", line 802, in _update_programs_and_rewards
values_list = self._get_reward_line_values(reward, coupon, product=reward_key[3])
File "addons/sale_loyalty_delivery/models/sale_order.py", line 64, in _get_reward_line_values
return super()._get_reward_line_values(reward, coupon, **kwargs)
File "addons/sale_loyalty/models/sale_order.py", line 573, in _get_reward_line_values
return self._get_reward_values_discount(reward, coupon, **kwargs)
File "addons/sale_loyalty/models/sale_order.py", line 321, in _get_reward_values_discount
discountable, discountable_per_tax = self._discountable_cheapest(reward)
File "addons/sale_loyalty/models/sale_order.py", line 211, in _discountable_cheapest
discountable = cheapest_line.price_unit * (1 - (cheapest_line.discount or 0) / 100)
```
The issue occurs when attempting to remove all product quantities from a cart. At this point [1], a bool value 'False' is returned, and the system attempts to get a value of 'price_unit' from it [2].
link [1]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L187-L195
link [2]: https://github.com/odoo/odoo/blob/499056a82db26f7d9caa86314e666e2bd49cc79c/addons/sale_loyalty/models/sale_order.py#L205
This commit resolves the issue, If the _cheapest_line() method returns False then also returns False from _discountable_cheapest(), To raise an error at [3].
link [3]: https://github.com/odoo/odoo/blob/cbc40eccf576c499709f7825edad9a3b3ce7a22d/addons/sale_loyalty/models/sale_order.py#L317-L333
sentry-5119007021
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#163055This fix resolves an issue where validating a delivery order would incorrectly trigger a backorder creation wizard after scrapping items. The system was mistakenly checking scrap moves alongside regular delivery moves, causing a mismatch in pickup status. Now scrap moves are properly excluded from this validation, allowing deliveries to complete smoothly without unnecessary backorder prompts.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”.
- Update its quantity to 10.
- Create a delivery picking:
- Add the product “P1” with 10 units.
- Mark as to do.
- Scrap 1 quantity of “P1”.
- Try to validate the picking.
Problem:
A wizard asking to create a backorder is triggered. This occurs because the move of the scrap is created, linked to the picking, and marked as 'done' (so, picked). Therefore, when validating the picking, we will checks if all the moves are picked (Even if not picked, it will work because we'll set them all to 'picked'). but as the first move is not picked and the scrap one is picked, the backorder wizard is raised.
opw-3821869A test case in the India localization module was incorrectly inheriting from an enterprise class instead of the community version. This fix corrects the inheritance to use the appropriate community class, ensuring tests run properly with the correct codebase.
Original PR description
Before this commit: Accidentally the test case in community inherited class from enterprise After this commit: We inherit the correct class which belongs to community --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where printing the same document multiple times (such as printing the same lot label several times in stock operations) was not working correctly. The system was losing track of duplicate items during the report generation process. This update ensures that reports can properly handle and print multiple copies of the same item.
Original PR description
In stock, you would print multiple times the same lot label. In this scenario, the rendering method get multiple times the same res_id as parameter. However, the code is loosing track of those duplicated ids before all streams are indexed by res_id. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163211 Forward-Port-Of: odoo/odoo#157710
This fix resolves a problem where subcontracting backorders were losing their connection to the original production order when quantities were adjusted during receipt processing. The issue occurred when users manually modified quantities in detailed operations, causing the system to incorrectly link production information to backorders. This fix ensures that production orders remain properly linked throughout the backorder process.
Original PR description
[FIX] mrp_subcontracting: fix origin moves on backorder This commit reverts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and 7a78839ca6cf45ddec7adb59051da132e0ebceb4 The commits above try to…
[FIX] mrp_subcontracting: fix origin moves on backorder This commit reverts commits d4abaafa4757ace22010be49bb1f7ce1c4fbfc0d and 7a78839ca6cf45ddec7adb59051da132e0ebceb4 The commits above try to split the origin moves during a split (backorder). However, if you create a subcontracting backorder by manipulating the stock.move.line qty_done, then it creates an issue were the production_id is not linked to the backorder. HOW TO REPRODUCE: - Create product FNS (storable) - Create subcontracted BoM for FNS - On Operation type 'Receipt', set Show Detailed Operations = True and Pre-fill Detailed Operations = True - Create PO for 10 units of FNS -> Confirm - Go to Receipt > Detailed operation > Set quantity = 1 > Validate (with backorder) - Repeat step above on the created backorder OR - Create storable product FNS tracked by serial number - Create subcontracting BoM, with strict consumption - Create PO for 10 units of FNS -> Confirm - Open detailed operation, add 2 lines with SN, confirm, Validate & create backorder - Redo the same step with backorder receipt --- https://github.com/odoo/odoo/assets/29302288/4c9de2b7-2a65-4e18-8a4b-c9faadf68d17 --- OPW-3838250 OPW-3812937 Forward-Port-Of: odoo/odoo#161323
This fix resolves an issue where invoice line dates were not being synchronized when the main invoice date was changed. Previously, if the system performed a data flush before the line dates were accessed, the line dates would remain outdated. This fix ensures that whenever an invoice date is updated, all associated line dates are automatically recalculated to match.
Original PR description
Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not…
Currently, when the `invoice_date` of an invoice is updated (triggering the recomputation of `date`) and if a system flush occurs before any line's date is accessed, the invoice lines' dates do not get updated. The following test illustrates this issue:
```py
move = self.init_invoice(
move_type='in_invoice',
partner=self.partner_a,
amounts=[1000.0],
)
move.invoice_date = fields.Date.from_string('2024-01-01')
self.env.flush_all()
for line in move.line_ids:
self.assertEqual(line.date, move.date) # will fail
```
### Cause
The `date` of a move is a computed field dependent on the move's `invoice_date`. The `date` of a move line is a related field, pointing to its parent move's `date` (note: related fields are computed fields). During a flush, the system recomputes all fields that need to be. Here, the system first processes 'account.move.date' and calls its computation (`_compute_date`). However, the `_affect_tax_report()` call within `_compute_date` triggers a recalculation of `account.move.line.date`, but as this happens within `_compute_date`, the invoice lines' `date` is recalculated using the old invoice `date`.
### Fix
Force a recalculation of the invoice lines' dates whenever the invoice's date is changed.
opw-3759472
opw-3875405
opw-3872006
opw-3884013
Forward-Port-Of: odoo/odoo#163491
Forward-Port-Of: odoo/odoo#162956This fix ensures that when accounting reports are updated with new grouping options, any incompatible user-selected grouping settings are automatically corrected. This prevents errors that could occur when upgrading the system, ensuring reports display correctly without manual intervention.
Original PR description
When the report is updated and `groupby` is updated, we might need to also update `user_groupby` if it was not compatible. Followup/fix of odoo/odoo@7d54c76aaee325449248fa698adb9e549c486ee For instance upgrading from before to after odoo/enterprise@d226977e19401f9d95b66991a69abebd466ee7e0 was an issue.
This fix corrects an issue where search results in many-to-one fields were not properly filtered according to domain restrictions set in form views. When users clicked "Search more..." on a many-to-one field with a domain filter, they would see all available records instead of only those matching the specified domain. The fix ensures the search dialog correctly applies the form view's domain restrictions.
Original PR description
Steps to reproduce the problem: 1. Add a many2one field to lines of a model, example: sale.order.line 2. Add it to form view of the lines with a domain 3. Click on Search more... option 4. You will…
Steps to reproduce the problem: 1. Add a many2one field to lines of a model, example: sale.order.line 2. Add it to form view of the lines with a domain 3. Click on Search more... option 4. You will see results out of the scope of the domain In the getDomain is passed an object that has only the key fieldName but for knew in what view is the field placed it needs to be provided the key viewType, this both are placed on the class object this.recordParams builded at: https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L129 If this key is not provided the viewType is beeing filled with the element viewType, this element is the record opened placed in the parent view, so by default if will be kanban or list. So if the domain is filled just in the form view, the search panel will get the domain [], so all the entries will be displayed and they will be able to be selected. If we see the next line: https://github.com/odoo/odoo/blob/b8a5175b6c92749bd3bb7b9f869b1ecff78e133f/addons/web/static/src/legacy/js/fields/relational_fields.js#L431 We will see that getContext is getting this.recordParams as argument, for the same reason that the domain should have it. With this changes the getDomain method is getting the viewType to take the domain instead of the viewType of the lines displayed on the parent view. 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#163297 Forward-Port-Of: odoo/odoo#162983
This fix resolves unintended data loss when creating job applicants for existing partners. Previously, phone numbers would be accidentally deleted from partner records. The update now preserves partner phone numbers, automatically pulls phone information from partners to applicants, and prevents unnecessary system updates when email formatting changes without altering the actual email address.
Original PR description
Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse…
Previously, when receiving a new email to create a job applicant for an existing partner, the process would inadvertently erase the phone and mobile numbers on the partner by using the inverse method. With this commit, the behavior is adjusted so that phone numbers are only written in the inverse method on the partner if there is a number present on the applicant. This prevents the inadvertent removal of phone numbers on the partner when creating new applicants for existing partners. Additionally, this commit ensures that phone numbers from the partner are computed on the applicant as if they were related non-stored fields. This avoids the need for manual re-encoding of numbers later and prevents the inverse method from being forced again. Furthermore, to optimize the process, email changes are now only processed using the inverse method if the normalized version of the email is different. This prevents unnecessary method calls on the highly used res.partner model when the email is updated, particularly for cases where the normalized version remains the same. Previously, changing the partner's email from `jke@odoo.com` to `"JKE" jke@odoo.com` would resend all waiting sign requests because the normalized versions of the email were distinct. While ideally, this check could be performed within the sign request code itself, this optimization now helps prevent unnecessary overrides across all modules simultaneously. 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
This fix corrects an error handling issue in the web module's public widgets that was introduced in a recent update. The change restores proper failure handling behavior, ensuring that error messages and notifications display correctly to users when issues occur on public-facing pages.
Original PR description
Commit [1] made a mistake when adapting the `guardedCatch` handler. [1]: https://github.com/odoo/odoo/commit/fcb16a3b1bd373726ffb54f0fbe41fb6d1784769
This update brings the spreadsheet application to the latest version with several important fixes and improvements. The changes address calculation errors, display issues with borders and data validation suggestions, and improve overall performance when handling spreadsheet dependencies. Users will experience more reliable spreadsheet behavior and faster performance.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/065ac988c [REL] 17.0.20 https://github.com/odoo/o-spreadsheet/commit/3046eb22d [FIX] evaluator: Prevent incorrect invalidation of spread Task: 3883954 https://github.com/odoo/o-spreadsheet/commit/d28b9b48a [FIX] borders: wrong borders on remove rows Task: 3884112 https://github.com/odoo/o-spreadsheet/commit/a54fa7fb0 [PERF] evaluation: faster dependencies checking Task: 3874821 https://github.com/odoo/o-spreadsheet/commit/9d7385612 [IMP] helpers: backport recompute zone https://github.com/odoo/o-spreadsheet/commit/17b354804 [FIX] dataValidation: Display suggestions on dv-icon click Task: 3872312 https://github.com/odoo/o-spreadsheet/commit/c917ca566 [FIX] tests: rewrite autocomplete test
This fix resolves an issue where uploading non-image documents (like PDFs) from a URL would fail in the web editor. The system was incorrectly trying to process all file uploads as images, which caused errors when dealing with document files. The fix ensures that only image uploads use the image-specific handling, while other document types use the standard file upload process.
Original PR description
The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported. Original commit message: Since [1] when uploading…
The goal of this commit is to forward port [the original commit] which was introduced in 16.4 but, due to an error, has not been forward ported. Original commit message: Since [1] when uploading images from URL the data is downloaded and then hosted on the Odoo instance. As stated in its task (task-3129360) it should not have been applied to document URLs. Because of this, when hitting a CORS issue to fetch binary data, we try to fetch the data through an `<img>` element by setting its `src` field - which also fails when the data is not an image. This commit makes the changes of [1] specific to image uploads and restores the previous behavior for other files. Steps to reproduce: - Drop a "Text - Image" snippet. - Double-click on the image. - Go to the Documents tab. - Click on "Add URL". - Enter an example PDF URL. E.g.: https://www.africau.edu/images/default/sample.pdf - Click on "Add URL". => Fails because of a CORS issue. [the original commit]: https://github.com/odoo/odoo/commit/238566d1dea29fd11353e7e6529d29843c4f658b [1]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a task-3493618
Fixed an issue where the OCR button was not properly hidden in the Account PEPPOL module. The fix corrects how the system determines when to display the OCR button by adjusting the default state of the extractable field, ensuring the button only appears when appropriate.
Original PR description
`extract_can_show_send_button` is a computed readonly field, providing a default value doesn't do anything. By setting `is_in_extractable_state` to `False` by default, we can hide the ocr button. no task, noticed while fixing a traceback in saas-17.1 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#163524