Daily updates from Odoo
Navigate
Branch
Friday, August 1, 2025
67 changes
34 changes
New functionality added to Odoo
Adds support for electronic invoicing in Guatemala, allowing businesses to connect to the tax authority through Infile and submit invoice XML from Odoo. This helps Guatemalan companies manage required SAT documents directly on invoices and streamline compliance workflows.
Original PR description
This commit implements the standard EDI flow for Guatemala. - Connect to the GT-SAT via a provider called Infile via the GT settings. - Generate the Invoice XML and send to the SAT using the Send & Print wizard. - Handles creating the EDI documents in the invoice form's SAT page. related community PR: https://github.com/odoo/odoo/pull/205863 task-3875982 Forward-Port-Of: odoo/enterprise#91383 Forward-Port-Of: odoo/enterprise#84036
Adds AI support to help create new website pages by generating relevant page text from a selected template. This can speed up website building and reduce manual content drafting for users creating new pages.
Original PR description
## Purpose This PR introduces a new bridge module, ai_website, which enables AI-assisted generation of website page content. ### ai_website The ai_website module provides an endpoint /ai_website/generate_page that allows dynamic generation of website page content using AI agents. Key functionalities: - Parses a given website page template to extract relevant text nodes. - Uses an AI agent to generate contextual content (e.g., name, description) based on the extracted structure. - Reintegrates the AI-generated content into the page structure. ---- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) task-[4825509](https://www.odoo.com/odoo/project/19060/tasks/4532108/project.project/19060/tasks/4825509)
Enhancements to existing features
Point of Sale now shows whether the connected IoT Box is available locally, online, or offline. This helps store staff quickly understand device connectivity and react faster when printers, payment terminals, or other IoT-connected hardware may be unavailable.
Original PR description
We now show local/online/offline IoT Box status in pos. Community PR: https://github.com/odoo/odoo/pull/221255 Task: 4978644 Forward-Port-Of: odoo/enterprise#91356
When a user has missed or ignored VoIP calls, the softphone now automatically opens the recent calls tab. This helps users quickly see who called and follow up without first navigating away from the dialer.
Original PR description
Purpose: To open recent calls tab in softphone interface when there are missed calls. Specification: This commit updates the VoIP systray item behavior to ensure that, when a user has missed calls, the softphone interface will automatically switch to the "recent" calls tab. Incase of an ignored incoming call, the softphone will now switch to the "recent" tab instead of the "dialer". Task-4917354
VoIP will no longer appear as the first app on the homepage. Its position has been adjusted to appear after WhatsApp, making the app ordering more intentional and less prominent for users who do not need VoIP first.
Original PR description
Change the sequence number of the VoIP root menu so that it doesn't show up as the first app on the homepage. The sequence number is set to 261 in order to put VoIP right after WhatsApp, which is 260 at the time.
The signing request email templates have been adjusted to display better across different screen sizes, especially on mobile devices. This makes signing communications easier to read and use, improving the recipient experience with minor visual refinements.
Original PR description
This commit introduces modifications to the `sign` email templates to make them more responsive. It also adds some minor style changes to the content of templates task-id: 4423436
The Sign app receives small interface refinements to make sending and managing signature requests smoother. These updates help users navigate common signing workflows more comfortably without changing the core process.
Original PR description
## Purpose Improvements to the user experience when using the sign application. ## Specification Minor tweaks to the UI of sign Task: 4306332
Knowledge conversations now open through a shared process instead of only in one specific action. This improves reliability across different user paths and helps ensure users reach the right discussion view wherever they start from.
Original PR description
Rather than patching the action specific method, patch thread open to work in all flows. Part of task-4681025 Part of task-4095268 https://github.com/odoo/odoo/pull/221069
Signing fields no longer use a blurred background over the document content. This makes the document easier to read while users review and complete signature items.
Original PR description
With this PR, the sign items no longer have a background that blurs what is underneath. Task: 4984615
Discuss actions such as message, thread, and composer options are now presented through a shared component, making them more consistent across the interface. This reduces duplicated presentation logic and gives users a cleaner, more familiar experience in areas like the Discuss sidebar and header.
Original PR description
Before this commit, discuss actions such as thread actions and message actions were defined differently from their own registries. The style of the actions are defined by component that make use of…
Before this commit, discuss actions such as thread actions and message actions were defined differently from their own registries. The style of the actions are defined by component that make use of these actions, so lots of code differ in style and use and have to use same pattern to present these actions nicely. Main problems are: - each component using these actions have to define complex code for presentation of the actions - style inconsistency This commit improves by introducing a DiscussActions component, which accepts formatted lists of actions from thread, message, composer registries. This gives the benefit of easing the showing of these actions in UI by just mounting the `DiscussActions` component and provide list of actions to display. Consequently to this improvement, style of discuss sidebar actions and discuss header actions have been changed to more closely look like usual odoo dropdown items and odoo control panel switch buttons. Task-4982792 Before / After (white theme) <img width="1106" height="906" alt="Screenshot 2025-07-30 at 16 24 09" src="https://github.com/user-attachments/assets/d0572f23-feca-4630-a651-9e779b6f1eb8" /> <img width="1107" height="898" alt="Screenshot 2025-07-30 at 16 23 35" src="https://github.com/user-attachments/assets/4326a902-51a2-4d60-86a3-6b010c5971e3" /> Before / After (dark theme) <img width="1107" height="906" alt="Screenshot 2025-07-30 at 16 18 41" src="https://github.com/user-attachments/assets/600fae4e-20c4-4be7-8bbd-4d2890e930bf" /> <img width="1107" height="902" alt="Screenshot 2025-07-30 at 16 01 32" src="https://github.com/user-attachments/assets/5712a98d-6eac-4e2c-bed5-422e26960b1c" />
Mobile users now access message actions through the same dropdown pattern used in Discuss. This makes message handling more consistent and easier to use on smaller screens.
The spreadsheet global filter dialog now shows all available filters immediately, removing the need to click an extra "Add filter" button. This makes filter setup and editing faster and more straightforward for users working with documents spreadsheets.
Original PR description
This commit make it so the global filter dialog always displays all of the filters, instead of having to click on the "Add filter" button. It also changes the `Edit Filter` button, so a tour had to be adapted. Task: [4948791](https://www.odoo.com/odoo/2328/tasks/4948791)
WhatsApp sidebar channels now show unread message counters, making it easier for users to spot conversations that need attention. The counters respect each user's notification preferences, so only relevant unread activity is highlighted.
Original PR description
community PR: https://github.com/odoo/odoo/pull/218977 This commit will add an unread counter badge to sidebar channels. This will follow the channel notification settings set by the user. task-2731882
This update adds automated tests for Enterprise Point of Sale custom behavior, helping ensure these workflows keep working as expected. It reduces the risk of regressions in preparation displays, sessions, and related configuration when future changes are made.
Original PR description
This commit adds hoot tests for the overriden methods of point_of_sale in the pos_enterprise module. taskId: 4945820 Forward-Port-Of: odoo/enterprise#90758
The rental website checkout has been updated to match recent changes in the cart summary layout. This helps keep the shopping cart experience consistent and prevents display issues for customers renting products online.
Original PR description
The cart summary now uses a separate template, so related templates need to be updated accordingly. Community PR: - https://github.com/odoo/odoo/pull/215859 task-4761121
Resolved issues and error corrections
When a logged-in user is included as a signer, the signing workflow now takes them straight to their signing page instead of showing a confusing send dialog or notification. This reduces duplicate steps and makes it easier for employees or customers to complete documents promptly.
Original PR description
**Version:** - saas-18.3 **Steps to reproduce:** - Open a sign template. - Click "Send". - Add signers (include yourself). - Click "Send" to confirm. - The template is shown in preview mode. - Click "Sign Now". - A new "Send" dialog appears. - You have to add signers again. - Click "Send" again. **Issue:** - When the logged-in user is one of the signers, clicking the "Send" button shows a notification and not allows the user to sign. But clicking "Sign Now" again after that is confusing. **Solution:** - If the current user is a signer, clicking the "Send" button should directly open the sign view for that user to sign. task-4933608 Forward-Port-Of: odoo/enterprise#89943
Field service sales orders using Anglo-Saxon accounting now correctly show zero-priced products as ready to invoice. This prevents valid no-cost items from being incorrectly marked as having nothing to invoice, allowing invoices to be created when needed.
Original PR description
Before this commit: When Anglo-Saxon accounting is enabled and a product with sale price of zero is added to SO through field service, the invoice_status show 'Nothing to Invoice'. After this commit: With Anglo-Saxon accounting enabled, adding product with a zero sale price to an SO through field service will display the invoice_status as 'To Invoice' instead of 'Nothing to Invoice'. task-3957962 Forward-Port-Of: odoo/enterprise#91159 Forward-Port-Of: odoo/enterprise#70132
This fixes an issue where mentioning someone in the full message composer could trigger an error because the conversation context was not always available. Users can now use mention suggestions more reliably when writing messages, reducing interruptions in communication workflows.
Original PR description
**Purpose of this PR:** Handled mention suggestions with optional chaining as thread is absent in MentionList. since we are using suggestions without thread in full composer. Forward-Port-Of: odoo/enterprise#91432
Point of Sale kitchen printers connected through IoT now receive the full device information needed to print through the backup websocket connection. This prevents kitchen tickets from failing while regular receipts continue working, and helps avoid checkout screen errors when IoT devices were not recently updated.
Original PR description
Due to a missing `iot_id` field when the `DeviceController` for kitchen printers is instantiated, the websocket fallback does not work. This results in kitchen tickets failing to print even when regular receipts are working correctly. The fix is to provide the full IoT device model to the `DeviceController` constructor, as is done elsewhere. To do so we now pass the `device_id` field for the preparation printer model from the backend. We also ensure IoT devices/boxes are loaded even with a 'limited' load. This is because of an issue where an IoT device is added to the PoS config, but because the device itself has not be written to recently, the PoS doesn't load it and you get a traceback in the frontend. Forward-Port-Of: odoo/enterprise#91369 Forward-Port-Of: odoo/enterprise#91260
Starshipit shipping requests now include the second address line when it is provided. This helps ensure carriers receive complete delivery addresses, reducing the risk of incomplete labels or delivery issues.
Original PR description
Current behaviour: --- When using Starshipit, street2 is not included in the payload sent to the API. Expected behaviour: --- Street and Street2 should be both included if street2 is set, separated by a space. Steps to reproduce: --- 1. Install delivery_starshipit 2. Create starshipit Shipping Method 3. Create an Australian partner 4. Make sure street2 is set 5. Make a new sale order 6. Set the Australian partner 7. Set a product and click on "Add shipping" 8. Set starshipit as the method to use 9. Confirm and validate the delivery 10. Only the first street is sent opw-4907475 Forward-Port-Of: odoo/enterprise#90775 Forward-Port-Of: odoo/enterprise#89725
Sign template editing is now easier because edit buttons take users directly to the matching field. Template preview screens are cleaner by hiding unnecessary edit icons, and the document menu button now displays correctly.
Original PR description
Improved the sign_template_sidebar view by enabling pencil buttons to focus corresponding input fields for editing, and hidden the edit icons in template visualization mode for a cleaner experience. Additionally, fixed the document menu button to ensure proper display. task-4908825 Forward-Port-Of: odoo/enterprise#89884
Fixes the calculation of accident-related days in Swiss payroll reporting so employee payroll data is reported more accurately. This helps reduce payroll reporting errors and supports more reliable compliance processing for Swiss companies.
Original PR description
Forward-Port-Of: odoo/enterprise#91391 Forward-Port-Of: odoo/enterprise#91358
Vendor batch payments now use the correct payable account when matched with bank statements. This prevents accounting entries from being posted to the wrong partner account during reconciliation, improving financial accuracy.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Vendors / Payments" - Create a payment: * Payment Type: Send * Vendor: [any] * Amount: 1000 - Confirm the payment - From payments list, select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -1000 * Memo: [anything] - Reconcile the statement with the batch payment **Issue:** The receivable account of the partner is used for the batch line instead of his payable account. **Solution:** Select the type of the account to use depending on the type of the payment. opw-4952786 Forward-Port-Of: odoo/enterprise#91354 Forward-Port-Of: odoo/enterprise#91206
Studio exports now retain several important customization fields that were previously left out automatically. This helps ensure exported Studio customizations, views, approvals, automations, and attachments can be restored or moved more reliably.
Original PR description
If you create a **StudioExportModel** with a model that we always export (for studio customizations, i.e. ir.ui.view) then the excluded_fields field gets computed. Before this commit, the _compute_excluded_fields method of the StudioExportModel model could have excluded some fields we would like to export. This commit fixes that. **List of fields we should export but by default were excluded:** - "base.automation": "action_server_ids" - "ir.model.fields": "selection" - "studio.approval.rule": ["approver_ids", "can_validate"] - "ir.ui.view": "arch" - "ir.attachment": "datas" task-4866474 Forward-Port-Of: odoo/enterprise#91409 Forward-Port-Of: odoo/enterprise#88125
This fix ensures the correct point of sale configuration appears in the Belgian blackbox installation banner. It also restores missing attribute labels on IoT device forms, making setup information clearer for users.
Original PR description
We fixed the associated pos config displayed inside the "install pos_blackbox_be" banner and the labels of attributes not showing on the iot device form. Forward-Port-Of: odoo/enterprise#91441
Self-order kiosks can now print receipts through connected IoT devices as intended. The update adds the missing dependency and adjusts communication so receipt printing works even when kiosk users do not have a standard logged-in session.
Original PR description
The kiosk was updated to use iot http service to print receipt, but the dependancy was missing. This commit fixes the issue. We now override the iot http service to avoid using the orm as there is no session using self order, and use rpc calls instead. Forward-Port-Of: odoo/enterprise#90532
Subscription commission calculations now account for plan transfers during renewals, so salespeople are credited or debited according to the correct recurring plan rates. The update also prevents duplicate achievement lines when currency is missing and improves commission report performance for larger datasets.
Original PR description
PURPOSE In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs SPECIFICATIONS Take into account transfer logs…
PURPOSE
In order to take into account the achievement rate based on recurring plan for MRR log on a renewal, we need to take into account transfer logs
SPECIFICATIONS
Take into account transfer logs in achievements computation. Source should be clear that it's a transfer log of a renewal
Example:
If you have a Monthly sub to 100$/month but the yearly of 1000/year (MRR = 83.33) With a commission plan rewarding: 80% MRR of Monthly and 100% MRR of yearly
If you renew a montlhy into a yearly --> MRR that was 100 become 83,33 so you have a negative MRR so a negative commission and a negative on yearly so with more weight (100% instead of 80)
Current:
Renew in into yearly: 100% of MRR change -16.67 = -$16.67
New monthly 80% of MRR change $100 = $80
Total = 63.33 (modifié)
New
New monthly 80% of MRR change $100 = $80
Transfer 1 : 80% of MRR change -100 = -$80
Transfer 2 : 100% of MRR change +100 = +$100
Contraction of MRR: 100% of MRR change -16.67 = -$16.67
Total = 83.33
Moreover this PR:
- fix a bug when achievements were duplicated when no currency was set.
- improve performances by creating a temporary table for invoice rules.
taskid-4783929
Forward-Port-Of: odoo/enterprise#91045
Forward-Port-Of: odoo/enterprise#88646The CRM activity tests were adjusted to match a recent change where the activity action loads in two steps. This helps ensure CRM activity views continue to work correctly, including records that may be active or archived.
Original PR description
The crm activity action is now loaded in two steps Also check that the domain gets `active in [true, false]` added while we're here See linked community pull request task-4951716 Forward-Port-Of: odoo/enterprise#91038 Forward-Port-Of: odoo/enterprise#90762
Users who manage timesheets but do not have Project access can now open Timesheet list and kanban views without being blocked by an access error. This keeps timesheet administration usable for teams with restricted project permissions while preserving existing access rules.
Original PR description
Steps to Reproduce: - Ensure the `timesheet_grid_holidays` module is installed. - Log in as a user with Timesheets Administrator access but no access to the Project module. - Navigate to the Timesheets > List or Kanban view. - An `AccessError` occurs due to missing read rights on the `project.task` model. Cause: - In the `timesheet_grid_holidays` module, the `_should_not_display_timer` method accesses `self.task_id.is_timeoff_task` without checking access rights, causing an `AccessError` when users who can view timesheets but lack read access to `project.task` try to access tasks linked to projects with private privacy visibility. Solution: - Use `sudo()` when accessing `self.task_id` in `_should_not_display_timer()` to avoid access errors. task-4798066 Forward-Port-Of: odoo/enterprise#91361 Forward-Port-Of: odoo/enterprise#86302
Payroll payment reports now use the company linked to the payslip batch instead of whichever company is currently selected. This helps multi-company payroll users avoid incorrect company details on payment reports.
Original PR description
Steps to reproduce: - install payroll and create a batch - generate payslips - select multiple companies. - Click on "Create Payment Report." - create any payment method issue: - The report displays the currently selected company instead of the one associated with the payslip batch. reason - the default company is given on the field which is self.env.company fix - now the company field is computed to the payslip company task-4643306 Forward-Port-Of: odoo/enterprise#91233 Forward-Port-Of: odoo/enterprise#81812
This update fixes a timezone-related issue in Field Service tests that could cause failures in some environments. It helps keep automated checks stable and prevents false alarms during development.
Original PR description
the task was missing the timezone context, which caused the test to fail in some environments. build_error-227059 Forward-Port-Of: odoo/enterprise#91121
Appointments in the evening before an all-day event are no longer incorrectly marked as unavailable because of timezone differences. This helps businesses avoid losing valid booking slots, especially for users in timezones where local evenings cross into the next UTC day.
Original PR description
All-day calendar events were incorrectly causing unavailability for appointment slots scheduled on the previous evening, due to mismatches between local time and UTC. Previously, all-day events…
All-day calendar events were incorrectly causing unavailability for appointment slots scheduled on the previous evening, due to mismatches between local time and UTC. Previously, all-day events scheduled for Tuesday were stored with a start time of 00:00 UTC. In timezones like America/Chicago, this corresponds to 7:00 PM Monday. As a result, a valid appointment booked from 6:30 PM to 8:00 PM local time on Monday would partially fall into Tuesday in UTC (ending at 01:00 UTC), causing a false conflict with Tuesday’s all-day event. The `calendar_verify_availability` method now calls the newly added `_get_date_boundaries` which than computes naive datetime boundaries based on the user's local timezone by taking the end of the previous local day and the start of the next local day. This change resolves those edge cases where evening slots crossing the UTC boundary were falsely marked as unavailable due to timezone misalignment. opw-4614544 Forward-Port-Of: odoo/enterprise#91398 Forward-Port-Of: odoo/enterprise#85654
The Barcode app now refreshes correctly after a quality check wizard is closed, so required quality check buttons reappear when needed. This helps warehouse users avoid missing required checks and makes the quality control flow more reliable.
Original PR description
Description of the issue/feature this PR addresses: The two buttons to open quality check and demand a quality check in the Barcode app are set in an override of MainComponent It would be better to set them in the BarcodeModel class like we do for the validate() button for instance (see enterprise/stock_barcode_quality_control/static/src/components/main.js) Current behavior before PR: - When closing quality check wizard without doing quality checks the quality check button would not appear (see screen recording below) Desired behavior after PR is merged: - When closing the qualityy check wizard force a page refresh to show the Quality check button if they are required task: 4825608 screen recording of QC button refresh issue: https://drive.google.com/file/d/1cVPwgp70Ivrnjufb6x9XdawXI9JYaH0n/view?usp=drive_link I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Code cleanup and technical improvements
This update simplifies internal code used by appointment booking and public knowledge pages. It helps keep these areas easier to maintain without changing the visible user experience.
Original PR description
see [https://github.com/odoo/odoo/pull/210104](https://github.com/odoo/odoo/pull/210104)
33 changes
Security fixes and vulnerability patches
Public visitors who open links to unpublished products now see a standard “not found” page instead of an access-denied message. This prevents sensitive record details from being exposed and gives shoppers a clearer, safer browsing experience.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have an unpublished product; 2. as admin, go to its `/shop` page; 3. copy URL; 4. open URL in private window. Issue ----- > ### 403: Forbidden > > Uh-oh!…
Versions
--------
- 16.0+
Steps
-----
1. Have an unpublished product;
2. as admin, go to its `/shop` page;
3. copy URL;
4. open URL in private window.
Issue
-----
> ### 403: Forbidden
>
> Uh-oh! Looks like you have stumbled upon some top-secret records.
>
> Sorry, Public user (id=4) doesn't have 'read' access to:
- Product (product.template)
>
> If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This is information should not be accessible to public users.
Cause
-----
Commit 06cc322e7e2f added a `_pre_dispatch` override which displays the product name in the URL for SEO purposes. However, when the user does not have access to the product record, it throws an `AccessError`, leading to the HTTP 403 response.
Solution
--------
If an `AccessError` is raised when building the URL for a public user, return a HTTP 404 response, as if the record doesn't exist.
opw-4936500
Forward-Port-Of: odoo/odoo#221039
Forward-Port-Of: odoo/odoo#220948New functionality added to Odoo
Adds a new Cambodia localization package with core accounting setup, tax configuration, fiscal positions, tax reports, and support for EMV QR code payments. This helps Cambodian companies use Odoo accounting with country-specific structures and payment standards out of the box.
Original PR description
Implement a basic accounting package for Cambodia including: - COA - Account groups - Tax groups - Taxes - Fiscal Positions - Tax reports - EMV QR Code for payment task-4383330 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This adds a new Cambodia reporting module with key financial statements and a WT003 withholding tax export. Businesses operating in Cambodia can now produce localized balance sheet, profit and loss, and tax reporting outputs more directly in Odoo.
Original PR description
Adds basic reporting module for Cambodia, including: - Balance sheet - Profit & loss - WT003 export task-4383330
Enhancements to existing features
Restaurant point-of-sale users can now access a "Get QR Codes" button directly from the floor plan view. The button opens a prefilled Odoo.com form, making it easier to order engraved QR codes for self-ordering tables.
Original PR description
Add a `Get QR Codes` button on the floor plan view TaskID: 4814164
Belgian payroll now excludes PFI contracts when calculating an employee’s seniority for departure notice periods. This helps ensure notice periods are computed according to Belgian rules and avoids overstating seniority for employees with PFI contract history.
Original PR description
When you generate the notice period for leaving employees, you must compute their seniority. In Belgium, PFI contracts should not be taken into account. This commit filters the contracts to ignore PFI ones. task-4788455
Resolved issues and error corrections
This fix updates the employee skills test flow so it opens the Resume tab before continuing. It prevents an automated test failure in setups without demo data, helping keep HR skills functionality reliable during updates.
Original PR description
step to reproduce: 1. install l10n_ch_hr_payroll_account 2. without demo 3. run test SkillsTestUI.test_ui added missing step is to go to resume tab in the tour build_error_181683 Forward-Port-Of: odoo/odoo#214578
Stock reports now avoid showing extremely large unit costs caused by tiny rounding differences when quantities are effectively zero. This makes inventory valuation figures clearer and prevents confusing cost values from appearing in reports.
Original PR description
## Before this commit: Opening the stock report displays gigantic unit cost in some cases, when the sum of the valuation's quantity is near zero but not exactly, due to float arithmetics. For example, if the total quantity is 1e-15 and the total value is $0.01, the average cost will display $10000000000000 instead of $0. ## After this commit: Use `float_is_zero` to correctly detect zero-ish quantity. opw-4869588 Forward-Port-Of: odoo/odoo#221062 Forward-Port-Of: odoo/odoo#218671
This fix ensures that when staff sell a physical gift card in Point of Sale, the entered card code is assigned to the correct gift card program even when several programs exist. This prevents unwanted automatically generated codes and helps stores activate the exact card handed to the customer.
Original PR description
### Problem: When selling a gift card via PoS, if multiple loyalty programs of type *Gift Card* exist, assigning a physical gift card code does not always link it to the correct program. As a result, the created gift card receives an automatically generated code instead of the one entered. ### How to reproduce: * Create multiple loyalty programs of type *Gift Card*. * Open a PoS session. * Add a gift card product from one of the created programs. * Assign a physical gift card code to it. * Complete the sale. * The created gift card will have a generated code. opw-4910647
Accounting log messages now use consistent original wording instead of translated text. This makes troubleshooting easier across multilingual environments while keeping translated messages for users.
Original PR description
Currently, error messages in logs are translated, which can make it difficult to debug issues — especially in multi-language environments or when analyzing logs programmatically. This commit ensures logs use the original, untranslated message templates for clarity and consistency, while keeping translations for user-facing errors. sentry-6763108230
This fixes an issue where point-of-sale orders created from sales orders could generate stock transfers with doubled quantities when the same lot-tracked product was split across multiple lots. The change ensures each lot is handled separately, improving inventory accuracy and reducing manual corrections.
Original PR description
When creating a sale order for a product, confirming it, and then modifying the stock move to use 2 different lots. Then paying the order in the POS, the picking created for the pos order will have double qty Steps to reproduce: ------------------- * Create a product tracked by lot * Create 2 lots for that product * Create a sale order for that 3 quantity of that product * Confirm the sale order * Modify the stock move to use 2 different lots, for example: - Lot 1001: 2 units - Lot 1002: 1 unit * Pay the order in the POS * Check the picking created for the pos order > Observation: The picking created for the pos order has double the quantity for the lots. Why the fix: ------------ A PoS line can only hold one lot, so when we import a sale order with multiple lots, we need to split the line into multiple lines, each with a single lot opw-4804704
This fixes a receipt editing issue for products tracked and valued by lot. Instead of causing a system traceback when quantities are changed without properly adding lots, Odoo now updates the existing single lot when possible or shows a clear error when multiple lots are involved.
Original PR description
Steps to reproduce: 1) Create a product tracked by lot and with valuation by lot. 2) Create a Purchase Order with this product and Confirm it. 3) Go to Receipt 4) Add a Lot number and validate 3) Unlock the receipt and modify the `quantity`. Current behavior - Get a traceback. Expected behavior: - If there is only one lot: - update the lot quantity - Else : - raise an error The fix should be applied before the `web_save` call to prevent the creation of a new `stock.move.line`. Therefore it's done on the `onchange` call. opw-4841162 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website settings now show the Google Search Console option with the correct name instead of the reversed wording. This small correction makes the setting clearer and easier for users to recognize.
Original PR description
Before this commit, the Google Search Console label in the settings was wrongly displayed as "Console Google Search". This commit replaces this field label with "Google Search Console". task-3839274
The event website now shows the registration status banner consistently for each visitor. This prevents customers from seeing incorrect “Registered” labels caused by cached pages from another session.
Original PR description
We had an inconsistent display of the Registered banner for events on the website. The banner would appear or disappear randomly, regardless of whether the user was logged in or not. Steps to reproduce: ------------------- - start the server - log in as a user that does not have access to website editor - get a ticket for an event - go to the event list -> event is marked register - go to the event page in a new browser session (incognito) -> event is still marked register > Observation: On refresh, Registered green banner on events appear and disappear randomly Why the fix: ------------ Keys that are not stored on the table of event should be added to the cache key to force a re-render when they change, or t-nocache should be used opw-4819021 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes sales order locking so orders that should remain editable, such as subscription-related orders and similar flows, are properly excluded. It restores previously intended behavior that was missed during version updates, reducing the risk of orders being locked at the wrong time.
Original PR description
The diff from this commit was introduced in the past up until saas-17.1, to prevent locking of subscription sales orders. https://github.com/odoo/odoo/pull/159863 However, the forward porting commits after saas-17.2 are missing this diff. https://github.com/odoo/odoo/pull/159993/files Few months after the commits were merged, someone mentioned about this diff being missing, but no actions were taken afterwards. This commit applies the missing diff. --- In another [bugfix](https://github.com/odoo/enterprise/pull/91339), which is dependent on this , we decided to not lock SOs from FSM tasks, taking similar approaches as how Subscription Orders process it, utilizing the `_should_be_locked()` function. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could block users from completing a subcontracted product receipt when they chose not to create a backorder for a very small remaining quantity. The system now correctly cancels the leftover manufacturing order instead of reducing it to an invalid zero quantity, making subcontracting receipts smoother and more reliable.
Original PR description
Steps to reproduce the bug: - unarchive the subcontracting route - Create a storable product C1 with the following route: - Buy + Resupply Subcontractor on Order - Create a storable product P1 with:…
Steps to reproduce the bug:
- unarchive the subcontracting route
- Create a storable product C1 with the following route:
- Buy + Resupply Subcontractor on Order
- Create a storable product P1 with:
- BoM type: Subcontracting - Type: subcontracting - Subcontractor: Azure Interior - Component: C1
- Create a purchase order for 20 units of P1
- Confirm the purchase order
- Validate the resupply transfer
- Go to the receipt of P1
- Record 19.8 units of the component (ignore the remaining 0.2)
- Validate the receipt with no backorder
Problem:
A user error is raised:
```
The operation cannot be completed: The quantity to produce must
be positive!
```
When clicking No Backorder, the `process_cancel_backorder` method is
called:
https://github.com/odoo/odoo/blob/18.0/addons/stock/wizard/stock_backorder_confirmation.py#L75-L77
This triggers the validation of the picking, so updates the subcontract
order quantity:
https://github.com/odoo/odoo/blob/16a1d9b19b8b07435a9c4b4db2cad3c1e37e4e17/addons/mrp_subcontracting/models/stock_picking.py#L53
At this stage, we check whether it should reduce the MO quantity or
cancel the order entirely. However, the logic compares the quantity to
remove against the initial order quantity without using `float_compare`,
which leads to minor rounding differences. This results to update the
MO quantity to zero instead of canceling it, which then triggers an SQL
constraint error because the MO quantity cannot be zero:
https://github.com/odoo/odoo/blob/e7e2a088495eed3c2886a69054af689c01628f32/addons/mrp_subcontracting/models/stock_move.py#L304-L311
https://github.com/odoo/odoo/blob/29d1f637d3ec6f3ebb218d103001a6182af1b8a4/addons/mrp/models/mrp_bom.py#L93-L95
opw-4905031
Forward-Port-Of: odoo/odoo#221273
Forward-Port-Of: odoo/odoo#219650Invoice and sales email subtitles now skip missing contact names instead of displaying “False”. This keeps customer-facing email notifications cleaner and avoids confusing recipients when invoice-address contacts do not have their own name.
Original PR description
**Steps to reproduce:** 1. Install *Accounting* and *Contacts*. 2. Create a company contact with a name & address. 3. Add a child contact: Type = “Invoice address” **Leave the Contact Name blank** 4. Configure an outgoing mail server. 5. Create & confirm a customer invoice for created invoice‑address contact. 6. Click Send, send the invoice email, and check subtitle — it displays `False`. **Issue:** - When the invoice is emailed to a contact without a name, the email subtitle shows False, for example: `INV/2025/00006 - False` **Note: Same issue for Sales** **Cause:** - The rendering logic only checked that `partner_id` existed, not whether `partner_id.name` was non‑empty - Since name was not mandatory for address-type Invoice Address, this resulted in `False` appearing in the email subtitle. **Solution:** - Add an check for the validity of partner_id.name when generating the email subtitle. **opw-4939158**
Past inventory reports now calculate available stock correctly when products move through multiple delivery steps. This prevents internal warehouse transfers from being counted as customer deliveries more than once, giving businesses more reliable historical stock figures.
Original PR description
Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report For products using multi-step delivery routes, the…
Before this commit, the available quantity was incorrect when using the "Inventory At" feature with a past date in the inventory report For products using multi-step delivery routes, the `_compute_quantities_dict()` method incorrectly treated internal moves as outgoing moves As a result, the same outgoing quantity was added multiple times, leading to an overestimation of the available stock This commit adds a filter to the `domain_move_out_done` domain used for past dates, excluding internal moves based on `location_dest_usage`` ## Steps to reproduce: - Create a new product - Active the multi-step routes in Settings - Set the Warehouse's Outgoing Shipments to Pick, Pack, then Deliver - Create a RFQ for 100 products and Receive Products - Create a Quotation for 20 products - Validate each delivery steps - Go to Inventory -> Report -> Stock - Click on Inventory At - Set the date to 2025-01-01 - Search for your product - The `In Hand` quantity should be 0 but is 40 before the fix opw-4848473
Canceling the reward selection after entering a promo code no longer incorrectly marks the code as used. This prevents customers or sales staff from being blocked by a false “already applied” message when they try the same valid code again.
Original PR description
Issue: currently, when a user initiates applying a promo code but then discards it before completing the process. the system still marks the code as used,…
Issue: currently, when a user initiates applying a promo code but then discards it before completing the process. the system still marks the code as used, https://github.com/odoo/odoo/blob/204eb9b0737634826c4666f85d0b9d39aeed0ee6/addons/sale_loyalty/models/sale_order.py#L1378-L1379 resulting in a false-positive validation on subsequent attempts https://github.com/odoo/odoo/blob/204eb9b0737634826c4666f85d0b9d39aeed0ee6/addons/sale_loyalty/models/sale_order.py#L1352-L1355 to reapply the same code. Steps to reproduce: - Create a record in "Discount & Loyalty" - select "Discount Code" in program type field. - From the conditional rules, copy the discount code. - Create a sale order and select a product. - Click on Coupon Code button and paste the code copied in step 3 in Coupon Code field. - Click Apply. - A wizard of Available Rewards will be opened. Now click the Discard button. - Repeat last 3 steps Observation: - It gives a Validation Error: "This promo code is already applied." Fix: - we introduce action_discard() method, which will un-use the coupon , in case user discard the reward dialog box. opw-4961738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change restores handling for deliveries that include both regular and subcontracted products, preventing backorder issues. It prioritizes keeping barcode workflows usable, while allowing warehouse users to manually adjust picked status in the backend if needed.
Original PR description
This commit reverts db8b33e (and the wrong follow-up fix of 2755c09) because it breaks backorders for pickings that mix regular and subcontrcted products. We'd rather the flow has problems in back end where the user can manually uncheck the picked box rather than in barcode where there is no work around. We keep the enterprise test introduced in [792c968](https://github.com/odoo/enterprise/commit/792c968) to protect the barcode flow. Forward-Port-Of: odoo/odoo#220318
Spreadsheet charts now keep global filters applied when their chart criteria are updated. This prevents charts from showing unfiltered or inconsistent data, helping users trust spreadsheet reports after edits.
Original PR description
The global filters were not re-applied when updating an oodo chart domain. Task: [4965683](https://www.odoo.com/odoo/2328/tasks/4965683) 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#220764
Website translation mode now shows only one notification when a user selects content that cannot be translated. This avoids confusing duplicate messages and makes the editing experience smoother for website managers.
Original PR description
Since [1], when clicking a non-translatable element in translation mode, the notification was sometimes shown multiple times due to event bubbling. This commit stops the click event from propagating, ensuring the notification is only triggered once. [1]: https://github.com/odoo/odoo/commit/41e341177611cf69d1bd61e66a809510c22cc1b7 Forward-Port-Of: odoo/odoo#221241
Website form fields now keep their preset default values when editors move the field or change its visibility. This prevents accidental loss of configured form defaults while editing website forms.
Original PR description
Problem: When changing the default value of a field, then modifying its position and visibility, the field loses its default value. Cause: Setting a default value assigns the `value` attribute to the…
Problem:
When changing the default value of a field, then modifying its
position and visibility, the field loses its default value.
Cause:
Setting a default value assigns the `value` attribute to the field's
input element. However, after re-rendering with `_renderField`, the
HTML `value` attribute is lost. As a result, when
`_computeWidgetState` called with `selectAttribute` as method name, it
fails to retrieve the value because there is no HTML `value` attribute
on the input.
Using `t-att-value="field.value"` will lead to `value` attribute loss
during owl rendering, this is an owl bug but this fix is to work around
it until it is globally fixed.
Solution:
use `t-attf-value="#{field.value}"` instead of
`t-att-value="field.value"`
Steps to reproduce:
- Add a form
- Select any input field
- Set a default value
- Change the field's position
- Change the field's visibility
-> The default value is lost
opw-4902544
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#220047This fix restores the previous handling of manually entered tax amounts after a recent change caused incorrect results for taxes included in prices. It helps ensure invoices and accounting calculations remain accurate while a more complete solution is prepared.
Original PR description
This reverts the changes to the handling of manual tax amounts made in commit 4911adb817c07c4f789d96c0044a9f01f266ac50. That commit moved the handling of manual tax amounts from `_add_tax_details_in_base_line` to `_round_base_lines_tax_details`, but didn't consider the case of price-included taxes where the manual tax amounts must modify the base of the tax. As a result, we are reverting it while we figure out an implementation that correctly handles price-included taxes. We keep the new `_dispatch_delta_amount_smoothly` method that is used wherever we need to dispatch delta amounts over several lines. task-none
Romanian electronic invoices can now be sent to the SPV even when no e-invoice format is configured on the customer record. Odoo falls back to the standard Romanian XML format, preventing a blocking error and reducing manual retry work.
Original PR description
Currently, if we try to send an invoice without defining an EDI format on the invoice's partner and attempt to send it to the SPV, we get the error: "CIUS-RO XML attachment not found." Steps to reproduce: - Install l10n_ro_edi - Create an invoice - Do not set the eInvoice format on the partner - Send it to the SPV - You will get the error: "CIUS-RO XML attachment not found." This fix, using "account.edi.xml.ubl_ro" as a fallback, makes sense because currently, when invoices are sent in batch mode, Odoo commits the issue stating that the CIUS-RO XML is missing. As a result, when we retry sending the invoice, "account.edi.xml.ubl_ro" will also be generated because the l10n_ro_edi_document_ids will not be empty. opw-4623492
Fixed an issue where adding products to a Field Service task could lock the related sales order too early when automatic sales locking was enabled. This ensures the delivery order is created properly, so users can manage the task’s products and deliveries without getting stuck on an inconsistent locked order.
Original PR description
Issue: When the "Lock Confirmed Sales" setting is enabled, adding a product to a Field Service task would lock the associated sales order before its picking could be created. The confirmation process…
Issue: When the "Lock Confirmed Sales" setting is enabled, adding a product to a Field Service task would lock the associated sales order before its picking could be created. The confirmation process locks the order first , and the subsequent step to create stock moves (`_action_launch_stock_rule`) explicitly skips locked orders. Reproducible on 17.0~master [Task](https://www.odoo.com/odoo/action-4043/4633977) Odoo 17: https://drive.google.com/file/d/1qmAYhSu6gU91efuJEDF-Irn2cLGUQP0A/view?usp=drivesdk Odoo 18: https://drive.google.com/file/d/1x8IeXwT7ZFM7Av9Vp6GSvGIbOaEGfmVx/view?usp=drivesdk Steps to reproduce: 1. In Sales > Configuration > Settings, enable "Lock Confirmed Sales". 2. Go to a Field Service task. 3. In the kanban view via the "Products" smart button, add a product. 4. Come back to the task, refresh the browser, open the linked Sales Order from the smart button. 5. **Before this fix:** The SO is locked, no picking is created, and SO lines will have delivered_qty set even though we haven't delivered anything. 6. **After this fix:** The SO is not locked, and a Delivery smart button is correctly displayed, linking to the generated picking. This behavior left the sales order in an inconsistent state: it was locked, but had no corresponding delivery order. As a result, users were blocked from removing or modifying the products added to the task, as the system prevented edits on a locked order with no picking to cancel. Let's step through what's going on here; 0. We enable "Lock Confirmed Sales" option. 1. Add a product to the Field Service(FS) task https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L19-L42 https://github.com/odoo/enterprise/blob/4256ea170c31209b83ff808e51145757571f8556/industry_fsm_sale/controllers/catalog.py#L38 2. set_fsm_quantity() is invoked, which will create a SO for the FS task https://github.com/odoo/enterprise/blob/35e1f47160d5840e8701fc0ad43ec42bbfaf9e36/industry_fsm_sale/models/product_product.py#L144 3. `_fsm_create_sale_order()` will immediately `action_confirm()` the new SO, because of the reasons in the function description. ( Since we are immediately confirming newly created SO, I think we should consider not applying the "Lock Confirmed Orders" option to FSM SOs.) https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L124-L134 https://github.com/odoo/enterprise/blob/2347dac2568dbcf83578f044f8fe41ab70a20f47/industry_fsm_stock/models/project_task.py#L134 4. `odoo/addons/sale/models/sale_order.py/action_confirm()` will lock SO because we enabled 'Lock Confirmed Sales' https://github.com/odoo/odoo/blob/863c064fd911cb4eeedad0abec82adb4690128f6/addons/sale/models/sale_order.py#L964 6. `_action_launch_stock_rule()` is invoked, is in charge of creating Pickings for SOs https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L303 https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L343-L344 7. But, since `line.order_id.locked` , the system do not create Pickings for the SOs. https://github.com/odoo/odoo/blob/3be83d363786526fe470e41122169e594b5467fb/addons/sale_stock/models/sale_order_line.py#L315-L316 The line was introduced by https://github.com/odoo/odoo/commit/17bece3e797913bcba8dd7e07fc8541c0a45e3f7 This commit resolves the issue by passing a context key `fsm_create_sale_order=True` when confirming a sales order that is being created from a Field Service task. The `_should_be_locked` method on the sale order is overridden to check for this context key. If the key is present, it prevents the order from being locked within that specific transaction, allowing the stock rules to execute correctly and create the necessary picking. The order will be locked for any subsequent operations as intended. Tradeoff here; We are sacrificing the universal application of one feature (automatic lock on confirmed sales order) to fix a critical bug that makes the entire FSM delivery process unusable. --- EDIT: Without this change, all of [test_fsm_stock](https://github.com/odoo/enterprise/blob/17.0/industry_fsm_stock/tests/test_fsm_stock.py)'s test cases that use `_fsm_ensure_sale_order()` will fail if the setting is on. (around ~20 test cases). [In the past, similar issue occurred for Subscription Orders, and the PO confirmed that the "Lock Confirmed Order" setting should never affect the subscriptions. ](https://github.com/odoo/enterprise/commit/e4f9d76c0a58f3cc226a2372f3936cea4547312e). This commit takes the same approach to ignore the setting upon SO confirmation. opw-4633977 opw-4749653 opw-4880664 Forward-Port-Of: odoo/enterprise#88855
Chilean vendor bill imports now work for accounting users who do not have administrator rights. This prevents imported bills from failing with empty fields, helping finance teams process supplier documents without needing elevated access.
Original PR description
### Issue: Vendor bills are not importing when the user has no administration rights. ### Steps to reproduce: - Install `l10n_cl_edi` and switch to a Chilean company - Create a new user without Administration access rights but with Accounting rights - Switch to this user - Go in Accounting > Vendor Bills - Import a Chilean vendor bill - On the created bill, we can see an error in the chatter, no fields have been filled ### Cause: This [commit](https://github.com/odoo/enterprise/commit/b26a7905cbcbfdb59d55a7ecf9e963e267b8f0a5) aadded a line writing on `l10n_cl_dte_file` but the field is only accessible to [`base.group_system`](https://github.com/odoo/enterprise/blob/bcd42d624587a968ec0b7023855ba4083894baf7/l10n_cl_edi/models/account_move.py#L1071). ### Solution: Use `sudo()` like everywhere in the file. opw-4943499
WinBooks imports now handle certain accounting data inconsistencies that previously blocked the import, including tax payable accounts, unknown journals, and deprecated accounts used in tax settings. This helps businesses complete legacy accounting imports more reliably without manual cleanup or unexpected validation errors.
Original PR description
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it…
When importing a winbooks file the following issues and or inconsistencies may be found **Issue 1** We may import an account with CENTRALID 'V03' and code 45100000 Having this centralID means that it will be set as tax payable account id according to https://github.com/odoo/enterprise/blame/d8d4812414dba8825a1c785c29d00f7d0fd98360/account_winbooks_import/wizard/import_wizard.py#L174 However, this means it needs to be a `liability_payable` account with reconcile enable, in order to comply with the following check https://github.com/odoo/odoo/blame/ad6c9001b447f5ffebafe1581512f48708c7d746/addons/account/models/account_tax.py#L80 *Note* Even if we set it as liability_payable, the import may fail later on in case the same account is used in a sales move where those types of account are not allowed https://github.com/odoo/odoo/blame/1b657cf1e1ce43874a3ede307b2f8ad68216aa56/addons/account/models/account_move_line.py#L1247 A solution is to skip the `_check_payable_receivable` check for winbooks lines **Issue 2** Move line data may reference an unkown journal, causing a validation error because no journal is retrieved from the database and a move always need a journal **Issue 3** Account created during import may be marked for deprecation, which occurs at the end of the import process. However, if the account has been used in a tax repartition line, trying to set it as deprecated will raise an error. https://github.com/odoo/odoo/blame/2cdc41c012f637849ba030989ce928b6b1152e7e/addons/account/models/account_account.py#L1028 opw-4850314
Sales achievements made on the final day of a commission period are now included in the correct period totals. This ensures commission reports and detail views reflect the full eligible sales activity for monthly targets.
Original PR description
**Issue** Achievements realised on the last day of the period were not taken into account (neither in the expected one, or the next period). **Steps to reproduce** - Create a commission plan with a monthly target frequency and an achievement on "Amount sold" - Have a Sale order with a `date_order` on the last day of a month - Click on the "Commissions" smart button to open the `sale.commission.report` list view -> achieved amount for the SO's month is missing. - Click on "Details" for the line -> there should be one `sale.commission.achievement.report` record. **Cause** We were comparing a Timestamp coming from the commission line with the start/end date of the period. To perform the comparison, the date was cast to a Timestamp with 0:00:00 as the hour, resulting in all commission lines on the last day of the period to be missed. opw-4857936 opw-4934168
This fix prevents in-progress POS cart items from disappearing after a page refresh when UrbanPiper is enabled. It also ensures product variants are synced to UrbanPiper with the correct vegetarian or non-vegetarian food type, improving menu accuracy for online orders.
Original PR description
Steps to reproduce: - Installed urbanpiper - Open POS and add product to cart - Refresh the page . Issue: - Product in the cart automatically removes. Cause: - Order lines were filtered out when urban piper is enabled. Fix: - Filter out the order lines which are not associated with online order. Issue 2: - While menu sync to Urban piper, 'product variant' food_type is sent as NA although main product food_type is set as Vegetarian or Non-Vegetarian. Fix: - Set variant food_type as main product food_type. task- 4971503
This fixes an issue where products could fail to register with Kenya eTIMS because the required quantity unit could not be set when creating a new unit of measure from the category screen. The unit field is now available in the right place and shown only when relevant for Kenyan fiscal settings, helping users complete eTIMS submissions successfully.
Original PR description
When trying to register a product with eTIMS, submisission happens to fail because `l10n_ke_quantity_unit_id` can not be set on new UoM via the UoM Category view. With this commit, we extend the UoM Category view and add the field in the notebook. We also make the column invisble regarding the fiscal country code from the UoM Category, which is get from a new, non stored, computed field. We also add the validation message from UoM model in addition to the one from Product. Note: Change was already done in 18.0 by 8e30b68b80b1db5b309c192ed7adf8be26b807d5 opw-4395902 Forward-Port-Of: odoo/enterprise#91442
Fixes a barcode app issue where scanning from the main menu could fail on iOS 18.5 if the scan confirmation sound was unsupported or blocked by the browser. The app now chooses a safer audio format and handles sound playback errors without interrupting barcode scanning.
Original PR description
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan…
Issue ----- On iOS 18.5, users can get a `NotSupportedError` when trying to scan a barcode from the (barcode) main menu. Steps to reproduce ----- - Open barcode - Click the center scan button - Scan a barcode --> Traceback Discussion ----- There are 2 issues occuring here. 1. We play either an ogg or mp3 file. However, the method to know if the format is supported by the browser returns one of 'probably', 'maybe', ''. https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement/canPlayType#return_value This means that when we do https://github.com/odoo/enterprise/blob/70e5013ea022ed04ff27db71ea3ecccb55ae1f70/stock_barcode/static/src/main_menu/main_menu.js#L37 We might end up using ogg even if the browser doesn't actually support it, as 'maybe' is truthy. To reduce the risk of this happening, we can specify the codec as "vorbis" (all ogg files of Odoo are vorbis). This is already done in mail: https://github.com/odoo/odoo/blob/cd4c1d599ea9403ce3791e239ad765d946446a47/addons/mail/static/src/core/common/sound_effects_service.js#L46 2. The browser might not have the permission to play the sound. In such cases, the best we can do is try to play the sound and log potential errors. ----- Ticket: opw-4820022
Expiration dates shown in the Barcode app now respect the user's local timezone when receiving tracked products. This prevents dates entered at midnight from appearing as the previous day, improving accuracy for inventory and compliance workflows.
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#88526
Documentation and clarification updates
This update records that GitHub user shawkialaddin has signed the Odoo Individual Contributor License Agreement. It helps ensure contributions can be accepted under Odoo's legal contribution requirements.
Original PR description
Description of the issue/feature this PR addresses: Sign the Odoo Individual Contributor License Agreement (CLA) for GitHub user shawkialaddin. Current behavior before PR: CLA not signed. Desired behavior after PR is merged: CLA signed and recorded in doc/cla/individual/ under shawkialaddin.md. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr