Daily updates from Odoo
Tuesday, June 23, 2026
28 changes · saas-19.1
New functionality added to Odoo
This update streamlines connections to remote SaaS databases for users created through the Odoo Databases module. Now, users automatically authenticate upon connecting, eliminating the need for manual login steps and improving the overall user experience. This enhancement ensures seamless access to data for users managing SaaS databases.
Original PR description
## [IMP] databases: SSO smooth connection and setup The aim of this commit is to allow databases_user to be directly connected to any remote SaaS database to which they have access. When they click…
## [IMP] databases: SSO smooth connection and setup
The aim of this commit is to allow databases_user to be directly connected to
any remote SaaS database to which they have access.
When they click the "connect" button, they will bypass the login screen and be
authenticated automatically.
To achieve this, when a user tries to connect to an accessible SaaS database, we
quickly write their `oauth_uid` to that remote database right before the
connection is initiated.
Before this commit:
A user that was created in the remote db using the create user feature from the
databases module wouldn't get automatically authenticated through the Odoo
OAuth SSO feature.
After this commit:
Users attempting to connect to a SaaS database will be directly connected if the
settings was activated.
task-id: 6071808
## TODO:
- [x] check if we always have oauth_uid for saas db
- [x] think about making the oauth module autoinstall (make a bridge module? or overkill?)
- We can avoid that and have everything work in place directly, avoiding an inheritance nightmare at installation time.
- [x] handle cases where it isn't there on both the remote db and the managing one
- [x] write some tests to ensure the code is free from traceback
- [x] add a feature allowing to:
- [x] add it to all server on which the user has access
- [x] add it to a specific server (may require the db list view on `res.users`
- [x] remove the previous and do everything when the user click on "connect"
- [x] would be better to put the code in a new module with auto install => people get auto-install + no "hacky" code.
- The "hacky" code is not so hacky and with that we can directly advertise the installation of `auth_oauth` in an action
- [x] add a config in the settings
Forward-Port-Of: odoo/enterprise#112369Enhancements to existing features
This update enhances the Helpdesk system by adding tests for automated reminder emails and correcting a calculation error in the reminder timer. These changes ensure timely and accurate automated reminders for support tickets, improving the overall efficiency of the support process.
Original PR description
- add tests for the auto reminder email before auto-closing tickets - fix issue with the reminder timer calculation --- task-5438678
Resolved issues and error corrections
This update removes a redundant step in a test used for validating account edi invoices. Previously, the test required manually removing a bank account to prevent incorrect partner matching. With the system's improved partner identification using VAT numbers (since saas-18.3), this step is no longer needed, streamlining the testing process.
Original PR description
Since `saas-18.3`, the partner is correctly found using the VAT number, so the test no longer needs to remove `partner_1`'s bank account to avoid a wrong match. Remove the unnecessary `self.partner_1.bank_ids.unlink()` from `test_xml_ubl_au.py`. Forward-Port-Of: odoo/odoo#269993
This update fixes an issue where preparation times weren't accurately calculated when order stages changed and where the preparation time report incorrectly included data from all companies. The changes now ensure preparation times are correctly updated and the report displays data specific to the active company, improving reporting accuracy.
Original PR description
Issues: - Preparation time for order lines was not computed when the preparation order stage changed. - Preparation time report aggregated orders across all companies instead of showing records for the active company only. Fixes: - Ensure preparation time is properly recomputed when the order stage changes. - Add company domain filtering to the preparation time report. Task-6250974 Forward-Port-Of: odoo/enterprise#118738
This update clarifies the appearance of the cursor when hovering over scrollbars in the HTML editor's syntax highlighting. Previously, a text cursor was shown, which was confusing. Now, the default cursor is displayed, providing a clearer visual indication that the scrollbar is for scrolling only.
Original PR description
Current behavior before PR: - When a syntax highlighting block contained a scrollbar, hovering over the scrollbar displayed a text cursor. This was misleading because the text cursor suggests text interaction, while the scrollbar is only used for scrolling. Desired behavior after PR is merged: - The default cursor is now shown when hovering over the scrollbar, avoiding this confusion. task- 6295899 Forward-Port-Of: odoo/odoo#269728
This update resolves a confusing warning message that appeared during bill editing, related to vendor history. The fix prevents the warning from appearing while a bill is being edited, instead recomputing it when the bill is saved. This creates a smoother and less disruptive user experience.
Original PR description
Abnormal bill warnings are based on vendor history read from the saved move in the db, while a bill is being edited the form uses a temporary record; after changing the vendor, that temporary value differs from the vendor still stored on the saved move. This makes the warning use the old vendor's history while showing the new vendor's name. Only compute these warnings for saved records, while editing hide them and let them be recomputed once the bill is saved. task-6263829 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270515
This update resolves an issue that prevented efficient processing of invoices with multiple related documents (specifically those involving Mexican tax cancellations). By using a different database index, the system now handles a greater volume of invoices without performance slowdowns, ensuring smoother operations for our Mexican customers. This change improves the reliability of the l10n_mx_edi module.
Original PR description
The field `l10n_mx_edi_cfdi_origin` can contain a large number of associated UUIDs, especially in complex cancellation scenarios. The default B-tree index fails when this field exceeds 2704 bytes, which occurs after approximately 20 UUIDs. By switching to a trigram index, we avoid the entry size limit of PostgreSQL's B-tree nodes. This ensures that invoices with many related documents can be processed while maintaining efficient search performance for partial matches on this field. **Video before the fix:** https://youtu.be/24u0HbxwIH8 **Video after the fix:** https://youtu.be/sUelv1HZMvI Forward-Port-Of: odoo/enterprise#118868
This update corrects a previous issue where Odoo was incorrectly selecting unavailable couriers from Shiprocket. The change now filters out 'blocked' couriers, ensuring only valid options are considered for shipping rates and selections. Additionally, the system is more robust to handle unexpected data from Shiprocket, preventing errors in pricing.
Original PR description
Shiprocket provides an odablock flag in the courier serviceability response. Couriers with odablock=True are not serviceable for the requested route and should not be considered for rate calculation or selection. Before this change, Odoo selected the first courier returned by Shiprocket regardless of its ODA status. As a result, unavailable couriers could be proposed to users and selected for shipments. The fix filters out ODA-blocked couriers before evaluating available services, ensuring that only serviceable couriers are considered. Additionally, freight charge parsing is hardened to gracefully handle non-numeric values returned by Shiprocket, preventing errors during AWB assignment and price computation. FYI: Shiprocket uses odablock=False for serviceable routes and odablock=True for routes that are blocked for a given courier. opw-6288768,6152279 Forward-Port-Of: odoo/enterprise#120374
This update corrects a technical issue within the Odoo’s Danish accounting module (l10n_dk) where an account was listed twice. Removing this duplication ensures accurate financial reporting and avoids potential errors in Danish tax compliance. This change improves the reliability of the accounting system for Danish businesses using Odoo.
Original PR description
In the list 'dk_coa_7630 ', the account has been used in the list twice. Removing the duplication from the list. [Reference](https://github.com/odoo/odoo/blob/17.0/addons/l10n_dk/migrations/1.4/end-migrate.py#L14) 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#270865 Forward-Port-Of: odoo/odoo#270573
This update resolves a crash that occurred when users attempted to view Instagram videos within Odoo. The fix now displays the video link instead of the image, ensuring a smooth user experience when accessing Instagram content. This improves stability and prevents disruptions for users.
Original PR description
Purpose ======= When we have a real on Instagram, we try to show the video as an image. When clicking on the broken image, the previewer crash. To fix that issue, we know show the link of the video in the message. Task-5491124 Forward-Port-Of: odoo/enterprise#121176 Forward-Port-Of: odoo/enterprise#113487
This update corrects a technical issue where the system incorrectly rejected zero measurement values received from caliper devices via IoT. This change ensures accurate data capture, preventing potential disruptions to work order tracking and quality control processes. A minor typo was also addressed.
Original PR description
Fix a check on the IoT response that incorrectly rejected valid measurements of 0 from caliper devices Also fix a typo opw-6184669 Forward-Port-Of: odoo/enterprise#121116
This update resolves an issue where changes to roles for duplicated sign templates were unintentionally reflected across all instances. Now, each duplicated sign template has its own dedicated set of roles, ensuring data consistency and preventing conflicts when managing sign items. This improves the stability and accuracy of sign workflows.
Original PR description
When duplicating a sign template, its sign items were copied but their `responsible_id` was kept as a reference to the same `sign.item.role` records. As a result, editing a role on one template (e.g. assigning a partner through `assign_to`) leaked to the other template sharing it. Copy the role when copying a sign item so each template owns its own roles. task-6288951 Forward-Port-Of: odoo/enterprise#119864
This update corrects a technical issue where new version creations were inadvertently duplicating notes, which should be specific to each version. The change ensures that each version has its own unique note, streamlining version management and preventing data inconsistencies. This improves the accuracy and reliability of our version tracking system.
Original PR description
When we create a new version, we don't want to copy the note which should be version specific task-6304034 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#270110
A recent update caused the Point of Sale system to incorrectly add the 'S' variant when scanning a barcode for the 'M' variant of a product with dynamic attributes. This fix ensures that the correct variant is added based on the scanned barcode, improving the accuracy of sales transactions. The change corrects a logic error in how the system handles product variants with dynamic attributes.
Original PR description
Steps to reproduce ------------------ 1. Create a product with two attributes: - Size with values S and M (Variants Creation: "Instantly") - a second attribute with a single value (Variants Creation: "Dynamically") 2. Set a different barcode on the S and the M variant. 3. Open PoS, scan the barcode of M. -> The S variant is added instead. Why the issue ------------- In 390b48a1ba24, when a product has a single-value attribute set to "dynamic", we look for the first variant that has this value and use it instead of the preselected variant. This is wrong when several variants share this value: in our case both S and M have it, so scanning M is overridden by the first variant, S. The fix ------- We now keep the preselected variant if it already has this value, and only look for or create one otherwise. opw-6272739 Forward-Port-Of: odoo/odoo#268590
This update corrects a bug where reordering rules were incorrectly creating purchase orders linked to sales orders. Now, reordering rules will always generate new, separate purchase orders, ensuring accurate inventory management and preventing duplicate purchase orders. This improves order fulfillment efficiency.
Original PR description
Steps to reproduce the bug: - Go to contact: - azure interior: - Group RFQ: On Order - Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor - Confirm a sale…
Steps to reproduce the bug:
- Go to contact:
- azure interior: - Group RFQ: On Order
- Create two storable products P1 and P2, both with the Buy route and Azure interior as vendor
- Confirm a sale order with P1 (MTO+Buy):
- a purchase order PO1 is created, linked to the sale order via reference_ids
- Create a reordering rule for P2 and trigger it
Problem:
The reordering rule procurement for P2 was merged into PO1 (the sale order's purchase order) instead of creating a new separate PO.
In _make_po_get_domain (purchase_stock/models/stock_rule.py), when group_rfq == 'default' (On Order), the domain only adds a reference_ids filter when the procurement carries reference_ids. When the procurement comes from a reordering rule (no sale order, no reference_ids), no filter was added, so the search matched any draft PO from that vendor, including PO1, which has reference_ids pointing to the sale order.
Solution:
When group_rfq == 'default' and the procurement has no reference_ids, add ('reference_ids', '=', False) to the domain so the search only matches POs that are also not linked to any sale order.
opw-6167835
Forward-Port-Of: odoo/odoo#270735This update fixes a confusing issue in the budget report where budget lines were labeled with repetitive 'Budget 2026 x' names. The change now includes relevant analytic accounts in the budget line display, making it much easier to distinguish between different budget lines. This improves report readability and data understanding.
Original PR description
Budget report grouping by budget line displayed the budget name for every line, which made different lines indistinguishable and produced labels like "Budget 2026 x", "Budget 2026 x (2)", etc. Compute a more specific display name for budget lines by appending the analytic accounts concerned by the line to the budget name. Also expose Budget Line as a first-class group-by in the Budget Report search view and apply it by default when opening the report. task-6293065 Forward-Port-Of: odoo/enterprise#121204
This update addresses several minor issues and improvements within the Odoo spreadsheet component. It includes fixes for visual glitches, formula parsing problems, and updates to the underlying technology (Node.js and npm). These changes ensure a smoother and more reliable spreadsheet experience for users.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/dce4ae7d4f [REL] 19.1.24 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/dce4ae7d4f [REL] 19.1.24 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/b09fce3cc8 [FIX] viewport: fix viewport jump with frozen pane [Task: 6292764](https://www.odoo.com/odoo/2328/tasks/6292764) https://github.com/odoo/o-spreadsheet/commit/28177797ff [FIX] composer_tokenizer: fix argument separator in formulas [Task: 6303210](https://www.odoo.com/odoo/2328/tasks/6303210) https://github.com/odoo/o-spreadsheet/commit/f70fba15e9 [FIX] rolldown: Fix cjs file extension [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8377e1112a [IMP] node: add script to run the model in node [Task: 6088515](https://www.odoo.com/odoo/2328/tasks/6088515) https://github.com/odoo/o-spreadsheet/commit/458bba3f53 [FIX] package.json: Update Node.js and npm engine requirements [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/60cc12db7c [FIX] carousel: custom color don't use carousels [Task: 6263128](https://www.odoo.com/odoo/2328/tasks/6263128) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an error in the generation of CFDI documents when payments are made in foreign currencies. Previously, the CFDI document incorrectly displayed the payment rate. The fix ensures the correct payment amount and rate are reflected in the generated CFDI document, improving accuracy for Mexican businesses.
Original PR description
The rate and payment amount shown on the CFDI document generated after updating payments was wrong when the payment was made in a foreign currency. Steps to reproduce: ------------------- * Create a journal that use USD as currency and set the rate to 20 MXN for 1 USD * Create an invoice in MXN and make sure it is set to PPD * Add any product to the invoice for 300$ and post it * Send the invoice to CFDI (a first document should be generated) * Create a payment of 15 USD in the new journal and reconcile it with the invoice * Go back to the invoice and click on "Update payments" to generate the second CFDI document > Observation: The payment document shows an amount of 300 USD with a rate of 1 instead of 15 USD with a rate of 20. Why the fix: ------------ We make sure to use the amount from the statement line when there is one. opw-5974519 Forward-Port-Of: odoo/enterprise#120934 Forward-Port-Of: odoo/enterprise#115779
This update resolves an issue where the invoice status cron job only processed invoices for the primary company within Odoo. The fix ensures that all companies within an Odoo instance are now correctly updated, improving invoice tracking and reporting accuracy. This change was made to align with best practices for multi-company environments.
Original PR description
The invoice status cron was only fetching the main company's invoices. Fetch all companies' invoice statuses. Reference: https://github.com/odoo/odoo/pull/267144#discussion_r3441968099 no-task Forward-Port-Of: odoo/odoo#271227
This update fixes an issue where a specific configuration setting, 'bin_path', wasn't being saved correctly when updating configuration files. Previously, changes made to this setting in a configuration file were lost. Now, this setting will be reliably persisted across saves, ensuring consistent configuration settings.
Original PR description
Have a configuration file with a "bin_path" entry. Use that config file and --save it. The "bin_path" entry is removed from the new config file, it should had been persisted. The problem is common to all "undocumented options", options that did not exist in `config.py` before ConfigCleaner(7) and that were not created upon --save. We can argue about creating or not those options upon --save with the default config, but what's sure is that when the option be set in the config file, then it must be persisted across saves. Task-6106771 Reference-to: 80007415d621 ([REF] core: ConfigCleaner(7) remove deprecated options) 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#270191 Forward-Port-Of: odoo/odoo#258377
This update fixes an issue where bank verification timestamps were incorrectly displayed to users in Poland. The change converts timestamps from the local Polish timezone to UTC, ensuring accurate time representation and preventing display errors for users in the UTC+2 timezone. This improves the reliability of the bank verification process.
Original PR description
The gov API returns a 'requestDateTime' in str format in PL timezone. This commit converts it back to UTC timezone for a better display in payment form. fields.Datetime assume the value is in UTC time and so when a field of this type is displayed, it's converted to the user timezone. This cause issue with the PL API call because the API will send us 9:25 PL TZ but if we store it directly, it will be interpreted by the ORM as 9:25 UTC and displayed to the user that's in UTC+2 as 11:25 task-6314380 Forward-Port-Of: odoo/odoo#270839
This update corrects an issue where generated work entries could create duplicate entries when a flexible working schedule overlapped with a public holiday. The fix prioritizes regular leaves, ensuring public holidays consume the overlapping time first and preventing the creation of redundant work entries. This improves payroll accuracy and reporting.
Original PR description
Issue: When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.…
Issue: When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day. Steps to reproduce: - Create an employee with Work Entry Source set to Attendances - Use a flexible working schedule on the employee - Configure a public holiday on a scheduled day with work entry type (Paid time off) - Create a time off type with Count as set to Worked Time - Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after) - Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry) Cause: In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into: - leaves: absences and public holidays - worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226 For non-flexible calendar: Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260 For flexible calendar: The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249 Solution: We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created: - for fully flexible employees, subtract regular leaves from worked leaves; - for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves - for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule. This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period. opw-6237163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#268527
This update corrects an issue where worked-time leave entries could overlap with public holidays, creating duplicate entries in payroll. The fix prioritizes regular leaves, ensuring public holidays consume the overlapping time first and preventing the generation of redundant work entries. This improves payroll accuracy and reporting.
Original PR description
Issue: When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day.…
Issue: When work entries are generated from Attendances, a worked-time time off created by the Indian sandwich rule can overlap a public holiday and generate duplicate work entries for the same day. Steps to reproduce: - Create an employee with Work Entry Source set to Attendances - Use a flexible working schedule on the employee - Configure a public holiday on a scheduled day with work entry type (Paid time off) - Create a time off type with Count as set to Worked Time - Generate time off for the period so the public holiday entry exists (maybe a day before and a the public holiday and the day after) - Open Payroll > Work Entries (Observe the date of the public holiday will have more than 8h entry) Cause: In `_get_version_work_entries_values()`, calendar leaves are split by `hr_holidays` `time_type` into: - leaves: absences and public holidays - worked_leaves: worked-time time off For attendance-based contracts, both sets were turned into work entries without removing overlap between a public holiday and a worked-time leave on the same period. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L222-L226 For non-flexible calendar: Public holidays and worked-time leaves are both clipped to the static working schedule (e.g. 8h per working day). overlap was kept in both result sets. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L260 For flexible calendar: The one-day intervals are kept as the actual interval (often 00:00-23:59 for a public holiday). The worked-time on that day is schedule-shaped (e.g. 8h). Subtracting intervals on a full-day public holiday left a 16h fragment instead of removing the public holiday entry. https://github.com/odoo/odoo/blob/3a088e23d3e563c39cdcb252edc8c7cc74981de4/addons/hr_work_entry/models/hr_version.py#L242-L249 Solution: We need to make regular leaves take priority over worked-time leaves, compute the real regular leave intervals first, then remove those intervals from the worked-time leave intervals before work entries are created: - for fully flexible employees, subtract regular leaves from worked leaves; - for flexible calendars, keep one-day regular leaves as is and subtract them from worked-time leaves - for non-flexible attendance-based calendars, clip regular leaves on the static schedule, then subtract them from worked-time leaves clipped on the same schedule. This means that when a sandwich worked-time leave overlaps a public holiday, the public holiday consumes that period first. The overlapping part is then removed from `real_worked_leaves`, so no second worked-time entry is generated for the same public holiday period. opw-6237163 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#119530
This update resolves a problem where Odoo couldn't correctly retrieve lot numbers from GS1 barcodes with specific prefixes (starting with '10'). The fix ensures accurate lot number identification when scanning these barcodes, preventing errors and improving inventory management. This impacts users relying on GS1 barcode scanning for stock tracking.
Original PR description
When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db. **Steps to reproduce** * In settings activate: - Lots & Serial…
When we scan a gs1 barcode that has in his lot a special character and start with 10, odoo will not be able to retrieve it from the db. **Steps to reproduce** * In settings activate: - Lots & Serial Numbers - Units of Measure & Packagings - Storage Locations - Barcode Scanner : GS1 nomenclature * Create a Product tracked by lot with - barcode: 00001234567895 * Add on hand quantity: - 100 kg in lot : 10002002303-4 - 100 kg in lot : 11002002303-4 * Go to barcode>Operation>Internal Transfer>New * Scan 02000012345678951010002002303-4#3100000100 meaning: - 02 following 14 characters are the product barcode - 10 following characters are the lot number - "#" separator - 3100: means the units are kilograms, - 00100 means 100 units. -> if you check with the edit button the lot was not found (if you click on validate it will trigger an UserError for missing lot) **Observation** When scanning the GS1 barcode it will call onBarcodeSubmitted->onBarcodeScanned where we will execute processBarcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/components/main.js#L387 Where we will deconstruct the barcode into his component en retrieve from the db the relevant data: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/models/barcode_model.js#L709-L717 - First the barcode is parsed, identifiers are erased and each section is separated, the variable with our lot number only has the lot number in it, the identifier (10) is not included, BarcodeObject.forBarcode(bc) -> new BarcodeObject -> parser.parse_barcode: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/barcode_object.js#L14 - Check if the data is in the cache, if not, set it to retrieve after - Retrieve missing data getMissingRecords : https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/static/src/lazy_barcode_cache.js#L349 From here we will get a call to get_specific_barcode_data for each element: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L176 In the case of the stock.lot since it has a symbol and it's not only digit it will skip the gs1 nomenclature domain converter (it will not become 'ilike' and stay with 'in'): https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L182-L197 We will do the search: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/controllers/stock_barcode.py#L205 during which we will retrieve specific query from the stock.lot module : https://github.com/odoo/odoo/blob/8d14665af5acf1bd391d05a5048dc701986e8b15/odoo/orm/models.py#L1408 Where, since it's a GS1 nomenclature, we will preprocess the agrs: https://github.com/odoo/enterprise/blob/8030b105d3fce1eef9b8965a2bfc37195f71723c/stock_barcode/models/stock_lot.py#L14 -> Since our barcode start with a 10, it will erase it, which lead to a miss in the search. It will also avoid further searches since we avoid multiple search on the same elements (added in missingBarcodeKeyCache in getMissingRecords). https://github.com/odoo/enterprise/blob/c6d18a7a92092ffdf96f4569a70e95bdc276441c/stock_barcode/static/src/lazy_barcode_cache.js#L294-L298 opw-6207120 Forward-Port-Of: odoo/enterprise#118828
This update resolves an issue where the partner associated with an invoice was incorrectly overridden by the purchase order during UBL XML imports. The fix establishes the purchase order as the definitive source for partner information on invoices, ensuring accurate data matching and billing. This improves the reliability of our UBL integration.
Original PR description
Fix a bug where the partner of a bill is overriden by the PO matching The chosen logic here is to say that in the context of a purchase, the purchase order is the single source of truth to set the partner on a bill Steps to reproduce: - Create a partner with is_company = True - Create a contact type 'invoice' for this partner - Create a purchase order for the first partner - Import an XML (UBL) that matches this PO - You can see in the import logs that the partner was correctly found first, and then the PO matching override it to set the contact as the partner task-6289358 Forward-Port-Of: odoo/odoo#271133 Forward-Port-Of: odoo/odoo#269223
This update resolves a bug that prevented users from correctly adjusting task deadlines within the Gantt chart view. Specifically, shrinking a task's deadline caused a server error. The fix addresses a situation where tasks without successors resulted in an empty candidate list, triggering the error. This ensures the Gantt chart functionality now works reliably for all task rescheduling scenarios.
Original PR description
## Current behavior: In the Project's app, switch to Gantt chart's view, when changing the deadline of a single task by shrinking its right edge, the server throws `ValueError: max() iterable…
## Current behavior: In the Project's app, switch to Gantt chart's view, when changing the deadline of a single task by shrinking its right edge, the server throws `ValueError: max() iterable argument`` is empty when calling end_date = max(candidates.mapped(stop_date_field_name)). ## Steps to reproduce: 1. In version 19.0 and above, install Project app 2. Create a project and only 1 single task 3. Switch to Gantt chart view 4. Try changing the deadline of a task by dragging its right edge 5. Observe that extending the task's deadline by dragging to the right works fine, but shrinking the deadline by dragging to the left will cause server to throw RPC_ERROR: Odoo Server Error and ValueError: max() iterable argument is empty. ## Cause of the issue: - A task with NO successors will cause candidates gathered via dependency_inverted_field_name to be empty. - The empty candidates recordset then get called by max(candidates.mapped(stop_date_field_name)), which is the reason causing error message ValueError: max() iterable argument is empty. opw-6283566 Forward-Port-Of: odoo/enterprise#120375
This update resolves a bug that prevented receipt printing after the initial order in the Italian POS module. The fix ties printing to the 'Skip Preview Screen' option, eliminating a race condition that previously blocked printer communication. This ensures consistent receipt printing for Italian POS transactions.
Original PR description
Module: l10n_it_pos Steps to reproduce: - In the POS settings, enable "Automatic Receipt Printing"; - Enable "ePos Printer" to make the "Skip Preview Screen" option appear; - Disable "Skip Preview…
Module: l10n_it_pos Steps to reproduce: - In the POS settings, enable "Automatic Receipt Printing"; - Enable "ePos Printer" to make the "Skip Preview Screen" option appear; - Disable "Skip Preview Screen"; - Disable "ePos Printer"; - Set up an Italian Fiscal Printer; - Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required. Cause: When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of `renderService`, permanently blocking the printer queue. Solution: Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option. Enterprise PR: https://github.com/odoo/enterprise/pull/112654 [opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270857 Forward-Port-Of: odoo/odoo#256932
This update resolves a bug that prevented receipt printing after the initial order in the Italian POS module. The fix ensures that receipts are consistently printed, eliminating the need for page reloads. The system now correctly ties receipt printing to the Italian fiscal printer configuration, improving the user experience.
Original PR description
Module: l10n_it_pos Steps to reproduce: - In the POS settings, enable "Automatic Receipt Printing"; - Enable "ePos Printer" to make the "Skip Preview Screen" option appear; - Disable "Skip Preview…
Module: l10n_it_pos Steps to reproduce: - In the POS settings, enable "Automatic Receipt Printing"; - Enable "ePos Printer" to make the "Skip Preview Screen" option appear; - Disable "Skip Preview Screen"; - Disable "ePos Printer"; - Set up an Italian Fiscal Printer; - Open a POS session and process a first order. Issue: After the first receipt, no other messages (price display, receipt, open register) are sent to the fiscal printer. A page reload is required. Cause: When "Automatic Receipt Printing" is true but "Skip Preview Screen" is false, a race condition occurs. `afterOrderValidation` triggers a print job while simultaneously transitioning to the `ReceiptScreen`. When the `ReceiptScreen` mounts, it triggers a second fiscal print job before the first has resolved. This creates a deadlock in `toHtml` of `renderService`, permanently blocking the printer queue. Solution: Since the italian localisation sending the receipt to the fiscal printer is mandatory, the printing route is now tied to the "Skip Preview Screen" option. UI settings are adjusted to hide the redundant auto-print checkbox when an IT fiscal printer is configured. Community PR: https://github.com/odoo/odoo/pull/256932 [opw-5979212](https://www.odoo.com/odoo/project/49/tasks/5979212) Forward-Port-Of: odoo/enterprise#121035 Forward-Port-Of: odoo/enterprise#112654