Daily updates from Odoo
Sunday, January 18, 2026
33 changes · master
Resolved issues and error corrections
This update fixes an issue where appointment dates were displayed out of order in the online booking cart. The problem stemmed from reversing a list of dates, which unintentionally reordered them. The fix ensures dates are formatted correctly for accurate display.
Original PR description
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The…
**Steps to produce:** - Install `appointment,website_sale` modules. - Go to website > appointment > Online Cooking Lesson. - Book a slot > Proceed to payment. - Open the cart. **Issue:** - The appointment dates are displayed in an incorrect order in the cart. **Root cause:** - In the linked commit, the logic reverses the `self.name` lines to fix a display issue. - However, since appointment dates are split across multiple lines, reversing the list also unintentionally reverses the appointment date order. **Solution:** - Ensure that the appointment dates are formatted to appear on a single line, preventing them from being split into multiple list entries and incorrectly reordered when the lines are reversed. [commit]: https://github.com/odoo/odoo/pull/223433/changes/5b69176e64e6a4cc46966a8c41b675ed3d98dd0a Before: <img width="554" height="138" alt="image" src="https://github.com/user-attachments/assets/3e13a2a5-61d5-48c5-8e6a-85f313f7b6ca" /> After: <img width="566" height="120" alt="image" src="https://github.com/user-attachments/assets/f0b04592-7fd4-4104-b200-cf9b6f080962" /> opw-5420805 --- Forward-Port-Of: odoo/enterprise#104536 Forward-Port-Of: odoo/enterprise#104100
This update resolves an issue where the system wasn't always creating new VoIP calls when a matching record wasn't found. Now, the system reliably creates a new call if one doesn't already exist, ensuring accurate call tracking and management within the Enterprise module. This improves the overall reliability of our VoIP functionality.
This update ensures that payment terminal responses sent via websocket include a necessary 'session_id'. This resolves an issue where the system couldn't properly track payment sessions, leading to potential errors. The fix improves the reliability of payment processing.
Original PR description
We provide the request data to the payment terminal response to ensure `session_id` exists in the response sent through websocket. Forward-Port-Of: odoo/odoo#244264
This update ensures that manually set currency rates on customer invoices (especially in Germany and Hungary) are correctly applied during the invoice posting process. Previously, the system automatically replaced these rates with standard currency rates, leading to potential inaccuracies. This change maintains the user's intended rate, improving financial reporting.
Original PR description
Initial setup: Install l10n_hu_edi and l10n_de. When creating a customer invoice DE in a foreign currency, a manually edited currency rate was overridden at posting time with the rate from the currency table. Reason: l10n_de overrides `move._post` to assign the `delivery_date`. l10n_hu_edi recompute currency rates when the `delivery_date` changes. Ensure that any manually entered rate is preserved during posting by making sure that l10n_hu_edi override only affect HU moves. task-5391774 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242192
This update corrects a misleading warning displayed on invoices for companies outside of Kenya. The fix ensures that eTIMS validation only applies to companies based in Kenya, preventing unnecessary alerts and improving the user experience. This change simplifies invoice processing for all businesses.
Original PR description
**Steps to reproduce:** * Install the **l10n_ke_edi_oscu** module. * Use a **non-Kenyan company** (e.g., “My Company (San Francisco)”). * Open any invoice for that company. **Observed behavior:** * A warning about **incomplete eTIMS configuration** is shown on invoices, even though the company is not based in Kenya. **Cause:** * The eTIMS validation logic runs for **all companies**. * Non-Kenyan companies, which do not require eTIMS setup, are still evaluated and trigger the warning. **Fix:** * Run the eTIMS validation only for **Kenyan companies**. * Suppress the warning for companies outside Kenya. opw-5435558 Forward-Port-Of: odoo/enterprise#103158
This update corrects a display issue in the Follow-up Levels list view. Previously, an 'Activity' was always shown even when 'Schedule Activity' was disabled. Now, the Activity column only appears when 'Schedule Activity' is actively enabled, ensuring a cleaner and more accurate view of follow-up level details.
Original PR description
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup`…
Currently, follow-up levels display an `activity` in the list view even when the `Schedule Activity` option is not enabled on the record. **Steps to reproduce:** - Install the `account_followup` module. - Navigate to Accounting > Configuration > Invoicing > Follow-up Levels. - Click `New` and enter a `description`. - Open the `Activity tab`, `enable` Schedule Activity, set an Activity Type and Summary, then `save`. - `Disable` Schedule Activity, `save` the record again, and return to the `list view`. - Observe the `Activity` for the newly created follow-up level. **Observation:** The Activity column still shows a value in the list view, even though Schedule Activity is unchecked. **Root Cause:** At [1], `activity_type_id` is always shown in the list view without considering `create_activity`, causing the `activity` to remain visible even when `Schedule Activity` is `disabled`. **Fix:** This commit ensures that the `Activity` is displayed in the list view only when `Schedule Activity` (`create_activity`) is enabled for the record. [1]: https://github.com/odoo/enterprise/blob/d7882a8f97802d7302d81c1fa375a81bb4ca4717/account_followup/views/account_followup_line_views.xml#L13 opw-5476176 Forward-Port-Of: odoo/enterprise#104427
This update fixes an issue where placeholder hint text in the HTML editor would awkwardly wrap onto multiple lines when the screen was narrow. Now, the text is correctly truncated when space is limited, ensuring a cleaner and more professional appearance for users.
Original PR description
Description of the issue this PR addresses: - The placeholder hint text wraps onto multiple lines when the cell width is reduced. - When there is insufficient horizontal space, the text should be truncated rather than wrapped. task-5480080 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244178 Forward-Port-Of: odoo/odoo#243006
This update prevents notifications for other recipients from being incorrectly marked as ‘bounced’ when a single bounce email is received. The issue stemmed from an outdated search domain that matched all notifications linked to a message, even when bounce data was incomplete. This fix ensures accurate notification tracking and avoids unnecessary confusion.
Original PR description
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an…
When a bounce is received for one recipient of a message sent to multiple partners, notifications for other recipients can be incorrectly marked as “bounced”. Reproduction Steps: 1. Configure an incoming mail server with a bounce alias. 2. Create multiple contacts with different email addresses. 3. Send a message that notifies multiple contacts. 4. Process a bounce email related to only one recipient. 5. Observe that notifications for other recipients of the same message are also marked as “bounced”. Root Cause: During bounce processing, `MailThread._routing_handle_bounce` builds a search domain to identify which `mail.notification` records should be updated. The original implementation constructed an `OR` domain that could include empty domain elements (`[]`) when some bounce identification data was missing. In Odoo’s domain logic, an empty domain represents a constant “match all” condition. When such a domain is included in an `OR`, the entire expression can match all notifications linked to the message, rather than only those related to the bounced recipient. Fix: The domain used to select bounced notifications is now built dynamically. Criteria are only added when the corresponding bounce identification data is present. opw-5349170 Forward-Port-Of: odoo/odoo#242650
This update resolves a critical issue where Odoo installations didn't consistently create foreign key relationships in the database. This resulted in 'Record missing' errors appearing after data changes, potentially causing significant disruptions. The fix ensures Odoo installs with properly configured foreign keys, improving database stability and preventing these unexpected errors.
Original PR description
---- Description of the issue/feature this PR addresses: See related OPW Ticket [opw-5495025](https://www.odoo.com/my/tasks/5495025) Current behavior before PR: Odoo seems to install correctly, and works normally. However the database consistency is not ensured. Foreign Keys are not created. User receives `Record missing` errors after some time, when there was a Contact deleted, for example. Issue is dangerous, because it can be latent and be undetected for weeks or months. Desired behavior after PR is merged: Odoo installs *with* the Foreign Keys, and works normally. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr --- Ticket opw-5495025 Forward-Port-Of: odoo/odoo#243833
This update resolves a potential error in the accounting system that could occur when calculating tax distributions. The change ensures the system handles the rare scenario where all factors are zero, preventing a traceback and maintaining accurate calculations. This improves system stability and reliability.
Original PR description
In 614dcf23b89 `_distribute_delta_amount_smoothly` was changed to use a half-up round rather than a ceiling, and incorporate an additional step of distributing any remaining cents. However, the step that distributes any remaining cents relies on the assumption that there are less remaining cents than the number of factors. This assumption generally holds true because most cents are already allocated in the first step which uses the `round` function; except in one edge case, which is if all factors are zero. In that case, the `_normalize_target_factors` method will return an all-zero list of normalized factors, and so no cents will be allocated in the first step. The fix is to change `_normalize_target_factors` so that in this edge case, the list of normalized factors allows most cents to get allocated in the first step. See #240136 task-none Forward-Port-Of: odoo/odoo#240616
This update prevents unnecessary requests to OpenStreetMap when warehouse location addresses are invalid. Previously, failed geolocation attempts led to a continuous loop of requests. Now, the system sets default coordinates for invalid addresses, streamlining the location process and improving overall efficiency.
Original PR description
When a warehouse location had no coordinates, a request to geolocate the address was made to OpenStreetMap every time the location selector was open. However, when the address was invalid, the geolocation failed, and no coordinates were set, which caused further geolocation requests being continuously sent. This commit changes the geolocation behavior to set invalid coordinates for the address when the request fails, thus disabling future geolocation attempts for that address. Forward-Port-Of: odoo/odoo#243523
This update fixes an issue where sale warnings weren't showing when set on a company contact instead of an individual contact. The change ensures that all sale warnings, regardless of whether they're linked to a company or individual, are now correctly displayed to users. This improves sales process visibility and accuracy.
Original PR description
### Issue: Due to this issue, the sale warning message is only shown when the warning message is set on partner itself, not partner's company. #### Steps to reproduce (with demo data): 1- Enable `Sale warnings` from setting. 2- On `Contacts` app, open `Azure Interior`, and add a sale warning from `Notes` tab. 3- Create a SO with `Brandon Freeman` from `Azure Interior` as the customer. 4- No sale warning is shown. ### Cause: The IMP #192211 replaces warning popup with a message. However, it doesn't check for the warning from `partner_id.parent_id`, which was the case before that PR. This is the case with purchase as well. opw-5404983 Forward-Port-Of: odoo/odoo#242050
This update resolves an issue where users without administrator privileges couldn't archive channels due to access restrictions. By allowing the use of 'sudo', this change now enables all users to archive channels, streamlining channel management. This improves usability and reduces the need for administrator intervention.
Original PR description
**Purpose of this PR:-** Allow users to archive channels using `sudo` so the action is not blocked by missing discuss role access error. task-5478832 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244247
This update corrects a data inconsistency within Odoo. Previously, Bulgaria was linked to the Bulgarian Lev (BGN). Now, with Bulgaria adopting the Euro as its official currency on January 1, 2026, this PR ensures Bulgaria is correctly linked to the Euro (EUR) within Odoo's system data.
Original PR description
Description of the issue/feature this PR addresses: Bulgaria adopted the euro as official currency as of 2026-01-01. Update the base country data accordingly. Current behavior before PR: In `res_country_data.xml`, Bulgaria is linked to BGN. Desired behavior after PR is merged: Bulgaria is linked to EUR in `res_country_data.xml`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241957
This update fixes an issue where loyalty points weren't being calculated correctly after discounts were applied in the POS system. The change ensures that loyalty rewards are accurately reflected in the customer's account, regardless of discount percentages. This improves the customer experience and ensures accurate reward tracking.
Original PR description
Step To Reproduce: - create a loyalty of type "loyalty card", that grants 1 point per $ spent - configure pos for global discounts - start pos, select a product (say price_with tax is 100) - select a…
Step To Reproduce: - create a loyalty of type "loyalty card", that grants 1 point per $ spent - configure pos for global discounts - start pos, select a product (say price_with tax is 100) - select a customer - apply a discount of 10%, price should be 90 refer image <img width="1367" height="687" alt="image" src="https://github.com/user-attachments/assets/37709299-b377-4eee-95af-e857b19c7671" /> Observation: - the loyalty gained stays 100, even after we applied discount, it should be 90 <img width="257" height="587" alt="pos loyalty issue" src="https://github.com/user-attachments/assets/772821c2-dc06-4dfc-8d4c-ab00de209ce8" /> Cause: - the recent commit [1], `applyDiscount` uses `addLineToOrder`, which bypasses `addLineToCurrentOrder`. - This skips `updateRewards` and other module-level extensions defined on `addLineToCurrentOrder` [1] https://github.com/odoo/odoo/commit/b63c7c28cfe6d59888982d58b8e9d99ea62281f4 https://github.com/odoo/odoo/blob/5d91798f0f5f712bf5210edd0bf6788f32d0c316/addons/pos_loyalty/static/src/app/services/pos_store.js#L439-L448 Fix: - Replace `addLineToOrder` with `addLineToCurrentOrder` to ensure rewards and programs are properly updated opw-5437844 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243548 Forward-Port-Of: odoo/odoo#242740
This update fixes a reporting issue where live chat response times incorrectly continued after a customer closed the conversation. The change ensures response times stop when the chat is closed, providing more accurate reporting data. This improves the reliability of live chat performance metrics.
Original PR description
Before this commit, the response time for a live chat conversation did not stop until the operator leaves the conversation, even if the customer had already closed it. This leads to response times that are longer than the conversation duration. The reason for this behavior is that the response time is indiscriminately checking for the first agent message. If the live chat gets closed by the customer without answer, the first message will be "Agent left the channel", posted upon the agent leaving the conversation. Once the conversations is closed the response time should stop as it can be expected that an operator does not pay attention to already closed chats This commit fixes the issue by setting the `time_to_answer` to NULL if the first message is posted after the live chat is closed. task-5117556 Forward-Port-Of: odoo/odoo#244119 Forward-Port-Of: odoo/odoo#242895
This update resolves a test failure within the 'test_discuss_full' module, ensuring accurate time zone handling. The fix explicitly sets the time zone for a test record, preventing a previous assertion error and improving the reliability of our automated tests.
Original PR description
This commit fixes a failing assert in `test_10_init_store_data`. The test fails since [1] due to asserting the value of the OdooBot time zone as False. This commit explicitely sets the time zone of the OdooBot partner record and asserts it. [1] https://github.com/odoo/odoo/pull/210094 runbot-237777 Forward-Port-Of: odoo/odoo#244192
This update speeds up product searches within Point of Sale, making the system more responsive, especially when dealing with a large number of products. The changes optimize how products are searched and sorted, reducing delays and improving the user experience. This enhancement focuses on performance improvements within the POS module.
Original PR description
Previously, the product search performed normalization inside the filter and sort loops. Because sort algorithms perform O(n log n) comparisons, the `normalize` function was called redundantly thousands of times for the same product, leading to UI lag when handling large products. This commit optimizes the search by: - Moving normalization to the model getters - Flattening the template search string to include all variants, removing the need for nested `.some()` loops during filtering. - Replacing `localeCompare` with primitive string comparison for faster sorting. opw-5448113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#241668
This update fixes an error in how price differences are calculated for subcontracted products. Previously, the system incorrectly compared costs in different currencies, leading to inaccurate price difference invoices. By converting component costs to the invoice currency, this fix ensures accurate price difference calculations and reliable reporting.
Original PR description
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This…
Problem: When computing the price difference on a vendor bill for a subcontracted product, the component cost is considered in the company's currency regardless of the currency of the invoice. This means the price difference calculation directly compares two different currencies without converting them, resulting in some incorrect values for the price difference invoice lines. Solution: We will convert the component cost to the invoice currency when computing price difference. Steps to reproduce (runbot 18): - Product with - Standard price auto - BoM: sbc, one component with nonzero value (e.g. $1) - Nonzero value (e.g. $5) - Another currency 1. Create a PO for the subcontracted product 2. Set the Invoice currency to something other than the company default 3. Confirm the PO and validate the sbc and receipt 4. Create the vendor bill, and bill for the correct value (Whatever $4 is in the invoice currency) A price difference line will be erroneously generated for some nonsense value, when we expect 0 price difference. opw-5232917 Forward-Port-Of: odoo/odoo#243941 Forward-Port-Of: odoo/odoo#238428
This update resolves a bug where imported sales orders containing kit products were incorrectly splitting the order into multiple lots during the POS process. The change prevents this splitting behavior when a kit product is sold, ensuring accurate order processing and a smoother POS experience. This was a critical fix to avoid errors in sales transactions.
Original PR description
When a kit product with tracked components is sold, and if the kit is tracked by lots, the imported sale order lines were being split by lots causing issues in the POS session. Although kits are not supposed to be tracked by lots, this commit prevents the splitting of sale order lines by lots when the product is a kit. opw-5423833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#242785
This update fixes a scheduling issue with the autovacuum cron job in Odoo, preventing it from being delayed unnecessarily. The change ensures the cron job correctly reports partial progress, allowing for quicker rescheduling and optimal performance. This improves the efficiency of database maintenance.
Original PR description
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have…
**NOTE** the problem regarding the auto-vacuum was fixed in 18.3 and above (including master) at https://github.com/odoo/odoo/pull/216483, this PR now solely exists for branlette intellectuelle. Have a ir cron action with the following code: time.sleep(MIN_TIME_PER_JOB) self.env['ir.cron']._commit_progress(remaining=1) return The code looks stupid, but we tracked down a bug we had in the autovacuum cron in 18.3, and the minimum code to reproduce the problem is that above line of code. Since there are remaining stuff to do, the cron worker should report a `PARTIALLY_DONE` status, and reschedule to call the cron action asap. But the system currently determine a `FULLY_DONE` status and reschedule the cron action *later* (next day for a cron with an interval of 1 day). It is pretty bad for the autovacuum cron in 18.3 We used the opportunity to rework the `status` computation to one big match-case, for extra readability. 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#216116
This update resolves an issue where read-only accounting users couldn't access customer statements. The fix corrects a restriction in the system's access controls, ensuring that all authorized users, regardless of their permissions, can view customer statements. This improves usability for a wider range of users.
Original PR description
Steps to reproduce: - Have a user with Accounting rights set to 'Read-only' - Login with the user - Open customer record - Button 'Customer Statement' won't be there Analysis: This occurs because we restrict the button visibility to 'Invoicing' users, even if all fields and views are accessible also for 'Read-only' users. opw-5357692 Forward-Port-Of: odoo/enterprise#103715 Forward-Port-Of: odoo/enterprise#102683
This update resolves a problem where clicks within editable lists were unintentionally triggering unwanted actions. A new feature allows developers to 'ignore' clicks on specific list elements, ensuring the correct focus and functionality is maintained when editing data. This improves the overall user experience for working with lists.
Original PR description
Since commit 37d78a4, the global click listener sets `capture: true`, which prevents other components to stop the propagation of the click event in order to maintain the focus on the selected list element. This commit introduces a special data key that can be set on an element so that any click occurring within it will be ignored by the list renderer. task-none but necessary for https://github.com/odoo/enterprise/pull/103732 Forward-Port-Of: odoo/odoo#243107
A recent update caused a crash when users clicked on boxes within x2many fields. This was due to a change in how click events were handled, leading to the system expecting the field to be in edit mode when it wasn't. This fix resolves the crash and ensures stable editing of these fields.
Original PR description
Since commit odoo/odoo@37d78a4, a crash would occur when clicking on a box while a field of a x2many field was focused.
The commit mentionned above changed the order in which the click event handlers are called because of the addition of `{ capture: true }` on the list renderer click listener.
Before, the propagation of the click event was stopped at the box layer level, preventing it to reach the global listener of the list renderer and thus keeping it in edit mode.
After, the click listener of the list renderer is executed first, which means we leave the edit mode before executing the click listener of the manual correction component. This causes a crash as the list renderer is expected to be in edit mode to be able to fill in the value.
task-none
Forward-Port-Of: odoo/enterprise#103732This update resolves a technical issue that caused a traceback error when employees removed their selected pay category in the payroll settings. The fix ensures the system handles the removal of pay category selections correctly, preventing errors and improving payroll stability.
Original PR description
Fixed a traceback bug that appears when removing unselecting the Pay Category in the Employee's form payroll tab Steps to reproduce: - Select a pay category for an employee - Delete your selection - Traceback appears Cause: _compute_display_be checks on the name of the structure_type_id without checking that this field is not null, producing a bug when its value is removed task-5453432 Forward-Port-Of: odoo/enterprise#104422
This update fixes a usability issue in the Sign editor where the document dropdown didn't close correctly after selection. The changes include improved hover behavior, consistent styling for actions, and a fix to handle interactions within the PDF iframe, ensuring a smoother user experience.
Original PR description
- Fix hover and pointer behavior on update document action - Apply consistent danger styling to delete action - Ensure dropdown closes correctly after interaction (PDF iframe has its own document so outside-click logic did not apply; add a click listener on the iframe document to close open dropdowns. ) task: 5384677 Forward-Port-Of: odoo/enterprise#102447
This update ensures that survey data exports retain the original formatting of answers, even after question types are changed. Previously, modifying a question type could cause issues with existing data exports. Now, the system consistently uses the stored answer type's formatting, guaranteeing accurate historical reporting.
Original PR description
Current behavior before PR: - Survey spreadsheet export derived date and datetime formatting from the current question type. - Changing a question type after submission (date to datetime) could lead to incorrect formatting or export errors for existing answers. Desired behavior after PR is merged: - Spreadsheet export now derives value conversion and formatting from the stored answer type instead of the question definition. - Historical answers keep their original date or datetime format, even if the question type is modified later. Task: [5410758](https://www.odoo.com/odoo/project/2328/tasks/5410758) Forward-Port-Of: odoo/enterprise#104472 Forward-Port-Of: odoo/enterprise#102930
This update resolves a display problem in the General Ledger report when using analytic accounting. Previously, the report showed incorrect information and linked to the wrong journal entries. The fix ensures the General Ledger accurately reflects analytic distributions and provides the correct journal entry links.
Original PR description
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report ->…
Issue: Inconsistent use of line ID in the general ledger between account_move_line.id and account_analytic_line.id Step to reproduce: - Activate analytic accounting - Go to Accounting Report -> General Ledger -> Options - Activate "Analytic Group By" - Create an invoice - add a line with an analytic account - Confirm the Invoice - Duplicate the invoice - Confirm the second invoice - Go to the General Ledger - Group By the analytic account you used Current Behavior: General Ledger display 2 lines per journal entry being part of the analytic distribution used for the group by. The first line displays the part related to the analytic group by, while the second line display infos for global general ledger. Clicking on the dots of the first line -> "View Journal Entry" send you to an unrelated entry. Expected behavior: - "View Journal Entry" should send to the right entry Proposed Solution: To proceed to the group_by, `_prepare_lines_for_analytic_groupby` create a temporary SQL table. This table uses the account_analytic_line.id as if it was the account_move_line.id. This commit fixes this and goes back to account_move_line.id. However, lines are merged into only one single line. opw-5267981 Forward-Port-Of: odoo/enterprise#104314 Forward-Port-Of: odoo/enterprise#103169
This update resolves a technical problem where order data wasn't being saved correctly in the Sweden POS module. The fix involves renaming related fields in the user interface to ensure data is properly recorded in the database. This ensures accurate order tracking and reporting.
Original PR description
In commit 807420a, the `pos.order` fields in `pos_l10n_se` were renamed to add `sweden_` at the start. However, these fields were not renamed in the JS code. The result is that the fields were not being saved to the DB. This commit fixes the issue by renaming the fields in the frontend. It also adds some fixes to ensure compatibility with the newest IoT box image. opw-5253585 Forward-Port-Of: odoo/enterprise#104393 Forward-Port-Of: odoo/enterprise#104180
This update streamlines the process for inviting users to channels. The redundant 'Invite People' button has been removed from channel types with member lists, consolidating the invitation option within the member list panel. This improves the user experience by reducing clutter and ensuring a consistent flow.
Original PR description
*=im_livechat Previously, channels with `memberList` had two ways to invite new users — one through the header action button and another via the member list panel. This caused redundancy since both performed the same action. This commit removes the header invite button for channel types that already have a member list and keeps only the invite option inside the member list panel. The behavior for chat-type channels remains unchanged. In addition, the invite button in the member list panel now opens a proper dialog instead of a popover. Invite buttons in other areas, such as the sidebar and chat window actions, remains unchanged for ease of access enterprise: https://github.com/odoo/enterprise/pull/98457 Task-5406953 Forward-Port-Of: odoo/odoo#233389
This update streamlines the process of inviting new users to WhatsApp channels by utilizing the existing member list panel invite button. Previously, a separate invite action was causing issues, and this change ensures a more consistent and reliable user experience. It resolves a technical bug identified in a related update.
Original PR description
After https://github.com/odoo/odoo/pull/233389, we rely on the member list panel's invite button to invite any new user and remove the dedicated invite action form the thread header action list for all channel type that have member list. This commit adapts the failing test for the same. community: https://github.com/odoo/odoo/pull/233389 Task-5406953 Forward-Port-Of: odoo/enterprise#98457
This update resolves a problem where Odoo invoices for exports were being rejected by the SII system due to incorrect decimal formatting. The fix ensures the `<TotClauVenta>` tag always uses a maximum of two decimal places, aligning with SII requirements and preventing validation errors. This ensures accurate export invoices and avoids potential issues with tax authorities.
Original PR description
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system…
Before this PR: Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`. The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator. After this PR: We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue. Source: https://www.sii.cl/factura_electronica/formato_dte.pdf Capture of this portion of the normative: <img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" /> Forward-Port-Of: odoo/enterprise#103600
This update restores automatic follower copying from parent sales orders to subscription renewals and upsells in Odoo 18.2. This ensures that users associated with the original order are automatically included in subsequent subscription orders, streamlining sales processes and improving customer management. This change specifically addresses a previous restriction on automatic follower copying.
Original PR description
[FIX] sale-subscription: Restore automatic follower copying from parent SO In Odoo 18.2 (Task 4655022), automatic follower addition was removed for all users and limited to internal users. However, for subscriptions, it is logical to automatically copy followers from the parent sale order to renewal and upsell orders. This commit restores that behavior for subscription renewals and upsells while keeping the restriction for other record types. task - 5002181 Forward-Port-Of: odoo/enterprise#101088