Daily updates from Odoo
Navigate
Branch
Monday, December 1, 2025
239 changes
15 changes
Resolved issues and error corrections
This update fixes an issue where tasks created from sales order lines weren't automatically reflecting the correct number of hours. Previously, allocated hours were incorrectly set to zero for certain service products. This change ensures that the allocated hours on tasks are accurately set to match the quantity of the corresponding sales order line, improving the accuracy of time tracking.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237398 Forward-Port-Of: odoo/odoo#234524
This update resolves an issue that prevented users from creating bank statements when the chart of accounts wasn't properly configured. The fix ensures the system only attempts to create bank statements when related accounts are present, preventing a syntax error and improving stability.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit only executes the SQL query when there are valid accounts to consider. sentry-7059353053 Forward-Port-Of: odoo/enterprise#100459
This update resolves an issue where the DIOT tax report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting reliability. This change addresses a technical bug related to data processing within the DIOT reporting module.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#100843 Forward-Port-Of: odoo/enterprise#96529
A test case in the account module was failing in the community version due to a difference in payment state handling between community and enterprise. This fix moved the test case to the enterprise environment to ensure it aligns with the expected behavior and resolves the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453 Forward-Port-Of: odoo/odoo#237933 Forward-Port-Of: odoo/odoo#237881
A test case in the Odoo Enterprise module was failing due to differences in payment state handling between the community and enterprise versions. This change moved the test case to the enterprise environment to ensure it accurately reflects the expected behavior, resolving the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453 Forward-Port-Of: odoo/enterprise#100865 Forward-Port-Of: odoo/enterprise#100834
This update corrects a bug where 'Cash on Delivery' was incorrectly offered for orders with 'In-Store' delivery. The fix ensures that 'Cash on Delivery' is only available when the delivery type is 'Pick Up In Store', streamlining the checkout process for customers and preventing confusion. This resolves an issue reported by our team.
Original PR description
### Issue: In this issue, `allow_cash_on_delivery` is allowed when delivery type is pick up in store. #### Steps to reproduce: 1. Create a `fixed_price` delivery method 2. Check `Cash on delivery` checkbox 3. Change the delivery type to `in_store` and configure it 4. Activate cash on delivery payment method 5. Choose a storable ptoduct on the /shop, checkout with a created dm and proceed to payment 6. Observe that you see the 'cash on delivery' pm for pickup in store. Currently, `allow_cash_on_delivery` is invisible when `delivery_type` is set to `in_store`. However, it's not set to `False`, once the type is changed to `in_store`. opw-5258535 Forward-Port-Of: odoo/odoo#235434
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and reduces potential errors.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#97417 Forward-Port-Of: odoo/enterprise#78380
This update prevents a critical error that occurred when employees without a working schedule attempted to view their time off in the Gantt view. The fix ensures the system gracefully handles missing schedule data, improving the user experience and preventing data display issues. This resolves a technical issue impacting time off reporting.
Original PR description
Currently, an error occurs when an employee has no working schedule set and the user tries to open the Time Off overview in the Gantt view. **Steps to Reproduce:** 1. Install `hr_holidays_gantt` with demo data. 2. Remove the **Working Hours**(Payroll section) of **Marc Demo**. 3. Navigate to: Time off > Overview. **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error. **Fix:** This commit skips the computation when the contract does not have a working schedule set. [1] - https://github.com/odoo/enterprise/blob/db049f42ad4c2c291b2d64a9e637cd2292c280e8/hr_holidays_gantt/models/hr_leave.py#L204 sentry-7017326141
This update fixes a previous issue where document fields weren't visible on the employee form. A new 'Documents' section has been added to the Personal tab, allowing HR staff to easily manage and view employee documents within the system. This improves data accessibility and streamlines HR workflows.
Original PR description
- These fields were not available in the employee form view. - create a new section named 'Documents' under the Personal Tab in employee form view - added the fields in the employee form view task-5366982
This update fixes a previous issue where important document fields for employees were missing from their profile views. A new 'Documents' section has been added to the employee form, providing a centralized location to manage and view employee-related documents. This improves data accessibility and streamlines HR processes.
Original PR description
- These fields were not available in the employee form view. - create a new section named 'Documents' under the Personal Tab in employee form view - added the fields in the employee form view task-5366982
This update resolves a regression issue in the Egyptian payroll tests. Previously, the tests were designed to project allocations for 2025 and failed when the system's date moved beyond that year. This fix ensures the tests remain reliable by adapting to future date ranges, preventing unexpected failures.
Original PR description
The Egyptian payroll regression tests built allocations for 2025 and relied on the runtime date, so they start failing once the global fake date advances beyond that year (e.g., 2026). task-5215779
This update fixes a bug preventing negative sales amounts (like credit notes) from appearing in the exported XBRL report for the Dutch EC Sales List. Previously, only positive amounts were included, leading to incomplete reporting. This change ensures all sales figures, including negative values, are accurately reflected in the report.
Original PR description
To replicate: 1. Install l10n_nl_reports_sbr_icp 2. Create an european partner with a VAT number 3. Create a credit note for this partner 4. Go to Accounting > Reporting > EC Sales List 5. The negative line appears in the report 6. Click on XBRL to export the report The negative line is not included in the exported report Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values. opw-5220622 Forward-Port-Of: odoo/enterprise#100669 Forward-Port-Of: odoo/enterprise#100009
This update fixes an issue where changes made within the Colibri interaction framework weren't being properly reset when the interaction ended. Previously, data wasn't fully restored to its original state. This ensures a more reliable and consistent user experience within Colibri.
Original PR description
When the Interaction framework was introduced in [1], fields that were modified by t-outs weren't restored to the initial values, although initial values were saved. This commit restores them on destroy. [1]: https://github.com/odoo/odoo/commit/dd13994674d4ef4683f5a4d46a1f604650cfb92b Forward-Port-Of: odoo/odoo#237912
This update fixes a bug that caused video streams with background blur to freeze when users switched between browser tabs during video calls. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring smooth and uninterrupted calls.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls. **Current behavior before PR:** When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life. **Desired behavior after PR is merged:** The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times. task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226455
This update resolves a technical issue preventing correct event description editing within the website. The fix clarifies HTML tag specifications, ensuring the system accurately reflects changes made by users. This improves the overall event management experience.
Original PR description
The tour test testUI.test_website_event_tour was failling because the HTML tag specify to edit the event description was not precise enough and led to wrong modification. I specified the itemprop property of the specific tag to edit in order to erase the previous ambiguity. The proposed fix is inspired by the saas-18.4 version of the code. Runbot error: 226574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236549
12 changes
Enhancements to existing features
This update adds logging to the automated reconciliation process, making it easier to identify and resolve issues when it runs in user databases. Previously, debugging this process was difficult, and these new loggers will provide more visibility into the reconciliation's steps. This improves reliability and reduces potential disruptions.
Original PR description
For the moment, it's difficult to debug in users databases in the cron and the try auto reconcile. This commit will add some loggers to be more aware of what's going on. task-5358849
This update enhances Odoo's tax calculations to properly account for taxes based on volume, such as VAT on sales of goods. This change, requested during Odoo Exp 2025, ensures more accurate tax calculations for businesses using volume-based tax models. It impacts the account_tax_python module and related components.
Original PR description
The use case to cover is when you have a volume based tax. Requested during Odoo Exp 2025. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237434 Forward-Port-Of: odoo/odoo#232146
This update simplifies and streamlines testing of Odoo's accounting XML files. The new framework provides a standardized way to save, update, and manage assertions, reducing errors and making test maintenance easier. This improves the reliability of our accounting tests.
Original PR description
> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files. This commit adds helpers and improves on the way we assert…
> This is a backport of the merged https://github.com/odoo/odoo/pull/235565 - with a couple of improvements & adaptations to the test files. This commit adds helpers and improves on the way we assert XML files in `AccountTestInvoicingCommon` and all accounting test that extend from it. From now on, all accounting test code that assert an XML tree/string to an XML file should call the `assert_xml` helper, and design their test file name/location/etc. around this framework. This approach has a few major benefits: Assert / Save XML When testing XML files, we often need to perform create/read/update operations on the asserted XML to make sure it corresponds to the most updated/intended data. Previously, to save something to an XML, a developer would need to write their own local helpers to save the XML in the right directory. This was cumbersome and error-prone, so we decided to design a helper that allows developer to immediately save AND/OR update the asserted XML: to save/update an XML, we can simply add `SAVE_XML` as an additional test tags. Better test naming and optional subfolder management To better organize test files, the `assert_xml` method allows us to write just the test key name (without `.xml`), and the framework will automatically get the XML to assert/save from the `test_files` directory. An optional `subfolder` parameter is also added to allow writing to specific subfolder within `test_files`. Better `___ignore___` management in assertion XMLs Sometimes, we want to ignore a few XML node that are not relevant, or have content that are not deterministic (changes on every test run). To handle this, previously, developers would need to modify the assertion XML content by hand or write their own local script to do so. With this new framework, we just need to add an `ignore_schema.xml` file somewhere in the `test_files` directory. If put inside a subfolder, it will be applied with more priority towards the XML that are put on that specific subfolder. Save "pure" XML (before applying `___ignore___`) in temporary folder When calling `SAVE_XML`, before applying the ignore patches, the XML will be saved in a temporary folder (same folder as the screenshots for tours), so that developers can use them in external tests in the future, and for any other saving reasons. In addition, this commit also: - add `extra_tags` helper to save all the common tags for EDIs, for a better way to enable `EXTERNAL_MODE` testing inspired by `l10n_mx_edi` - convert some non-assert XML test helpers into a class method - canonicalize the XML to ensure consistency of the generated test files following the C14N Version 2 standard. (Deterministic namespaces location, sorted attributes, etc.) task-4891206 Forward-Port-Of: odoo/odoo#237435 Forward-Port-Of: odoo/odoo#237285
Resolved issues and error corrections
This update fixes an issue where tasks created from service orders weren't automatically reflecting the order's quantity in their allocated hours. Previously, the hours were incorrectly set to zero unless the service type was 'milestones' or 'manual'. Now, the task's hours will accurately match the quantity of the corresponding service order line, ensuring accurate time tracking for service projects.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237398 Forward-Port-Of: odoo/odoo#234524
This update fixes an issue where vendor bills created in the Documents module incorrectly defaulted to the company's currency instead of the vendor's. Now, when a vendor is selected in the Documents module, the bill automatically uses the vendor's currency, ensuring accurate financial reporting. This improves data consistency and reduces potential errors.
Original PR description
**Issue:** When creating a vendor bill or vendor refund through the Documents module after selecting a supplier, the currency defaults to the company's currency instead of the vendor's. However, if the supplier is selected later in the Accounting module, the correct supplier currency is applied. **Steps to reproduce:** - In Documents, upload a bill. - Click on the bill and assign a vendor (whose supplier currency is different from the company's currency). - Click on "Create Vendor Bill". The used currency isn't that of the supplier. opw-4406074 Forward-Port-Of: odoo/enterprise#97417 Forward-Port-Of: odoo/enterprise#78380
A recent test failure related to editing event descriptions has been resolved. The fix clarifies the HTML tags used to ensure accurate modifications, drawing inspiration from a planned update in the next version. This improves the reliability of the event editing process.
Original PR description
The tour test testUI.test_website_event_tour was failling because the HTML tag specify to edit the event description was not precise enough and led to wrong modification. I specified the itemprop property of the specific tag to edit in order to erase the previous ambiguity. The proposed fix is inspired by the saas-18.4 version of the code. Runbot error: 226574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the invoice date was unexpectedly changing after a company partner's address was modified. The fix prevents the invoice date from being recalculated when an invoice is in the ‘posted’ state, ensuring data accuracy and consistency. This change improves the reliability of invoicing processes for Czech customers.
Original PR description
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any…
**Steps to reproduce** 1.Install Accounting, Contacts, and l10n_cz. 2.Create an invoice with a future `invoice date` and confirm it. 3.Go to Contacts → open the company (res.partner). 4.Modify any address field (street, zip, etc.) and save. 5.Return to the invoice → in the chatter, the `date` field has change unexpectedly > Note: The `date` field is not shown in invoice default form view. Add it manually for clearer reproduction. **Issue** - The confirmed invoice `date` changes when updating the company partner’s address. **Cause** https://github.com/odoo/odoo/blob/7a1b27e5985b3b16768bea450c51226ae3659c76/addons/l10n_cz/models/account_move.py#L20-L24 - When creating an invoice, the `date` field is correctly set based on the `taxable_supply_date` while the invoice is in the draft state. After confirming (posting) the invoice, it moves to the `posted` state. - However, when updating the partner address, the `_compute_date` method is triggered again, which calls `super()` and recomputes the `date` field using the standard logic. Since the invoice is already in the `posted` state, the CZ-specific condition is not satisfied, and the `date` gets updated incorrectly. **Solution** - Update `_compute_date` to only call super() for invoices in draft state. - This prevents unwanted recomputation of the `date` on post invoices. opw - 5086961 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229513
This update fixes an issue where negative sales amounts (like credit notes) were not being included in the exported XBRL report for the EC Sales List. The change ensures that all sales figures, including negative ones, are now correctly generated and available for export, improving report accuracy and compliance.
Original PR description
To replicate: 1. Install l10n_nl_reports_sbr_icp 2. Create an european partner with a VAT number 3. Create a credit note for this partner 4. Go to Accounting > Reporting > EC Sales List 5. The negative line appears in the report 6. Click on XBRL to export the report The negative line is not included in the exported report Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values. opw-5220622 Forward-Port-Of: odoo/enterprise#100669 Forward-Port-Of: odoo/enterprise#100009
This update corrects a technical error that prevented bookings from appearing correctly in the restaurant appointment system. The fix involves 'freezing time' to ensure bookings are always displayed accurately, regardless of date changes. This improves the reliability of appointment scheduling.
Original PR description
Depending on when the booking form was opened and closed you could end up no seeing the booking if the day had changed. Freezing time should ensure we don't have this scenario error-234349
This update resolves an issue where background blur in video calls would cause video streams to freeze when users switched to another tab. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring a smoother experience for users regardless of which tabs they are using.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls. **Current behavior before PR:** When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life. **Desired behavior after PR is merged:** The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times. task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226455
This update resolves an issue where the system was incorrectly creating multiple bank accounts from UBL invoices. The fix filters out duplicate account numbers, ensuring accurate bank information is imported into Odoo. This improves data integrity and avoids potential accounting errors.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621 Forward-Port-Of: odoo/odoo#237850 Forward-Port-Of: odoo/odoo#236676
This update corrects a previous issue where the system incorrectly remembered the first invoice sending method chosen for a partner. This meant users wouldn't be able to easily switch to preferred sending methods like PEPPOL, leading to confusion. This change ensures users can now set their desired sending method without being automatically defaulted back to email.
Original PR description
Before this commit, we were setting the preferred invoice sending method on the Contact depending on what was in the first Send & Print to this specific partner. It's a bad idea because user don't know about this setting and when they want to switch the default method (example email -> peppol) the wizard will keep propose them to send it by email only and they don't know why since they never knowingly set it to "email". task-none (feedback from AVW) Forward-Port-Of: odoo/odoo#237956
1 change
Resolved issues and error corrections
This update resolves an issue that prevented users from placing test orders when a product's tax was set to a Group of Taxes without any defined tax rates. The fix corrects a technical error within the Urban Piper integration, ensuring test orders can now be successfully created under this scenario. This improves the reliability of the PoS testing process.
Original PR description
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module -…
When creating a test order for a product whose tax is configured as a Group of Taxes without any definitions, a traceback occurs. Steps to reproduce the error: - Install ``pos_urban_piper`` module - Configure Urban Piper integration for the PoS - Create a new tax without Definition > ``Tax Computation: Group of Taxes`` > Save - Create a new product > Set the above tax in sales taxes > Save - Open the session for PoS - Go to Settings > Urban Piper Location > Set Food Delivery Platforms > Save - Click Test Order > Select the product and Delivery Provider > Place Order Traceback: ```py IndexError: list index out of range ``` https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/pos_urban_piper/controllers/main.py#L319-L322 The issue happens because ``flatten_taxes_hierarchy()`` calls ``_flatten_taxes_and_sort_them()`` method at [1], which returns an empty record when the group tax has no children at [2]. As a result, ``tax_types`` becomes an empty list ([]), leading to an IndexError when trying to access ``tax_types[0]``. [1]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L2786 [2]: https://github.com/odoo/odoo/blob/57850b32332a71933a4f6b52d7428684de831f4b/addons/account/models/account_tax.py#L795 sentry-6984648461
33 changes
New functionality added to Odoo
This update introduces a new process to accurately calculate and apply year-end tax adjustments for employees in Egypt and Pakistan. Previously, HR managers had to manually correct tax discrepancies. Now, a wizard allows for the calculation of the difference between expected and actual tax, automatically applied to the final payslip.
Original PR description
purpose: In Egypt & Pakistan, the tax amount is based on monthly computations, where each month's portion is accounted for. However, in cases where an employee gets a raise during the year that increases the gross amount into a different tax slab, the tax amount paid would not be correct, and in most cases, HR managers are responsible for computing it manually. The reason behind this task is to introduce a way to compute the difference, if any, and apply it to the last payslip of the year. current behavior: - added server action for End of year Tax Adjustment which opens a wizard with the actual ytd gross and ytd tax and on confirming, it creates a salary input on the payslip with the difference between actual tax that should be paid and ytd tax - added 2 salary rules for positive and negative tax correction - added corresponding accounts for the salary rules (Eg only) task-id: 5092724
This pull request introduces a new module within Odoo Enterprise focused on managing equity information, including share classes, transactions, and valuations. This addition provides a framework for businesses to track and report on equity-related data, streamlining financial reporting and compliance processes. The module includes demo data and security settings for initial configuration.
This pull request introduces a new module within Odoo Enterprise focused on managing equity-based investments. The module provides tools for tracking share classes, shareholders, transactions, and valuations, offering a more comprehensive solution for businesses managing equity holdings. This addition expands Odoo's capabilities to support financial reporting and investment tracking.
Enhancements to existing features
This update significantly improves the speed of auditing large financial reports. By caching report data and line expansions, users avoid lengthy reloads and blank screens when navigating between reports and their details. A warning banner indicates when data is being refreshed in the background.
Original PR description
When auditing large reports, users often navigate back and forth between the report and its underlying move lines. Each time the user returns to the report, it triggers a full reload, resulting in a blank screen and long wait time making auditing slow and painful. This commit caches the report information, and line expansion rpc calls in disk with validity of 90 minutes. RPC calls are being called asynchronously and report is updated if data changed. While data is being refreshed in the background, cached report is displayed along with a warning banner informing the user that report is being loaded. task-5145462
This update enhances tax reports by allowing labels to be associated with cell values. This solves the issue of using codes in multi-column reports, making it easier to understand and reference data directly within the report UI. It improves the clarity and usability of tax reporting.
Original PR description
Tax reports often denote values by codes. While these are easily added to line names in simple reports, this is insufficient for multi-column reports where every cell corresponds to a code needed for reference. This commit introduces a mechanism to attach specific labels to report cells using a reserved expression prefix: `_cell_label_`. When an expression is named with this prefix (e.g`_cell_label_balance`), its value computed using the 'text' engine is treated as a label for the target expression (e.g `balance`). The label is then displayed next to the cell value in report UI. task-5233075
This update enhances Odoo's automation performance by logging the duration of each action. The logging system now uses increasing log levels based on action duration, helping the Odoo Infra team identify and address slow-running automations. Additionally, statistics on automation run times are now included in server dumpstacks.
Original PR description
The Odoo Infra team wants to be able to track down the base automations that slow down the server, but at the same time they don't want to fill logs with silly data. In this work we refactored the logging to log the run duration, the log level increases with the action duration. The longer the action takes to run, the more severe the log level is. Also as per request of the Infra team, we also included some statistics about base automations in the SIGQUIT dumpstack. At the moment the stats are a mapping action_id: accumulated run duration.
This update enhances the reliability of our website generation process by proactively verifying URLs before sending requests to the website scraper. The system now checks URLs on the IAP server to filter out invalid or unauthorized links, preventing wasted resources and potential errors. This ensures a smoother and more efficient website generation experience.
Original PR description
This PR adds the client side verification of an url for the request we make to generate a website using the website scraper. **The goal is to filter all the unwanted requests (invalid urls, banned urls) before launching the scraper process.** The check is done on the IAP server, and retrieved on the DB. The reason is that we don't want to send a request directly from the db [as this was already discussed](https://github.com/odoo/enterprise/pull/92724). Since the IAP server is also the one that will eventually do the scraping request, it also makes more sense that it is the one to check (to avoid the case where odooDB has access to an URL and IAP server does not).
This update modifies the VAT report process to include tracking of payment steps. The change adjusts a setting within the accounting system to specifically flag the 'pay' stage for VAT reports, ensuring accurate reporting of payments. This improves the visibility and tracking of VAT payments within the system.
Original PR description
removed states_workflow `generic_state_review_submit` value from `account.return.type` to default `generic_state_tax_report` in order to add pay step in reports. task-5126401
This update enhances the initial guidance provided to users when running payruns within the Odoo Enterprise system. The previous implementation relied heavily on custom JavaScript and lacked robust testing, leading to potential instability. This change introduces a more structured tour to guide users through the payrun process, improving usability and reducing the risk of errors.
Original PR description
Payruns are currently heavily customized with javascript, and we have weak integration tests. So everytime framework makes a change in the ORM, it is likely that it might break. Such as with this PR https://github.com/odoo/odoo/pull/233635, that lead to this fix https://github.com/odoo/enterprise/pull/99771. Task: 5323872
This update ensures Odoo's Swissdec ELM certification is compatible with version 5.3. It includes key enhancements for payroll calculations, specifically related to French-crossborder workers, retirement regulations, and allowance calculations, improving compliance and accuracy.
Original PR description
This Pull request extends the Odoo Swissdec ELM Certification to the minor version 5.3. By doing so we add the following features : - Telework Percentage declaration for French-crossborder comuters - Adapting to AVS21 regulation, where retired employees can refuse their right to retirement - Adding automatic Child and education allowance calculation - Add the calculation of LPP in % - Allowing the specification of custom employer parts for LAAC and IJM Forward-Port-Of: odoo/enterprise#95518
This update enhances the payroll system by providing specific warnings for employees not included in completed pay runs. Instead of a general alert, users now see a message for each missing employee with an option to add a payslip. This improves clarity and streamlines the process of ensuring all employees are accounted for in payroll.
Original PR description
Replace the global warning for missing employees with a per-employee message. Now, employees not included in a confirmed but not validated pay run show a warning with an option to add a payslip. The message disappears when the pay run is closed. task-5156963.
This update makes a small visual adjustment to the offline systray item in the Odoo interface. The change enhances the user experience by refining the design for better clarity and visual appeal. This is a cosmetic improvement focused on presentation.
Resolved issues and error corrections
A test case in the Odoo Enterprise accounting module was failing due to differences in payment state handling between the community and enterprise versions. This change moved the test case to the enterprise environment to ensure it accurately reflects the expected behavior, resolving the reported error.
Original PR description
Community build was failing with: ``` test_bill_state_change_on_payment_state self.assertEqual(payment.invoice_ids.payment_state, 'not_paid') AssertionError: 'paid' != 'not_paid' - paid + not_paid ``` [Commit](https://github.com/odoo/odoo/pull/234725/commits/5dc43a2156e5b176e3236583b45b4838a987ee7d) In community there is no any `in_payment` state for account move records. As on changing payment state to draft It stayed in the `paid` only. `in_payment` state introduced in the enterprise module. So the test case is failing for the community version. To fix this I've moved the test case to the enterprise to retain the expected behaviour. runbot error: 234453 Forward-Port-Of: odoo/enterprise#100865 Forward-Port-Of: odoo/enterprise#100834
This update corrects a bug in Odoo where setting an employee's timezone to 'None' would cause an error. Now, the system will display a validation error, ensuring the 'Timezone' field is always populated. This prevents data inconsistencies and ensures accurate employee timezone tracking.
Original PR description
Description of the issue/feature this PR addresses: On Odoo 19.0 and master, setting an employee’s timezone to None would cause a traceback when creating or updating the employee. Current behavior before PR: a traceback when creating or updating the employee. Desired behavior after PR is merged: A Validation Error occurs because it missing required value for the field 'Timezone' (tz). Model: 'Resources' (resource.resource) task-5257749
This update resolves visual inconsistencies and display issues within the skill table across the employee, recruitment, and appraisal forms. Specifically, cropped elements and styling problems have been corrected, and outdated code for sample data display has been removed, streamlining the user experience.
Original PR description
This PR fixes various issues with how the skill table is displayed in hr, hr_recruitment, and hr_appraisal. Additionally, all code related to displaying sample data for the appraisal skills is removed in this PR, as the skills page has been hidden (rather than showing sample data) since at least v18. Issues: 1. The skills table on the employee form view is cropped on the sidees when viewing in Firefox. 2. The skills table header and the resume header on the employee form view is not aligned and styled the same way. 3. The skills table header on the employee form view is missing the separator below it when viewing in Chrome. 4. The skills table header on the applicant form view is missing the separator below it when viewing in Firefox. 5. The skills table on the appraisal form view is missing a separator when viewing on Firefox. Task-5033427
This update simplifies the HR payroll process by removing a redundant action from list views. Previously, the 'Working Schedule Change' action was unnecessary and caused validation errors when attempting to modify schedules for multiple employees. This change streamlines the workflow and improves user experience.
Original PR description
The 'Working Schedule Change' server action can only be used on a single employee, so having it in the list view does not make sense. This also avoids having a validation error when the user tries to use the action on multiple selected employees. Task: 5358499
This update resolves an issue where website generation requests could fail silently, preventing results from being fetched. Additionally, a redundant cron trigger was eliminated, reducing potential frontend errors. This ensures website generation processes run reliably and efficiently.
Original PR description
It is possible to get a serialization error when creating the website generator request. This caused the request call to go off without the record being saved. The server would start the process but the result would never be fetched. In order to avoid this scenario, we send the request in a post commit hook. Also fixed issue where we triggered the cron even when not necessary (error_still_proccessing). This was an issue because the frontend js calls this method every 10 seconds so it was easy to get a concurrent access a few times and then receiving a traceback in the frontend. (Altough the process still succeeded in the end).
This update resolves an issue where the DIOT report export failed when journal entries lacked a linked partner. The fix ensures that the export process gracefully handles entries without partners, preventing errors and improving data reporting accuracy. The change includes a safeguard to prevent crashes and a more robust method for retrieving data.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#100843 Forward-Port-Of: odoo/enterprise#96529
This update fixes an issue where a header on the spreadsheet dashboard action pushed content downwards, obscuring the bottom of the spreadsheet. The change ensures the full spreadsheet view is consistently displayed, improving usability and data visibility. This resolves a minor visual inconsistency.
Original PR description
The current rule applied on the spreadsheet action assumes that the action takes the full page but if we add a header , the full action is pushed downwards, which hides the bottom of the spreadsheet. Task: 5212448 Forward-Port-Of: odoo/enterprise#99654
This update resolves an access error that prevented managers from marking appraisals as complete. The issue occurred when users lacked the necessary HR permissions. This fix ensures that managers can correctly finalize appraisals, improving workflow efficiency.
Original PR description
STEP TO REPRODUCE: 1- Set Marc demo as a manager on an employee 2- Be sure he doesn't have the group group_hr_user 3- Log as Marc Demo 4- Create an appraisal for this employee 5- Confirm this appraisal 6- Click on "mark as done" You will have an access error; you shouldn't have it task-5349554 Forward-Port-Of: odoo/enterprise#100145
This update addresses a visual issue within the Account Online Synchronization module. The entire column displaying company information was previously partially visible; this fix now completely hides the column, improving the user interface's clarity and professionalism. This change ensures a cleaner and more consistent user experience.
Original PR description
The whole column needs to be invisible, not just the content of it Forward-Port-Of: odoo/enterprise#100446
This update resolves an error that occurred when generating the payment report from a pay run. The issue stemmed from an empty data set being returned for certain pay run configurations, leading to a key error. This fix ensures the payment report function now works correctly for all pay run scenarios.
Original PR description
When user clicks the payment report button in pay run, a traceback will appear. Steps to reproduce the error: - Install ``hr_payroll`` module - Open ``Administrator`` Employee > In Payroll tab, Set…
When user clicks the payment report button in pay run, a traceback will appear.
Steps to reproduce the error:
- Install ``hr_payroll`` module
- Open ``Administrator`` Employee > In Payroll tab, Set ``Contract, Wage`` > In Personal tab, ``Set Bank account`` > Save
- Go to Payroll > Configuration > Structures > Regular Pay > Open Net Salary rule > ``Amount Type: Fixed Amount`` and
``Fixed Amount: 0.0`` > Save
- Now, Go to Payroll > Payslips > Pay runs > Create a new Pay run > Select record > (One payslip will be created with the regular pay structure)
- Open that pay run > Click new > ``employee: Administrator`` >
``structure: worker pay`` > save
- Now, Open that pay run again > Compute > Confirm > Payment Report
Traceback:
```py
KeyError: '2'
```
https://github.com/odoo/enterprise/blob/7d90ece2756c1d8434f90a29ee6b34015a349acb/hr_payroll/models/hr_payslip.py#L2192-L2199
Here, the method ``compute_salary_allocations`` returns an ``empty dict {}`` for payslips with ``net_wage = 0.0``
https://github.com/odoo/enterprise/blob/7d90ece2756c1d8434f90a29ee6b34015a349acb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L39-L41
So, ``allocations`` becomes an ``empty dict``, so accessing a key in it causes the above traceback.
sentry-6931674861
Forward-Port-Of: odoo/enterprise#96805This update ensures that the indexed wage for Luxembourg employees remains read-only after a contract is signed. This prevents manual changes to the base salary threshold, aligning with local regulations and guaranteeing accurate payroll calculations based on annual indexing.
Original PR description
In LU, when you sign a new contract, the salary should automatically increase henceforth and is indexed each year. The indexed wage at a given year defines the base threshold for the employee's salary. It is dependent on the country's salary rules, index at signature and current index, and must not be modifiable by the company's officers. The field should thus be read-only. TaskID: 5217101
This update resolves an issue where the generation of Intrastat export files for Belgium was inconsistent, potentially leading to discrepancies in reporting. The change ensures a predictable and reliable export process, improving the accuracy of Intrastat data. This fix addresses a technical problem that impacts the integrity of business reporting.
Original PR description
Ensure be intrastat file export is deterministic Runbot error 234045
This update resolves an issue where changing a contract template on a new offer would trigger a validation error. The fix ensures that the system correctly handles work entries and salary simulations, preventing incorrect contract assignments. This improves the accuracy of offer creation and avoids potential data inconsistencies.
Original PR description
Steps to reproduce the bug: 1. install hr_contract_salary_payroll 2. check "My US Company" 3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries…
Steps to reproduce the bug: 1. install hr_contract_salary_payroll 2. check "My US Company" 3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month 4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it. 5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract. This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`: https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7 This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries. The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back) The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation. But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False` The context variable and a check before `_remove_work_entries()` has thus been added to fix that. task-5207567 Forward-Port-Of: odoo/enterprise#100151
This update ensures that when a customer in Mexico uses the Point of Sale (PoS), the correct CFDI usage (as defined on their partner record) is automatically applied to the order. Previously, the system defaulted to 'G03', which is now corrected to reflect the customer's specific CFDI setting, ensuring compliance with Mexican tax regulations.
Original PR description
When making an order in the PoS in Mexico, if the customer has a CFDI usage set on their partner, it should be used for the order instead of the default one. Steps to reproduce: ------------------- * Install l10n_mx_edi_pos * Create a partner with a CFDI usage different than 'G03' * Open the PoS, select the partner and make an order * Validate the order and check the order in the backend > Observation: The CFDI usage is 'G03' instead of the one set on the partner. opw-5018288 Forward-Port-Of: odoo/enterprise#98607
This update corrects a technical issue where duplicate methods were introduced in several Odoo modules. The problem stemmed from a missed custom build step, and this fix ensures the integrity of the codebase by removing these redundant methods. This improves stability and prevents potential conflicts.
Original PR description
Followup of #100053 because I forgot to run the custom build, and thus missed newly introduced duplicate methods. Forward-Port-Of: odoo/enterprise#100655 Forward-Port-Of: odoo/enterprise#100599
A bug in the rental order system was causing incorrect quantity calculations when returns were processed within linked pickings. This update fixes a calculation error, ensuring rental order quantities accurately reflect product movement, particularly after returns. This resolves an issue impacting rental order accuracy.
Original PR description
Steps to reproduce: - Enable multi-step & Rental transfers - Set warehouse to 2 steps reception/delivery - Create a rental order for a product with a qty of 5 - Process the PICK - Change the quantity in the rental order to 3 and save - Change the quantity back to 5 and save again Issue: The Rental IN picking has now a `product_uom_qty` of 1. This is due to a wrong computation of incoming/outgoing moves when there are returns (e.g. here a return PICK) in the linked pickings. opw-5028794 Forward-Port-Of: odoo/enterprise#100645 Forward-Port-Of: odoo/enterprise#98473
The Original Bills report was producing empty results in Odoo Studio. This was due to the report's complex process of combining multiple streams to create the PDF. To resolve this, the Studio module has been configured to simply blacklist this specific report, preventing errors and ensuring correct functionality.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to Invoices - Open studio - Click on "Reports" - Select the "Original Bills" report => The report is empty Cause of the issue ================== The Original Bills is a very specific report. Multiple streams are created and then combined to make the final PDF See: odoo/odoo#85150 Solution ======== Since studio cannot handle this usecase, we blacklist this report opw-5108198 Forward-Port-Of: odoo/enterprise#100769 Forward-Port-Of: odoo/enterprise#100729
Features or functions removed from Odoo
This update removes the use of the pytz library from Odoo Enterprise. The change addresses inconsistencies in timezone handling, improving the stability and reliability of date and time operations within the system. This resolves a potential issue related to timezone conversions.
This pull request removes outdated files related to FedEx, UPS, and USPS delivery configurations within the Odoo Enterprise system. These files were identified as no longer needed and were removed to streamline the codebase and improve performance. This change ensures the system remains efficient and focused on current delivery functionalities.
Original PR description
Oversight of 83d5bc4b0df37e0786348238b7379cb9f62fd5e4 and fw ports Forward-Port-Of: odoo/enterprise#100482
This update removes an outdated and confusing reference to a previous module name ('finkok') within the l10n_mx_edi module. The change simplifies the codebase and avoids potential confusion for developers. This is a routine maintenance fix.
Original PR description
It has been some time since finkok changed its name to quadrum, and now no one remembers quadrum as finkok. Having it in the name only causes more confusion, so we decided to simply remove it. I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#100663
Code cleanup and technical improvements
This update streamlines the management of proxy status within Odoo's Point of Sale system. Previously, proxy status information was duplicated, now it's consolidated within the dedicated `pos_iot` module for better organization and consistency. This change ensures a cleaner and more reliable system.
Original PR description
For consistency reasons, we removed the proxy status from `point_of_sale`, to move it to `pos_iot`. odoo/odoo#238085
26 changes
New functionality added to Odoo
This update introduces a new module, l10n_jo_edi_pos, to facilitate the generation and synchronization of electronic receipts with the JoFotara portal in Jordan. This ensures compliance with local tax regulations and streamlines the receipt management process for businesses operating in Jordan.
Original PR description
This commit add a new module to sync receipts with JoFotara portal. task-4213323 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds new tests to ensure the 'get_contacts' function within the VoIP module is working correctly. These tests improve the reliability of the VoIP system by verifying accurate contact retrieval, which is crucial for seamless communication features. This change enhances data integrity and stability.
Original PR description
Task-4646694 Forward-Port-Of: odoo/enterprise#100794 Forward-Port-Of: odoo/enterprise#99884
Enhancements to existing features
This update enhances the user experience for uploading TDS certificates within the PAN entity form. The button's appearance has been updated to a gray secondary style with a clear 'Upload' label and upload icon, making it easier for users to locate and utilize this feature. This improves usability and clarity.
Original PR description
### Commit Message
**Improve UI for TDS Certificate Upload Button in PAN Entity**
---
#### Before this commit:
- The TDS certificate upload button in the PAN entity form displayed the generic **"Upload your file"** label.
- It used the **purple primary button style**.
#### After this commit:
- The button now uses a **gray secondary style**.
- The label has been updated to **"Upload"** and includes an **upload icon**, providing a clearer UI.
---
### Visual Comparison
<table>
<tr>
<td align="center"><b>Before</b></td>
<td align="center"><b>After</b></td>
</tr>
<tr>
<td>
<img width="276" height="52" alt="before" src="https://github.com/user-attachments/assets/ea564f0a-51d9-4f32-8448-4978100ac72c" />
</td>
<td>
<img width="265" height="69" alt="after" src="https://github.com/user-attachments/assets/d12168ef-6015-4b13-991c-bcb93cc7dc0f" />
</td>
</tr>
</table>This update enhances the accounting module's search functionality by initially showing only active currencies. Users can then easily filter to display inactive currencies, streamlining the process of managing multiple currencies within Odoo. This improves usability and reduces confusion for users working with diverse currency settings.
Original PR description
In account.move form view, when the user clicks on search more of the currency, they should only see active ones they can then show inactive currencies using filters task-5354516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the emails sent for equity transactions and UBO form requests, making them more professional and user-friendly. Specifically, the email design has been modernized, and the ability to send to both subscriber and seller parties has been added for greater flexibility. This improves communication and streamlines processes related to equity management.
Original PR description
This commit improves the emails sent for equity notice and UBO form request. The following improvements are applied: 1. Make the equity/UBO button fixed at the top of the email without being editable for the user (to not mess up the token) 2. Make the rendered email look more odooish (used mail_notification_light) 3. Allow for sending to subscriber and seller at the same time in an equity transaction task-5123366
This update improves the equity tracking application by refining the email sending wizard. The changes include new unit tests for UBO records, UI/UX enhancements for a better user experience, and fixes for previously identified issues. This results in more reliable and user-friendly equity valuation communication.
Resolved issues and error corrections
This update fixes an issue where tasks created from sales order lines weren't automatically reflecting the correct number of hours. Previously, allocated hours were incorrectly set to zero for certain product types. Now, the task's allocated hours will accurately match the quantity of the sales order line, ensuring accurate time tracking for service-based projects.
Original PR description
To reproduce: ============= - Create service product with `service_tracking = task_in_project` and `service_type = manual` - Create a SO with this product and set quantity on the line - Confirm the SO - check the created task, allocated hours is 0.0 instead of the quantity of the SO line Problem: ======== When creating tasks from SO lines, allocated hours is initialized to 0 then computed based on the SOL quantity except when the product's service_type is 'milestones' or 'manual'. Solution: ========= Following the logic in `write` method of `sale.order.line`, the allocated hours should be set to the SOL quantity. opw-5153467 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237398 Forward-Port-Of: odoo/odoo#234524
This update resolves a technical issue in the UAE reporting module that prevented accurate calculations for returns when not specifically related to the UAE ('AE'). Adding a necessary 'super()' call ensures the logic executes only when the return is associated with the UAE, improving reporting accuracy.
Original PR description
We have an override of `_evaluate_amount_to_pay_from_tax_closing_accounts` in l10n_ae_reports, but it should only be executed when the country_code of the return is 'AE'. This commit add a super in case it's not 'AE' runbot-234445 Forward-Port-Of: odoo/enterprise#100833
This update corrects a bug in Odoo 19.0 where setting an employee's timezone to 'None' would cause an error. Now, the system will display a validation error, ensuring the 'Timezone' field is always populated, preventing data inconsistencies and saving users from encountering errors when managing employee timezones.
Original PR description
Description of the issue/feature this PR addresses: On Odoo 19.0 and master, setting an employee’s timezone to None would cause a traceback when creating or updating the employee. Current behavior before PR: a traceback when creating or updating the employee. Desired behavior after PR is merged: A Validation Error occurs because it missing required value for the field 'Timezone' (tz). Model: 'Resources' (resource.resource) task-5257749
This update fixes an error in the French payroll module that prevented users from correctly calculating payslips. The issue stemmed from an outdated reference to 'contract' instead of 'version' within the module's data files. This change ensures accurate payroll processing for French companies.
Original PR description
Steps to reproduce: 1. Open database with version saas-18.4 2. Install module l10n_fr_hr_payroll_with_accounting 3. Make sure that your company's country is France. 4. Set `Salary Journal` in:…
Steps to reproduce: 1. Open database with version saas-18.4 2. Install module l10n_fr_hr_payroll_with_accounting 3. Make sure that your company's country is France. 4. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde` 5. In Payroll app create a payslip for any employee having contract. 6. Make sure in `other inputs` you make new type and in that in the `availability in structure` has Employee cadre chosen. 7. Now with that Salary Input type click on `Compute sheet` button. 8. The `Invalid Operation` error card will appear. **Description:** In saas-18.4, the model hr.contract was [changed](https://github.com/odoo/upgrade/blob/fa44eb03c2b46d948e20dc6f5ac01dca2b625b90/migrations/hr/saas~18.4.1.1/pre-migrate.py#L41) to hr.version . All related code https://github.com/odoo/enterprise/commit/46052c4bc5ad1bd2549a6125202e0671b56beac8 was updated to use version instead of contract. in this commit. However, in the module l10n_fr_hr_payroll, there where some fields which is still using `contract` to refer other fields . https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/data/l10n_fr_hr_payroll_employe_cadre_data.xml#L130 Because of this, Odoo raises the error `Wrong python code name 'contract' is not defined when evaluating the code`. I have fixed the issue by updating the name from contract to version in that module contract to version. opw: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362) Forward-Port-Of: odoo/enterprise#100112
This update fixes an error in how Odoo handles invoices for customers in the UAE. Previously, invoices issued to related contacts were incorrectly labeled as 'Simplified Tax' invoices. Now, the system uses the customer's commercial contact information to accurately determine whether an invoice should be a 'Tax' or 'Simplified Tax' invoice, ensuring proper accounting and compliance.
Original PR description
Before this commit: - If an invoice is issued to a related contact of a company contact, it is labeled as a 'Simplified Tax' invoice. This is incorrect since the invoice is being issued to the related company on behalf of the company, so it should be a 'Tax' invoice. After this commit: - The commercial_partner field is now used to decide whether an invoice is a 'Tax' or 'Simplified Tax' invoice. task-5366608
This update prevents the loss of CUFE codes during DIAN invoice processing for Colombian companies. The previous process incorrectly removed the code due to a technical issue, now fixed to ensure accurate reporting and compliance. This resolves a critical bug impacting financial data integrity.
Original PR description
This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed…
This issue requires a valid Colombia DIAN certificate and credentials to reproduce. Access to the Odoo Knowledge article *[CO] EDI – DIAN* is necessary for the setup. With `l10n_co_dian` installed and a Colombian company: - Set up the DIAN Sales journal with the correct *Technical Key / Technical Control Key* as described in the article. - Ensure that each invoice name follows the required format. - Create a commercial invoice in the DIAN Sales journal (invoice date set in the past) and send it to DIAN. - Create the corresponding bill by copying the invoice reference and the CUFE code, then acknowledge receipt. - Run the server action **“Colombian EDI: Update Invoice Commercial States”**. Repeat this process at least twice. The CUFE code on the older invoice is removed. The server action calls `_l10n_co_dian_cron_update_event_status()`, which triggers `l10n_co_dian_action_update_event_status`. In this method, we remove `l10n_co_dian_document_ids` from moves considered duplicates. This deletion removes the `document_id` from the older move since it is treated as a duplicate of the newer one (both are in the “sent” state). However, in the compute method for `l10n_co_edi_cufe_cude_ref` (`_compute_l10n_co_dian_cufe`), we always reset `l10n_co_edi_cufe_cude_ref` to `False` before checking documents. Since the oldest move ends up with no documents, it never enters the loop and the CUFE code is lost. opw-5257129
This update resolves a technical issue that previously caused crashes when creating certain fields within the Web Studio module. The fix prevents a problem with parallel field creation, ensuring greater stability and reliability for users working with Web Studio. This improves the overall user experience and reduces the risk of unexpected errors.
Original PR description
Before this commit and subsequently to commit odoo/enterprise@75db3379655dc889b31ad34c66332f5a21f8cff4 creating a related binary field crashed because of the parallel creation of the filename related field. After this commit, this is fixed. opw-5237866 Forward-Port-Of: odoo/enterprise#99760
This update optimizes how the product configurator popup loads in Point of Sale, making the system faster and more responsive. Previously, the system was slow when calculating exclusions for product attributes due to an inefficient search process. This change improves the overall user experience and reduces potential delays during sales transactions.
Original PR description
Before this commit, to compute the exclusions of a ptav, it would loop through all ptav records to find those that exclude the current one. This could be slow when there are many attributes and values. opw-5230890 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a previous issue where ecommerce orders were incorrectly allowing decimal quantities. The change adds a test to ensure that quantities in the ecommerce system are always whole numbers, aligning with standard ecommerce practices. This improves order accuracy and prevents potential errors during the checkout process.
Original PR description
In ecommerce quantity shouldn't have decimal. This commit aims to to add a test for the fix in #234888 opw-5237233
This update resolves an error that occurred when generating the payment report within a pay run. The issue stemmed from an empty data structure being returned, leading to a key error. The fix ensures the report generation process functions correctly, preventing the error and allowing users to access payment reports.
Original PR description
When user clicks the payment report button in pay run, a traceback will appear. Steps to reproduce the error: - Install ``hr_payroll`` module - Open ``Administrator`` Employee > In Payroll tab, Set…
When user clicks the payment report button in pay run, a traceback will appear.
Steps to reproduce the error:
- Install ``hr_payroll`` module
- Open ``Administrator`` Employee > In Payroll tab, Set ``Contract, Wage`` > In Personal tab, ``Set Bank account`` > Save
- Go to Payroll > Configuration > Structures > Regular Pay > Open Net Salary rule > ``Amount Type: Fixed Amount`` and
``Fixed Amount: 0.0`` > Save
- Now, Go to Payroll > Payslips > Pay runs > Create a new Pay run > Select record > (One payslip will be created with the regular pay structure)
- Open that pay run > Click new > ``employee: Administrator`` >
``structure: worker pay`` > save
- Now, Open that pay run again > Compute > Confirm > Payment Report
Traceback:
```py
KeyError: '2'
```
https://github.com/odoo/enterprise/blob/7d90ece2756c1d8434f90a29ee6b34015a349acb/hr_payroll/models/hr_payslip.py#L2192-L2199
Here, the method ``compute_salary_allocations`` returns an ``empty dict {}`` for payslips with ``net_wage = 0.0``
https://github.com/odoo/enterprise/blob/7d90ece2756c1d8434f90a29ee6b34015a349acb/hr_payroll/wizard/hr_payroll_payment_report_wizard.py#L39-L41
So, ``allocations`` becomes an ``empty dict``, so accessing a key in it causes the above traceback.
sentry-6931674861This update resolves an issue where uploading vendor bills with specific XML formatting caused an Odoo Server error. The fix allows users to upload bills even when item descriptions are blank, ensuring a smoother bill import process. This improves the reliability of the accounting module.
Original PR description
Vendor bills import from UBL XML fails whenever the `<cac:OrderReference>`/`<cbc:ID>` is missing **and** all the `<cac:Item>`/`<cbc:Description>` have no text. The `invoice_origin` field computation results in the second condition `' '.join([None])` traceback-ing. https://github.com/odoo/odoo/blob/2217d5220640531828eb5b2ae7a9d41ba9c97e78/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1166-L1170 Steps to reproduce: 1. Install the Accounting `accountant` app. 2. Go to Accounting > Vendors > Bills. 3. Click *Upload*. 4. Upload the test XML file `addons/account_edi_ubl_cii/tests/test_files/bis3/test_vendor_bill_empty_description.xml` 5. An *Odoo Server Error* appears. Ticket [link](https://www.odoo.com/odoo/project.task/5269474) opw-5269474 Forward-Port-Of: odoo/odoo#236659
This update resolves a bug where a call would remain visible in the Odoo softphone after it was disconnected. The fix ensures that calls are immediately removed from the softphone interface when they are no longer linked, improving the user experience and data accuracy.
Original PR description
A call that was unlinked previously remained visible in the VOIP softphone. This fix ensures that the call is correctly removed from the softphone view as soon as it is unlinked. Task-5262162 Forward-Port-Of: odoo/enterprise#100138 Forward-Port-Of: odoo/enterprise#100036
This update corrects a bug where 'Cash on Delivery' was incorrectly offered for 'in-store' delivery types. The fix ensures that cash on delivery is only available when the delivery type is set to 'pick up in store', streamlining the checkout process for customers using this payment method. This improves the overall customer experience.
Original PR description
### Issue: In this issue, `allow_cash_on_delivery` is allowed when delivery type is pick up in store. #### Steps to reproduce: 1. Create a `fixed_price` delivery method 2. Check `Cash on delivery` checkbox 3. Change the delivery type to `in_store` and configure it 4. Activate cash on delivery payment method 5. Choose a storable ptoduct on the /shop, checkout with a created dm and proceed to payment 6. Observe that you see the 'cash on delivery' pm for pickup in store. Currently, `allow_cash_on_delivery` is invisible when `delivery_type` is set to `in_store`. However, it's not set to `False`, once the type is changed to `in_store`. opw-5258535 Forward-Port-Of: odoo/odoo#235434
This update resolves an issue where background blur in video calls would cause streams to freeze when users switched tabs. By using a separate worker thread for frame scheduling, the system now maintains a consistent video stream, ensuring a smoother and more reliable experience during calls, regardless of tab activity.
Original PR description
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab…
**Description of the issue/feature this PR addresses:** This PR fixes an issue where the video stream freezes when the background blur effect is enabled and the user switches to another browser tab during video calls. **Current behavior before PR:** When background blur is enabled during a video call, the user’s video stream freezes if they switch to another browser tab. This happens because currently frame scheduling relies on `requestAnimationFrame` and `setTimeout`, which modern browsers pause or throttle in inactive tabs to conserve system resources and battery life. **Desired behavior after PR is merged:** The user’s video stream continues to render with the background blur effect, even when the browser tab is inactive. This is achieved by moving the frame scheduling logic to a Web Worker, which runs in a separate thread and is not subject to browser throttling. As a result, a consistent frame rate is maintained at all times. task-[4781227](https://www.odoo.com/odoo/project/1519/tasks/4781227) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226455
This update resolves an issue where a new order was incorrectly created when the 'Skip Preview Screen' option was enabled in the restaurant POS. The fix ensures that orders are only initialized when a table is selected or a floating order is created, preventing data access errors and improving stability. This change primarily impacts the restaurant POS experience.
Original PR description
**Steps to reproduce:** - In the config, click the ePos Printer checkbox - Also check Automatic Receipt Printing and Skip Preview Screen - Put a default preset with Name as it's identification - Go…
**Steps to reproduce:** - In the config, click the ePos Printer checkbox - Also check Automatic Receipt Printing and Skip Preview Screen - Put a default preset with Name as it's identification - Go in the restaurant and make a sale, pay for it - When going back to the floor plan, a traceback appears **Why the fix:** This current problem arises because we are trying to access the current order, but we are on the floor plan, so there is no current order yet. The order is undefined, so we try to access *undefined.floating_order_name* and a traceback appears. But the root issue is deeper than this. In the restaurant, the order is initialized when clicking a table, or when we create a floating order. But when the Skip Preview Screen option is enabled, we try to initialize the order right after the last order has been validated, like we do it in the normal PoS. Doing this, we will try to handle the preset selection way too early, as the order is not fully initialized yet, and we will try to access data that have not been set yet. The current error is not the only one we have with this setup, as other errors also arise if we bypass this specific error. To fix this, we are now only initilizing the new order when we click on a table that has no order or when making a floating order. We do not create a new order after the validation of the last one, even if the Skip Preview Screen option is enabled. This is only true in the restaurant, as we keep on initializing a new order after the validation in the regular PoS. Before this commit, we also tried to create a new order when opening the restaurant from the frontend (see image below), which resulted in a traceback. We now only create a new order if the default screen is different from the Floor Screen. <img width="375" height="249" alt="image" src="https://github.com/user-attachments/assets/e38520f6-81e2-471e-a987-98d9426a6493" /> Starting in version 19.0, there is another waiting screen after paying and before going back to the floor plan, which handles things, so the bug is not present anymore. But the traceback we get when opening the register from the frontend is still present in future versions. opw-5131309 Forward-Port-Of: odoo/odoo#230796
This update adjusts the precision of price unit values within the Odoo accounting module. This change ensures that financial calculations are more accurate by aligning with the lowest possible decimal place, improving data integrity and reducing potential rounding errors. It's a standard maintenance update to maintain accurate financial reporting.
Original PR description
task-4895014
This update resolves an issue where the time calculations for operations on Bills of Materials (BoMs) were inaccurate when decimal quantities were used. The fix ensures that operation times are now correctly computed, leading to more precise production planning and costing. This improves the reliability of BoM-based reports and calculations.
Original PR description
When a BoM has a decimal quantity, the operations' times are not correctly computed. task: 5366973 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses a stability issue in the Discuss test environment. A recent change to intercept window openings lacked proper cleanup, leading to potential problems. This fix ensures the test runs reliably without introducing instability.
Original PR description
Window is patched in test to intercept `window.open()` but was made without cleanup.
This update removes unnecessary filters from the Follow-up Report, making it easier to understand and use. This change simplifies the report's output, providing clearer insights for financial analysis. It's a straightforward fix to enhance the user experience.
Original PR description
Removed default journal filters from the Follow-up Report to improve clarity. task-5149502
This update enhances Odoo's barcode scanning capabilities by adding support for hexadecimal encoded barcodes (EPCs). Previously, the system only recognized specific barcode types. Now, it can decode barcodes represented in hexadecimal format, expanding the range of barcodes that can be scanned and processed, particularly for items with unique identifiers.
Original PR description
Add an EPC decoder as a front-end service. The decoder takes an EPC as a hexadecimal input and return the resulting URI or Element String. On incorrect input or unsupported decoding, the returned value is null. Currently support SGTIN-96, SGTIN-198, SSCC-96, SGLN-96, SGLN-195.
6 changes
Resolved issues and error corrections
This update resolves an issue preventing MRP users from correctly validating manufacturing orders with project accounting. The fix ensures the system handles analytic account access properly, allowing users to assign serial numbers and complete work order validation without encountering access errors. This improves the efficiency of project costing and reporting.
Original PR description
Steps to reproduce: - Create a storable product with the following BoM: - Tracking: Serial number - Component “C1”: - Sales price: $10 - Cost: $20 - Operation: OP1 (60 min) - Add any analytic…
Steps to reproduce:
- Create a storable product with the following BoM:
- Tracking: Serial number
- Component “C1”:
- Sales price: $10
- Cost: $20
- Operation: OP1 (60 min)
- Add any analytic distribution
- Give the following access rights to Marc Demo:
- Manufacturing: User
- Timesheets: User
- Log in as Marc Demo
- Confirm the MO
- Start the work order
- Try to assign a new serial number using the "+" button
Problem:
```An access error is raised:
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Marc Demo (id=6) doesn't have 'write' access to:
Analytic Line (account.analytic.line)
```
Since the user has no access to analytic accounts, calling
`_prepare_analytic_lines()` attempts to modify an existing analytic line
amount, which triggers the access error.
Solution:
Because analytic lines are created using `sudo()`, we also need to
call `_prepare_analytic_lines()` with `sudo()` to avoid write-access
violations.
opw-5258044
Forward-Port-Of: odoo/odoo#237174This update resolves a bug that prevented the generation of SAFT files when journal entries lacked a partner but included receivable accounts. The fix ensures accurate SAFT export functionality, particularly for localized accounting systems like l10n_dk. This prevents export failures and maintains compliance.
Original PR description
If we try to export a SAF-T file when a line doesn't have any partner but having a receivable account, then a traceback is displayed.
(Backport of #98240)
How to reproduce?
1. Use a company with a localization using SAF-T (e.g. l10n_dk)
2. Create and post a journal entry with no partner, and with a line having a receivable account.
3. Go on the general ledger, and export in the SAF-T format
opw-5260937
Forward-Port-Of: odoo/enterprise#100296This update resolves an issue where duplicating an approver within an approval request caused a system error. The fix prevents the same user from being linked to multiple approvers, eliminating the traceback and ensuring approval requests function correctly. This improves stability and prevents disruptions to the approval workflow.
Original PR description
When User duplicates the approver for any approval request and tries to open that approval request, A traceback will appear. Steps to reproduce the error: - Activate the developer mode - Go to Approvals > Create a new approval request > add any approver > Save - Click on the ``View`` button in the approver line - Now, In the Form view > Actions > Duplicate - Go back to that approval request through breadcrumbs Traceback: ``` ValueError: Expected singleton: approval.approver(1, 3) ``` https://github.com/odoo/enterprise/blob/83b6c0e1c052b08bd23c5e009773b5a3148ddeec/approvals/models/approval_request.py#L270 When the customer duplicates the approver, ``user_id`` will be also duplicated. So, Now Same User is linked with multiple approver. So, It will lead to the above traceback. sentry-6642840799
This update resolves an issue preventing payroll officers from accessing salary offer details. The fix prevents access errors when officers attempt to view offers, ensuring they can continue generating salaries without needing recruitment permissions. This improves workflow efficiency for the payroll team.
Original PR description
steps to reproduce: - Install l10n_be_hr_contract_salary - Log in as a payroll officer (without recruitment rights) - Go to Payroll > Contracts > Offers - Open any offer - Notice an 'Access Error' appears: You are not allowed to access 'Candidate' (hr.candidate) records. cause: The module tries to read `employee_id.candidate_id.partner_id` in offer computations. Since payroll officers lack recruitment rights accessing `hr.candidate` triggers an access error. fix: Wrap candidate access in try/except to handle missing permissions. - If accessible, candidate partner data is used as before. - If not accessible, skip without raising an error. This allows payroll officers to open and generate salary offers without requiring recruitment rights. task - 5039712
This update fixes a bug where changes to spreadsheet sale inputs were unexpectedly lost due to system updates or user actions. Now, changes made to the input are reliably saved, ensuring data accuracy and a smoother user experience. This resolves a previous issue impacting data consistency.
Original PR description
Currently, the FieldSync record input suffers from two issues: 1) The input value can be reset by parasitic renders While the user is inputting a value, if they did not confirm it and a global render occurs (other user joining the session, dragging the mouse on the grid), the input value will be reset to the one stored in the plugin, therefore erasing the last change of the user 2) In Chrome-based navigators, users can change the value of the input by using their mouse scrolling wheel. Such action *does not* trigger an `onChange` event; which means that the new value is never directly saved. Both issues are addressed in this commit by keeping an internal state inside the component `FieldSyncSidePanel` and ensure this state is properly reflected in the plugin once we stop editing the input. Task-5123069
This update resolves an issue where the Odoo shell command wouldn't consistently start due to problems with imported tools. Specifically, the `hw_drivers` module caused errors when not actively used. This change ensures the Odoo shell starts reliably, improving developer workflow and command execution.
Original PR description
Description of the issue/feature this PR addresses: Not all tools imported in addons that have a `cli` directory may be installed on the system when that module is not used. Importing it will result in errors such as missing modules. In case of `hw_drivers`, there are hardcoded paths for the iot box. Current behavior before PR: Failing to start `odoo-bin shell` because of hw_drivers code. Desired behavior after PR is merged: Start commands. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231151
7 changes
Enhancements to existing features
This update enhances the way users manage currencies within Odoo. It now allows searching for both active and inactive currencies, and provides a toggle in the mobile kanban view to easily switch between currency states. This simplifies currency management for users and improves data accessibility.
Original PR description
This commit does 2 things: 1. In account.move form view, when the user click on search more of the currency, they would only see active ones they can then show inactive currencies using filters 2. The kanban view of the currency now shows a toggle which can toggle between active and inactive states for the currency so that the users on the mobile view can easily toggle through kanbans without having to go to form view task-5354516 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves a problem that prevented the Odoo shell from starting correctly, specifically when certain addons with a 'cli' directory were involved. The issue stemmed from incorrectly removing files during git updates, leading to errors. Now, the Odoo shell should start reliably.
Original PR description
Description of the issue/feature this PR addresses: Not all tools imported in addons that have a `cli` directory may be installed on the system when that module is not used. Importing it will result in errors such as missing modules. In case of `hw_drivers`, there are hardcoded paths for the iot box. Current behavior before PR: Failing to start `odoo-bin shell` because of hw_drivers code. Desired behavior after PR is merged: Start commands. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where short feedback messages were incorrectly wrapping the last word, creating a messy layout. The change resolves a conflict between floating rating images and block-level elements, ensuring feedback messages display cleanly and professionally. This improves the overall user experience for rating interactions.
Original PR description
**Current behavior before PR:** - Short feedback wraps the last word unnecessary.  **Desired behavior after PR is merged:** - Short messages wrapped unnecessarily due to block-level element conflicting with floated rating image. This fix ensures cleaner inline layout.  Backport of this: [Commit](https://github.com/odoo/odoo/commit/52a1913ea7082655009c9eca1201c8c42e4e4037) task-[4788428](https://www.odoo.com/odoo/project/1519/tasks/4788428) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where administrators without HR permissions could inadvertently trigger an access error when attempting to create a new employee. The fix hides the 'Create Employee' button for users lacking HR rights, preventing this error and improving system stability. This ensures that only authorized personnel can create employee records.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** - Make sure Marc Demo is an Administrator but has no Employees (HR) access rights. - Log in as Marc Demo. - Go to Settings → Users → Create a new user. - Enter a name and email, then Save. - You’ll see the "Create Employee" button it appears even though the user has no HR rights. - Click it → an Access Error occurs. **Isuue:** - The "Create Employee" button is visible for users who don’t have HR permissions, causing an access error when clicked. **Solution:** - Hide the "Create Employee" button for users without HR access by adding the correct group restriction. task-5212464 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a visual issue within the Odoo Enterprise portal where a badge was incorrectly styled, appearing as a clickable link. This change ensures the badge displays correctly, maintaining a consistent and professional user experience. It's a minor fix addressing a cosmetic problem.
Original PR description
This PR aims to fix issues introduced after the portal redesign. task-3714408 part of task-3703251 - Requires https://github.com/odoo/odoo/pull/152039 ----------- Prior to this PR, there was a badge that was not using the right classes and would then look like a link, misleading the user that could try to click on it. This commit fixes this issue by replicating the design of the other badges
This update resolves an issue where a warning banner appeared during SEPA batch payments when a linked employee had an address. The change ensures the system correctly uses the employee's address instead, preventing the misleading warning. This improves the user experience and data accuracy.
Original PR description
…oyee has an address Doing batch payment for sepa payment would generate a warning banner if the partner has no address ( city and country ) However in reality ( already working ) the xml report will be generated with the linked employee address in the case of absence of the partner address thus it should not show a warning. The change removes the warning in this case. task: 5266346
This update resolves a problem where invoice counters submitted to the Jordanian tax authority (ISTD) were not consistently sequential. The fix utilizes a new calculation to ensure counters are always in order, meeting ISTD requirements and preventing potential export delays. This improves the accuracy and reliability of our Jordan-specific accounting processes.
Original PR description
Before this commit, the invoice counter in the XML submitted to JoFotara was set to the move id. The problem with the move id is that it's not guaranteed that submitted counters would be sequential; they may contain gaps or even be out of order. The ISTD expects counters to be sequential. This commit solves this issue by relying on a computed field in assigning invoice counter in the EDI XML. task-4632768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr