Daily updates from Odoo
Friday, February 27, 2026
293 changes
20 changes
Resolved issues and error corrections
This update corrects a minor issue in the Attendance module where duplicate field names were appearing in the attendance list view. The changes ensure that the 'in_location' and 'out_location' fields display correctly, preventing confusion for users. This resolves a technical detail that didn't impact core functionality.
Original PR description
Steps to reproduce: -------------------------------------- 1. Install the Attendance module 2. Go to the attendance list view 3. Click on the optional fields tray Observation: -------------------------------------- Duplicate field name Longitude (In) Issue: -------------------------------------- For the `in_location` field, a duplicate string was added in the list view Solution: -------------------------------------- Changed string to `Location (In)` for `in_location` field and changed string to `Location (Out)` for `out_location` field Before: <img width="348" height="511" alt="image" src="https://github.com/user-attachments/assets/109ff380-df4f-4dc6-ad01-a955d85436c7" /> After: <img width="330" height="503" alt="image" src="https://github.com/user-attachments/assets/894e6045-ec34-4296-8aff-f0e7bee32d9f" /> opw-5909500 Forward-Port-Of: odoo/odoo#249404
This update fixes an issue where financial reports were inaccurate due to accounts lacking codes in company mappings. Now, the system automatically finds the correct code for these accounts across other companies, ensuring consolidated reports match expected financial figures. This improves the reliability of our reporting.
Original PR description
Description of the issue this commit addresses: When consolidating reports, any account that doesn't have a code on the consolidating company is filtered out of the consolidation. This will lead to amounts that do not match which should not happen. --- Desired behavior after this commit is merged: When an account should be used but is filtered out because of not having a code in the per company mapping, we try to find its code on any of the other companies he is and use that one as anchor in the consolidation. --- task-5911409 Forward-Port-Of: odoo/enterprise#107651
This update fixes an issue where stock deliveries weren't accurately reflecting the FIFO (First-In, First-Out) inventory valuation method. The previous process didn't properly account for quantities already delivered, leading to incorrect cost calculations. This change ensures that stock valuations align with the FIFO method, improving financial reporting accuracy.
Original PR description
Steps to reproduce: - Have a product valued in fifo - Create 3 PO for it, each for 1 qty of price 10, 20 and 30. - Confirm these PO & validate their receipts - Create 2 SO for this product, each for 1 qty - Confirm these SO & validate their deliveries together Issue: The value associated to the delivery moves (and so the cogs generated from them) is 10 for both. When calling `_action_done()` on the moves, we'll set the value of each move before moving them. To get the correct value from the fifo stack, we rely on the `qty_available` at the time. However, since we're going to set the value of multiple moves before validating them, the `qty_available` won't be updated between each call. opw-5359484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240866 Forward-Port-Of: odoo/odoo#238680
This update fixes a bug in the Swiss payroll calculations, ensuring the employer cost is accurately computed. Previously, the system incorrectly reported a zero employer cost due to a missing flag. This change ensures accurate payroll reporting for Swiss businesses.
Original PR description
The computation of the employer cost in Switzerland was wrong (always 0) because the rules didn't have the appears_on_employee_cost_dashboard flag set and were therefore not counted in the computation of the fiels. Furthermore we modify the override of the function used to compute the values of some fields, to add the correct computation of the employer cost. Task: 5354103 Forward-Port-Of: odoo/enterprise#106839
A technical error prevented managers without appraisal rights from scheduling meetings. This update corrects a flaw in how the system accesses employee information, ensuring managers can now successfully schedule meetings as intended. This resolves a potential disruption to workflow.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127 Forward-Port-Of: odoo/enterprise#106106
This update resolves an issue where creating scrap orders from the shopfloor view resulted in a traceback. The fix reintroduces a necessary method and corrects a display problem that incorrectly prompted users to add lot/serial numbers for non-trackable products like screws. This ensures scrap orders can be created smoothly.
Original PR description
Issue before this commit: ========================= Creating a scrap order from a specific workorder in the shopfloor view raises a traceback: `The method 'mrp.workorder.action_scrap' does not…
Issue before this commit: ========================= Creating a scrap order from a specific workorder in the shopfloor view raises a traceback: `The method 'mrp.workorder.action_scrap' does not exist.` Additionally, in the scrap form view, the `Lot/Serial Numbers field is displayed for non-tracked(e.g. consumables such as screw) products`, incorrectly prompting the user to add a lot/serial number. Steps to Reproduce: ========================= - Install the mrp module. - Create a Manufacturing Order for a product with at least one operation (e.g. Desk Combination). - Open the shopfloor view. - Enter a specific workcenter (e.g. Assembly 1). - Open the three-dot menu and create a scrap order. - Confirm the scrap order. - A traceback is raised. Cause of the issue: ========================= The method action_scrap was removed from mrp.workorder in [this PR](https://github.com/odoo/odoo/pull/210299), However, from the JavaScript side, the scrap option still triggers a call on the mrp.workorder model when the user clicks Scrap in the shopfloor view. With This Commit: ========================= Reintroduce the action_scrap method on mrp.workorder so users can correctly create scrap orders from a specific workcenter in the shopfloor view without triggering a traceback. Fix the visibility condition of lot_ids so the Lot/Serial Numbers field is hidden for non-tracked (consumable) products and is shown only for trackable products (lot/serial). Enterprise PR: https://github.com/odoo/enterprise/pull/108259 Task: 5958933
This update fixes a bug preventing notifications from appearing when scrap orders are created from the shopfloor. Previously, users didn't receive confirmation of the order's creation. Now, users will receive a notification when a scrap order is successfully registered, improving workflow visibility.
Original PR description
Issue before this commit: ========================= Creating a scrap order from the shopfloor does not show any notification after it is created, which was shown in the previous version. Steps to…
Issue before this commit: ========================= Creating a scrap order from the shopfloor does not show any notification after it is created, which was shown in the previous version. Steps to Reproduce: ========================= - Install the mrp_workorder module. - Create a Manufacturing Order for any product (e.g. [FURN_7023] Wood Panel). - Open the shopfloor view. - Click the three-dot menu to access more options. - Create and confirm a scrap order. - No acknowledgement/notification is shown to the user. Cause of the issue: ========================= The method responsible for triggering the notification was renamed in [this PR](https://github.com/odoo/enterprise/pull/85706), but the notification condition was still referring to the old method name. As a result, the notification was never triggered. With This Commit: ========================= Align the method name used in the notification condition so that, when a scrap order is created from the shopfloor, the user correctly receives the notification: `The scrap order has been successfully registered.` Community PR: https://github.com/odoo/odoo/pull/250024 Task: 5958933
This update resolves an issue where checkboxes within product listings weren't updating correctly. The fix involves a change in how clicks are handled, ensuring the checkbox state is accurately toggled. This improves the user experience when managing products.
Original PR description
- Destructure `{ anchor }` from the `run` method arguments instead of using the `this` context.
- Swap `actions.click()` for native `anchor.click()` to ensure the checkbox state is toggled correctly.
runbot-234872
Note: backport of https://github.com/odoo/odoo/commit/6fdc329838ee099524e61eea9698373949881c1e
missed the 19.2 freeze.A recent update to web studio resolved a bug that prevented users from correctly saving approval rules with specific domain filters. The issue stemmed from how the system handled boolean values, leading to an error. This fix ensures that approval rules with domain filters, including those using 'not set', now function as expected.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update resolves an issue preventing the deletion of archived employee versions. Previously, a validation error would occur if an archived version was deleted, even if other active versions existed. Now, archived versions can be safely deleted without triggering this error, streamlining employee record management.
Original PR description
Version – saas-18.4 Issue: Deleting an archived version of an employee that has only a single version raises a `ValidationError` stating: `Employee %s must always have at least one active version.`…
Version – saas-18.4 Issue: Deleting an archived version of an employee that has only a single version raises a `ValidationError` stating: `Employee %s must always have at least one active version.` Steps to Reproduce: - Make an archived version of an employee which have exactly one version. - Try to delete that archived version - Validation Error will occur which states that `Employee %s must always have at least one active version.` Cause: The validation logic prevents deletion when the number of versions being deleted equals the total number of unarchived versions of the employee. Fix: Improved the ValidationError logic by ensuring that no error is raised when the version being deleted is archived. Impact: Archived employee versions can now be deleted without raising unnecessary errors. Task – 5347109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250557 Forward-Port-Of: odoo/odoo#238344
This update fixes an issue where deleting a partially signed offer would incorrectly delete the associated employee. The change ensures the employee record is only deleted when the offer is archived and the employee has no other active offers. This prevents data loss and maintains accurate employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the…
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#108634 Forward-Port-Of: odoo/enterprise#100991
This pull request corrects a minor typo in the Combo Configurator module within the Odoo sale functionality. The fix ensures accurate data typing, preventing potential display issues and improving the overall user experience. This update ensures consistent and reliable configuration within the sales process.
Original PR description
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#249973
This update optimizes how Odoo synchronizes data between its database and IndexedDB, specifically addressing slow synchronization when dealing with large datasets like loyalty cards. This change improves the speed and responsiveness of adding products to the cart in the Point of Sale module, leading to a better user experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250799 Forward-Port-Of: odoo/odoo#241373
This update resolves a potential issue during Odoo database upgrades. Previously, removing a payroll rule could cause upgrade scripts to fail. This change ensures upgrade scripts continue to function correctly even if a rule has been deleted, improving the reliability of database updates.
Original PR description
This method is used in various places, including when upgrading a database. When doing so, it is done in a post upgrade script. If later one of the updated rules is removed, the pre-script removing it will run before the post script trying to update it, causing the migration to fail as the update method tries to browse a falsy value. This updates the `update_properties_definition_domain` method so that it ignores falsy values when browsing, allowing previous upgrade scripts to run even if the referred rule has been since deleted. Forward-Port-Of: odoo/enterprise#102964
This update clarifies the event booking process for existing partners. When booking with a known email, the system now suggests both 'Sign In' and 'Create an Account' options. This ensures partners receive the most relevant guidance, regardless of their portal access, leading to a smoother booking experience.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This update fixes a RecursionError that occurred when producing large quantities of serial-tracked products. The issue stemmed from excessive recordset access during the splitting process of manufacturing orders. This change improves stability and reliability for users managing high-volume production runs.
Original PR description
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture…
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled). - Create a BoM for product A containing product B. - Create a BoM for product B containing product C. - Create a BoM for product C containing another product. - Create a manufacturing order of 100 units for product A and confirm it. - Go to the MO C and split into 100 mo - Go to the MO B and split into 100 mo -> RecursionError: maximum recursion depth exceeded. **Cause** While splitting, this method is called: https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls: https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError. opw-5265424 Forward-Port-Of: odoo/odoo#247839
This update resolves a bug that caused a RecursionError when producing large quantities of serial-tracked products. The issue stemmed from an inefficient calculation process during order splitting, which triggered repeated data processing. This fix ensures stable production runs for high-volume manufacturing.
Original PR description
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture…
**Issue** When producing a large number of serial-tracked products, a RecursionError can occur. **Steps to reproduce** - Create three products tracked by serial number (ensure MTO and Manufacture routes are enabled). - Create a BoM for product A containing product B. - Create a BoM for product B containing product C. - Create a BoM for product C containing another product. - Create a manufacturing order of 100 units for product A and confirm it. - Go to the MO C and split into 100 mo - Go to the MO B and split into 100 mo -> RecursionError: maximum recursion depth exceeded. **Cause** While splitting, this method is called: https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/mrp/models/mrp_production.py#L2031 which ultimately calls: https://github.com/odoo/odoo/blob/cda011dc8590773f6c3a26f4ae9d5242a3147024/addons/stock/models/stock_move.py#L658-L661 This retriggers `_compute_packaging_uom_id` for all moves in `move_orig_ids` or `move_dest_ids`, and accessing the full recordsets causes recursive recomputation leading to a RecursionError. opw-5265424 Forward-Port-Of: odoo/enterprise#106999
This update quietly handles errors that occur during tour termination, specifically 'AssetsLoadingError' which represents lazy-loaded assets. Previously, these errors were flagged, but this change prevents them from disrupting the user experience after the tour is complete. This ensures a smoother experience for users.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#250839 Forward-Port-Of: odoo/odoo#248003
This update eliminates a warning generated during testing of document attachments. The team replaced the use of artificial PDF content with actual sample PDF files from the base code. This ensures consistent and reliable test results without unexpected errors.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update fixes an issue where the VAT Book download was only generating for the primary company. Now, when multiple branches with the same CUIT are selected, the VAT Book will correctly include data for all related branches. This ensures accurate tax reporting for businesses with multiple Argentinian branches.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#108466
Forward-Port-Of: odoo/enterprise#10189821 changes
Resolved issues and error corrections
A bug was preventing users from correctly saving approval rules within the web_studio interface. This was due to a mismatch in how boolean values were represented between Python and JavaScript. The update corrects this by using the appropriate method to convert Domain objects to strings, ensuring approval rules are saved reliably.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update fixes an error in the UAE Payroll localization module that incorrectly calculated pay rates for employees on attendance-based contracts. Previously, rates were based on actual work hours, but now they accurately reflect the planned working schedule, ensuring correct payroll processing for this contract type.
Original PR description
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry…
Step to Reproduce: - install UAE Payroll localization and attendance - create employee and running employee contract and give basic salary, housing, transportation and other allowance. - work entry source should be attendance - create a payslip and compute sheet. Issue: - The values for payslip lines are not as expected. - The rate per hour for basic salary , housing, transportation and other allowances was being calculated based on employee's attendance work entries, not the planned working schedule. Reason: - When using attendance-based contracts, the hourly rates for basic salary, housing, transportation, and other allowances should be calculated based on the working schedule's hours per day, if a working schedule is available. Solution: - Instead of sum_worked_hours which takes working hours of employee's work entries, use total_number_of_days multiplied by the hours per day from the working schedule. task-5270185 Forward-Port-Of: odoo/enterprise#108637 Forward-Port-Of: odoo/enterprise#103282
This update fixes an issue preventing the deletion of archived employee versions. Previously, a validation error would occur if an archived version was deleted, even if other active versions existed. Now, archived versions can be safely deleted without causing errors, streamlining employee record management.
Original PR description
Version – saas-18.4 Issue: Deleting an archived version of an employee that has only a single version raises a `ValidationError` stating: `Employee %s must always have at least one active version.`…
Version – saas-18.4 Issue: Deleting an archived version of an employee that has only a single version raises a `ValidationError` stating: `Employee %s must always have at least one active version.` Steps to Reproduce: - Make an archived version of an employee which have exactly one version. - Try to delete that archived version - Validation Error will occur which states that `Employee %s must always have at least one active version.` Cause: The validation logic prevents deletion when the number of versions being deleted equals the total number of unarchived versions of the employee. Fix: Improved the ValidationError logic by ensuring that no error is raised when the version being deleted is archived. Impact: Archived employee versions can now be deleted without raising unnecessary errors. Task – 5347109 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250557 Forward-Port-Of: odoo/odoo#238344
This update fixes an issue where deleting a partially signed offer would incorrectly delete the associated employee. The fix ensures the employee record remains intact unless the offer is fully archived and the employee has no other active offers. This prevents data loss and maintains accurate employee records.
Original PR description
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the…
Version – saas-18.4 ### Issue: When an applicant has both a partially signed offer and a fully signed offer, deleting the partially signed one also deletes the employee that was created from the fully signed offer. ### Steps to Reproduce: - Create two offers for an applicant. - Fully sign the first offer and partially sign the second one. - Delete the partially signed offer. The employee created from the fully signed offer is also deleted. ### Cause: Due to this issue, the employee record is incorrectly deleted from the system, which is not expected behavior. ### Fix: Improved the employee deletion logic by deleting the employee only when: - the employee is archived, and - they do not have any other offers besides the one being deleted. ### Impact: The employee will no longer be deleted when another partially signed offer for the same applicant is removed. --- Task – 5347109 Forward-Port-Of: odoo/enterprise#108634 Forward-Port-Of: odoo/enterprise#100991
This update ensures overtime calculations are correct when creating or modifying time off requests. Specifically, the system now automatically recomputes overtime when a time off record is created or changed, even if an existing attendance record exists, improving the accuracy of payroll processing.
Original PR description
If you don't have time off app, the option Timing - when Employee is off, should not be available. Creating a time off on a day when there is already an attendance record should automatically recompute the overtime if this rule is on the employee. Forward-Port-Of: odoo/odoo#240940
This pull request corrects a minor typo in the Combo Configurator module, which ensures consistent and accurate display of product information. This resolves a potential confusion for sales staff and customers, improving the overall user experience. The fix was made to maintain data integrity and a professional presentation.
Original PR description
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#249973
This update fixes an issue where dependent salary rules weren't appearing in the employee input selection. The change ensures that all relevant rules, including dependent ones, are displayed when adding inputs, streamlining payroll configuration for users. This prevents errors and ensures accurate payroll calculations.
Original PR description
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the…
Problem ------------------ The salary inputs selection widget only displays the main salary rule, not the dependent rules, so when a new dependent rule is created after the main one was added to the employee form, it is not possible to select the the new rule to display. Navigation: 1. Payroll > Configuration > Rules > New > Condition Based On: Salary Input > Input On: Employee > Save 2. Employees > Select Employee > Payroll > Add Inputs > Select Rule > Save 3. Configuration > Rules > New > Condition Based on: Salary Input > Input On: Employee > Depends On: Previous Rule > Save 4. Employees > Select Employee > Payroll > Add Inputs > New Rule is not available Objective ---------------------- Version 19.0 doesn't filter out existing rules, so it is possible to select the prerequisite rule again and add the new dependent rule, but later commits changed the search domain to filter out inputs that were already selected. Some of the changes should probably have been included in the 19.0 version. Need to back port the changes and edit the search domain to show dependent rules that have not been selected yet. Solution --------------------------- Option B from the task specifications to show the dependent salary rules when "Add Inputs" is clicked if it's not already displayed even if the prerequisite rule is displayed. Edited the payroll structure search domain to find rules that are not displayed and either do not have prerequisites OR have a prerequisite that is already displayed. Task: 5942461 Forward-Port-Of: odoo/enterprise#107719
This update optimizes how Odoo's Point of Sale system synchronizes data using IndexedDB. Previously, large datasets like loyalty cards could cause slow synchronization, leading to delays when adding items to a customer's cart. This change significantly improves the speed and responsiveness of the Point of Sale experience.
Original PR description
Before this commit, if a model had a large number of records, for example, loyalty card, the synchronization of IndexedDB could be slow, leading to performance issues when adding products to the cart. opw-5232087 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250799 Forward-Port-Of: odoo/odoo#241373
This update resolves a bug where work entries weren't being generated when multiple resource calendar attendances were close together in time. The fix prevents attendances from being incorrectly combined, ensuring accurate work entry creation for employees. This improves the reliability of payroll and time tracking.
Original PR description
When you have two resource calendar attendances that are stuck together, and you generate work entries, the second one doesn't appear: Bug is caused when having two attendances stuck together: In a resource.calendar, change the time of a resource.calendar.attendance to finish at 15.36 and create a new one that begins at 15.36 and finished at 16.36 with a work entry type of Credit time. Go and regenerate work entries and you can see that no work entries are generated for credit time. Fixed by adding keep_distinct in an interval to not fuse them together. Also added extra checks to another test to not pass with incorrect values. task-5894994 Forward-Port-Of: odoo/enterprise#105981
This update clarifies the event booking process for existing partners. When booking with a known email, the system now suggests both 'Sign In' and 'Create an Account' options. This ensures partners are guided to the most appropriate action, regardless of their portal access, improving the overall booking experience.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This update resolves an issue where the correct currency wasn't consistently applied when transferring CODA transactions between multiple journals with the same IBAN but different currencies. The fix ensures that transactions are accurately routed to the appropriate journal based on its currency, improving financial reporting accuracy. This was a critical fix impacting multi-currency accounting.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update resolves an issue preventing the SAF-T report from correctly displaying supplier names for fixed assets. The fix ensures that the report accurately identifies suppliers by incorporating depreciation lines alongside journal entries, addressing a discrepancy caused by bills being posted in a previous month.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#108734 Forward-Port-Of: odoo/enterprise#105987
This update resolves an issue where AVCO valuations were incorrectly defaulting to a product's initial price when stock move dates were earlier than the product's creation date. The fix ensures that actual stock movements always take precedence in AVCO calculations, providing more accurate inventory valuation.
Original PR description
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps…
**Issue**: If the date of some stock moves is anterior to the creation date of the product in the database, the associated valuation is replaced by the initial standard price of the product. **Steps to reproduce**: - Create a new product with a standard price of 0 and AVCO cost method - Create a PO for that product with a unit cost of 1,000,000, confirm it and validate the receipt - Go to Accounting > Review > Inventory > Inventory Valuation -> Observe that the valuation correctly takes the purchase into account - Go back to the receipt, unlock it and change the effective date to one week in the past - Go back to Inventory Valuation -> Observe that the valuation no longer takes the purchase into account - Change the valuation date to yesterday -> Observe that the valuation takes it into account again **Cause**: When a product is created, a `product.value` record is instantiated with today’s date: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L174 https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L202 In the AVCO computation, a manually set product value (`product.value`) takes precedence over move values when it is anterior, either here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L309-L312 or here: https://github.com/odoo/odoo/blob/bbaf38aa99143be4679cf951c5c0f1a1c8ecf716/addons/stock_account/models/product.py#L334-L338 Since the stock move date is set one week in the past, the initial product value (0.0) takes precedence over the move valuation. When the valuation date is moved forward to yesterday, this initial product value is ignored and the move value is correctly applied again. **Solution**: Setting the initial `product.value` date to the product creation date is arbitrary, as it makes inventory valuation depend on when the product was encoded rather than on real stock history. Instead, set the date of the first `product.value` to the earliest possible epoch, ensuring that any real stock move always takes precedence in AVCO valuation. opw-5882080 Forward-Port-Of: odoo/odoo#247407
This update fixes an issue where salary inputs configured for employees weren't appearing on their payslips. The fix ensures that any salary input enabled for a payslip is now correctly reflected, providing a more complete view of employee compensation. This improves data accuracy and reporting.
Original PR description
### Issue: When a salary input is already configured at the employee level and later enabled for payslip , it does not appear on the payslip. ### Fix: Fixed the domain to show the salary input in the payslip. ### Impact: Now the salary input if enabled for payslip can also be viewed in the payslip. --- task:5951414
This update quietly handles errors that occur during tour termination, specifically 'AssetsLoadingError', which represents lazy-loaded assets. Previously, these errors were handled differently, and this change ensures a smoother experience by consistently ignoring these types of failed requests after a tour ends. This improves stability and prevents minor errors from disrupting the user experience.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#250839 Forward-Port-Of: odoo/odoo#248003
This update fixes an error in how holiday pay recovery is calculated for employees in Belgium with non-standard working schedules. Previously, the calculation used a default 38-hour week, leading to inaccurate deductions. The fix now uses the employee's actual weekly hours, ensuring correct holiday pay recovery amounts are applied.
Original PR description
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount…
**Steps to Reproduce:** 1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee 3 - Set 2000 euros in recovery amount holiday n-1 4 - Set 10 days in recovery day holiday n-1 5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February and validate it 7 - Do one payslip for this employee for December Current behaviour : - the holiday n-1 amount for February = 824.80 - the holiday n-1 amount for December = 742.32 Expected behaviour : - the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80 **Reason** - The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules. **Solution** - Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied. Forward-Port-Of: odoo/enterprise#108784 Forward-Port-Of: odoo/enterprise#106205
This update resolves a warning generated during testing related to fake PDF content. The team replaced the problematic 'fake PDF content' with actual sample PDF files from the base directory, ensuring consistent and reliable test results. This improves the stability of the testing process.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update enhances the accuracy of payment reference validation by checking against the bank account's country. Previously, a single check applied to all countries could lead to incorrect validations. Now, the system prioritizes country-specific rules, falling back to a standard check only when a country isn't supported, ensuring more reliable payment processing.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/odoo#249380 Forward-Port-Of: odoo/odoo#248194
This update enhances the accuracy of payment reference checks by tailoring validation rules to the bank account's country. Previously, a single check applied to all countries could lead to incorrect validation. Now, the system verifies the reference format against the specific country of the bank account, with a fallback to a standard check for unsupported countries.
Original PR description
Currently, when initiating a payment, we check if the reference is a structured one by using `is_valid_structured_reference` which checks the validity of the structure accross all supported countries. This can lead to issues when it matches formats accepted by other countries but not the one of the bank account. With this commit, we replace this check by a call to a new function that checks the structure validity according to the country of the bank account, with a fallback to the generic check (ISO 11649) if the country is not supported. opw-5387269 Forward-Port-Of: odoo/enterprise#107870 Forward-Port-Of: odoo/enterprise#107116
This update fixes an issue where a POS order could incorrectly apply a pricelist even if it wasn't the customer's standard price list. Previously, loading a pricelist from a paid order would override the correct selection. This change ensures that only available pricelists are applied, improving order accuracy and preventing pricing errors.
Original PR description
When changing the customer on a POS order, if the customer's pricelist is not in the list of available pricelists for the POS, but the pricelist was loaded due to loading a paid order, the POS would still set that pricelist on the order. opw-5461556 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248904 Forward-Port-Of: odoo/odoo#247029
This update fixes an issue where POS receipts incorrectly showed the standard 21% tax label, even when a fiscal position (like 6%) was applied. The change ensures that the POS receipt accurately reflects the tax group based on the selected fiscal position, improving accuracy and compliance.
Original PR description
Steps: - Install l10n_be_pos_restaurant. - Create a restaurant POS configuration with presets. - Assign a fiscal position to one preset that replaces 21% tax with 6%. - Open a POS session and process an order using that preset. Issue: - The POS receipt still displays the 21% tax's tax group label, even though the 6% tax is correctly applied. Cause: - Fiscal position was not taken into account when computing the tax group label for POS receipt orderlines. Fix: - Apply the fiscal position when determining the POS receipt tax group label. Task-5899938 Forward-Port-Of: odoo/odoo#250832 Forward-Port-Of: odoo/odoo#248571
2 changes
Resolved issues and error corrections
This update fixes an issue where the correct currency wasn't being applied when transferring CODA payments to multiple journals with the same IBAN but different currencies. The change ensures payments are routed to the correct journal based on its currency, improving financial accuracy and reducing the risk of errors.
Original PR description
When having multiple journals with the same IBAN, but different currencies, upon fetching and dispatching the CODA into the right journals, the currency of the journal was not correctly taken into account as the condition was incorrect. This commit fixes this condition which was introduced in [^1] such that the right journal, with the right currency is correctly chosen. [^1]: 4fda4fb5353ed9c14dbc023ab7d07fabd3c06e98 opw-5723017 Forward-Port-Of: odoo/enterprise#108677
This update resolves a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This improves the stability and accuracy of the document processing features.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
14 changes
Resolved issues and error corrections
This update fixes an issue where QR code payment links on invoices were incorrectly showing the full outstanding amount, particularly for installment-based invoices. By using the default values for the payment link wizard, the links now accurately reflect the next payable installment, ensuring accurate payments.
Original PR description
The link from QR code in invoice pdf was explicitly passing `amount`, `res_model`, `res_id` to create `payment.link.wizard` using create method which overrides default_get() of wizard. As a result, installment-based invoices were generating payment links for the full residual amount. Also the `active_id` and `active_model` is passed in context which writes to `res_model` and `res_id` so no need to add it in create again. By letting default_get() populate the wizard values, the payment link now correctly reflects the next payable installment. task-5401335
This update corrects a problem with how VAT tax schemes are calculated for Romanian customers. Previously, an empty company registry caused errors. The fix re-introduces specific logic for Romanian CIUSRO invoices to ensure accurate VAT calculations, addressing a critical issue for Romanian businesses using Odoo.
Original PR description
Problem --------- If the customer has not VAT set up on it record, we use the DEFAULT_VAT value. However, the scheme to be used is computed using the partner company_registry (which might be empty), which fails. Secondly, the piece of logic that compute the VAT/NON_EU_VAT for the Tax Scheme node was removed during the refactor. However, this is needed in Romania. Solution --------- Compute the scheme using the DEFAULT_VAT and add back the VAT/NON_EU_VAT logic for the Romanian CIUSRO only. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250110
This pull request corrects a minor typographical error within the Odoo sale module's configuration settings. This ensures consistent and accurate display of sale options for users, improving the overall user experience. The fix addresses a small, non-functional issue that could have caused confusion.
Original PR description
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#249973
This update fixes a bug where employees with scheduled future attendances couldn't check out. The fix ensures that only past attendance records are considered when determining the employee's checkout status, preventing errors and restoring normal kiosk functionality. This resolves a critical issue impacting employee workflow.
Original PR description
### Issue: When having an attendance in the future, the employee cannot checkout anymore. ### Steps to reproduce: - In Attendances, create an attendance in the future for an employee - Go in the kiosk mode - Manually select the employee to check in - Do the same to check out - An error pops up ### Cause: The field `last_attendance_id` of the employee contains his future attendance. The field `attendance_state` use `last_attendance_id` in its computation, so it's always "checked_out", even if an attendance is curently open for the employee. So when trying to check out an exception is raised in [`_check_validity()`](https://github.com/odoo/odoo/blob/fee6b32a8a57577bd8229c80dff6f93964f9f556/addons/hr_attendance/models/hr_attendance.py#L224-L234). ### Solution: Add a condition in the domain of `_compute_last_attendance_id()` to only consider the last **past** attendance. opw-5491867 Forward-Port-Of: odoo/odoo#248875
This update fixes a potential issue with after departure payments to work. Now, if a previous payslip isn't linked, a clear error message is displayed to the user instead of a technical error. This ensures accurate payment processing and avoids confusion.
Original PR description
For after departure payment to work, a previous payslip is required in the system. So, instead of having a traceback, display an informative message to the user. task-5933607 Forward-Port-Of: odoo/enterprise#107386
This update clarifies the event booking process for existing partners. When booking, the system now suggests both 'Sign In' and 'Create an Account' options, ensuring partners have clear guidance regardless of their portal access. This improves the user experience and streamlines the registration process.
Original PR description
When booking with an email that belongs to an existing partner, a 'Sign in' link is shown to the booker. If the partner has no portal access, then it is not relevant as they could also need to create an account. Therefore, change the wording by adding 'or create an account'. This way, the use of the login page redirection is more complete. opw-5419532 Forward-Port-Of: odoo/odoo#250740 Forward-Port-Of: odoo/odoo#241445
This update fixes an issue where the number of available time off allocations wasn't accurately reflecting allocations started in the previous year. The fix ensures that all valid allocations, regardless of their start date, are correctly counted on the time off type page, improving reporting accuracy. This resolves a discrepancy between the smart button and the allocation details.
Original PR description
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee…
__ ## Short functional explanation of the error When setting the start date for a time off allocation to the previous year, it is not taken into account when computing the count of employee allocations on the time off type page. ## Reproduction Steps 1. Go to Time off > Configuration > Time off Types and click on any time off type. 2. A smart button Allocations should appear with a number in it. Note the number and click on the button. 3. If no allocation exists yet, create one. Otherwise, click on an already existing allocation. 4. Set the start date of the validity period to any date last year. Set the ending date so that the allocation is still valid as of now. 5. Go back to the Time off type page and look at the number on the Allocations smart button. ### Expected behavior As the allocation we set is still valid, the number shouldn't have changed. ### Unexpected behavior The allocation number has been decreased. However, when we click on the smart button, the same number of valid allocations will show. This creates an inconsistency between the smart button and the allocation page, as the smart button should show the number of valid allocations, and when landing on the allocation page, the results are automatically filtered by validity. ## Origin of the issue The domain of the allocations to take into account when computing the count of valid allocations is defined here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/models/hr_leave_type.py#L297-L304 This doesn't take into account valid allocations that started during the previous year. The inconsistency with the allocation page can be seen here: https://github.com/odoo/odoo/blob/2264f330859b79010b227e3a9fda1075de8ed4e8/addons/hr_holidays/views/hr_leave_allocation_views.xml#L40-L46 Where the filter is defined based on today, rather than on the whole year, unlike above. __ opw-5504272 Forward-Port-Of: odoo/odoo#250378 Forward-Port-Of: odoo/odoo#248482
This update fixes an issue where Point of Sale session messages were consistently displayed in English, regardless of the user's selected language. The fix ensures that all cash-related messages within POS sessions are now translated accurately based on the user's language preference, improving the user experience for international customers.
Original PR description
**Problem:** When opening or closing a POS session, chatter messages display untranslated English text regardless of the user's language setting. **Steps to reproduce:** 1. Set user language to any non-English language (e.g., Spanish) 2. Open a POS session and register cash in/out operations 3. Close the session 4. Check the chatter messages - labels appear in English **Current behavior:** Messages display in English: "Opening cash difference", "Opening cash expected", "Opening cash counted", "Closing difference", etc. **Expected behavior:** Messages should be translated according to the user's language setting. **Cause of the issue:** The hardcoded strings were not wrapped in the translation function `_()`, preventing them from being translated. **Fix:** Wrap the concatenated strings with `_()` to enable proper translation of all cash details messages. opw-5185310 Forward-Port-Of: odoo/odoo#244501
This update fixes a limitation in the eCommerce search bar's placeholder text, preventing it from being translated. The change replaces a technical method with a standard translation-friendly format, ensuring all placeholder text can now be localized. This improves the user experience for international customers.
Original PR description
The placeholder of the search bar for attributes in eCommerce was not translatable, because it was using a Python expression to set its value. This commit replaces the Python expression with a t-attf-placeholder, which allows the placeholder to be translated. opw-5978276
This update fixes a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file, resolving compatibility issues with the PyPDF library. This ensures consistent and reliable test results.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update ensures taxes are automatically calculated for charge and discount lines in UrbanPiper orders, even when tax data isn't initially provided by the UrbanPiper system. Previously, taxes weren't applied if UrbanPiper didn't send tax information, now it defaults to using standard product tax rules. This ensures accurate tax reporting for all UrbanPiper transactions.
Original PR description
Before this commit: --- - If UrbanPiper did not send tax data for charge and discount lines, taxes were not applied. - Tax data was only provided by UrbanPiper for the India region. After this commit: --- - When the payload does not include tax data, compute taxes for charge and discount lines using the product tax, the same way as for normal order lines. task-5895987 Forward-Port-Of: odoo/enterprise#108405 Forward-Port-Of: odoo/enterprise#106686
This update resolves an issue where rapidly clicking the 'Back' button during barcode internal transfer creation resulted in duplicated quantities being added to the transfer. The fix ensures that multiple 'Back' clicks don't trigger redundant saving operations, preventing incorrect quantity calculations.
Original PR description
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By…
**Steps to reproduce:** * Install `stock` module. * Go to the > Settings*, enable *Packages* and *Storage Locations*(warehouse). * Create a storable product and set *Tracking Inventory* to **By Quantity** and set some *barcode* * Update the on-hand quantity for the product and assign it to one packages. * Open *Barcode > Operations > Internal Transfer* and create a new transfer. * Click the *gear icon* in the top-right corner to open the barcode scanning flow. * manually enter the created product barcode and apply it. * Click the **Back** button multiple times in quick succession. * Go to the backend and open the created internal transfer. **Observed behavior:** * The internal transfer is created with *double quantities* compared to what was added in the barcode interface. **Cause:** * When clicking the *Back* button, the following flow is triggered: `exit()` → `beforeQuit()` → `save()`. https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/components/main.js#L406-L414 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L473-L475 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_picking_model.js#L828-L832 https://github.com/odoo/enterprise/blob/07ede9bda567d94da27da79b945e2189fa5aca6e/stock_barcode/static/src/models/barcode_model.js#L477-L483 * If the button is clicked multiple times rapidly, `exit()` is called again before the previous `save()` RPC completes. * This results in multiple `save()` calls being executed, causing duplicated quantities on the picking. reference - https://github.com/odoo/enterprise/pull/103999/changes/b791239c154deb6a25f85d65ebc72e3ac53b6c74 **Fix:** * Prevent rapidly clicking the Back button multiple times does not multiply quantities. --- opw-5375899 Forward-Port-Of: odoo/enterprise#108881 Forward-Port-Of: odoo/enterprise#103130
This update fixes an issue where creating multiple email templates using favorites could lead to errors due to excessive HTML nesting. The fix prevents unnecessary wrapper application when using favorites, ensuring smoother template creation and preventing potential crashes. This improves the stability of our email marketing functionality.
Original PR description
**Steps to reproduce:** - Go to Email Marketing app - Create a new mailing - Click on empty mail body and add only a Heading block - Set a subject, save it and click `Add to Templates` (favorites) - Create another mailing which use the first one as its template - Repeat the operation multiple times - Error will be raised at some point due to the depth of the template html **Issue:** Unnecessarily nested `div` are created when using favorites to create new `mailing.mailing` records, if those favorites are themselves based on other favorites etc., it later can lead to a recursion error when rendering the template. **Fix:** Check if the template comes from the favorites to avoid reapplying the wrappers on it. This seems to be solved in 19.0 with the refactoring (https://github.com/odoo/odoo/commit/354b8f60dbabcfac690d90bf657592e1347e4f86) opw-5275187 Forward-Port-Of: odoo/odoo#249476 Forward-Port-Of: odoo/odoo#238489
This update fixes an issue where the calculation of 'sandwich leave' (leave periods surrounding holidays) was incorrect. Specifically, when leave was approved and then re-approved, the total leave days were sometimes miscalculated. The fix ensures that all leave periods, including holidays and weekends, are accurately counted according to the sandwich leave rule.
Original PR description
## Steps to reproduce:- 1. Apply Friday to Monday leave and Tuesday is Public holiday and again apply single leave on Wednesday. - According to the sandwich leave rule, the leave should be counted as 6 days (Friday to Wednesday, including weekend and holiday). 2. Now refuse the Friday to Monday leave and re-approve again. 3. Now the leave count is updated to 5 days as it should be 6 days! ## Root cause:- On approve action the neighbor leaves where not recomputed. ## Fix:- - Override `_l10n_in_update_neighbors_duration_after_change` on approve action. - Updated `_l10n_in_update_neighbors_duration_after_change` so that current and neighbors both leaves are recomputed. task-[5446346](https://www.odoo.com/odoo/action-4043/5446346) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244235
3 changes
Resolved issues and error corrections
This update corrects a previous failed backport caused by attempting to use a field that hadn't been implemented in the 18.2 branch. The commit removes the reliance on this missing field, ensuring the backport now functions correctly. This resolves a technical issue preventing the update.
Original PR description
A previous backport was using a field that was not yet present in the 18.2 branch, which caused the backport to fail. This commit remove the use of the field. support: 5975960
This update resolves an issue where taxes weren't correctly calculated during Google Pay (GPay) express checkout using Stripe. The fix ensures that Avatax taxes are now accurately applied, aligning payment amounts with the final order total. This improves payment accuracy and prevents discrepancies for customers using GPay.
Original PR description
## Versions 17.0+ ## Issue Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes. ## Steps to reproduce…
## Versions
17.0+
## Issue
Avataxes are not computed during express checkout leading to discrepancies between customer payments and effective price including Avalara taxes.
## Steps to reproduce
*Ensure the Stripe account has activated Google Pay* *This requires a complete Google profile on Google Chrome (with a valid payment method)*
- Setup Stripe payment method in test mode with Express Checkout;
- In the Settings, in the Accounting section:
- Setup Avatax;
- Set main Sales/Purchase taxes to 0.
- Create a new product with 0% selling taxes and any Avatax category;
- Activate fiscal position and enable automatic detection;
- Open a Chrome session with the Google profile:
- Go to the shop;
- Add the product you created to the cart;
- Enter the cart;
- Click the "Buy with GPay" button:
- The amount is equal to the sales price excluding taxes.
- Go to the Sales app and open the newly created order:
- The total amount differs from the amount paid (cf. transaction).
opw-5020793
Forward-Port-Of: odoo/enterprise#108873
Forward-Port-Of: odoo/enterprise#101579This update fixes an issue where newly hired employees were incorrectly inheriting their private email address as their work email. The fix ensures that the employee's work email field is properly cleared during the contract creation process, preventing this duplication. This ensures accurate email data for new employees.
Original PR description
**Steps to Reproduce:** 1. Send an offer to an applicant. 2. The applicant submits their details via the salary configurator and enters their private email in the Email field. 3. Once the offer and contract are signed, an employee record is created in Odoo. 4. In the created employee record, the `work_email` field is populated with the email entered in the salary configurator. This same value is also present in `private_email`, which is correct. **Reason:** - The email entered in the salary configurator is stored on the partner and represents the applicant's private email. - The employee's `work_email` field is linked to the partner's email via compute and inverse methods, causing it to inherit the private email value when the employee record is created. **Solution:** - Explicitly clear the employee's work_email field when the applicant sign. task: 5502797 Forward-Port-Of: odoo/enterprise#108769 Forward-Port-Of: odoo/enterprise#106974
13 changes
Resolved issues and error corrections
This update fixes a technical issue related to how numeric values are handled in the web_studio interface and ensures consistent use of the new badge widget across the appointment module. It improves the reliability of data entry and aligns with recent changes to the core widget system, enhancing overall system stability.
Original PR description
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a…
### **This PR addresses:** Updating the `appointment` module to reflect the removal of the `selection_badge_icons` widget in core `web` and fixing property parsing in `web_studio`. This is a mandatory follow-up to the migration of icon support and dropdown fallbacks into the standard `selection_badge` widget. ### **Key Changes:** * **Widget Migration:** Replaced all occurrences of `widget="selection_badge_icons"` with `widget="selection_badge"` in appointment question views. * **Studio Property Fix:** Updated `web_studio` property parsing to use `Number()` instead of `JSON.parse` for numeric values. This prevents errors when handling numeric strings with leading zeros (e.g., "032"). * **Test Alignment:** Updated the OWL tests to use the new `.o_field_selection_badge` class name for waiting and selectors, ensuring the test suite remains green. * **Compatibility:** Maintained the existing `icon_mapping` and `size` options, which are now natively supported by the core widget. **Task-5270283** **Related Community PR:** odoo/odoo#243855
This update fixes a technical error preventing managers without appraisal rights from scheduling meetings. The issue stemmed from access restrictions related to employee data. The fix simplifies the process by directly using the employee's work contact information instead of the problematic related partner ID.
Original PR description
Steps to reproduce: - Create two employees: one as a manager and the other as a subordinate. - Ensure that the manager does not have any officer or appraisal rights. - Create an appraisal for the subordinate through the manager. - Confirm the appraisal and then click the Schedule Meeting button Issue: - The manager should schedule a meeting even though he does not have the rights, but a traceback error occurs due to access rights issues when trying to schedule a meeting. Reason: - The manager is unable to access the related_partner_id due to restrictions set by the officer/manager group, which results in a traceback error. Fix: - Replace the related_partner_id with the work_contact_id of the employee. Since related_partner_id is computed from work_contact_id, we can directly use work_contact_id task-5881127 Forward-Port-Of: odoo/enterprise#106106
This update fixes an issue where accounts without a code in the primary company were being excluded from report consolidation, leading to inaccurate totals. Now, the system will automatically find the correct code for these accounts in other companies, ensuring accurate report generation and financial data consistency.
Original PR description
Description of the issue this commit addresses: When consolidating reports, any account that doesn't have a code on the consolidating company is filtered out of the consolidation. This will lead to amounts that do not match which should not happen. --- Desired behavior after this commit is merged: When an account should be used but is filtered out because of not having a code in the per company mapping, we try to find its code on any of the other companies he is and use that one as anchor in the consolidation. --- task-5911409 Forward-Port-Of: odoo/enterprise#107651
A bug was preventing users from correctly saving approval rules with specific domain filters in the web studio. This was caused by a mismatch in how data was represented between Python and JavaScript. The fix ensures that domain filters are saved accurately, allowing users to properly configure email approvals.
Original PR description
Steps to reproduce ================== - Install web_studio,sale_management - Open a form view in sale - Open studio - Click on the "Send by email" button - Add an approval rule - Add a domain by clicking on the filter icon - Use the not set operator - Confirm - Click on the filter icon again - Confirm => ValueError: malformed node or string on line 1: <ast.Name object at 0x79ff4c7b7f50> Cause of the issue ================== JSON.stringify was used to pass the domain as a string to the DomainSelectorDialog. This doesn't work for boolean as they don't have the same representation in JavaScript as opposed to Python. Solution ======== Use the Domain().toString function opw-5923585 Forward-Port-Of: odoo/enterprise#108595 Forward-Port-Of: odoo/enterprise#107432
This update resolves an issue where payment reference data from the Codabox integration was incorrectly formatted, often with leading or trailing spaces. The change automatically removes these spaces before creating reco models, ensuring accurate data processing and preventing potential errors in financial reporting. This improves the reliability of bank statement imports.
Original PR description
Before this commit, when we do the creation of the automatic reco models, it was possible that the payment ref ended with a lot of empty spaces. To avoid that, we now strip the payment ref before the creation of the reco model. Data coming from codabox where wrongly formatted since the payment ref could have space at the end or the start and even in the middle. By using a split join we solve that issue. task-5926548 Forward-Port-Of: odoo/enterprise#107421
This update corrects a problem in how Odoo handles extended sick leave in Belgium. Previously, different work entry types for consecutive days of absence caused matching issues. The change reverts a previous fix and isolates the Belgium-specific logic, ensuring accurate calculations for sick leave durations.
Original PR description
In Belgium, when more than a month of consecutive sick time of is taken, every day over the month is of a different type of work entry (sick time of without pay). This means that work entries relative to the same leave have different work entry types which was causing problems when checking the matching of the types. To fix this, a previous PR (https://github.com/odoo/odoo/pull/237829) made it so that if the internal_leaves computation returned empty, every leave was considered. Because of this some problems in the HK localization arose so we go back to the original code (see related Community PR) and we move the BE specific changes to the BE localization module. Here we override the check function to allow for the specific case described above, where LEAVE110 is the code for sick time off and LEAVE214 is the code for sick time of without pay. Task: 5472538 Community PR: https://github.com/odoo/odoo/pull/246116 Forward-Port-Of: odoo/enterprise#105776
This update resolves an issue where test applications for new hires were failing due to missing applicant name information. The team has added required partner_name values to the test cases, ensuring data integrity and preventing errors during application creation. This improves the reliability of our recruitment testing process.
Original PR description
In the related community PR, we are making the partner_name as required. So need to give the partner_name values in the test cases while creating the `hr.applicant` to resolve the not null violations Community PR:- https://github.com/odoo/odoo/pull/203222 sentry-6409185730
This update streamlines the process of generating salary simulations by introducing a standardized context manager. This ensures consistent setup and teardown of necessary operations, reducing potential errors and improving the reliability of the simulation process. It also enforces the correct context setup for related methods.
Original PR description
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose…
Description ----------- Getting an `hr.version` from an `offer` during simulation is done in a savepoint, preceded and followed with flushing of the environment and some post-cleanup. This is verbose and error-prone, as it's done at each call site of `hr.contract.salary.offer._get_version` and `hr.version._generate_salary_simulation_payslip` (or any other future method that may require such a savepoint). These methods have a comment that mentions *requiring* a savepoint to be called, but nothing is enforcing it, so a bug due to oversight is bound to happen. Context keys are also injected a bit everywhere like `salary_simulation` and `tracking_disable`, without much consistency, and adding to the visual clutter. This commit introduces a little context manager called `hr_version_context` that manages the creation of the savepoint, the setup and teardown necessary, and the setting of the keys in the context. It's accompanied by a decorator `@requires_hr_version_context` that will fail if the caller didn't use `hr_version_context` before invoking the marked method. This ensures: - Correct creation of the savepoint and its related pre-/post-operations - Apply context keys consistently - Ensure methods that require such setup *cannot* be called without it. Forward-Port-Of: odoo/enterprise#107743 Forward-Port-Of: odoo/enterprise#103187
This update corrects a display issue in the chat window where the agent's subtitle was not appearing correctly when the agent description was blank. The fix adds a default message to ensure the subtitle is always visible, improving the user experience. This resolves a previous display problem.
Original PR description
The chat subtitle is false, if the agent description is not set. This commit fixes the issues by adding a default message if subtitle is missing. Task-5916227 Forward-Port-Of: odoo/enterprise#108948 Forward-Port-Of: odoo/enterprise#106949
This update fixes an issue where social security numbers were incorrectly displayed across different company views in Odoo. The change restricts SSN visibility to only appear within the specific country's company records, ensuring data privacy and compliance. This improves data accuracy and reduces potential reporting errors.
Original PR description
[FIX] l10n_hr_payroll: limit l10n_xx_ssn to appear only in xx companies Bug reproduction: Select version >= saas-19.2 -> select your company -> payroll->employee->personal->you will see social security number even though that can belong to SA, MX, EG. Bug cause: added ssn fields are not restricted to their own l18n, then they are appearing in each employee form views. Bug solution: add country restrictions for MX, EG, SA to not appear in other country's company. task - 5974006 Forward-Port-Of: odoo/enterprise#108903
This update fixes a bug that prevented accurate payment advice reports when employees had multiple bank accounts. The team verified all bank accounts and BIC codes to ensure the system correctly generates reports, even with secondary bank information. This ensures accurate financial reporting for our users.
Original PR description
steps to reproduce: - install `l10n_in_hr_payroll` - create an employee, with multiple bank accounts - add invalid BIC in one of the bank accounts with isn't primary - notice that you will still be able create the advice report with invalid data. issue: - after the support of multiple bank accounts, the payment advice methods were not adapted with it. fix: - checked all the banks and their BIC. task-5890497 Forward-Port-Of: odoo/enterprise#109002 Forward-Port-Of: odoo/enterprise#107283
This update fixes a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This resolves a technical issue that could have impacted the stability of the document processing features.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update fixes an issue where the VAT Book download was limited to only the primary company. Now, when multiple branches with the same CUIT are selected, the VAT Book will download for all of them, ensuring accurate reporting for multi-branch businesses in Argentina. This improves the reliability of tax reporting.
Original PR description
#### Issues: VAT Book should download for all selected companies with same CUIT as the current one. #### Step to reproduce: - In a company in Argentina ("Parent Company") - Create a branch "Child…
#### Issues:
VAT Book should download for all selected companies with same CUIT as the current one.
#### Step to reproduce:
- In a company in Argentina ("Parent Company")
- Create a branch "Child Company A" with no CUID
- Create a branch "Child Company B" with a different CUID than parent
- Go to "Child Company A"
- Either:
- i. Select both "Parent Company" and "Child Company A" but not "Child Company B"
- ii. Select all 3 "Parent Company", "Child Company A" and "Child Company B"
- In Accounting > Report > Tax Return :
- Download the VAT Book (wheel > "VAT book(ZIP)")
#### Current behavior:
i. Get Invalid Operation
ii. Download the VAT Book for "Parent Company" only
#### Expected behavior:
- Download the VAT Book for both "Parent Company" and "Child Company A"
A previous call to get_options provide the client with the info about which selected companies have the same CUIT as the current company. Therefore companies in the options are the correct ones.
opw-5385585
Forward-Port-Of: odoo/enterprise#108466
Forward-Port-Of: odoo/enterprise#1018981 change
Resolved issues and error corrections
This update fixes a bug where NSSF Tier 2 and Pension Contribution deductions weren't consistently shown on payslips, even when correctly reported. The changes ensure that all relevant deductions are accurately displayed on the payslip, regardless of whether contributions are remitted to insurance or the pension authority. This improves payroll transparency and reporting accuracy.
Original PR description
Issue: - NSSF Tier 2 and Pension Contribution salary rules only appeared on the payslip and salary computation when remitted to NSSF. - When Tier 2 was remitted to insurance, NSSF Tier 2 deductions were missing from the payslip display, even though reporting was correct. - Similarly, Pension Contribution was missing from the payslip when pension was remitted to insurance instead of the pension authority. Fix: - Updated the NSSF Tier 2 salary rule condition to ensure it always appears in salary computation and payslip. - Updated the Pension Contribution salary rule to ensure it is always displayed on the payslip even when remitted to insurance. - Adapted the NSSF Report as well. task-5896380
12 changes
Resolved issues and error corrections
This update ensures the cash drawer opens automatically when the cash details popup is opened in the Italian Point of Sale (POS) system. Previously, this functionality was missing, causing a discrepancy between the fiscal printer and cash drawer behavior. This fix resolves an issue where closing and reopening the PoS session was required to trigger the cash drawer opening.
Original PR description
When opening the cash details popup the cash drawer should be opened. It was not the case for the Italian fiscal printer. Steps to reproduce: ------------------- * Setup a Italian fiscal printer with cash drawer support * Open PoS * Open the cash details popup > Observation: The cash drawer does not open * Try to close the PoS session * Open the cash details popup > Observation: The cash drawer opens Why the fix: ------------ The cash drawer opening function was simply not called opw-5391094
This update fixes a data issue in the Danish demo company setup within Odoo. Specifically, the street number was missing, which was preventing proper functionality with Nemhandel (the Danish e-commerce payment system). This change ensures accurate data for testing and demonstration purposes.
Original PR description
This commit adds the street number to the DK demo company, because we need it for nemhandel. no-task
This update corrects a display issue in the website editor where the 'Custom URL' field incorrectly appeared on certain pages. The fix ensures this field only shows when the page URL contains a customizable slug, preventing confusion and ensuring accurate SEO settings. This improves the user experience for website administrators.
Original PR description
This PR hides the "Custom Url" field in the "Search Engine Optimization" when the URL of the current page do not contain any editable slug. Previously, this field could be filled when the URL did not contain any modifiable slug. However, the value was not take into account since the route of the page did not expect slug. Reproduce: With an admin user, activate the website editor on an appointment page. Clicking on "Optimize SEO" in the "Site" dropdown menu, a form containing the "Cutsom Url" field is displayed. This field should represent the current page's URL but with fillable field instead of the editable URL part. In this case, this is not correct as the URL is repeated before and after the fillable field, which does not represent the current URL. Also, the URL is not modified with the value entered in the fillable field. After the fix: The "Custom Url" field must not be displayed when URL does not contain a customisable slug. Task-5114394
This update corrects a potential issue where calculations on payslip lines could become out of sync, leading to inaccurate payroll reports. The change ensures that all related data is consistently updated, improving the reliability of payroll processing. This resolves a technical problem that could have impacted payroll accuracy.
Original PR description
Forward-Port-Of: odoo/enterprise#108729
This update resolves a bug that caused a 500 error in the portal when users attempted to edit company information without specifying a country. The fix handles the situation where a company record lacks a country association, preventing a calculation error that triggered the issue. This ensures a smoother experience for all users.
Original PR description
How to reproduce:
- Create a company with no country
- Set a contact's company to that company
- Grant portal access to that contact
- Login as that contact
- Go to the edit information tab
- Leave some of the required fields (Phone, Street & City) empty
- Click on save
The problem:
The page displays an error 500
Why:
When you try to submit the form with some required field missing, the page will try to evaluate this expression : 'int(country_id)''. But since this commit (https://github.com/odoo/odoo/commit/d6d6bee087fe2d3dc17974054353430c2662aecf), the post variable country_id is set to "False" if the partner has no country. 'int("False")' will then raise an error.
opw-5867975
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#247761This update addresses random errors occurring during Point of Sale (PoS) testing, primarily identified by Runbot. The issue stemmed from prematurely ending tests before all requests were processed, and a subsequent problem where all products were unavailable in PoS and Self-Order modules. This fix ensures more stable testing and improved PoS functionality.
Original PR description
https://runbot.odoo.com/odoo/runbot.build.error/241044 We were not waiting the last request to be processed before ending the test, which could cause some random errors. https://runbot.odoo.com/odoo/runbot.build.error/241151 All products were not available in PoS and Self, which caused some errors on community builds.
This update corrects a bug where the '#top' and '#bottom' menu links were incorrectly prefixed with the current page's URL, preventing them from functioning as intended. The fix ensures these links consistently work as universal 'scroll to top' features, improving user navigation.
Original PR description
__Before commit:__ Menu items with anchor URLs (e.g., `#my-anchor`) are prefixed with the current page's path. This is correct for page-specific anchors but breaks generic ones like `#top` and `#bottom`. A menu with the URL `#top` becomes `/current-page#top`, preventing it from functioning as a universal "scroll to top" link. __Cause:__ The server-side logic for processing menu URLs does not differentiate between page-specific anchors and generic anchors like `#top` or `#bottom`, treating all anchor links as belonging to the current page. __Fix:__ In the `save` method, exclude `#top` and `#bottom` from the logic that prefixes anchors with the current page's URL. This ensures these special anchors, typically set on the header and footer, work consistently across the entire website. A new unit test verifies that `#top` and `#bottom` menu URLs are saved correctly without being prefixed. task-5941115 Forward-Port-Of: odoo/odoo#250136
This update resolves a warning generated during testing of document attachments. The team replaced artificial PDF content with a standard, minimal PDF file used for testing, ensuring consistent and reliable test results. This improves the stability and accuracy of our document-related testing processes.
Original PR description
While creating attachments/documents for testing, using a "fake PDF content" generates warning from PyPDF 5.4.0 (even with `strict=False`) when the said PDF is eventually parsed. This commit replaces those "fake PDF content" by reading the "minimal" PDF file provided for testing purposes in `base`. runbot-231278 Forward-Port-Of: odoo/enterprise#108779
This update fixes an issue where the stock forecast report incorrectly displayed reserved stock from sublocations as negative values in 'Free Stock in Transit'. Previously, when a delivery was created from a sublocation, the system wasn't properly updating the 'Free Stock' report. This change ensures accurate stock reporting, providing a clearer view of available inventory.
Original PR description
If you create & reserve a move from a sublocation of the main stock location, the forecast report would put this reserved quantity as a negative line in "Free Stock in Transit" instead of removing it from the "Free Stock". ## Steps to reproduce: - Create sub location WH/Stock/A - Put 20 unit of a storable product P in WH/Stock/A - Create Delivery todo in future of 5 units of P, from WH/Stock/A => Check Forecasted report, Free Stock = 20 | Free Stock in Transit = -5 OPW-5953172 --- <img width="1827" height="784" alt="image" src="https://github.com/user-attachments/assets/57c0b130-3916-4b35-9dad-e642f5319591" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250148
This update ensures One Stop Shop (OSS) invoices for intra-EU B2C sales meet Italian Revenue Agency requirements. The system now correctly generates invoices by splitting out VAT information, resolving previous rejection issues with the FatturaPA system. This ensures accurate and compliant e-invoicing for Italian customers.
Original PR description
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior:…
This commit aligns the Italian e-invoicing (FatturaPA) generation for One Stop Shop (OSS) transactions with the requirements of the Italian Revenue Agency ( Agenzia delle Entrate). Current behavior: Invoices for intra-EU B2C sales (OSS) are generated with a single line containing the foreign VAT rate. This is rejected or considered non-compliant by the SDI because foreign VAT cannot be typically exposed in the standard way for Italian electronic invoices. New behavior: The XML generation logic has been updated to follow the specific codification required for OSS operations: 1. Invoice Lines (`DettaglioLinee`): - The product line is reported with 0% VAT and Nature 'N7' (VAT paid in another EU member state). - A new, separate line is injected to represent the VAT amount, classified with Nature 'N2.2' (Non-taxable/Other). 2. Tax Summary (`DatiRiepilogo`): - The original foreign tax lines are excluded from the summary. - Synthetic summary lines are added for the 'N7' (Taxable Base) and 'N2.2' (VAT Amount) categories. Implementation details: - Added `_l10n_it_is_oss_tax` helper to identify OSS taxes. - Modified `_l10n_it_edi_get_line_values` to split OSS lines. - Modified `_l10n_it_edi_get_tax_values` to adjust the tax summary. task-4711509 Forward-Port-Of: odoo/odoo#243740
This update fixes a technical issue related to how Romanian VAT invoices (l10n_ro_cpv_code) map CPV codes to internal classifications. The previous mapping incorrectly used 'CPV' when the correct code ('STI') should have been applied, as defined by PEPPOL standards. This ensures accurate invoice processing and compliance with Romanian tax regulations.
Original PR description
The value of `ItemClassificationCode/listID` that corresponds to `CPV` classification is `STI` not `CPV`. See https://docs.peppol.eu/poacc/billing/3.0/codelist/UNCL7143/ task-5416833 Forward-Port-Of: odoo/odoo#250045
This update resolves an issue where updating a Bill of Materials (BoM) in a draft manufacturing order would incorrectly trigger the deletion of associated work orders, leading to errors. The fix ensures that work orders are only deleted when they are truly outdated, preventing these deletion attempts when components are added to the BoM.
Original PR description
Steps to reproduce: - Create a storable product P1 with the following BoM: - Component: C1 - Operation: OP1 - Create a draft MO for P1 - Update the BoM by adding a new component - Go back to the MO…
Steps to reproduce:
- Create a storable product P1 with the following BoM:
- Component: C1
- Operation: OP1
- Create a draft MO for P1
- Update the BoM by adding a new component
- Go back to the MO and click "Update from BoM"
Problem:
Missing Record
Record does not exist or has been deleted.
(Record: mrp.workorder(8,), User: 2)
Clicking on `update bom` will launch a call of the `action_update_bom`
which will itself call the `_link_bom` to update the record:
https://github.com/odoo/enterprise/blob/ac3f333d97eda5c86a0813490ac6204d4ec5721f/mrp_plm/models/mrp_production.py#L73-L80
https://github.com/odoo/odoo/blob/98da30375a5ae50a77d848b838781aa7247bd362/addons/mrp/models/mrp_production.py#L2406-L2418
The function will sets `bom_id` to False, which triggers
`_compute_workorder_ids` and `_compute_move_finished_ids`
(depends on bom_id). As the MO is in draft, related moves and
workorders are deleted.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L849
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L659
After that, it will try to delete the work orders again, and
since the operation no longer exists, an error will be triggered.
https://github.com/odoo/odoo/blob/19.0/addons/mrp/models/mrp_production.py#L2586-L2587
opw-5947687
Forward-Port-Of: odoo/odoo#24933614 changes
Resolved issues and error corrections
This update corrects a problem with how leave periods are calculated, specifically related to time zone differences. By using `request_date_from` and `request_date_to`, the system now accurately reflects leave interruptions, ensuring correct payroll processing for employees in Switzerland. This resolves potential discrepancies and improves data accuracy.
Original PR description
This commit fixes the leaves work interruption constraint by replacing `date_from` and `date_to` with `request_date_from` and `request_date_to`, thereby resolving any inconsistencies that may arise from time zone differences. task-5966780
This update resolves an issue where importing data files with incorrect field definitions would cause a system error. The fix ensures that the system gracefully handles invalid field data during the import process, preventing crashes and improving data import reliability.
Original PR description
This traceback arises when the user imports a file with invalid fields on a model. To reproduce this issue: 1) Import a file with an invalid field ex:-(`in_group_44`) for a model (`Users`) Error:-…
This traceback arises when the user imports a file with invalid fields on a model.
To reproduce this issue:
1) Import a file with an invalid field ex:-(`in_group_44`) for a model (`Users`)
Error:-
```
KeyError: 'in_group_44'
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, 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 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/base_import/models/base_import.py", line 1378, in execute_import
import_result = model.load(import_fields, merged_data)
File "odoo/models.py", line 1220, in load
if isinstance(model_fields[field_name], odoo.fields.One2many):
```
when the user tries to import a file with an invalid filed it leads to a traceback from here
https://github.com/odoo/odoo/blob/be611deca82c0f0e9c110d2ff35f3e081e94b3be/odoo/models.py#L1192
After applying this commit will resolve this issue by raising an exception
sentry-5093791365This update resolves a bug that occurred when users clicked the status bar on Follow-up Reports after excluding certain records. The issue stemmed from a missing data field within the system, preventing proper report rendering. This fix adds a check to ensure the necessary data is present before processing, improving report stability.
Original PR description
This traceback occurs when the user clicks on the `statusbar` of `followup reports` by excluding all `aml's`. To reproduce this issue:- 1) Install `Accounting` 2) Open the `Follow-up-report` from…
This traceback occurs when the user clicks on the `statusbar` of `followup reports`
by excluding all `aml's`.
To reproduce this issue:-
1) Install `Accounting`
2) Open the `Follow-up-report` from `dropdown menu` of
`Customer Invoices` in `accounting onboarding dashboard`.
3) Open any one record by removing the default filter
4) Enable the `Exclude from follow-ups` for all `aml's`
5) Now click on the `status bar`
Error:-
```
KeyError: 1
File "odoo/http.py", line 2256, in __call__
response = request._serve_db()
File "odoo/http.py", line 1832, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1852, 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 1830, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1837, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2062, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 742, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 76, in web_save
return self.with_context(bin_size=True).web_read(specification)
File "addons/web/models/models.py", line 129, in web_read
vals = many2one_data[values[field_name]]
```
When the user `Excludes` all the `Followups` and clicks on the `status-bar`,
the `web_read` method triggers with a record of `res.partner` having no `followup_line_id`.
Because of that, there will be no `many2one_data` as `extra_fields` are `{}`
values_list is also empty for the recursive call of many2one_data as `co_records` is also
having no recordsets.
Which leads to an exception from the below line (128).
https://github.com/odoo/odoo/blob/0d1399d06bd5ab30918b1a84abccb0f44504a508/addons/web/models/models.py#L116-L128
After applying this commit, it will resolve this issue by adding an extra check of "many2one_data" before assigning the value from many2one_data. Which makes the code more robust.
sentry-4982604710This update resolves a technical issue that prevented users from correctly attaching receipts to expense records. Specifically, a bug caused an error when a user canceled the attachment process. The fix ensures the system handles this cancellation gracefully, preventing a crash and improving the user experience.
Original PR description
A traceback is occurring when the user tries to attach a receipt in the expense To reproduce this issue: 1) Install `hr_expense` 2) Open any existing `my expense` record 3) Click on the `Attach Receipt` button and attach a file 4) Now again attach a file through the `Attach Receipt` button 5) This time click on `cancel` while attaching a file through `Attach Receipt` Error:- ``` IndexError: list index out of range ``` When the user clicks on the cancel button when trying to attach a file, it triggers an `orm` call with `attachments` as an empty list with respected `model` & `action`. Which leads to the above traceback in the backend. After applying this commit, will resolve this issue by checking the length of the file before triggering the form. Which makes code more robust. sentry-4705156379
This update changes how payment errors are displayed to users. Instead of showing a technical exception, the system now presents a standard validation error, making it easier for users to understand and correct issues. This improves the overall user experience and reduces confusion.
Original PR description
Currently, we are showing an exception to the end user when the transaction operation fails from the below line https://github.com/odoo/odoo/blob/8b035af881a72048027072743f7ba80accd73109/addons/payment/controllers/post_processing.py#L57 Error: ``` Exception: retry ``` Which is not a valid case to show traceback to the end user, Instead of a traceback, it's better to raise a validation error. After applying this commit, the message should be shown as ValidationError sentry-5512362745
This update resolves an issue that occurred when a user deleted a warehouse and then attempted to create a new scrap. The fix prevents a traceback by ensuring a valid warehouse is selected during scrap creation, improving data integrity and preventing errors.
Original PR description
Currently, a traceback occurs when the user deletes a warehouse and tries to create a new scrap. To reproduce this issue: 1) Install `stock` without demo data 2) Archive the `warehouse` from the…
Currently, a traceback occurs when the user deletes a warehouse and tries to create a new scrap.
To reproduce this issue:
1) Install `stock` without demo data
2) Archive the `warehouse` from the stock configuration
3) Now create a new `Scrap` from `Inventory/Operations`
Error:-
```
KeyError: False
File "odoo/http.py", line 2248, in __call__
response = request._serve_db()
File "odoo/http.py", line 1823, in _serve_db
return self._transactioning(_serve_ir_http, readonly=ro)
File "odoo/http.py", line 1843, 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 1821, in _serve_ir_http
return self._serve_ir_http(rule, args)
File "odoo/http.py", line 1828, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "odoo/http.py", line 2053, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
result = endpoint(**request.params)
File "odoo/http.py", line 756, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "addons/web/controllers/dataset.py", line 38, in call_kw
return self._call_kw(model, method, args, kwargs)
File "addons/web/controllers/dataset.py", line 34, in _call_kw
return call_kw(request.env[model], method, args, kwargs)
File "odoo/api.py", line 458, in call_kw
result = getattr(recs, name)(*args, **kwargs)
File "addons/web/models/models.py", line 1006, in onchange
todo = [
File "addons/web/models/models.py", line 1009, in <listcomp>
if field_name not in done and snapshot0.has_changed(field_name)
File "addons/web/models/models.py", line 1122, in has_changed
return self[field_name] != self.record[field_name]
File "odoo/models.py", line 6610, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "odoo/fields.py", line 2954, in __get__
return super().__get__(records, owner)
File "odoo/fields.py", line 1206, in __get__
self.recompute(record)
File "odoo/fields.py", line 1421, in recompute
apply_except_missing(self.compute_value, recs)
File "odoo/fields.py", line 1394, in apply_except_missing
func(records)
File "odoo/fields.py", line 1443, in compute_value
records._compute_field_value(self)
File "addons/mail/models/mail_thread.py", line 416, in _compute_field_value
return super()._compute_field_value(field)
File "odoo/models.py", line 4936, in _compute_field_value
fields.determine(field.compute, self)
File "odoo/fields.py", line 100, in determine
return needle(*args)
File "addons/mrp/models/stock_scrap.py", line 38, in _compute_location_id
res = super(StockScrap, remaining_scrap)._compute_location_id()
File "addons/stock/models/stock_scrap.py", line 74, in _compute_location_id
scrap.location_id = locations_per_company[scrap.company_id.id]
```
When the user tries to create a new scrap without a warehouse a traceback occurs, because in the below lines `locations_per_company` is getting through the warehouse.
If there is no warehouse for that company the `locations_per_company` will be empty.
which leads to the above traceback when fetching a value from `locations_per_company`.
https://github.com/odoo/odoo/blob/0ac43fa3cffce83e88accda435f3315600af558a/addons/stock/models/stock_scrap.py#L64-L74
After applying this commit, it will resolve this issue by raising an usererror when there is no `locations_per_company`
sentry-5631303884This update resolves an issue where new sale orders were created without a specified Incoterm. The change ensures that the company's default Incoterm is automatically applied when a new sale order is created, streamlining the sales process and improving data consistency. This prevents manual entry of Incoterms and reduces potential errors.
Original PR description
Currently, when creating a new sale order Incoterm value remains empty. <b>Steps to reproduce:</b> 1) Install sales, stocks, and enable incoterms for sales in settings 2) Give the default Incoterms value in the settings 3) Try to create a new SO record <b>Issue:-</b> Even after providing the default incoterm value in the settings, The value of incoterm remains empty while creating the SO. <b>Solution:-</b> Give the company incoterm value as the default incoterm in the definition of incoterm in sale order. opw-4700346
This update fixes a bug that occurred when users entered a maximum appointment duration. The issue caused a system error due to an overly large number being processed. This change ensures the system can correctly handle maximum duration values without crashing, improving the user experience when scheduling appointments.
Original PR description
A traceback occurs when the user gives a maximum duration value while updating an appointment. To reproduce this issue: 1) Install appointment 2) Open an appointment record from the grant view of the calendar event 3) Give the maximum duration value 4) Click on preview Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value, it calculates the time from the below. https://github.com/odoo/enterprise/blob/e74b05fa7a777053fd0e2cd5a265de365e1e434a/appointment/models/appointment_type.py#L623-L624 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves an issue where creating a new appointment with the maximum allowed duration caused a system error. The fix prevents an 'OverflowError' by correctly handling large duration values, ensuring users can accurately set appointment lengths without disrupting the system. This improves the appointment scheduling process.
Original PR description
A traceback occurs when the user gives a maximum duration value while creating a new calendar event. To reproduce this issue: 1) Install appointment 2) Create a new appointment from the Gantt view 3) Give the maximum duration value Error:- ``` OverflowError: Python int too large to convert to C int ``` This is because when the user gives a maximum duration value it is used to calculate the time from the below. https://github.com/odoo/odoo/blob/a4c46f358401077a65106a6172b2a636755d41aa/addons/calendar/models/calendar_event.py#L369 This leads to the above traceback because of the duration value sentry-5926537828
This update resolves a bug that caused an error when users attempted to access the website after deleting all websites within the Odoo system. The fix ensures a minimum website requirement is maintained, preventing the 'ValueError: Expected singleton: website()' error. This improves website functionality for all users.
Original PR description
Currently, a traceback occurs when the user deletes all the websites and tries to open the website. To reproduce this issue: 1) Install the website 2) Delete the default website from external identifiers in settings/technical 3) Now delete all websites from website/configuration/websites 4) Tries to access or open the website Error:- ``` ValueError: Expected singleton: website() ``` Initially, there is a check for at least one website while uninstalling the websites, But after the below commit the code is changed only to check for the default website. But if the user deleted the external identifier of the default website and deleted all the websites it leads to a traceback. https://github.com/odoo/odoo/pull/113405/commits/60adaf5632ddfe3f68da369a2e9642ad639da37e After applying this commit, it will resolve this issue by ensuring at least one website is required. sentry-5900356108
This update corrects a technical issue that prevented users from uploading files without a name, resulting in a traceback error. By providing a default value, the system now handles this scenario gracefully, ensuring a smoother user experience.
Original PR description
Currently, a traceback may arise when the user uploads a file with no name. Error:- ``` TypeError: Web_Editor.add_data() missing 1 required positional argument: 'name' ``` When the value of the `name` we get from the RPC call is `undefined`, we get this traceback on the backend. If there is no `name`, this case is already handled in the python side https://github.com/odoo/odoo/blob/6838782baf222db4591edce5fe80f5af3a39810c/addons/web_editor/controllers/main.py#L261-L266 So by just giving the fallback value if there is no name, we can resolve this issue. sentry-5741581459
This update resolves a technical issue that caused a traceback when users removed the UOM from Sale Order Lines. The fix ensures the UOM is correctly handled during price calculations, preventing errors and improving data accuracy. This impacts the pricing of sales orders.
Original PR description
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales…
Currently, a traceback occurs when the user removes the UMO from the Sale Order Line. To reproduce this issue: 1) Install `sale` 2) Enable `UOM`, and `Pricelist` with advanced rules from sales configuration 3) Create a new pricelist with a `price rule` of `discount` and make sure to change the `discount policy` to `without_discount` from the pricelist configuration 4) Now create a new `Quotation` with the pricelist 5) Remove the `UOM` from the Order Lines and update the Quantity Error:- ``` ValueError: Expected singleton: uom.uom() ``` When the user removes UOM from the SOL it triggers a compute method `_compute_discount` through which another method `_get_pricelist_price`. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/sale/models/sale_order_line.py#L518-L522 In the second method, UMO is used to compute the price for the `pricelist item`, but in that `_compute_price`, `uom.ensure_one()` is used. Which leads to the above traceback. https://github.com/odoo/odoo/blob/d83bd4f8970e5495205cf2fa583d9343368b5d70/addons/product/models/product_pricelist_item.py#L362-L364 By applying this commit will resolve this issue by taking UOM from product, which is a required field in product. sentry-5537497781
This update resolves an issue where users experienced a type error when creating payroll pay slips with contracts that lacked an end date. The fix adds a necessary check to ensure the correct data types are used, preventing the error and allowing users to successfully generate pay slips. This improves the reliability of the payroll process.
Original PR description
Currently, a traceback occurs when the user tries to create a pay slip with a contract and without an end date. To reproduce this issue: 1) Install `hr_payroll` without demo data 2) Create a new record for `payroll/payslip/to pay` 3) Create a new contract then remove the `start date` and change the `end date` in the period. 4) An error will occur Error: - ``` TypeError: '<' not supported between instances of 'bool' and 'datetime.date' ``` Here in the below line, you can see that when the user only gives an end date and have a contract it leads to a type error. https://github.com/odoo/enterprise/blob/3f1c5535235646c0444acffe0bf4ecf756b6b73c/hr_payroll/models/hr_payslip.py#L1002-L1003 Note:- If the contract has an end date and the user gives the end date in the period, it also leads to Typeerror from different lines. After applying this commit, it will resolve this issue by doing an additional check. sentry-5635149758, 5405887212
This update fixes an error in the Timesheet/Planning Analysis report that incorrectly calculated hours for shifts starting or ending outside of regular workday times. The system now accurately determines the actual overlap between shifts and work schedules, ensuring more precise time tracking and reporting. This improves the reliability of time data used for payroll and analysis.
Original PR description
When a multi-day planning shift starts later than the workday start time or ends earlier than the workday end time, the Timesheet/Planning Analysis report was incorrectly calculating hours for those partial days. Before: - V17: Showed full working day hours (8h) for all days, resulting in incorrect totals - The system divided allocated_hours evenly across working_days_count, ignoring actual shift start/end times After: The report now calculates the actual time overlap between the shift and the working schedule for each specific day by: - Finding the intersection of shift times with work attendance periods - Excluding lunch breaks (day_period != 'lunch') - Computing actual hours worked per day instead of dividing evenly - Applied same logic to planned_hours, planned_costs, and difference fields - Added COALESCE to handle NULL values safely opw-5126359