Daily updates from Odoo
Tuesday, June 23, 2026
33 changes · saas-19.2
New functionality added to Odoo
This update streamlines connections to remote SaaS databases for users created through the Databases module. Now, users will automatically authenticate upon connecting, eliminating the need for manual login screens and improving the overall user experience.
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#112369This update adds the ability to generate invoice PDF reports in multiple formats (Original, Duplicate, and Triplicate) to meet government regulations regarding GST documentation. Users can now print two or three copies of an invoice with distinct titles for different recipients, ensuring accurate record-keeping for transporters and suppliers. This improves compliance and reporting accuracy.
Original PR description
The Goverment specifies that invoice should be printed in different formats as per the different parties the invoice is been given to. Invoice should be marked as "Original" for receiver's copy. Invoice should be marked as "Duplicate" for transporter's (incase of goods supply) or supplier's copy. Invoice should be marked as "Triplicate" for supplier's (incase of goods supply) copy. This commit adds two new report actions, for Duplicate and Triplicate on invoice, visible in the Print section under the gear icon. When user prints Duplicate, 2 copies will be printed and for Triplicate, 3 copies will be printed at once, with different titles set on each copy of invoice. task-5899610 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270813
Enhancements to existing features
This update optimizes the calculation of work order durations, preventing unnecessary recomputations. Previously, creating a work order from the Shop Floor triggered an extra step, slowing down the process. This change ensures the duration is calculated efficiently, improving performance.
Original PR description
When creating a work order from the Shop Floor using the "Add Work Order" option and providing a start date and duration, the `write()` method is called to update the finished date. This triggers a recomputation of the expected duration. Since the expected duration is already correct after the fix introduced in the community module, this additional computation is unnecessary and only adds extra processing. This commit use alredy availble context flag to bypass the redundant recomputation when the expected duration is already known and valid. task-6232842
This update clarifies the process for adding signatures within the HTML editor. The wording has been changed from 'Insert your signature from Sign' to 'Insert your handwritten signature' to better reflect the functionality. This change enhances the user experience and ensures clarity for users adding official signatures to documents.
Original PR description
Purpose of this PR: - Replace 'Insert your signature from Sign' with 'Insert your handwritten signature'. task-6217718 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267995
This update allows customers using the self-order system to pay at the counter, even if they've already selected a payment method within the self-order process. This provides greater flexibility for customers and streamlines the checkout experience, particularly in scenarios where a customer wants to pay with cash after selecting a payment method digitally.
Original PR description
pos*: point_of_sale, pos_self_order This commit allows the user to allow his customer to pay at the counter even if they already have payment method set in the self order. task-id: 5960666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250364
Resolved issues and error corrections
This update prevents users from incorrectly increasing refund quantities when processing gift card or e-wallet orders in the ticket screen. Previously, clicking these orderlines would lead to unintended quantity adjustments. This change ensures accurate refund processing and improves the overall reliability of the point-of-sale system.
Original PR description
Before this commit: =================== - Clicking an e-wallet or gift card orderline in the ticket screen increased the refund quantity. After this commit: ================== - Gift card and e-wallet products are now restricted from refund quantity increments in the ticket screen. Task - 6200888
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 that reports only show data for the active company, improving the accuracy of order preparation tracking.
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 temporary data discrepancies from triggering these warnings, resulting in a smoother and more intuitive editing process. The warnings are now only calculated when the bill is saved, ensuring a better 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 fixes an issue where the sandwich rule incorrectly excluded public holidays from leave calculations. Now, when 'Include Public Holidays as Working Day' is selected, the system accurately determines the correct leave duration, including weekend days as part of the calculation. A new test case has been added to ensure this fix.
Original PR description
Problem: When a time off type is configured with "Include Public Holidays as Working Day", the sandwich rule was still treating public holidays as non-working days. This caused the sandwiched weekend days to not be included in the leave duration. Example: Employee applies leave from May 15 (Friday, Public Holiday) to May 18 (Monday). Expected duration is 4 days since May 15 is a working day and May 16-17 (weekend) should be sandwiched. Instead, only 1 day was calculated. Fix: Now when "Include Public Holidays as Working Day" is enabled, the correct number of days are calculated in the sandwich rule. Also added a test case to verify that public holidays are correctly treated as working days during sandwich rule evaluation. Task-4570118 Forward-Port-Of: odoo/odoo#270254 Forward-Port-Of: odoo/odoo#266624
This update resolves an issue that prevented efficient processing of invoices with multiple related documents (specifically those related to Mexican tax filings - CFDI). By using a specialized index, the system now handles complex cancellation scenarios and large volumes of data more effectively, ensuring smoother invoice workflows.
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 fix now filters out 'blocked' couriers, ensuring only service-eligible options are considered for shipping rates and selections. Additionally, the system is more robust to handle potential errors in Shiprocket's data.
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 data accuracy and prevents potential errors in financial reporting. This change improves the reliability of the accounting processes 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 fix resolves an issue where extra prices were incorrectly applied to products with 'always' attributes when creating point-of-sale combos. The update ensures that extra prices are now set on the combo creation page for 'always' attributes, aligning with how the system should calculate prices for these product variations.
Original PR description
## Steps to reproduce - Create an attribute A, of type always, with 2 values, one should have an extra price - Create an attribute B, of type never, with 2 values - Create a product that has both…
## Steps to reproduce - Create an attribute A, of type always, with 2 values, one should have an extra price - Create an attribute B, of type never, with 2 values - Create a product that has both those attributes - Create a combo with that product with both values for A - Go to the PoS and order that combo with the value that has an extra price for A - The extra price is added ## Why the fix: For variants of type always, a product is created, meaning we can chose which products of this variants to have in our combo. As we can chose this, it means that we can and should chose the extra price on the combo creation page, not on the attribute page. It does not make sense to take the attribute extra price into account, as we do not take the unit price of combo items into account, so this extra price should be set on the combo page and we should ignore the attribute's extra price if the type is "always". The variants are then considered as different products, as they should in this case. If the type of the attribute is never, we can't chose which one gets an extra price on the combo page, so we should still take the attribute's extra price in this situation, as we have no other way to set it. We need to have both an always and a never attribute in order to reproduce this bug because if we only have "always" values, the configuration of the combo item is bypassed and is undefined, so **attribute_value_ids** will be undefined in this code and we won't get any value for the extra price in this code: https://github.com/odoo/odoo/blob/c09e8b2fc24ee75495fc947924e29cf5c601506f/addons/point_of_sale/static/src/app/models/utils/compute_combo_items.js#L44-L49 We now ignore the attribute's extra price if it's type is always, otherwise, it the behavior stays the same. opw-6262431 Forward-Port-Of: odoo/odoo#270894 Forward-Port-Of: odoo/odoo#268567
This update corrects a technical issue where the system incorrectly rejected zero measurement values received from caliper devices via IoT. This ensures that zero readings are now properly recorded, providing a more complete and accurate picture of product quality. The update also includes a minor typo correction.
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 recurring plans would disappear from the website when a product's quantity was increased. The original fix only worked on the initial page load, but this change ensures the recurring plan selection remains accurate even after updates to the product's price or variant. This improves the user experience for subscription customers.
Original PR description
# Introduction note This PR fixes two bugs introduced by the same commit : https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa The original commit fixed multiple issues…
# Introduction note This PR fixes two bugs introduced by the same commit : https://github.com/odoo/enterprise/commit/106d70a1ef0ddbd61a74b7cac82dfce1e316beaa The original commit fixed multiple issues regarding the display of recurring plans when the One-time purchase option was enabled, but it also introduced new ones. Theses new issues are due to multiple new checks on `allow_one_time_sale`, but this variable only indicates that the One-time purchase option is available to the user, not that it is actually selected. So the fixes of the original commit works when first loading the page, but fails when the content of the page is updated. # Shared steps - Activate Subscriptions & eCommerce modules - Create a subscription product, enable 'Accept One-Time' and publish it on the website # Bug 1 ## How to reproduce - Add atleast two recurring plans to the product - Go to the product page on the website - Select one of the recurring plans - Increase the quantity of the product ## The problem The recurring plan selection is removed ## Cause The condition `!combination_info.allow_one_time_sale` was added on the `t-att-checked` of the recurring plan selection display. This correctly fixed the issue when first loading the page, but when the user changes the price or the variant, the recurring plan are recomputed and rerendered : https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L37-L40 When that is the case, that condition blocks the proper display of the selected recurring plan. ## Proposed Solution When loading the recurring plan selection, what defines wich plan is selected is the `subscription_default_pricing_plan_id` variable, which is based on the `plan_id` value given in the request to the server : https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/models/product_template.py#L222 We make it so if no `plan_id` is sent to the server and `allow_one_time_sale` is enabled, then the server does not give back any `subscription_default_pricing_plan_id` opw-6131532 # Bug 2 ## How to reproduce - Add an attribute with values A & B for the product - Define atleast two recurring plans for the variant with attribute B - Publish the product - Go to the product page - Select the variant with attribute B ## The problem The recurring plan is not displayed. If the order of the attribute is reversed, then it works as expected. ## Cause The pricings are correcly sent to the front-end but they are not added to selection because of the check on `allow_one_time_sale` : https://github.com/odoo/enterprise/blob/0b408acbadb2cfcbc844521f3244a06b7ae7be22/website_sale_subscription/static/src/interactions/product_page.js#L42-L50 opw-6132160 Forward-Port-Of: odoo/enterprise#120873 Forward-Port-Of: odoo/enterprise#115446
This update fixes a bug in the stock valuation calculation that incorrectly displayed product values when multiple companies and currencies were involved. The fix ensures that values are accurately converted to the main company's currency (USD) for a correct total value calculation. This impacts how stock values are reported across different company setups.
Original PR description
**Steps to reproduce:** - make sure your main company (company 1) has dollars as its main currency - create second company (company 2) and a warehouse in this second company - set euro has the main…
**Steps to reproduce:** - make sure your main company (company 1) has dollars as its main currency - create second company (company 2) and a warehouse in this second company - set euro has the main currency in the company 2 From company 1: - set an exchange rate of 1$ = 0.5 eur on the euro currency - create a storable product with a cost of 10$ and an on-hand quantity of 1 From company 2: - set the cost to 10 eur and set an on-hand quantity of 1 with both company selected and company 1 as the main company selected: - open the stock view and look for your product **Current behavior:** the total value is 20$ **Expected behavior:** with conversion rate, it should be 30$ **Cause of the issue:** when computing the total value we do not apply a conversion rate from the value of the company to the main company selected https://github.com/odoo/odoo/blob/8759429547e42e9f63b15a7c80475be46ef437e2/addons/stock_account/models/product.py#L273 opw-6280108 Forward-Port-Of: odoo/odoo#270575
This update resolves a bug where overtime was incorrectly generated when using timing rules with employer tolerances. The fix ensures that attendance limits are accurately considered, preventing unnecessary overtime calculations. This improves the accuracy of employee time tracking.
Original PR description
**Version:** - 19.0 **Steps to reproduce:** - Create a rule of Timing type. - Add a tolerance for the employer. - Set the ruleset on the employee. - Add an attendance of less than the tolerance. **Issue:** - When using a Timing type rule with employer tolerance, overtime is still created even if the attendance is below the tolerance limit. **Cause:** - The timing rule calculation was missing the tolerance check that exists in the quantity rule calculation. **Fix:** - Added the missing tolerance check in the timing rule calculation. - Removed employee tolerance from view for timing rules. **Task-6064081** Forward-Port-Of: odoo/odoo#257079
This update resolves an issue where attendees received duplicate email notifications when rescheduling a meeting. The problem stemmed from a technical error in how the system handled date changes, leading to unnecessary email sends. The fix ensures that attendees only receive one notification for meeting updates.
Original PR description
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a…
Steps to reproduce: 1. Install CRM, Calendar, and Contacts. 2. Create a contact with an email address you can receive emails on. 3. Configure an outgoing email server. 4. Open a CRM lead and create a meeting activity using the calendar. 5. Add the created contact as an attendee of the meeting. 6. Return to the lead and click the Reschedule button on the activity. 7. Select the same meeting and change its start date to a future date. Issue: - Attendees receive the meeting date-change email twice. Root cause: - When a calendar event linked to an activity is rescheduled, the event write syncs the new start date to the related activity through `_sync_activities`. That activity write was not marked as calendar-originated after commit https://github.com/odoo/odoo/commit/bc090486bd7810b1b0af1bae398255a2d6615f09, so `mail.activity.write` treated the updated deadline as an activity-originated change and wrote back to the same calendar event. https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/calendar_event.py#L779 https://github.com/odoo/odoo/blob/8cbb0fe91a35fcdb4a7e4e1a7e8afe40b1691f11/addons/calendar/models/mail_activity.py#L24-L33 - This created a nested calendar event write. Both the nested write and the original write then triggered attendee date-change notifications, resulting in duplicate emails. Solution: - Pass the existing `calendar_event_meeting_update` context flag when syncing calendar event changes to linked activities. This prevents the activity sync from writing back to the event while preserving activity-to-event rescheduling. opw-6209956 Forward-Port-Of: odoo/odoo#266675
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 always added, 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 fixes an issue 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 corrects a scheduling issue in manufacturing orders where operations with dependencies were not always processed in the correct order. The fix ensures operations are planned based on their dependencies, preventing delays and improving production efficiency. This resolves a conflict when planning operations with shared blockers.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe Steps to reproduce the bug: - Create a product with a BoM with operation dependencies enabled - Add 4…
Bug introduced in: https://github.com/odoo/odoo/commit/cfc5c998035b4268c36f5097782888e18e21b4fe
Steps to reproduce the bug:
- Create a product with a BoM with operation dependencies enabled
- Add 4 operations on the same workcenter:
- opA: no blocker
- opB: blocked by opA
- opC: blocked by opA
- opD: blocked by opC
- Confirm a manufacturing order from this BoM
- Click Plan
Problem:
opA was scheduled after opB, violating the dependency.
`_plan_workorders` starts planning from the "leaf" workorders (those
with no dependents). Given the structure above, the initial set is
[opB, opD]. Processing opB first correctly plans opA then opB. But
processing opD triggers a recursive chain opD→opC→opA which calls
`action_unplan(opA)` and replans it from scratch. By then, opB already
occupies the workcenter slot that opA originally held, so opA ends up
scheduled after opB.
Solution:
Add `and not wo.is_planned` to the filter on `blocked_by_workorder_ids` in the recursive call inside `_plan_workorders`. Workorders that are already planned are skipped instead of being unplanned and replanned, preserving the correct order.
opw-6299179This update resolves a bug where clicking gift cards, e-wallets, or discount order lines in the ticket screen incorrectly increased refund quantities. Now, these product types are properly restricted from quantity increments during refunds, ensuring accurate transaction processing.
Original PR description
pos*: point_of_sale, pos_loyalty, pos_discount Before this commit: =================== - Clicking an e-wallet, gift card, discount order line in the ticket screen increased the refund quantity. After this commit: ================== - Gift card, e-wallet and discount products are now restricted from refund quantity increments in the ticket screen. Task-6200888 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a confusing issue in the budget report where budget lines were labeled with unclear identifiers like 'Budget 2026 x'. The report now displays budget lines with more specific names, including associated analytic accounts, making it easier to understand and analyze budget data. This enhancement improves the user experience and reporting accuracy.
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 resolves a crash that occurred when users tried to view Instagram videos within Odoo. The fix now displays the video link instead of attempting to render the video as an image, ensuring a stable preview experience. This improves usability and prevents disruptions for users accessing Instagram content.
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 bug where the invoice status cron job only processed invoices for the main company. Now, it accurately retrieves and updates the status of invoices across all companies within the Odoo system. This ensures accurate reporting and compliance for all business entities.
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 bank verification timestamps were incorrectly interpreted, leading to display errors for users in Poland. The change converts timestamps from the local Polish timezone to UTC, ensuring accurate display and preventing misinterpretations during API calls. This improves the reliability of bank verification processes.
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 fixes an issue where scanning an unknown barcode in the Point of Sale (POS) system didn't automatically open the product creation form. The fix removes a redundant check for API keys, ensuring the form opens correctly regardless of whether a barcode lookup key is configured. This streamlines the process for users adding new products via barcode.
Original PR description
When scanning an unknown barcode in POS, the product creation form was never opened because `barcode_lookup()` was called with no barcode as an implicit API key check. Commit 0c8019a4aa7 ([FIX] product_barcodelookup: avoid crash on invalid image URLs) standardized `barcode_lookup_request()` to always
return a `requests.Response` object, removing the `{'authenticated': True}` dict it previously returned for HTTP 404 responses. As a result the JS check `response?.authenticated` was always falsy and the form never opened.
Fix: remove the API key check entirely. `allowProductCreation()` already gates on the user having product create rights, which is the only condition that matters. If a Barcode Lookup API key is configured the `_onchange_barcode` on the form will auto-fill product data; if not, the user can fill it in manually. Either way the form is always usable.
opw-6295221
Forward-Port-Of: odoo/enterprise#120256This update ensures that kiosk orders aren't automatically sent to the blackbox if the payment hasn't been finalized. This change allows for seamless payment at the counter with other payment methods, improving the kiosk experience for customers and streamlining order processing.
Original PR description
This commits adapts the code in confirmation_page.js to not send the order to the blackbox from the kiosk if the order is not in paid state. task-id: 5960666 Forward-Port-Of: odoo/enterprise#117585
This update resolves an issue where the partner associated with a bill was incorrectly overridden during UBL XML import processes. The fix ensures that the purchase order always serves as the primary source for partner information on bills, improving data accuracy and consistency. This prevents errors related to mismatched partner information in invoices.
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 an issue where the timesheet icon disappeared from the toolbar when 'Attendances from Backend' was disabled. The fix ensures the icon remains accessible, allowing users to log hours directly from the toolbar regardless of the backend attendance settings. This improves usability for users who prefer to log timesheets manually.
Original PR description
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet…
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet systray` from the `registry` and merges it inside the attendance dropdown. When `attendance_from_systray` is off, the dropdown hides itself and takes the timesheet icon with it, leaving no way to log hours from the toolbar. Expected behavior: Timesheet icon should remain accessible when attendance from systray is disabled. Issue: `registry.remove()` at module load made the timesheet icon impossible to restore. Fix: Keep the timesheet systray registered. Patch TimesheetSystray to read `display_systray from lazy_session` on startup and show itself standalone when attendance from systray is off. The template no longer replaces nodes. Header and total_hours are toggled via `position="attributes"` (`t-if="!props.signInOut"`, a prop only passed by the attendance dropdown), and a self-contained dropdown-only footer with the Check out button is added after total_hours. Ref: odoo/enterprise#104347 task-6285068
This update prevents a frustrating access error that occurred when users opened the timesheet task suggestion dropdown. The fix filters task suggestions to only include tasks the user currently has permission to view, ensuring a smoother timesheet experience. This resolves an issue impacting user productivity.
Original PR description
Steps to reproduce: - 1. Log in as a user who can see their own timesheets and has already logged time on tasks that are now in projects they can no longer read (e.g. Marc Demo in the demo data). 2. Open the Timesheets timer in the systray and check in. 3. Click the task field to open the suggestions dropdown. Issue: - An access error is raised when the task dropdown is opened. Cause: - The timer's `project.task` `name_search` override suggests recently used tasks via `account.analytic.line.sudo()._get_recently_used_records()`. The sudo surfaces task ids the user can no longer read. `name_search` returns them, raising the access error. Fix: - Filter the aggregation result so only tasks the user can read are returned. task-6319815
This update corrects a technical issue where new version creations were inadvertently duplicating notes, which should be specific to each version. This change ensures that each version's note is accurately recorded, improving data consistency and reducing potential confusion. It's a small, internal fix that enhances the reliability of our versioning 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#271379 Forward-Port-Of: odoo/odoo#270110