Daily updates from Odoo
Friday, February 27, 2026
341 changes
26 changes
Enhancements to existing features
This update streamlines the user experience for accessing notification settings within the Discuss app. Previously, settings opened in a dialog, now they appear in a dropdown, creating a more consistent and user-friendly interface. Minor UI improvements have also been made for better visual harmony.
Original PR description
Before this PR, opening the notification settings from the thread action (In Discuss App) displayed them in a dialog, which made the UI less consistent with other thread actions. After this commit, opening the notification settings from the thread action displays them in a dropdown instead of a dialog, providing a more consistent and streamlined user experience. Task-5936685 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update streamlines the user experience by changing how notification settings are accessed from thread actions in the Discuss sidebar. Previously, settings opened in a dialog, now they open in a dropdown, creating a more consistent and user-friendly interface.
Original PR description
Before this PR, opening the notification settings from the thread action in the Discuss sidebar displayed them in a dialog, making the UI inconsistent with other thread actions. After this PR, the notification settings open in a dropdown instead of a dialog, ensuring a more consistent and streamlined user experience. community: https://github.com/odoo/odoo/pull/247352 task-5936685
This update clarifies the process for setting an out-of-office period by introducing separate start and end date fields. Previously, users could unintentionally create indefinite out-of-office periods due to a confusing workflow. This change simplifies the setup and reduces the risk of errors.
Original PR description
In the user preference panel, the end date of the out-of-office period is not displayed by default. To define an end date, users must first click the field and then select the "Range" option in the calendar picker. Because these steps are not intuitive, users may enter only a start date and omit the end date, inadvertently creating an unlimited out-of-office period. To address this issue, we will introduce two separate fields: one for the start date and one for the end date. The end date field will appear only after a start date has been selected. This approach clarifies the workflow, reduces the risk of incomplete entries, and keeps the form view concise. Task-5435466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248651
Resolved issues and error corrections
This update resolves an issue where action buttons on the work entry Gantt view would cause errors when no employees were assigned to selected entries. The fix now intelligently hides these buttons when there are no employees, preventing unexpected errors and improving the user experience.
Original PR description
On gantt view of work entries when user multi-selects entries, action buttons appears Ex. Set, Reset etc. When their are no employees in the column, on clicking these action buttons gives traceback. Ex:- `TypeError: Cannot read properties of undefined (reading '0')` or `KeyError: 'employee_id'` This fix will hide these buttons when there are no employees present. task-[5445718](https://www.odoo.com/odoo/project/1251/tasks/5445718) Forward-Port-Of: odoo/enterprise#108995 Forward-Port-Of: odoo/enterprise#105957
This update fixes an issue where Point of Sale orders would incorrectly display the wrong date if the PoS device had an outdated time setting. Now, orders are always created with the correct date as determined by the server, ensuring accurate order records and preventing potential discrepancies.
Original PR description
Before this commit, if the PoS device had a wrong date, the orders created while being online would have a wrong date_order. This commit prioritizes the server date for the order that is currently being processed when the PoS is online. opw-5884498 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248897
This update resolves a technical problem that was preventing users from correctly searching for products within the product catalog. The fix addressed a race condition and a broken configuration in the search panel, ensuring accurate and reliable search results. This improves the user experience and prevents potential errors.
Original PR description
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading.…
- `PurchaseStockProductCatalogSearchModel._fetchSections()` was calling `super._fetchSections()` without `await`, causing `sectionsPromise` to resolve immediately before sections finished loading. This made `expandDefaultValue()`, `expandValues()`, and `updateActiveValues()` run with empty sections in `onWillStart`, leaving `state.expanded` and `state.active` uninitialized and causing a crash when the template accessed `state.expanded[section.id][valueId]`.
```
UncaughtPromiseError > OwlError
Uncaught Promise > An error occured in the owl lifecycle (see this Error's "cause" property)
Occured on 127.0.0.19:8069 on 2026-02-24 10:16:04 GMT
OwlError: An error occured in the owl lifecycle (see this Error's "cause" property)
Error: An error occured in the owl lifecycle (see this Error's "cause" property)
at handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:762:101)
at App.handleError (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1420:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:787:19)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
Caused by: TypeError: Cannot read properties of undefined (reading '1')
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:25:69)
at App.callTemplate (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1011:129)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:85:15)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:138:34)
at PurchaseSuggestCatalogSearchPanel.template (eval at compile (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:1375:421), <anonymous>:19:29)
at Fiber._render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:786:96)
at Fiber.render (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:785:6)
at ComponentNode.initiateRender (http://127.0.0.19:8069/web/assets/9723d8e/web.assets_web.min.js:855:47)
```
- `purchase_stock.ProductCatalogSearchPanelContent` had a broken xpath: a `<t t-if>` element inside `<xpath position="attributes">`. OWL's `modifyAttributes()` silently skips non-`<attribute>` children, so the conditional class was never applied. Replaced with a proper `t-att-class` ternary binding.
Forward-Port-Of: odoo/odoo#250810This update resolves several issues impacting the Odoo Profiler's reliability, specifically related to thread management and data handling. The fixes prevent errors that could interrupt profiling sessions and ensure consistent data collection, leading to more accurate performance insights. These improvements enhance the overall stability and usability of the profiling tool.
Original PR description
Multiple fixes for the Profiler. Issues: - Python throws cannot join current thread when using the entry count with memory and traces async profilers. - The periodic profilers were waiting the full amount of the sleep before ending. - When using the entry_count, the memory profiler was throwing a non serializable object error - Sometimes the memory collector throws an error that the tracemalloc needs to be started so that it collects. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248501 Forward-Port-Of: odoo/odoo#232551
This update ensures that employees cannot check in through the attendance app if location tracking is enabled and a location cannot be determined. This prevents inaccurate attendance records and ensures data integrity, particularly important for payroll and workforce management reporting.
Original PR description
When a user is trying to check in on the attendance app with the setting Device tracking enabled and the location cannot be determined, it should raise an error to prevent the check-in without a valid location. Task: 5486178 Forward-Port-Of: odoo/odoo#249753
This update resolves an issue related to how sick leave is tracked in Belgium, specifically when extended periods of absence occur. The change moves a targeted logic to a localized module to avoid conflicts and ensure accurate work entry type matching, improving the reliability of sick leave calculations. This addresses a previous localization problem and enhances the overall accuracy of HR data.
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 and we move the BE specific changes to the BE localization module. To do this, we move the logic in a function which we will override inside that module (see related Enterprise PR). Task: 5472538 Enterprise PR: https://github.com/odoo/enterprise/pull/105776 Forward-Port-Of: odoo/odoo#246116
This update corrects a problem in how Odoo handles extended sick leave in Belgium. Previously, different work entry types for consecutive sick days caused matching issues. The fix ensures accurate tracking of sick leave durations by specifically recognizing different types of sick leave, resolving a previous issue in the Hong Kong localization.
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 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
Features or functions removed from Odoo
This update removes a redundant model, `res.city`, from the `l10n_gt` localization module. This model was previously included but wasn't a necessary dependency for the GT version of Odoo. This change ensures a cleaner and more streamlined codebase.
Original PR description
This reverts commit 728465e0a4a9b651dd6e1059bd4788b0c13e2a52. The model `res.city` is defined in `base_address_extended` which isn't in `l10n_gt` dependencies. runbot-241066 Forward-Port-Of: odoo/odoo#250606
27 changes
Resolved issues and error corrections
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 referenced 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 fixes a critical error in the calculation of employer costs for Swiss payroll. Previously, employer costs were incorrectly displayed as zero due to a missing flag. The update now accurately computes and displays these costs, ensuring accurate financial reporting and compliance for Swiss businesses using Odoo Enterprise.
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
This update fixes a technical error preventing managers without specific permissions from scheduling meetings related to appraisals. The fix replaces a restricted data field with a simpler one, ensuring managers can now correctly schedule meetings as intended. This improves the user experience for all managers.
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
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
Features or functions removed from Odoo
This update removes a redundant model (`res.city`) from the `l10n_gt` localization module. This model was previously included but wasn't a necessary dependency for the GT version. This change simplifies the codebase and improves efficiency.
Original PR description
This reverts commit 728465e0a4a9b651dd6e1059bd4788b0c13e2a52. The model `res.city` is defined in `base_address_extended` which isn't in `l10n_gt` dependencies. runbot-241066 Forward-Port-Of: odoo/odoo#250606
Documentation and clarification updates
This pull request updates the signature for Mega-ramo, a key element within Odoo. This change ensures proper identification and compliance with legal requirements. It's a routine update to maintain accuracy and adherence to Odoo's standards.
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#250493
This pull request updates the contributor information for Elvis Begovic in the Odoo documentation. The change was made to ensure proper legal compliance and verification of the contributor's agreement. This update confirms that Elvis Begovic has signed the necessary legal agreement to contribute to the Odoo project.
Original PR description
Description of the issue/feature this PR addresses: Cla Current behavior before PR: No cla Desired behavior after PR is merged: Verified --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250200
9 changes
Resolved issues and error corrections
This update resolves an issue where kiosk users couldn't add products with descriptions and no attributes to their order. The fix ensures these products are correctly recognized as valid and allows users to add them to the cart, improving the kiosk ordering experience. This prevents a frustrating user experience and ensures all products can be ordered.
Original PR description
Steps to reproduce: ------------------------------- - Install pos_self_order - Open kiosk - Select product that has description and no attributes. - Attempt to add it to the cart. Issue: ----------------------- - Add to Cart button remains disabled despite product being available. Cause: ------------------------- - The system incorrectly treated the product as having incomplete selection. Fix: --------------------- - Ensure such products are treated as valid and can be added to the cart. Task-4868023
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
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
14 changes
New functionality added to Odoo
This update allows users to directly link materials to specific employees within planning schedules. When an employee is assigned to a planning slot, the associated material is automatically added to the resources, streamlining resource allocation and shift assignments. This improves planning efficiency and accuracy.
Original PR description
In this commit, we add a field "Assigned To" to materials. This allow users to assign one employee to the material. With that, when adding an employee to a planning slot, its assigned material will automatically added to the resources, and a shift will be assigned to it. task-5259038
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
5 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#24776115 changes
Resolved issues and error corrections
This update resolves a warning generated during testing related to fake PDF content. The change replaces these fake files with a minimal PDF file, ensuring consistent test results and preventing potential issues with the PyPDF library. This improves the reliability of our 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
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