Daily updates from Odoo
Navigate
Branch
Monday, August 25, 2025
74 changes
44 changes
Enhancements to existing features
Marketing automation now includes a controlled option to bypass the blacklist for important transactional or incident-related emails and SMS messages. This helps ensure critical customer communications can still be delivered when needed, while limiting visibility of the option to ERP managers in debug mode.
Original PR description
Add an option to bypass the black list for example for transactional or incident emails/sms. This option is only displayed for erp manager and when debug mode is enabled. Task-3575361
This update adds missing account mappings for salary rules in the UAE and Egypt payroll accounting modules. It helps ensure payroll entries are posted to the correct accounts, improving accounting accuracy and reducing manual corrections.
Original PR description
xx: ae,eg In this commit we add the mapping for all the salary rules accounts Taks: 4930175
The salary offer form was adjusted so the salary structure field no longer shows a dropdown icon. This makes the field presentation clearer and avoids suggesting an action that may not be relevant for users preparing salary offers.
Original PR description
task-5025998
Installing the Guatemalan electronic invoicing module is now safer for companies with large databases. The update avoids heavy recalculations during setup that could previously cause installation failures, and the module will no longer be installed automatically with the base Guatemalan localization.
Original PR description
This commit adds `_auto_init` to the `account.move` object in the Guatemalan EDI that prefills all computed stored fields in the move object with null values. This prevents computation on those fields when installing the module, and also prevents MemoryError on large databases. task-5031330 Forward-Port-Of: odoo/enterprise#92881
Chilean delivery guides can now include editable cross-reference documents, such as purchase orders, directly on stock pickings. This reduces manual work and improves accuracy by copying references from sales orders and backorders while reusing the same reference display across invoices and delivery guides.
Original PR description
Currently Delivery Guides can reference a Purchase Order by using the client_order_ref field on the sale order linked to the picking. This works but has issues, it is hardcoded to only that one reference document, it isn't editable if needed, and has a hardcoded date of the picking. This PR takes advantage of the `l10n_cl.account.invoice.reference` model that exists in `l10n_cl_edi` for `account.move` and supports identical functionality on `stock.picking`. It will automatically copy the reference from the sale order to the picking if it is set and copy over to any related backorders. To remove duplication, l10n_cl_edi was modified to extract the report table to a reusable template that is accessible by both modules. task-4970185
Accounting document synchronization is now enabled automatically when Documents Accounting is installed. New and existing journals get the needed folders, tags, and sync settings without manual setup, making accounting documents easier to organize consistently.
Original PR description
We enable the synchronization of document account by default, and we create automatically the journal synchronization configuration along with the corresponding folder and tag when a journal is…
We enable the synchronization of document account by default, and we create automatically the journal synchronization configuration along with the corresponding folder and tag when a journal is created.
We also create all the synchronization configuration of the existing journal when documents_account is installed.
Notes:
- we do the configuration of the journal synchronization in sudo because the user creating the journal has not necessary access to document.
- we transfer the translation of the journal type to the folder name, but it only transfers the installed language so to benefit from it, languages must be activated before documents_account is installed.
- we also transfer the translation of the journal name to the documents tags. But as we can only add translations after the creation of the journal where the auto creation of the settings are performed, it will only benefit when installing documents_account after having activated multiple language and added translation to the journal names.
[IMP] documents_account: remove accounting sync option
The user can no longer disable the accounting synchronization with document when documents_account is installed.
Note: Following the change of _get_default_folder in account_reports.export.wizard where we just return the account_folder_id of the company, we set precompute to True for the field account_folder_id of company to ensure a folder is set by default. Note that the field is not required on the model but well in the settings view. test failing without that change: account_reports:TestAllReportsGeneration.test_generate_all_export_files
[IMP] documents{_account}: prevent document warning in the tests
In document._prepare_create_values, we emit a warning and set the owner to False when the owner of the document to be created is not active. Now that we have enabled the document account synchronization as soon as document_account is installed, we get that warning in lot of account test. To avoid those warning, we set upstream the owner to False when the owner is not active.
Co-authored by: Stephane Debauche <std@odoo.com>
[IMP] documents_account: disable documents sync during account test
To avoid a lot of test to fail or emit warning in account (not in documents_account) following the enabling of the account document synchronization by default, we disable the document account synchronization during the account test and re-enable it for documents account test.
We also modify the tests because they were expecting that no configurations for journal synchronization were set up which is no longer the case.
Task-4873102Turkish payroll can now keep an employee's net wage constant and calculate the required gross salary each month. This helps businesses honor net salary agreements while accounting for changing payroll calculations and deductions.
Original PR description
This PR adds the feature of keeping the NET wage constant in payroll of employees with contracts in Turkey, while every month calculating the Gross Salary that will result in said net wage. task link: https://www.odoo.com/odoo/all-tasks/4619061
The scale certification status now shows the Point of Sale version instead of the IoT version. This makes the certification information clearer and ensures users see the version that matters for their PoS compliance checks.
Original PR description
We need to display the PoS Version, not the IoT version. Forward-Port-Of: odoo/enterprise#91682
Mexican electronic invoicing now handles discount distribution across invoice lines more consistently, including complex refunds and point-of-sale invoices. This helps produce more accurate compliant invoice data and reduces errors in edge cases involving negative lines or discounts.
Original PR description
Forward-Port-Of: odoo/enterprise#92910 Forward-Port-Of: odoo/enterprise#92727
Planning schedules now better match employees with the shifts they are eligible to see. Employees are shown slots based on their assigned roles, and non-flexible employees only see slots that fit within their working hours, reducing scheduling confusion.
Original PR description
- Added role-based filtering: employees only see slots that match their roles or have no role assigned (unless they have no roles, in which case all are allowed). - Applied attendance filtering for non-flexible employees, restricting slots to their valid work intervals. related task - 4701095
Maintenance requests now show an explicit scheduled end time, making planned work easier to understand. Teams can also log or plan workcenter maintenance outside normal hours or after it has happened, while conflict checks are handled earlier to avoid unnecessary scheduling records.
Original PR description
With This Commit: ----------------------- 1. Replace duration with schedule_end - Replaced the `duration` field with an `scheduled end` on maintenance requests, in preparation for removing the…
With This Commit: ----------------------- 1. Replace duration with schedule_end - Replaced the `duration` field with an `scheduled end` on maintenance requests, in preparation for removing the problematic `date_delay` attribute in calendar views. - Improves time range visibility by making the end time explicit in the form view. 2. Allow past leave creation - Allowed creating leaves in the past for workcenters. - This matches real-world maintenance use cases where activities are logged after they happen or just started. 3. Reorder logic to prioritize scheduling on the exact desired date - The logic now first checks if the requested time slot is available for the maintenance request. - If the slot is already taken, it raises a UserError before creating any preventive maintenance leaves. - This ensures early validation and avoids unnecessary record creation, improving overall performance. 4. Allow creating maintenance during non-working hours (flexible schedule) - Users can now plan maintenance during nights, weekends, or other off-hours. - This ensures the "MO already scheduled for this time slot" error only shows when there's an actual conflict. - This removes unnecessary restrictions and supports more efficient maintenance planning. 5. Refine `Maintenance Requests Analysis` report - Removed low-impact measures to improve clarity and help users focus on key metrics like request count and duration. - Retained the duration measure to help users analyze time spent by assignee. Framework task: [4609678](https://www.odoo.com/odoo/all-tasks/4609678) task-4582789
The Field Service customer ratings action has been changed so it no longer depends on a live server connection. This improves reliability for users working in offline mode while keeping access to customer rating information.
Original PR description
Before this commit The "Customer Ratings" action in industry_fsm used a server action, incompatible with offline mode due to its dependency on a live backend connection. After this commit The server action is replaced with a standard window action, which is supported in offline mode. task-4920361
Belgian payroll now supports setting a minimum withholding tax amount as an additional payslip input. This helps ensure payroll calculations meet required withholding levels by automatically adjusting payslip lines when the calculated tax is below the specified minimum.
Original PR description
This commit adds a new other input type that can specify the minimum amount of withholding tax that should be applied. The withholding tax is adjusted on the payslip lines if it does not reach the specified minimum. task-4936543
Products in UrbanPiper point of sale can now be grouped by the delivery locations where they are available. This helps teams review and manage location-specific product availability more quickly.
Original PR description
In this commit: ------------------ - Added a groupby filter to easily organize products based on their availability at different delivery locations. task: 4942185
HR users can now open the employee’s contract version directly from an offer before countersigning, making review easier. The signed contract button now consistently opens the correct version, including after the page is refreshed.
Original PR description
New: - A smartbutton for HR to view the employee version before countersigning. - The smart button exists within the offer form view when the offer is partially-signed, redirects to a view of the employee version based on the partially signed contract. Fixes: - When the contract is countersigned, clicking on the "signed contract" smart button now leads to the correct version view. - When the page is refreshed, the correct version is still loaded. Task-4873800
This update improves the Time Off request experience and keeps related payroll, planning, project, and localization workflows aligned. It mainly adjusts supporting checks to ensure existing business processes continue to behave consistently after the time off window changes.
Original PR description
related: https://github.com/odoo/odoo/pull/213604/
The employee form has been reorganized to make key HR and payroll information easier to find and understand. Wording and layout improvements reduce friction for HR teams, while the signatories area has been removed to simplify the page.
Original PR description
In this PR, we improved the existing employee form UX, by moving some parts, improving wording and UX, and removing the Signatories tab. Related task: 4879234 Community PR: https://github.com/odoo/odoo/pull/214962
Shopfloor cards now show which employees are assigned to each work order, making it easier to see which work is already taken and which remains available. Active work orders are more clearly highlighted, and the selected employee's assigned work orders are emphasized in the overview for faster access.
Original PR description
In shopfloor, to know which WOs are free to take, Assigned employees are now shown on the card (limited to 13 employees). With the recent shopfloor redesign, it became less easy to identify active WOs. Therefore, now any active WOs are highlighted for any user. **NEW:** In overview, for the employee currently selected, the WO quick access button is highlighted in WOs they're assigned to. Task: 4987845
VAT returns now separate the VAT total for the period from the balance shown on the closing entry, making amounts easier to understand. The update also improves return management with deadline filtering, archive controls, automatic paid status for zero or negative submitted balances, and more accurate payable amounts across periods.
Original PR description
* Show VAT Total for the period and show the vat balance on the closing entry if it is different from period vat total. * Add Deadline Filter on return search. * Allow Archive and Unarchive automatically generated returns. * Return is paid automatically if submitted and balance is negative or equal to zero. task-4981853
UAE payroll calculations now include days when an employee is outside their contract period. This helps payroll teams produce more accurate salary results by reflecting non-contract days in the relevant salary rules.
Original PR description
days to UAE payroll task-4700453 Forward-Port-Of: odoo/enterprise#92807 Forward-Port-Of: odoo/enterprise#84758
Marketing automation now keeps the exclusion list option hidden when it is already enabled, preventing users from turning it off by mistake. If the option was disabled through another method, it remains visible so teams can identify and restore the recommended setting.
Original PR description
We hide the field use_exclusion_list to prevent user to disable it (enabled by default). We still displays it if it has been disabled by another way (ex.: programmatically). Indeed, it doesn't make sense to disable it in a marketing context. Task-3575361
Resolved issues and error corrections
The product search in Kenya localization now works correctly when users filter by KRA item code. This prevents search errors and helps sales users find products more reliably.
Original PR description
This commit odoo/enterprise@c17ebfc7cdf2b218945280e6e3bd09f2b9ee8adc added a [searchview](https://github.com/odoo/enterprise/blob/17.0/l10n_ke_edi_oscu/views/product_views.xml#L74-L84) for `l10n_ke_item_code` but it never worked. as `l10n_ke_item_code` in `product.template` is non-stored field, we generally get error in console about it. fast forward to newer version e.g. saas-18.3, searching on non-stored fields raises traceback on frontend. Step to reproduce: - install L10N_ke and sale_management - switch to kenya company - go to product in sales app - type something in search bar and select 'kra item code' from autocomplete Observation: - nothing happens on frontend - on backend we receive a error `ERROR odoo.osv.expression: Non-stored field product.template.l10n_ke_item_code cannot be searched.` Fix: - we introduce a search method for l10n_ke_item_code field opw-4985176 Forward-Port-Of: odoo/enterprise#91526
Helpdesk portal tickets with logged timesheets no longer show an unrelated Timesheets breadcrumb. This keeps navigation clearer for customers viewing their support tickets online.
Original PR description
**Steps to reproduce:** 1. Install 'Helpdesk Sale Timesheet' and 'Website' modules. 2. Create a helpdesk ticket and add timesheets to it. 3. Go to the portal view of helpdesk tickets. **Issue:** If the ticket contains timesheets, the "Timesheets" breadcrumb appears in the portal ticket view. **Cause:** The reason the timesheet variable is used in the hr_timesheet portal template is because it makes the condition evaluate to true, which is why the breadcrumb for Timesheets is displayed. **Fix:** Renamed the loop variable in `t-foreach` to avoid shadowing the `timesheet` variable from the outer context. task-4744294 Forward-Port-Of: odoo/enterprise#85411
The automated setup check for field service reports has been adjusted to follow the correct page flow more reliably. This helps prevent false test failures and supports smoother quality assurance for future updates.
Original PR description
In this commit, we fix tour by splitting
{
isActive: ["auto"],
trigger: 'body:not(.modal-open) nav.o_main_navbar, button[name="action_generate_new_template"]',
run: "click",
},
in two distinct steps
For this, we use isActive key of a step that allow to activate the step with conditions.
We take advantages of this commit to add expectUnloadPage where it is required.
Forward-Port-Of: odoo/enterprise#92834Payroll administrators will now see Python code displayed correctly when working with salary rules and rule parameters. This reduces confusion and helps users review or maintain payroll configurations more reliably.
Original PR description
Forward-Port-Of: odoo/enterprise#92960 Forward-Port-Of: odoo/enterprise#91811
A missing setup entry has been added so the payroll correction wizard is properly loaded. This ensures users can access the intended correction screens in payroll without manual workarounds.
Original PR description
- wizard views file was missing from the manifest file Task: 4731029
Receipt validation now correctly triggers lot or serial number label printing after a quality check is passed. This prevents missing labels when receiving tracked products and improves completion of mixed receipts with and without quality checks.
Original PR description
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The…
## Issue: When 'auto_print_lot_labels' is activated on Receipts Operation Type, and you received a product, the print action wasn't trigger when you validate before making the Quality Check The wizard is automatically opened but when you click on the Pass button, the wizard was closed without sending the print action ## Cause: The action wasn't return by the wizard function 'action_generate_next_window()' making the only action to be a 'act_window_close' ## Note: The state wasn't correctly set to done for all products when you validate pickings both with and without QCs in them at the same time, it should now be fix Enabling Delivery Slip for the Receipts will make the SN to not be print even after disabling the option ## Steps to reproduce: - Toggle the Lot/SN Labels option in the Hardware Tab for the Operation Type Receipts - Create a Product tracked by Unique Serial Number - Add a Quality Check for the Receipts operation - Create a New Receipt for the product - Mark as Done and Add the Serial Number - Validate the receipt and Pass the check - Before the fix, no document was downloaded opw-4790427 Forward-Port-Of: odoo/enterprise#92850 Forward-Port-Of: odoo/enterprise#90134
Users with appointment access can now create resource-based appointments directly from calendar events without hitting an access error. This keeps the booking flow working as expected when an appointment type has a single resource assigned.
Original PR description
Before this commit, trying to create an appointment through a calendar event as an user will raise an AccessError. This is because in this fix #76653 we needed to make sure the appointment_resource_id is being set on the calendar event and for this we needed to make it readonly. This causes that an user, is not able to get the proper access rights to read on to the 'appointment.booking.line' which is being triggered since inside each booking line, we have an appointment_resource_id which is a many2one to the appointment resource. To fix this, we are adding a sudo on the booking lines when we only have 1 booking line and the appointment resource is set on the calendar event. This way, the user will be able to read the booking lines and create the appointment. opw-4614976 Forward-Port-Of: odoo/enterprise#90149 Forward-Port-Of: odoo/enterprise#88373
This update corrects display issues in stock valuation settings and makes Peru stock report lines appear in a consistent order. It helps users avoid confusing configuration screens and prevents inconsistent report results when records share the same date.
Manufacturing orders now follow the configured backorder preference when the first work order is completed with a smaller quantity. This prevents unwanted production and work order backorders, helping teams keep manufacturing records aligned with their operational settings.
Original PR description
When marking as done the first workorder with less quantitites, backorders (mo+wo) were always created, with no respect of the 'Create Backorder' setting defined on the Manufacturing picking type. Now this setting is taken into account. task: 4440866
The Journal Audit report PDF export now works when users filter by receivable or payable account types. This prevents an error that blocked exporting the report, helping accounting users retrieve audit documents reliably.
Original PR description
- In the Journal Audit report options, set the Account Type (filter_account_type) to either receivable, payable, or both. - Attempt to export the PDF of the Journal Audit report. A traceback occurs because, in _generate_document_data_for_export, we attempt to add a join using an alias. However, if the filter_account_type option is enabled, there is already a left join in the query with the same alias: account_move_line__account_id. opw-4926547 Forward-Port-Of: odoo/enterprise#92240 Forward-Port-Of: odoo/enterprise#91683
This fixes an issue where Sendcloud delivery filters could fail when reading a shipping option identifier. Users should see more reliable Sendcloud delivery handling without invalid index errors interrupting the workflow.
Original PR description
Before this commit: `sendcloud_shipping_id` is of type `Object`. Trying to index the field was causing `invalid index error`. After this commit: Value is accessed correctly with the key `id`. opw-5011642 Forward-Port-Of: odoo/enterprise#92859
WhatsApp composer actions are now disabled when a conversation is inactive, preventing users from attempting actions that should not be available. This keeps the messaging experience consistent after recent changes to discussion actions.
Original PR description
Before this commit, whatsapp composer actions were enabled when the whatsapp conversation is inactive. This shouldn't be the case, and happened from the recent technical changes around discuss actions that affected composer actions. `showQuickAction` no longer exists in template. Commit puts the semantically equivalent code in composer action definition.
Expiration dates shown in the Barcode app are now displayed using the user's local timezone. This prevents products received with a midnight expiration time from appearing as expiring one day earlier, reducing confusion during warehouse receipt validation.
Original PR description
**Issue**: The expiration date displayed in the barcode app's scan screen may appear incorrect. **Steps to reproduce**: - Go to Settings > Inventory, and enable the `Expiration Date` field - Open the…
**Issue**: The expiration date displayed in the barcode app's scan screen may appear incorrect. **Steps to reproduce**: - Go to Settings > Inventory, and enable the `Expiration Date` field - Open the Purchase app - Create a new Request For Quotation - Select a product that: - is a good tracked by lot - has the `Expiration Date` field enabled (Inventory tab > Traceability) - Confirm the RFQ - Click the `Receipt` smart button - Click the `hamburger button` and enter an expiration date at midnight. - Go to the Barcode application > Operation > Receipts - Open the corresponding RFQ - Click Edit and increase the quantity to 1, then Validate - Observe that the date is displayed as one day earlier **Cause**: The code https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L17 assumes that the date is encoded using the local while the date comes from the server https://github.com/odoo/enterprise/blob/b5ad18b101f4a2608758762edf0f49270a67ba20/stock_barcode_product_expiry/static/src/components/line.js#L13, and thus is utc encoded. So for example, if the user's timezone is `Europe/Brussels`, a midnight timestamp will appear as 10 PM the previous day. **Solution**: To solve this issue, use this method https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L619-L622 instead of https://github.com/odoo/odoo/blob/7a40285fd03f75f07a74f05d4b60e760e1c83eb3/addons/web/static/src/core/l10n/dates.js#L514-L516. This way, it would parse the utc-base server date as a utc-base date. opw-4865513 Forward-Port-Of: odoo/enterprise#92109 Forward-Port-Of: odoo/enterprise#88526
This update corrects internal point-of-sale calls after a recent technical change, helping restaurant and UrbanPiper delivery workflows continue to behave as expected. It also updates related automated tests to match the corrected behavior, reducing the risk of checkout or ticket screen issues.
Original PR description
In a previous commit, some method signatures were changed to use an options object instead of multiple parameters. This commit updates the affected method calls to use the new options object format. Forward-Port-Of: odoo/enterprise#92696 Forward-Port-Of: odoo/enterprise#92091
When an applicant is hired through the salary configurator, their recorded skills are now transferred to the employee profile. This prevents HR teams from losing useful candidate information during onboarding and avoids manual re-entry.
Original PR description
Originally, an applicant, who became an employee through the salary configurator flow, loses his skill info. So, the migration of applicant information, through the salary configurator flow, to employee view has been adjusted. Forward-Port-Of: odoo/enterprise#92591 Forward-Port-Of: odoo/enterprise#87076
Reconciliation between a customer invoice and a vendor bill now keeps the correct partner on each accounting line. This prevents paid invoices and bills from being reflected under the wrong customer or vendor in reports such as the Partner Ledger.
Original PR description
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open…
**Steps to reproduce:** - Install account_accountant - Create an invoice ($100) for Customer X - Create a bill ($100) for Vendor Y - From "Customer Invoices" journal in Accounting dashboard, open "Payments Matching" - Select the invoice and the bill - Reconcile them **Issue:** A move is created with 2 lines that will mark both invoice and bill as paid. However, on both created lines, the partner is "Vendor Y", which is wrong as it will generate incorrect reports (e.g. Partner Ledger). One line should have "Vendor Y" as partner and the other line should have "Customer X". This kind of reconciliation is apparently current in India. **Cause:** When reconciling lines from 2 accounts exactly, a transfer from one account to the other one is created. The transfer is made from the account where the absolute amount to move is the lowest. A transfer is made for each partner that has a move being reconciled with the source account. The transfer is crediting (or debiting) the source account and debiting (or crediting) the reconcile account with the same partner. This is working most of the time but it totally ignores all the partners linked to the moves with the reconcile account. **Solution:** Create one line of the transfer with the source account and the partner as before. For the line on the reconcile account, first check if there's one for the same partner, currency and sign (of the amount to transfer). If not, try to find another partner with the same currency and sign. Otherwise, fall back on the same partner as the line on the source account as it was done before. opw-4735147 Forward-Port-Of: odoo/enterprise#92909 Forward-Port-Of: odoo/enterprise#89972
Adds test coverage for a crash that occurred when users tried to Freeze and Share a spreadsheet containing an Odoo List from Documents. This helps ensure the sharing workflow remains reliable after the related fix in the community codebase.
Original PR description
Steps to reproduce: - Install documents_spreadsheet (enterprise) - Create a spreadsheet with an Odoo List - Open the document view - Select the spreadsheet - Click on "Freeze and Share" => Boom This commit contains only the test, the fix is done in the community PR. Task: 5025331 Forward-Port-Of: odoo/enterprise#92627
Users editing a Knowledge article will no longer lose unsaved work when another article is moved beneath it. The system now saves pending changes before reloading the article, reducing frustration and preventing accidental data loss.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494 Forward-Port-Of: odoo/enterprise#87937
Manufacturing users can now search for employees to assign without triggering errors caused by records from companies they cannot access. The employee picker is limited to employees in companies available to the current user, making work order assignment more reliable in multi-company setups.
Original PR description
Task ID: 5005753 Prev behavior: when searching for employees to assign (employee_assigned_ids) from the manufacturing page and using "Search More", it was raising an error bc it was fetching data even from employees part of companies he's not part of New behavior: added domain over employee_assigned_ids such that the accessed users are only the ones being part of a company the current user can access Forward-Port-Of: odoo/enterprise#92079
Payroll users can now edit validated work entries as long as those entries have not yet been included in a payslip. This helps teams correct payroll preparation mistakes earlier without weakening the protection around entries already used for payslip calculations.
Original PR description
Originally, the validated work entries cannot be modified, either they have been included in payslips or not. This logic has been adjusted to allow for modifying the work entries marked as "validated" if they are not linked to a payslip. Task #4921300 Forward-Port-Of: odoo/enterprise#89552
The Indian Payroll EPF report export now uses the correct date format when finding payslips. This prevents an error when users export the EPF report to XLSX after processing paid payslips.
Original PR description
Steps to Reproduce: - Install Indian Payroll Localization - enable the Provident Fund of the employee in Payroll tab of employee form view - Create a payslip of the employee and mark as paid - Try to export XLSX file of EPF report from the reporting menu Issue: - A traceback error occurs when click on 'Export XLSX File' report. Reason: - The domain used to search payslips uses an incorrect date format. Solution: - Use the correct date format for the search. task-5002518 Forward-Port-Of: odoo/enterprise#91920
The Indian Payroll yearly salary report now prints correctly when salary structure names are stored in multiple languages. This prevents an error that blocked payroll teams from generating the report after payslips were paid.
Original PR description
Steps to Reproduce:
- Install Indian Payroll Localization
- create a payslip of any employee and mark as paid
- try to print yearly salary report from reporting menu
Issue:
- A traceback error occurs when printing the yearly salary report.
Reason:
- the sturcture name is translatable field, which gives the value in a dict with the key as languages like {'en_US': 'India: Regular Pay'}.
- The error occurs because the code attempts to use this dictionary with setdefault, which expects a string.
Solution:
- Get the structure name corresponding to the appropriate language from the dictionary before passing it to setdefault.
task-5002518
Forward-Port-Of: odoo/enterprise#91901Features or functions removed from Odoo
The Payroll settings page no longer shows the redundant Payroll Entries option because payroll accounting is enabled automatically when the required apps are installed. This simplifies configuration and removes an unnecessary dependency for SEPA payment settings.
Original PR description
The "Payroll Entries" setting is redundant because the hr_payroll_account module is auto-installed when both modules are present. Changes: - Removed the "Payroll Entries" setting from the Payroll configuration view - Removed the module_hr_payroll_account field from the model - Updated the SEPA payment setting to remove its dependency on the "Payroll Entries" setting Task ID: 5016728
30 changes
New functionality added to Odoo
Adds a new connector to bring TikTok and Tokopedia Shop orders into Odoo from multiple seller accounts. Businesses can match marketplace orders to Odoo products, handle both platform-fulfilled and seller-fulfilled orders, and keep delivery and stock information synchronized.
Original PR description
- Import orders from multiple accounts - Orders are matched with Odoo products based on their internal reference (item_id or SKU ID in Tokopedia | Shop) - Support for both Fulfillment by TikTok/Tokopedia | Shop (FBT), Fulfillment by Seller (FBS): - FBT: Importing the completed orders - FBS: Delivery information is fetched from Tokopedia | Shop, track and synchronize the stock level to Tokopedia | Shop Task ID: 3690836
Enhancements to existing features
Xendit payment forms now report token creation errors immediately, such as when entered details are invalid. This prevents failed or incorrect payment data from continuing through the checkout process, giving customers faster feedback and reducing avoidable payment issues.
Original PR description
Previously, if error was found during token creation (i.e. invalid input) , it's not immediately reported but instead invalid data will be used for further process. Now, any errors caught early will be reported immediately back. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When an Indian EDI e-invoicing retry is triggered, Odoo now records a message on the related accounting document. This helps businesses see which user retried the process, improving traceability especially when repeated requests can lead to temporary GST request blocks.
Original PR description
Following the implementation of [Black list request by GST](https://github.com/odoo/iap-apps/pull/1039) the users are blocked for 24 hours on generating too many request. When processing through EDI there is no log when clicked on the retry button, Which is more essentially needed now to know by which user the EDI was retried and we logged the same on the move --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223886 Forward-Port-Of: odoo/odoo#207184
This update makes product quantity calculations much faster when working with very large product catalogs, especially when manufacturing kits are involved. Businesses with hundreds of thousands of products should see significantly shorter search and inventory availability response times.
Original PR description
In the stock module one of the bottleneck of the `_compute_quantities` is the call to `product.update`. While this is not really an issue when the number of products is small, it becomes slow when…
In the stock module one of the bottleneck of the `_compute_quantities` is the call to `product.update`. While this is not really an issue when the number of products is small, it becomes slow when this number grows above 100 000 products. This can happen when searching on one of the computed non-stored fields for instance. In this case, the underlying issue is the unbatched call to `__setitem__` that calls `Float.convert_to_cache` that calls `get_digits` and `float_round`. These two methods are not that costly for small recordsets but can take a bit of time for larger ones. The solution proposed in this commit is to grouped the quantities_dict by values then call update on batches of product.products. This leads to a noticeable speedup, mostly for the > 100 000 records recordsets. Another bottleneck appears when the mrp module is installed. When there's a lot of products, the calls to `mrp.bom.explode` can stack up and lead to slow execution. A solution for this is to memoize the exploded values of the boms. We can do that because this value is actually independent of the current product, as we are not using the first list returned by the `explode` method. This leads to a noticeable speedup, especially in database where there are a small number of boms for a large number of product.products. speedup Time to search for products with `free_qty` > 0.0. Database with mrp installed and kit boms. Most of the kit boms are for templates. 800 000 products in the db, 15 000 templates. | Total number of products | Before PR | After PR | |:------------------------:|:---------:|:---------:| | 100 | 51ms | 48ms | | 1000 | 220ms | 200ms | | 10000 | 1.2s | 900ms | | 100000 | 10s | 5.77s | | 800000 | 15min | 1min15s | The customer database has 3 boms for templates that have more than 20 000 variants each. In this case, memoizing the explode gives a significant speedup. That's what happens in the 800 000 case above. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Italian VAT XML export now correctly adapts between monthly and quarterly submissions, including separate quarterly sections where required. The exported file name is also corrected, and the VAT threshold handling is updated to match the latest expected amount.
Original PR description
Description of the issue this commit addresses: The XML export should contain three "Modulo" sections when the report is submitted quarterly but currently only ever sends one big chunk of data. Also the name of the exported file is wrong. --- Desired behavior after this commit merged: The exported file adapts to whether it is submitted monthly or quarterly and the name of the file issue is addressed. --- Community PR: https://github.com/odoo/odoo/pull/216887 task-4826511 Forward-Port-Of: odoo/enterprise#86642
Resolved issues and error corrections
When an individual customer is linked to a company, their assigned pricelist now stays synchronized with the company's pricelist. This prevents quotations from switching to the wrong pricelist when users change the customer between a company and its related contact.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create an individual partner; 2. assign them a pricelist A; 3. create a new company partner for them; 4. create a new pricelist A & sort it on top; 5. open a…
Versions
--------
- 18.0+
Steps
-----
1. Create an individual partner;
2. assign them a pricelist A;
3. create a new company partner for them;
4. create a new pricelist A & sort it on top;
5. open a new quotation;
6. set new company as customer;
7. change customer to the individual partner.
Issue
-----
The quotation's pricelist changed from B to A. The pricelist used for the individual should be identical to the one used for their company.
Cause
-----
Commit de302c2d36305 added the `specific_property_product_pricelist` field to `res.partner`, as the way company-dependent fields are managed was changed on the database-level.
Commit 67cf577cd0a0 added the `_company_dependent_commercial_fields` method to enable syncing company-dependent commercial fields. The base method fetches all fields retrieved via `_commercial_fields`, and selects those whose `company_dependent` attribute is `True`.
In previous versions, the `_company_dependent_commercial_fields` override in `product` adds `property_product_pricelist`, as this field does not have the `company_dependent` attribute set, but it behaves as a company-dependent field. Starting from 18.0, the override adds `specific_property_product_pricelist` instead, which does have the `company_dependent` property set.
As a consequence, when `_company_dependent_commercial_sync` gets called, it does not sync the `specific_property_product_pricelist` as it's not included in the `_commercial_fields` override, nor does it sync when retrieving it from `_company_dependent_commercial_fields`, as it skips the current company, assuming the field was already handled by `_commercial_sync_from_company`: https://github.com/odoo/odoo/blob/c40760244d128cb57e11a233e89a93dd92b8fb56/odoo/addons/base/models/res_partner.py#L667-L668
Solution
--------
- Move `specific_property_product_pricelist` to `_commercial_fields`
- This enables it to sync in `_commercial_sync_from_company`
- Remove the `_company_dependent_commercial_fields` override
- `property_product_pricelist` shouldn't get synced by itself
- `specific_property_product_pricelist` is already included by the base method
opw-4988736The Employee app resume section now keeps the skills table within its intended area, even when a resume entry contains a very wide table. This prevents resume content and action buttons like Add and Delete from being hidden, making employee profile editing more reliable.
Original PR description
Steps to reproduce:
1- Go on employee app
2- Click on resume section
3- Click on Add on resume tab
4- Put on description a big table with at least 20 columns
5- Save
The resume table and the buttons "add", "delete" with be hidden by the skill table.
Reason:
The skill table element is too wide
Solution:
The skill table's width is fixed and is contained in resume section element
task-4881917
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents errors when creating, updating, or validating work entries for employees with fully flexible schedules. It helps HR teams process these entries reliably when no fixed working calendar is assigned.
Original PR description
When we validate/write/create a work entry for an employee with a fully flexible working schedule, we can encounter a traceback when trying to call `_attendance_intervals_batch` on a non-existing calendar. To rectify this issue, we continue in the loop when no calendar is set. opw-4979974 opw-4968312
Resetting a refused or cancelled Extra Hours time off request now correctly recreates the related overtime entry. This keeps employees' extra hours balances accurate when time off requests are changed and reset.
Original PR description
When refusing or cancelling a time off request of type Extra Hours, the linked hr.attendance.overtime record was hard deleted. As a result, if the leave was later reset, the extra hours were not deducted again. This fix ensures that a new hr.attendance.overtime record is recreated when resetting the leave, restoring the correct impact on the employee's extra hours balance. Related task: 4966880. 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
The Job Position form now shows eligible recruiters and interviewers even when no company is selected. This prevents hiring teams from seeing empty selection lists and makes recruitment setup smoother in multi-company environments.
Original PR description
In the Job Position form, the 'Recruiter' and 'Interviewers' fields were empty when no company was selected. This was due to the static domain using 'company_id' directly without taking into consideration that company_id can be False. This fix introduces computed domain fields (, ) that dynamically adapt based on the selected company. If a company is set, users belonging to that company are shown. If not, only internal users are listed regardless their companies. Related task: 4926154. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217884
This fixes an error that could appear after merging contacts and then selecting multiple contact records. Peppol-related contact information is now calculated separately for each contact, keeping contact management workflows from being interrupted.
Original PR description
**Steps to Reproduce:** 1. Install `account_peppol` and `contacts`. 2. Open the Contacts app (list view). 3. Select any two contacts and click on "Merge" from the "Actions" menu. 4. Open any of the merged contacts in form view. 5. Close the form view and click on "Add a line". 6. Select multiple records. **Error:** ValueError - Expected singleton: res.partner(11, 9) **Cause:** The method `_compute_available_peppol_eas` accesses `self.available_peppol_eas` directly. When multiple `res.partner` records were involved, it will raised a singleton error. **Fix:** Loop over each partner to compute `available_peppol_eas` for each. This prevents the singleton error when multiple records are processed. sentry-6807787390
The Italian localization now uses the updated €100 threshold for the VP7 line in VAT tax reports, replacing the previous €25.82 amount. This keeps tax reporting aligned with current requirements and reduces the risk of incorrect report values.
Original PR description
While implementing the modulo tag of the tax report xml export, it came to light that the vp7 line of that report which previously used a 25,82€ threshold has been changed for one at 100,00€. This commit adapts the amount across the module. --- Enterprise PR: https://github.com/odoo/enterprise/pull/86642 task-4826511 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#216887
Fixes an issue where deleting a bank account from a customer could trigger an error and interrupt the workflow. The change prevents invalid empty duplicate-bank-account data from being processed, making customer bank account management more reliable.
Original PR description
Currently an error occurs when we try to remove bank accounts from a partner. **Steps to reproduce:** - Install `accountant` (with demo), Go to customers and create a new one with random name. -…
Currently an error occurs when we try to remove bank accounts from a partner.
**Steps to reproduce:**
- Install `accountant` (with demo), Go to customers and create a new one with random name.
- Under accounting tab add a new bank account with an acc number, bank and save.
- Now remove the bank account record.
**Error:**
`AttributeError: 'NoneType' object has no attribute 'origin'`
**Cause:**
- The error occurs because of the SQL query [1] returning None values in the `id2duplicates` dict, somewhat like `{1: [None]}`, this caused the browse [2] to assign `None` to the `duplicate_bank_partner_ids`.
- While recording snapshots for diff checking in onchange system the none value will be stored like`None: {display_name:{}}` and when the line [3] tries to access `id_.origin` where `id_` is None and causes the error.
**Solution:**
- Added a condition which makes sure null values are not accounted. (The Join is added to makes sure that the correct `partner_id` is fetched.)
[1]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L71-L85
[2]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/account/models/res_partner_bank.py#L88
[3]: https://github.com/odoo/odoo/blob/04ba4e4a51843701dd42a3f0243add50b3ac0c79/addons/web/models/models.py#L1173
sentry-6748249363
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prUsers returning from editing a shared project task are now taken back to the correct project instead of another project's task board. This prevents confusion when multiple shared projects are available and keeps the portal navigation aligned with the task being edited.
Original PR description
Steps to Reproduce: ------------- 1. Install project and create two projects and tasks. 2. Share both projects with edit access. 3. Edit a task from the portal view (Back to edit mode) then click the (back to tasks) button. 4. Instead of the correct project the page redirects to the another project kanban view. Issue: -------------- - When redirecting to a task from project sharing (edit mode – task form view) it redirects to a different project’s kanban view instead of the actual project. Cause: ------------- - In the portal view the URL is hardcoded with `id=1` instead of dynamically using the correct project ID. Fix: --------------- - pass the correct `project_id` in the URL instead of using a hardcoded value. The issue occurred from this PR-https://github.com/odoo/odoo/pull/174648 task-5031632
New recruitment candidates and applicants now create linked contacts using the candidate's name instead of falling back to the email address. This helps recruiters and other users identify people correctly in contact records, while related point-of-sale test updates help keep automated checks reliable.
Original PR description
after this commit when a candidate or applicant is created, the corresponding contact should display the candidate’s name correctly, rather than defaulting to the email address. task-4687196 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Check validation now compares payments using the check's effective payment date instead of the operation date. This prevents valid customer receipts with already-issued checks from being incorrectly blocked or warned.
Original PR description
When validating check movements, the system was comparing the operation date against date, which caused false warnings in scenarios such as customer receipts that include checks already issued with…
When validating check movements, the system was comparing the operation date against date, which caused false warnings in scenarios such as customer receipts that include checks already issued with past payment dates. This commit changes the validation to use payment_date, which is the correct reference for ensuring that the payment operation is not prior to the last effective payment of the check. Description of the issue/feature this PR addresses: When validating check movements in `l10n_latam_checks`, the system compares the operation date (`date`) of the last check operation against the current payment date. This generates false blocking warnings in cases such as customer receipts, where checks can be received with past payment dates (already issued and ready to be deposited). Current behavior before PR: The validation uses `last_operation.date` for comparison. If the last operation's `date` is greater than the current payment's date, the system raises a warning, even if the check's `payment_date` is already in the past and valid. Desired behavior after PR is merged: The validation uses `last_operation.payment_date` instead of `last_operation.date`. This ensures that the comparison is consistent with the effective payment date of the check, avoiding false positives when processing checks in customer receipts. Video: https://drive.google.com/file/d/1Ro2NvKGK_uRyBovMuNeA395y-6MUbzu5/view --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Restricted website editors can edit permitted website content without triggering an access rights pop-up when saving. The change prevents editor-only metadata from being added to page elements that restricted users are not allowed to modify directly, improving the editing experience while preserving permissions.
Original PR description
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival"…
Steps to reproduce: - Install website_event, with demo data - Change Marc Demo's website access to "Restricted Editor" - Log into Marc Demo and visit an event's website page e.g."Live Music Festival" - user is able to edits is footer contents,make a change - try to save. Observation: A pop-up for access right appears Cause: after this fix odoo/odoo@11e94cb059901ffc3c521a431259d627beb69e1e , we allow website to be editable for restricted user if, user can modify other models, which are editable from website,like event. And, if website is editable, we brand the ir.ui.views nodes, https://github.com/odoo/odoo/blob/3ceb04bf2aa90442430f5bf321bac4a9d872752c/addons/website/models/ir_qweb.py#L93-L94 but restricted user do not have access to ir.ui.view model, causing access issue Note: if a node is branded, that means it is editable Fix: Brand ir.ui.view nodes only if user has full access to website editor opw-4659114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#221202
Duplicating a warehouse now also duplicates its Point of Sale operation type, matching the behavior of other warehouse operation types. This prevents missing PoS logistics settings on copied warehouses and reduces manual correction after duplication.
Original PR description
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types…
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types will be duplicated. ## Reproduction Steps 1. Make sure PoS and inventory are well installed. 2. Go to inventory. 3. Click on configuration, then warehouse. 4. Select a warehouse, click on action, then duplicate. 5. Click on configuration, then on Operation Types. ### Expected behavior We should be able to see 2 instances of PoS operation type: one for the original company, and one for the copy. ### Unexpected behavior There's only one instance of PoS operation type, which is related to the original company. ## Origin of the issue PoS operation type is a model inherited from stock.warehouse, and no copy method was defined. Therefore, upon duplication, the copy method of the original stock.warehouse was called, leading to issues with the field created in the inherited version. __ opw-4991271 Forward-Port-Of: odoo/odoo#222694
Fixes Turkish e-invoice and e-archive XML data so Nilvera no longer rejects invoices when no tax office is set. Also corrects the displayed country label from the misspelled “Turkyie” to “Türkiye,” reducing validation failures and confusion for users.
Original PR description
### Description of the issue/feature this PR addresses: Nilvera rejects E-Archive invoices if extra fields are present under `PartyTaxScheme` when no tax office is set. In addition, the…
### Description of the issue/feature this PR addresses:
Nilvera rejects E-Archive invoices if extra fields are present under
`PartyTaxScheme` when no tax office is set. In addition, the
`invoice_edi_format` selection name for TR was incorrect.
### Current behavior before PR:
When generating E-Archive invoices, Odoo includes extra nodes such as
`registration_address_vals`, `registration_name`, and `company_id`
under the `PartyTaxScheme` element. Nilvera’s validation fails if
these nodes are present while no tax office is configured. At the same
time, the TR value for `invoice_edi_format` was using the wrong name,
which caused inconsistencies. These issues result in blocking
validation errors on Nilvera’s side and prevent the invoices from
being accepted.
### Desired behavior after PR is merged:
After this fix, the `PartyTaxScheme` is cleaned up only to include the
expected XML structure:
```xml
<cac:PartyTaxScheme>
<cac:TaxScheme>
<cbc:Name>TAX OFFICE NAME</cbc:Name>
</cac:TaxScheme>
</cac:PartyTaxScheme>
```
And the invoice_edi_format selection name for TR will be corrected
to display Türkiye rather than Turkyie.
task-5017223
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix stops users from selecting the Shop Floor screen as their default home action. It prevents a login-time error that could appear when that screen opened before the system had loaded the current app context.
Original PR description
**PROBLEM** In debug mode, we can change the default home action of a user (the action he sees when logging in). When the action `action_mrp_display` is set as the home action, there is a traceback after logging in. **STEP TO REPRODUCE** 1. Go in debug mode 2. Change the home action of a user to the 'Shop Floor' action (in the user form, in the preference tab). 3. log out, and log in with this user. 4. a js traceback should appear. **CAUSE** On the js side, the Shop Floor action uses the `menu` service to get the name of the current app. when accessing the 'Shop Floor' action as a home action, the `menu` service app is set after the action is rendered, so the current app during rendering is undefined. **FIX** Prevent the user from selection the 'Shop Floor' action as a home action (we already do this for action that doesn't work as home action). opw-4926317
Installing the Belgium Accounting localization now continues successfully even if a referenced demo account tag was previously deleted. This avoids a setup failure in demo-data scenarios and makes localization installation more reliable for affected users.
Original PR description
Currently, installing the Belgium Accounting localization fails with an error, if the user has deleted referenced demo account tags. **Steps to reproduce:** - Install the Accounting app. - Delete the "Demo Capital Account" account tag. - Install the Belgium Accounting localization (`l10n_be`). **Error:** `ValueError - External ID not found in the system: account.demo_capital_account` At [1], if the `account.demo_capital_account` is not found, it raises an error if the external ID is missing. This commit prevents the error by explicitly passing `raise_if_not_found=False` and skipping the tag if not found. [1] - https://github.com/odoo/odoo/blob/71d1c9a4bef1c29485e3b0390713a9301ad6db4f/addons/l10n_be/demo/account_demo.py#L13-L19 sentry-6776341713 Forward-Port-Of: odoo/odoo#221227
Invoices created after portal subscription payments now trigger the required electronic document signing process. This restores compliance for localizations such as Mexico, where government-signed invoices are required after payment.
Original PR description
## Steps to reproduce: - Make sure the Mexican localization is installed and properly set up for signing invoices - Make sure the payment providers are set up (it can be demo, the customer uses…
## Steps to reproduce: - Make sure the Mexican localization is installed and properly set up for signing invoices - Make sure the payment providers are set up (it can be demo, the customer uses Stripe but it can be reproduced with any - Make sure the online payment setting is active - Go to subscription module - Do a new order - In other info, add the online payment checkmark - Confirm the order - Generate the payment link or go into the preview - Make the payment ## Issue: The invoice is generated, but is not signed by the government (no edi is generated), as it used to. ## Cause: The flow works in 17.0 but for the wrong reason. Before this [commit](https://github.com/odoo/enterprise/pull/70562), two mails were sent. And during the chain of triggers of the second email, edi document was generated with `orders._send_success_mail(tx.invoice_ids, tx)`. https://github.com/odoo/enterprise/pull/70562/files#diff-8778c8dce7ca1c24de19f26f11ac0c5410c6c2a4d121c3815682a2323cbb09c2L177 After the removal of the method, it should still work since we still have `payment.transaction._send_invoice` which calls `_generate_and_send_invoices` and should trigger the sub calls necessary for generating the edi stuff. But in `_create_or_link_to_invoice`, we check that the transaction has no invoice_ids linked (make sense with the name of the method). However, at this stage, we already created the invoice in https://github.com/odoo/enterprise/blob/2f3698b250092ad376344e959d46bdc0eebf1a81/sale_subscription/controllers/portal.py#L419-L424 And unfortunately, it will be effectively possible to "let the post process of transaction create" the invoices only in Master (the code is not ready yet). For now it would be too risky for a stable version to make such change. ## Solution: We ensure EDI documents are generated whenever a `subscription_action` is set. To achieve this, modify the `_post_subscription_action` hook to call `_subscription_post_success_payment` for any `subscription_action`, including `assign_token`. From `_subscription_post_success_payment`, we can call `_generate_and_send_invoices` on any invoice that has an EDI associated with it, which sends & signs the required EDI documents. opw-4648189
The contract offer screen now hides the signature request button when the current user cannot access any related signature request. This prevents users from clicking a button that would lead to an error, while still allowing authorized users such as signing administrators to use it.
Original PR description
Before this PR, when logged in as a different user from the one responsible for counter-signing the contract, the smart button still showed, and clicking on it caused an error. This PR fixes that, by hiding the smart button when there are no accessible signature requests. Note that sign admins will still be able to see the smart button; users with access to the signature request. Task-4966129
Fixed an issue where disabled Urban Piper delivery providers were automatically re-enabled when a cashier returned from the backend to continue selling. Provider availability is now kept consistently in the backend, preventing unwanted online status changes and avoiding unnecessary update requests.
Original PR description
Steps to reproduce: - Configure urban piper in pos.config - Open Register - You could see a notification that providers are online on your config - Disable any one provider. - Go to backend. - Click Continue Selling Issue: - Despite disabling the provider, all providers get enabled as soon as we resume the pos.config Cause: - Not updating togglestate properly while going to the backend. - Unnecessary api request when resuming session. Fix: - Not removing the toggleState from local storage as the user go to the backend - When the user resumes the session, restrict api request for location update. - Remove dependency from local storage and handling all through backend only. task- 4962969
Portal users viewing helpdesk tickets with logged timesheets will no longer see an unrelated Timesheets breadcrumb. This keeps ticket navigation clearer and avoids sending users toward the wrong portal section.
Original PR description
**Steps to reproduce:** 1. Install 'Helpdesk Sale Timesheet' and 'Website' modules. 2. Create a helpdesk ticket and add timesheets to it. 3. Go to the portal view of helpdesk tickets. **Issue:** If the ticket contains timesheets, the "Timesheets" breadcrumb appears in the portal ticket view. **Cause:** The reason the timesheet variable is used in the hr_timesheet portal template is because it makes the condition evaluate to true, which is why the breadcrumb for Timesheets is displayed. **Fix:** Renamed the loop variable in `t-foreach` to avoid shadowing the `timesheet` variable from the outer context. task-4744294 Forward-Port-Of: odoo/enterprise#85411
Product weight and volume information retrieved from barcode lookup is now properly saved on the product record. This helps keep product data complete and avoids missing logistics details after lookup.
Original PR description
Before this commit: ------------------------- - The weight and volume fields were not present in the main product form, so even when data was retrieved, it was not stored in the product record. After this commit: ----------------------- - We have added the weight and volume fields to ensure that whenever data is fetched, it is properly stored in the product record Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/231155
Steps to reproduce: -------------------------- 1. Install `l10n_co` and activate spanish(es_419) language 2. Configure [DIAN Environment](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#electronic-invoicing-credentials-and-dian-environment) by enabling DIAN mode 3. Create a customer invoice 4. Fill the required details in the related [customer and journal](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colomb
Original PR description
Steps to reproduce: -------------------------- 1. Install `l10n_co` and activate spanish(es_419) language 2. Configure [DIAN Environment](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#electronic-invoicing-credentials-and-dian-environment) by enabling DIAN mode 3. Create a customer invoice 4. Fill the required details in the related [customer and journal](https://www.odoo.com/documentation/18.0/applications/finance/fiscal_localizations/colombia.html#sales-journals) record 5. Send it with DIAN box checked Issue: -------- `Payment Means` and `Payment Method` are not translated to spanish(es_419). Cause: -------- After this 88d7e5a, the `<br/>` tag was removed and its related **.pot** and **.po** files were not updated. Solution: ----------- Apply the changes to the **.pot** and **.po** files to resolve the issue. opw-4790642
Fixes an issue where adjusting a checkout time in the weekly Attendance view could be lost when saving. The system now keeps the user’s selected checkout time instead of replacing it with the current time, helping prevent incorrect attendance records.
Original PR description
Steps to Produce: - Go to the Attendance interface and select week. - Drag on one column to adjust checkout. - Save the change. Issue: - Dragging on one cell deletes the checkout value from the context. - As a result, the system sets the checkout time to the current time instead of the dragged value. - This leads to incorrect attendance records. Fix: - Ensure the checkout value remains in the context when dragging the cell. - Preserve the modified checkout time so it reflects the user's intended change instead of defaulting to the current time. Task-4958060
Knowledge now saves any unsaved article edits before reloading the page after another article is moved nearby. This prevents users from accidentally losing work while organizing articles in the sidebar.
Original PR description
Currently, when a user moves another article beneath the one they are editing, the record is reloaded, causing any unsaved changes to be lost. This can be especially frustrating if the user has made significant edits. To address this issue, we will ensure that any changes made to the article are saved before the record is reloaded. This will prevent accidental loss of work and improve the editing experience. Steps to reproduce the issue: 1. Open an article 2. Make changes to the article (e.g, type or edit text) 3. Drag and drop another article beneath the current one. => The article reloads, and your unsaved changes are lost. In the `moveArticle` function, we will check if the record has unsaved changes (i.e., if it's "dirty"). If so, we will save the current content before triggering a reload via `this.props.record.model.load()`. Task-4636494
Fixes an error that occurred when refunding Mexican Point of Sale orders containing a global discount line. This helps businesses process refunds normally without interruption when discounts were applied.
Original PR description
**Steps to reproduce:** ``` - Install PoS mexican localization - Activate PoS setting Global Discounts - Navigate to PoS and create an order with a discount line - Go to back end and try to refund this order - Notice an error pops-up ``` **Cause:** Bad fw-port In the original commit `json.lines` is an array and accessing index "2" of the array was not a problem (https://github.com/odoo/enterprise/pull/84331/files#diff-63a117ed6751a8aae4fcb11d867177f5d0feb78cc1e2f3461f425babc10b5016R15) From 18.0 we are accessing the record `currentOrder` itself and `currentOrder.lines` is an PosOrderline object which doesn't have a property named "2". **Fix:** Remove index access `[2]` opw-4899501