Daily updates from Odoo
Navigate
Branch
Tuesday, March 12, 2024
108 changes
38 changes
Resolved issues and error corrections
This update corrects a bug where the employee search bar incorrectly displayed duplicate results for employees with the same name within the same company. The issue stemmed from a misconfiguration in the search domain, which wasn't properly applied to the front-end search functionality. This ensures accurate and consistent employee search results.
Original PR description
STEP TO REPRODUCE : =================== - Select only one company - Write "marc demo" in employee search bar You will see two Marc Demo for manager line. task : 3716448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where users with limited 'User' access for Point of Sale couldn't create invoices or use the 'Ship Later' feature. The change adjusts user permissions to ensure proper functionality within the PoS interface. This improves the usability for all users.
Original PR description
Current behavior: When a user has only "User" right for point of sale and no other access some functionalities are not working properly. For example, the user cannot create an invoice from the PoS interface. And the user cannot use the "Ship Later" functionality. Steps to reproduce: - Change the right of a user to "User" for point of sale and no other access. - Log in as this user and try to create an invoice from the PoS - Try to use the "Ship Later" functionality Note: This commit modify the access right of the test pos_user so that it has the minimum access to be able to use the PoS interface properly. opw-3644739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#153104
This update corrects a visual inconsistency in mass mailing emails. Previously, applying text color and font size adjustments automatically set the text color to black. Now, the text color will remain the user-defined color, ensuring consistent branding and appearance across all emails.
Original PR description
**Current behavior before PR:** When we apply a text color and change its font size, the text color defaults to black. This occurs because the default black color is applied to a span within `o_basic_theme.o_layout`. **Desired behavior after PR is merged:** Now, when applying text color and adjusting its font size, the color of the text remains unchanged. task-3770351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155715
This update prevents the system from incorrectly flagging changes in x2many fields as modifications, which was causing unnecessary recalculations of SO totals. The fix ensures that the system only updates totals when there's a genuine change in the data, improving performance and stability. This resolves a potential issue impacting SO reporting accuracy.
Original PR description
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands…
In some conditions, a x2many field can be considered as modified by the webclient when in fact there is no change in 'meaningful' stored fields. In this case, on save, an empty list of magic commands will be sent to the server, potentially triggering unexpected recomputations. Steps to reproduce: * install sale_stock & sale_management * create a new storable product * create a new SO * create a new line with this product * Confirm the SO * Set or Update the SO delivery date (Other info tab) * Save -> In the chatter, you will notice an useless tracking value being printed for the SO Total, with identical values before and after update. Cause Since the server received an empty list of commands for the `order_line` field, this triggered a recomputation of the total amounts of the SO, even though there were no effective changes in the lines. Solution Do not send empty command lists for x2m fields. This will avoid unexpected recomputation and also improve performance since the fields were recomputed for 'nothing' --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155549
This update fixes a bug where completed Point of Sale (PoS) orders that weren't invoiced were not being accurately reflected in sales reports. Previously, the 'Sales' smart button didn't count these transactions. Now, all completed PoS orders, regardless of invoicing status, will be included in sales reporting, providing a more accurate view of revenue.
Original PR description
Current behavior: Orders from a closed pos that were not invoiced are not taken into account in the sales count (can be seen in the "Sales" smart button) Steps to reproduce: - Create a new product P1 - Sell this product in the PoS without invoicing it - Close the PoS session - Go to the "Sales" smart button of the product P1 - You will see that the sales count is not incremented opw-3726153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156926 Forward-Port-Of: odoo/odoo#156320
This update fixes a bug in the Spanish Point of Sale (POS) module where split payments didn't correctly prompt the user for a customer. Now, when a split payment is selected, the system will always ask the user to specify a customer, aligning with the standard behavior in the base POS. This ensures accurate invoicing and customer data management for Spanish POS transactions.
Original PR description
Current behavior: When in a spanish PoS, every order needs to be invoiced. If no customer is specified, there is a default customer selected. But if the payment method is split, the default customer should not be selected. And the user should be asked for a customer. Steps to reproduce: - Install the l10n_es_pos module - Go to PoS and create a new order - Select a product and go to payment - Select split payment (Customer Account) - The default customer is selected, but you should be asked for a customer Note: To fix this we use the same behavior as in the base PoS, where the user is asked for a customer if the payment method is split. If no user is selected after being asked for a customer, the default customer is selected. If a user is selected, the user is sent back to the payment screen, as it's done in the base PoS. opw-3736293 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156570
This update ensures that QR codes are now printed on all receipt reprints. Previously, reprinted receipts lacked this crucial code, causing problems with validating receipts and scanning them. This improvement enhances the reliability of our point-of-sale system and improves the customer experience.
Original PR description
Before this commit, if a receipt was reprinted, the QR code was not included. This could lead to issues with receipt validation and scanning. opw-3763169 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156948
This update resolves an issue where incorrect model names in web requests could cause errors, leading to unexpected behavior. The fix ensures that the system correctly identifies and processes model names, improving stability and reliability of web-based functionality. This prevents errors related to incorrect data retrieval.
Original PR description
Requests sent to the server may use an incorrect model (because of a typo, a module uninstallation, etc). In such case, it leads to several possible `KeyError` as we try to get the model in the…
Requests sent to the server may use an incorrect model (because of a typo, a module uninstallation, etc). In such case, it leads to several possible `KeyError` as we try to get the model in the models of the registry, and the error might not be correctly handled. Suppose the user loads the page: `http://localhost:8069/web?id=6&cids=1&model=lorem.ispum&view_type=form` At some point, js side, it leads to a jsonrpc with route: `/web/dataset/call_kw/lorem.ipsum/get_views`. Server side, to process the rule linked to the httprequest, we first check if the cursor should be a readonly one, line 1821 in: https://github.com/odoo/odoo/blob/c1d92a0b3be1f125c8fa4061e55b9676c83dd424/odoo/http.py#L1819-L1826 For this route, we use the default method `/web._call_kw_readonly`, where we get the model class -> `KeyError`. But, as we can see in the above code, we are not yet in the `_transactioning` method, where the correct dispatcher is defined. As a result, for the mentionned use case, when the `KeyError` is raised, it leads to: https://github.com/odoo/odoo/blob/c1d92a0b3be1f125c8fa4061e55b9676c83dd424/odoo/http.py#L2264-L2278 First, because of the error class, the `else` block is executed, where we uselessly print the traceback in the logs (-> we need to wrap the error in a known one). Second, since the proper dispatcher is not defined, we use the `HttpDispatcher` and the format of the answer is therefore incorrect (-> we need to define the dispatcher earlier) sentry-4924497911
This update resolves an issue where record sorting unintentionally disrupted data prefetching and filtered out newly created records. The fix maintains prefetching functionality and avoids filtering new records during sorting, ensuring data integrity and stability.
Original PR description
BaseModel's sorted() has two problems: - It breaks the prefetch of self for no reason - When it is called without an argument, it filters out new records because the search() used in sorted() doesn't return new records. Keep the same prefetch as self to fix the first problem. We partially fix/support the second issue, we just avoid filtering out new records (but we don't actually sort them) Forward-Port-Of: odoo/odoo#157033 Forward-Port-Of: odoo/odoo#156729
This update corrects a bug where an approval action wasn't correctly filtering expenses. The change ensures that the action now uses the updated panel view, aligning it with recent changes to the expense sheet. This prevents delays in expense approvals.
Original PR description
In odoo/odoo#93802 some filters (including submitted) were removed from hr.expense.sheet view in favor of the side panel. Meanwhile, action_hr_expense_sheet_department_to_approve was not adjusted and was still using the removed filter. This commit changes the action to also use panel view. task - 3578235 Forward-Port-Of: odoo/odoo#143759
This update corrects a restriction that prevented export invoices from using the correct document type (01). Previously, the system automatically selected invoice document types based on a customer's RUC, limiting other options. Now, export invoices can correctly utilize document type 01, ensuring accurate reporting and compliance for Peruvian businesses.
Original PR description
In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "credit note boleta." [Enterprise PR related](https://github.com/odoo/enterprise/pull/56465) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154511
This update fixes an issue where localization modules, like l10n_pe, couldn't properly handle special characters in UBL invoice notes. By allowing localization modules to format the Note node content, this change ensures invoices are correctly displayed and processed across different regions and languages. This improves the accuracy of invoice data.
Original PR description
In UBL 2.0, the Note node can contain the narration field of an invoice. Its content can be some complex HTML. Some localization (e.g. l10n_pe) doesn't support special characters like '\n' or '\u00A0'. This fix allows the localization modules to format the value used by Note node. opw-3744946 Linked enterprise PR: https://github.com/odoo/enterprise/pull/57268 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155081
This update fixes an issue where link coloring in the Odoo editor was inconsistent, only affecting the first and last links in a list. Now, when a list of links is colored, the font element is correctly created within each link, ensuring consistent background color alignment with the font size. This improves the visual appearance and functionality of the editor.
Original PR description
Currently, when we color a list of links with more than three items in the list, only the first and last links are colored. Now when the li element is colored in a list, the font element is created inside the link. We also make sure when the font size is defined the font element is created inside so that the background color is aligned with the font size task-3677214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156932 Forward-Port-Of: odoo/odoo#149056
This update ensures that ticket prices displayed on the website accurately reflect the user's chosen tax inclusion setting. Previously, prices were shown without tax regardless of this setting. This fix corrects a discrepancy between configuration and presentation, providing accurate pricing for event registrations.
Original PR description
**Current behavior:** When enabling the option which specifies that products should be displayed with their prices including tax, the dialog which appears when a user is buying tickets for an event…
**Current behavior:**
When enabling the option which specifies that products should
be displayed with their prices including tax, the dialog which
appears when a user is buying tickets for an event has a label
at the top of the window which lists the range of prices for
the available tickets. This price range does not include tax
irrespective of the status of the aforementioned option.
**Expected behavior:**
Displayed prices should adhere to the configuration which has
been selected in the db settings.
**Steps to reproduce:**
1. In the Settings app, give the `Display Product Prices`
configuration setting the `Tax Included` selection
2. In the Event app, select an event and give at least one
ticket type a nonzero cost
3. Go to the website, select the event which has the modified
ticket prices, and click the Register button
4. The label atop the dialog window displays pretax prices
**Cause of the issue:**
The database setting does not affect anything in the XML which
is responsible for displaying this price range label.
**Fix:**
Set the all_prices value to be calculated respective to the
account group that indicates their setting about including or
excluding taxes in display prices.
opw-3734299
Forward-Port-Of: odoo/odoo#153619This update fixes an issue where Italian clients were unable to find required labels within the DDT (Documente di Trasporto Merci) reason field. The translations have been corrected to ensure compliance with Italian legal requirements and improve usability for our Italian customers. This ensures accurate reporting and adherence to regulations.
Original PR description
Some translations was unusable by the clients, who didn't find the law-required labels on the DDT reason field. Link: https://www.odoo.com/web#model=project.task&id=3604549 opw-3604549 Forward-Port-Of: odoo/odoo#153109
This update corrects a bug that prevented public users from successfully entering their email addresses during Xendit payment transactions. Previously, an error would occur, disrupting donation processing. This fix ensures a smoother payment experience for all users, regardless of their account type.
Original PR description
When there's a payment that involves public user, an error will occur when they've input the email. An example is as you can see on the task when user wants to send donation as a public user task-3789416 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157195
This update resolves an issue where custom snippets created from event pages would retain original branding and styling, causing layout problems when the snippet was used elsewhere. The fix ensures that branding is cleaned from snippets before they are saved, preventing this disruption and maintaining consistent page formatting. This improves the reliability of custom content creation.
Original PR description
Steps to reproduce the bug: - Go to an event "Introduction" page - Enter edit mode - Click on the pre-existing "Introduction" title (note that it cannot be removed because of the way the page is built, we might want to improve that in master) - Save it as a new custom snippet - Go to your homepage - Drop that new custom snippet that was saved => It cannot be removed, the rest of the content is kinda broken as wells, etc etc. This is because the original branding was saved with the snippet. Indeed the event pages are made in such a way those pre-defined titles are snippets but which are "editable root elements", i.e. elements whose ancestors cannot be edited since themselves or their neighbors contain dynamic elements. opw-3633326 Forward-Port-Of: odoo/odoo#157191 Forward-Port-Of: odoo/odoo#157110
This update fixes a bug that caused Odoo Server errors when users pressed Enter while editing labels in the Reconcile 8 items feature. The issue stemmed from duplicate updates triggered by keydown and change events. The fix ensures that updates are handled correctly, preventing the server from crashing.
Original PR description
Steps to reproduce ================== In 16.4: - Go to Accounting > Reconcile 8 items - Click on the first line on the right - Edit the label and then press Enter - Switch to another line => Odoo…
Steps to reproduce ================== In 16.4: - Go to Accounting > Reconcile 8 items - Click on the first line on the right - Edit the label and then press Enter - Switch to another line => Odoo Server Error Cause of the issue ================== When pressing Enter, two events are triggered: keydown and change. In the useInputField hook, there is a listener for both of those events, and they both end up calling `record.update` with the current value from the input. In the relational model, the update is locked inside a mutex. So the first update (triggered by the keydown) does an onchange. This onchange deletes the current records (Command.CLEAR) and returns new records. Once this is done, the mutex is released. The second update (triggered by the change event) then tries the same update. Since the value was obtained when queuing for the mutex, it uses the old (now deleted) record. Solution ======== If the keydown handler was called and it was dirty at the time, isDirty would be reset to false. So we can simply check if the field is still dirty in the "change" handler. This was initially done in https://github.com/odoo/odoo/pull/154991 but got lost in a conflict resolution. opw-3726818 Forward-Port-Of: odoo/odoo#157155 Forward-Port-Of: odoo/odoo#157105
This update resolves an issue where a test for image gallery updates could produce unreliable results. The fix adds a deliberate click to ensure the editor panel is refreshed, preventing a potential error caused by checking outdated values. This improves the stability and reliability of the image gallery feature.
Original PR description
[FIX] website: adapt test tour to avoid undeterministic error Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also…
[FIX] website: adapt test tour to avoid undeterministic error Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also adapted the `snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder` from version 16) to test this behavior. To do so, the test adds a filter on an image in an "Image Gallery" snippet, checks that the filter is displayed on the editor panel, moves the image, clicks on it and finally checks that the filter is still displayed on the editor panel. The problem is that the steps that check if the filter is displayed on the editor panel are the same before and after the move of the image which means that the second check is true also before the move of the image. This situation is a typical case where an undeterministic error could happen. Indeed, we do not know if the second check tests an old value or an updated one. To solve the problem, the test has been adapted; after the move of the image, the test clicks somewhere else (on the footer in this case), and then back on the moved image to finally check that the filter is still displayed on the editor panel. The goal of the click on the footer is to be sure to have a loaded version of the editor panel. By doing so, we remove the risk of an undeterministic error situation where a condition is already true before an action is done. Note: this problem has been discovered because the test `snippet_image_gallery_reorder` succeeds on version 16.3 without the fix of [1]. Now, the adapted test fails on version 16.3 without the fix of [1]. [1]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481 task-3717041 Forward-Port-Of: odoo/odoo#156943 Forward-Port-Of: odoo/odoo#153014
This update fixes a gap in our HR contract management system by adding essential fields. Previously, certain contract details were not consistently tracked, leading to potential data inconsistencies. Now, all contracts will include the required information, improving accuracy and streamlining HR processes.
Original PR description
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#157012
This update corrects a problem where deleting an action in Odoo would sometimes display an error message related to a missing filter. The fix ensures that user-defined filters are automatically removed when their parent action is deleted, preventing these errors and improving data consistency.
Original PR description
When deleting records from ir.action.action, the user-defined filters(ir.filters) will not be deleted automatically, thus causing an error. Steps to reproduce: - Create a User-defined Filter under any action - Remove that action - Go to User-defined Filter again -> There will be an error message pop out that says action record does not exist Cause The User-defined Filters will not be automatically removed when the parent action gets deleted Solution Remove all the User-defined Filters when deleting the parent action Forward-Port-Of: odoo/odoo#156622
This update fixes a problem where live chat channels using chatbots weren't showing the operator's name. This made it difficult for managers to track chat sessions. The change ensures that the operator's name is always displayed in the channel name, improving visibility and management of live chat interactions.
Original PR description
Description of the issue/feature this PR addresses: - Create a website - Create a chatbot with forward to operator --> Issue all mail.channel have 'Chatbot' in name field  @tde-banana-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156123 Forward-Port-Of: odoo/odoo#152223
This update resolves an issue preventing users from logging into the website via RPC when their user profile had a specific website configured. The fix utilizes a thread URL to accurately determine the current website, ensuring consistent login functionality regardless of the RPC request method.
Original PR description
__Current behavior before commit:__ When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can only login if…
__Current behavior before commit:__ When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can only login if [`get_current_website`][2] returns the same website as `website_id`. The issue is that when login with RPC, `dispatch_rpc` is making a [`borrow_request`][3] which hides the `request` object from the RPC layer. This has the consequence that `get_current_website` is not able to retrieve the website based on the url of the request. Thus preventing a user to login via RPC even if the domain used corresponds to the website set in its `website_id` field. __Description of the fix:__ Add the possibility to retrieve the current website via `threading.current_thread().url` (which is set [here][4]). This way it is possible to know the current website even if `borrow_request` has been used. opw-3742591 [1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/addons/base/models/res_users.py#L779 [2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944 [3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361 [4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037 Forward-Port-Of: odoo/odoo#157309 Forward-Port-Of: odoo/odoo#154447
This update allows users to search for products within Point of Sale using their internal notes. Previously, this functionality was missing, limiting the search options and potentially impacting sales efficiency. This change enhances the user experience and improves product discovery within the POS system.
Original PR description
Prior to this commit, PoS did not support searching for products using their internal notes. This limited the search functionality. opw-3795066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where a second invoice was incorrectly marked as paid due to outdated transaction data. The change updates the system to prioritize the invoice's payment status, ensuring accurate payment tracking and a smoother user experience when paying multiple invoices.
Original PR description
Steps to reproduce the issue - set up the test provider - order something from the website and pay - create an invoice for the SO (invoice is paid) and confirm it - add an extra item to initial SO - create a second invoice - check the invoice on the portal ==> second invoice is automatically marked as paid because of the transactions on the SO The transactions that were used on the SO are filled in on the new invoice in the transaction_ids field. In the view in the portal the method 'get_portal_last_transaction' is called which finds the transaction for the older invoice and assumes its paid. We will now rely on the payment status of the invoice instead of the state of the last transaction. opw-3594556 Forward-Port-Of: odoo/odoo#157267 Forward-Port-Of: odoo/odoo#155045
This update resolves an issue where invoice analysis reports incorrectly duplicated invoices for products with different costs in different companies. The fix ensures that invoices are accurately represented in reports, preventing double-counting and improving financial reporting accuracy. This was triggered by a specific scenario involving multiple companies and product costs.
Original PR description
Steps to reproduce: - have two companies; Company A and Company B - create a product Product A and set a different cost in each company - create an invoice for Company A with Product A and post it - Go in invocie analysis > pivot view and set the y-axis as 'move' Issue: The invoice will be taken twice Issue: for Product A, there are two ir_property lines (one per cost/company) opw-3753395 Forward-Port-Of: odoo/odoo#157268
This update fixes a display issue where the domain picker incorrectly reversed in RTL mode, showing email addresses in the wrong format (domain@alias instead of alias@domain). Now, the domain picker functions correctly regardless of the user's language settings, ensuring accurate email address display.
Original PR description
**Description of the issue/feature this PR addresses:** This PR resolves an issue where the domain picker was being unintentionally reverted in RTL mode, leading to a disruption in the email format. **Current behavior before PR:** Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. **Desired behavior after PR is merged:** Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task link: https://www.odoo.com/web#model=project.task&id=3624012 Task-3624012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157091 Forward-Port-Of: odoo/odoo#154834
This update resolves an issue where the email composer could display inconsistent data due to user-specific inconsistencies. The fix ensures that the composer consistently accesses reliable information, leading to a more stable and accurate email creation experience. This improves the overall reliability of the email functionality.
Original PR description
Avoid accessing inconsistent data based on the user Forward-Port-Of: odoo/odoo#157098
This update resolves an issue where the body of SMS templates wasn't being displayed correctly. The fix adds a hidden field to the SMS composer form, ensuring the template ID is properly processed during the SMS generation process. This ensures SMS templates are correctly populated with their content.
Original PR description
Steps to reproduce: - - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template…
Steps to reproduce: - - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template (this will allow you to use this template from the contact form view). - Go to Contacts, select any, click on the gear icon and send an SMS using your new SMS template. Issue : the Body of the SMS template is not displayed. Cause of the issue: - The send SMS action generates an `sms.composer wizzard` that triggers a call of the `onchange` method to compute the values of the form view of the record from scratch. The body of the message is computed during the snapshot1 of the onchange of the `sms.composer` https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L1076 by the `_compute_body` method: https://github.com/odoo/odoo/blob/72c1a4f96a1219d98ce9b90ee54fd7297b9ab999/addons/sms/wizard/sms_composer.py#L167 To be processed correctly, this computation requires a `template_id` (field of the sms.composer model). This `template_id` information is present in the `self._context` of the onchange as a 'default_template_id'. However, since the template_id is not present in the form view of the sms.composer, it is not part of the `fields_spec` arguments of the onchange and this `default` value is not converted into a value before the snapshot1 at this step: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 Prior to Odoo 17.0, this was not a problem as the value was still used from the context the snapshot1. However, this value is now cleaned form the context during the snapshot1: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/api.py#L567 https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/tools/misc.py#L1010-L1014 As a result, there is no template_id during the call of the `_compute_body` and the body of the message stays empty. Fix: - In order to compute the body, correctly, we add the template_id as an invisible field of the `sms.composer` form view so that it becomes part of the `fields_spec` arguments of the onchange so that its default value 'default_template_id' is converted into a real value: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 that will be used as an argument of the snapshot1. opw-3733881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#154549
A recent test related to Odoo's image handling was intermittently failing. This update increases the test's waiting period, ensuring the image is properly set before the test completes. This resolves a minor issue that could have impacted the reliability of image functionality.
Original PR description
Before this commit, the changed test sometimes failed because we expected the image to be set, but it wasn't (yet). This commit increases the delay. Runbot error 56099 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#157335
This pull request updates the core spreadsheet component used in Odoo. It addresses several bug fixes and performance improvements related to data validation, calculations, and autofill functionality, ensuring a smoother and more reliable spreadsheet experience for users. These changes contribute to overall stability and efficiency within the Odoo platform.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3a9f33458 [REL] 17.1.7 https://github.com/odoo/o-spreadsheet/commit/7d7fddba9 [FIX] header_positions: perfs of update…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/3a9f33458 [REL] 17.1.7 https://github.com/odoo/o-spreadsheet/commit/7d7fddba9 [FIX] header_positions: perfs of update style Task: 3797400 https://github.com/odoo/o-spreadsheet/commit/41682f930 [PERF] functions: return #N/A instead of throwing Task: 3775565 https://github.com/odoo/o-spreadsheet/commit/1c3a9fca1 [FIX] automatic_sum: wrong behaviour with spreaded values Task: 3782971 https://github.com/odoo/o-spreadsheet/commit/2133f544a [FIX] DataValidationCheckbox: Fix input positioning in FF Task: 3774645 https://github.com/odoo/o-spreadsheet/commit/81b1983d8 [FIX] evaluation: ensure value to evaluated cell https://github.com/odoo/o-spreadsheet/commit/1b104b810 [FIX] GridComposer: Reset the cell reference visibility on stop edition Task: 3736211 https://github.com/odoo/o-spreadsheet/commit/99390b35a [FIX] data validation: checkbox not disabled in readonly Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/f2fe5d0a7 [IMP] data validation: performance of icons Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/ce113cc3c [PERF] evaluation: apply compute function Task: 3775636 https://github.com/odoo/o-spreadsheet/commit/b1aeca88d [FIX] autofill: allow to autofill a mix of number values and formulas Task: 3700733
This update fixes an issue where images, like user profile pictures, weren't loading correctly when viewed outside of the current record. The system was using an outdated method for caching images, leading to inconsistent display. This change ensures all images, including user images, load properly in Kanban and Activity views.
Original PR description
The way we cache the image is not right when that image is not on the current record. For instance displaying a partner/user image. The unique key used is not related to that record. Introduced by https://github.com/odoo/odoo/pull/97544 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#157199 Forward-Port-Of: odoo/odoo#157004
This update resolves a bug that prevented users from correctly setting the opening balance for accounts, particularly those in foreign currencies. The fix ensures accurate initial account balances are established, improving the reliability of financial reporting.
Original PR description
Allow the user to set back the debit or credit to 0. It's a bug introduced by https://github.com/odoo/odoo/commit/c3793357d823273cb4297b0eb31308ad73a9dff8 Allow to create an opening balance for an account having a foreign currency. opw: 3665557 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157307 Forward-Port-Of: odoo/odoo#148305
This update resolves an issue where free product rewards weren't correctly applied within Next Order Coupon programs. The fix ensures that customers receive their intended free products when using these coupons, improving the accuracy and reliability of promotional offers. This change was made to address a reported bug and maintain consistent coupon functionality.
Original PR description
Before this commit, the free product reward feature in a Next Order Coupon program was not functioning as expected. This commit fixes this issue, ensuring that free product rewards are correctly applied in Next Order Coupon programs. opw-3703485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156008 Forward-Port-Of: odoo/odoo#153268
This update ensures that a unique security identifier (secure_sequence_id) is automatically created when a new journal is set up with specific security restrictions. Previously, this ID wasn't generated unless the journal was manually modified. This change improves security by consistently tracking journal configurations and preventing potential vulnerabilities.
Original PR description
**Description of the issue/feature this PR addresses:** The secure_sequence_id is not generated when creating a journal with restrict_mode_hash_table set to True. It only happens if you trigger a…
**Description of the issue/feature this PR addresses:** The secure_sequence_id is not generated when creating a journal with restrict_mode_hash_table set to True. It only happens if you trigger a write() on the record. Even changing it's name on edit triggers the creation of the sequence. On runbot is correctly created because account_check_printing triggers a write() after the create of the account.journal. But this module is not a dependency from account (or any of it's dependencies) and if it is uninstalled, this behaviour occurs. **Current behavior before PR:** When creating an account.journal with restrict_mode_hash_table set to True we should generate the secure_sequence_id but it's not happing. It is only contemplated on the write() **Desired behavior after PR is merged:** When creating an account.journal with restrict_mode_hash_table set to True we generate the secure_sequence_id. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157134 Forward-Port-Of: odoo/odoo#155188
This update resolves an issue where the payment method selected in the 'Cash' journal was incorrectly retained when switching back to the 'Bank' journal. The fix ensures the journal ID is correctly computed only during payment creation, preventing this data inconsistency. This improves the reliability of payment processing.
Original PR description
The goal of the `def new` override on `account.payment` is to have the `journal_id` computed when creating a payment in the form view. The problem is that it is also called by the onchange when a field is modified. This is causing a bug: - Go the the cash journal and change the name of its payment methods (so you can distinct them from the ones of the bank journal). - create a payment (do not save) - switch the journal to "Cash" then switch back to "Bank". -> the "Payment Method" is still one from the "Cash" journal. The fix is here is a hacky way of checking this is the call on the record creation. Forward-Port-Of: odoo/odoo#157407 Forward-Port-Of: odoo/odoo#155710
This update addresses a technical issue within the Odoo system related to a test for user avatars. The original fix attempted a problematic workaround, which has now been removed. This change ensures the test runs correctly and maintains the system's stability.
Original PR description
This PR fixes an infinite setTimout loop in a m2x avatar test. Patching the setTimeout method is not a good idea anyway since it makes it synchronous which totally changes the flow that is tested. This PR removes this patch as the assertion that relies on it is too technical anyway. fixes runbot-55891
This update resolves an issue where non-administrator users were unable to access journal items within the accounting module. Previously, access was restricted, preventing users from performing essential accounting tasks. This change ensures all users, regardless of their permissions, can manage journal items correctly.
Original PR description
Steps to reproduce: - Install Accounting - Connect with a user without "Administration: Settings" rights (e.g. Marc Demo) - Go to "Accounting / Accounting / Journals / Journal Items" Issue: An Access Error is raised when trying to access a "ir.ui.view" record that is restricted to "Administration/Settings" group. opw-3787114 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#157363
32 changes
New functionality added to Odoo
Luxembourg payroll now supports a dedicated 13th month salary structure with the rules needed to calculate it. Payroll teams can enable this benefit directly on employee contracts, helping automate an important recurring compensation process.
Original PR description
This will add a structure for the 13th month and the rules to compute it. It will also add a checkbox on the contract form view to enable the 13th month. Task: 3748840
Moroccan tax reports can now be exported in the required EDI format for submission through the Simpl-TVA platform. This streamlines VAT declarations for businesses in Morocco and adds company identification fields needed for compliant reporting, including customs VAT handling for imports.
Original PR description
This commit adds functionality to export tax reports in EDI format, simplifying VAT declarations through the Simpl-TVA platform, making the process easy and seamless for users. for the purpose of this task, two fields were added to res.partner: - l10n_ma_ice: This is Morocco's common company identifier, utilized in conjunction with the VAT ID for company identification. - l10n_ma_customs_vat: A technical field to record customs' VAT ID, which replaces the company's VAT ID during import operations. This is necessary as the customs' VAT ID may change. task-3517877
This adds a new export capability so US payroll work entries can be prepared for use in ADP software. It helps businesses reduce manual payroll data entry and streamline the transfer of employee time and payroll information between Odoo and ADP.
Original PR description
task-3612658
Enhancements to existing features
Documents that are only useful for demonstrations have been moved out of the standard Documents setup and into demo data. This keeps regular databases cleaner while preserving example content for demo environments.
Original PR description
Since https://github.com/odoo/enterprise/commit/f3c1cecf1583e0185d1bd75e757ce45b1912299a, some documents are added in Documents data. These documents are not meant to be installed on each databases, and only serve demonstration purposes. This commit therefore moves those documents data to demo data and reorder items in alphabetical order.
Contacts now always show the Tasks and Tickets buttons, even when there are no linked items yet. This lets users create a task or support ticket directly from a contact, automatically linking it to that contact and saving time.
Original PR description
After this commit, the "Tasks" and "Tickets" stat buttons in the contact form view are displayed even when no tasks/tickets are linked to the partner. Furthermore, when clicking on the "Tasks" stat button when there is 0 or 1 task linked to the partner, only the task form view is opened. Otherwise, the kanban and list views are opened. The rationale is that clients will gain time as they will now be able to quickly create tasks and support tickets that will automatically be linked to the partner of the contact view, even when no task/ticket has been created for that partner yet. task-3699110 related-https://github.com/odoo/odoo/pull/151536
Project users now get an Auto Plan option in the Gantt planning dialog, letting them decide when to use smart scheduling. This improves usability by making automated scheduling optional and more transparent during task planning.
Original PR description
This commit will add an "Auto Plan" button, in the gantt view Plan dialog. This way the user can choose whether they want to use the smart scheduling feature or not. task-3644342
This update adjusts how several apps use database indexes to reduce unnecessary storage and improve search behavior where it matters. Helpdesk searches should better support partial text matching, while Knowledge, Marketing Automation, and Subscriptions avoid overly broad indexes that may slow maintenance without clear benefit.
Original PR description
See odoo/odoo#135057 for the core ideas. This just applies them in locations triggering warnings.
Room records can now be archived, helping teams keep inactive rooms out of daily workflows while preserving their history. The room screens also include sample content, clearer placeholders, empty-state guidance, and layout updates to make setup and day-to-day use easier.
Original PR description
This PR will, -Add an archive feature to allow users to archive rooms for better data management. -Add sample data in all views. -Insert placeholders where necessary to guide users and provide context. -Incorporate a helper to assist users when there are no records present. -Update the UI layout and design to enhance the user experience. **Task**-3525422
This update aligns Belgian payroll accounting tests with a simplified leave duration setup. It reduces reliance on duplicate leave-related fields, helping keep payroll test maintenance simpler and more consistent.
Original PR description
Before this commit, there was way too much fields related to the duration of the leave in `hr_holidays`: - number_of_days - number_of_hours - number_of_days_display - number_of_hours_display - number_of_hours_text - duration_display This commit only adapts the enterprise code to the change that only keeps `number_of_days`, `number_of_hours` and `duration_display` to simplify things.
Appraisal surveys now rely on a shared availability setting to decide when live session options should appear. This keeps appraisal survey screens cleaner and reduces duplicated customization, with no live sessions enabled for appraisals.
Original PR description
Where possible, use the newly introduced `session_available` field to identify whether to show options allows to reduce views overrides. See related COM PR, where this field is an opt-in method based on survey_type, such that no live session is enabled for appraisals. Task-2803327
The Documents app no longer shows the split PDF scissors button in the inspector when viewing documents from the Activity view. This avoids offering an action in a context where it should not be available, making the interface clearer for users managing activities.
Original PR description
Before this commit: - Switch to the Activity view - Schedule an activity for any PDF file and select it - The scissor (split PDF) button is present on the inspector After this commit: - We remove the scissor (split PDF) button from the inspector. Task-3770691
The HR demo data has been adjusted so the Marc Demo manager account no longer receives extra access rights across related apps. Payroll conflict messages were also made clearer by showing the employee name, helping teams identify issues faster.
Account report filters are now easier and faster to use because users can choose multiple filter values before refreshing the report. The update also standardizes filter behavior across reports, removes a redundant “All” choice in the Argentine localization filter, and improves currency-rate comparison accuracy for currencies with higher decimal precision.
Original PR description
The aim of this commit is simplify all the account report filters. For several filters, we don't want to recompute the report directly after we select an option. For example, the journal filter that…
The aim of this commit is simplify all the account report filters.
For several filters, we don't want to recompute the report directly after we select an option.
For example, the journal filter that allows users to select from which journal they want to get report lines, before this commit users have to select one by one and recompute the report everytime.
Of course is not efficient at all and it can takes a lot of times for big database.
After this commit, users can select several journals before recomputing the whole report.
We take advantage of this commit for cleaning a bit the JS code of report filters and to have something more consistent.
This commit changes the `precision_rounding` parameter when we make a `float_is_zero` by comparing custom currency rate and actual rate, the bug occurs because some currencies have a decimal precision bigger than what we decide for the comparison.
This commit remove an option ("ALL") from a l10n_ar filter.
The idea is that we want to keep something consistent between all the filters and it's the only filter that implement an option "ALL".
Now, when users don't select any filters or all the filter, it's implied "ALL" without adding this new option.
task-3710483Expired or refused salary offers no longer show the salary configurator or send by email buttons. This helps prevent users from taking actions that are no longer relevant for inactive offers.
Original PR description
With this commit, when an offer is expired or refused, these buttons : "salary configurator" and "send by email" are hidden. task : 3746557
Several payroll and project messages now use a shared formatting helper instead of manually building lists. This improves consistency and makes translated text read more naturally for users in different languages.
Original PR description
*=hr_payroll_account,project_enterprise,project_holidays This PR replaces a few occurrences of list being manually constructed by making use of the new helper. Task-3506960 Community: https://github.com/odoo/odoo/pull/154395
The Belgian salary configurator now automatically disables and clears the fuel card option when an employee selects a private bike. The benefit categories were also reorganized to make the form easier to understand and reduce incompatible selections.
Original PR description
This commit enhances behavior of the benefits selection within the salary configurator. It introduces logic that deactivates the fuel card option and resets its value to 0 upon the selection of a private bike. It restructures the configurator form categories for improved clarity and user experience. Task-3784177
Spreadsheet users now get more helpful suggestions when writing Odoo formulas for filters, pivots, and lists. They can search by both technical identifiers and familiar display names, making formulas faster and easier to build accurately.
Original PR description
Autocomplete global filter names, pivot/list ids, fields, etc. Smart autocomplete for ODOO.FILTER.VALUE, ODOO.PIVOT[.HEADER], ODOO.LIST[.HEADER] Search on technical values (field names, ids, ...) and display values (translated field name, pivot/list titles)
Social post previews now show the thumbnail from links included in the message, helping marketers see a more realistic preview before publishing. Instagram previews also hide images when they cannot be displayed correctly, reducing misleading or broken previews.
Original PR description
Purpose ======= Improve the preview in the social post form view, to show the thumbnail of the URL in the message. Task-3627918
Rental orders placed on the website now use the store website's configured timezone instead of the shopper's personal timezone. This makes rental periods and date pickers more accurate for businesses operating in a different timezone than their customers.
Original PR description
### Version - master ### Cause When users make rental orders from the website then rental periods are set in the user timezone even if the store is located in a different timezone. ### Improvement Add a new field in the website for timezone and use that timezone when the user makes a rental order and displays date picker according to website timezone. See also: - https://github.com/odoo/odoo/pull/145705 task-3293817 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
Resolved issues and error corrections
Rental product availability now reflects early pickups and early returns, so customers are less likely to book unavailable items or be blocked from available ones. The update improves the online rental experience and cleans up related tests to better protect this behavior going forward.
Original PR description
Previously, only the expected pickup and return dates were considered when computing a rental product's availabilities. Early pickups and returns were ignored. This allowed customers to rent products that weren't available (due to early pickups), or prevented customers from renting products that were available (due to early returns). This PR updates the computation to take early pickups and returns into account. Note that late pickups and returns are not considered, and shouldn't be. Indeed, we don't know when late pickups and returns will happen, and we don't want to guess. Late pickups are considered unavailable (until the expected return date), and late returns are considered available. This PR also refactors the tests in `sale_stock_renting` and `website_sale_stock_renting` to: - Follow unit testing best practices - Extract shared helper methods - Fix incorrect tests - Remove useless test messages task-3576910
Code cleanup and technical improvements
This update refreshes how Odoo works with PDF files across delivery, documents, payroll, and signing features. It keeps these workflows compatible with the newer PDF library version without changing the intended user experience.
This pull request updates internal automated tests across several Odoo Enterprise apps so they align with upcoming changes in the shared testing framework. It should not change day-to-day product behavior, but helps keep future upgrades smoother and reduces maintenance risk.
Original PR description
See individual commits. https://github.com/odoo/odoo/pull/157058
Miscellaneous changes
In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "boleta" or "debit note boleta." For this, inherit the compute method, and extend the depends to add the operation type and allow generate invoi
Original PR description
In commit 355250d, the domain was adjusted to automatically select the invoice document type for customers with a RUC and limit others to the "boleta" document type. This generally holds true, except for export invoices requiring the 01 document type. This commit addresses the current restriction, allowing the selection of document type 01 other than "boleta" or "debit note boleta." For this, inherit the compute method, and extend the depends to add the operation type and allow generate invoice for exportation cases. [Odoo PR related](https://github.com/odoo/odoo/pull/154511) Forward-Port-Of: odoo/enterprise#56465
…ct warning * a regular user error can be displayed user-side instead of the redirect warning, in case we don't want to propose to contact the support (in case there's no need) Forward-Port-Of: odoo/enterprise#58308 Forward-Port-Of: odoo/enterprise#56935
Original PR description
…ct warning * a regular user error can be displayed user-side instead of the redirect warning, in case we don't want to propose to contact the support (in case there's no need) Forward-Port-Of: odoo/enterprise#58308 Forward-Port-Of: odoo/enterprise#56935
Steps to reproduce: - Install Accounting and l10n_pe_edi - Switch to a Peruvian company (e.g. PE Company) - Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html) - Create an invoice: * Customer: Comercial Constructora los Patitos S.A. * Operation Type: [0101] Internal sale * Invoice Lines: - Product: Arroz descascarillado (arroz cargo o arroz pardo) - Taxes: 18% - Terms and Conditions: [text containing
Original PR description
Steps to reproduce:
- Install Accounting and l10n_pe_edi
- Switch to a Peruvian company (e.g. PE Company)
- Configure Peruvian localization (https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/peru.html)
- Create an invoice:
* Customer: Comercial Constructora los Patitos S.A.
* Operation Type: [0101] Internal sale
* Invoice Lines:
- Product: Arroz descascarillado (arroz cargo o arroz pardo)
- Taxes: 18% - Terms and Conditions: [text containing several consecutive spaces and/or several lines]
- Confirm the invoice
- Process UBL 2.1
Issue:
The service responds with an error because the <cbc:Note> node doesn't comply with the supported format.
Special characters like '\n' and '\u00A0' are not supported.
opw-3744946
Linked community PR: https://github.com/odoo/odoo/pull/155081
Forward-Port-Of: odoo/enterprise#57268**Issue** website_appointment_tour was not working properly because of some changes done in the mail.py and appointment app. **After this PR** Now the appointment tour is working perfectly as expected. Task-3774280 Forward-Port-Of: odoo/enterprise#57898
Original PR description
**Issue** website_appointment_tour was not working properly because of some changes done in the mail.py and appointment app. **After this PR** Now the appointment tour is working perfectly as expected. Task-3774280 Forward-Port-Of: odoo/enterprise#57898
task-3610704 Forward-Port-Of: odoo/enterprise#52297
Original PR description
task-3610704 Forward-Port-Of: odoo/enterprise#52297
This commit fixes an issue with the comments panel when creating comment. When you have the panel opened and you want to create a comment, after logging your message the temporary box is not removed, leading to issues like boxes not being handled or crashes. This is caused because when syncing the handler and the panel when creating the comment, the insertion function was still the one from the handler meaning that the KnowledgeComment was not using the correct function which led to thos
Original PR description
This commit fixes an issue with the comments panel when creating comment. When you have the panel opened and you want to create a comment, after logging your message the temporary box is not removed, leading to issues like boxes not being handled or crashes. This is caused because when syncing the handler and the panel when creating the comment, the insertion function was still the one from the handler meaning that the KnowledgeComment was not using the correct function which led to those issues. Now when the panel is adding the comment from the handler we change the function so that it uses the correct one. task-3792116 Forward-Port-Of: odoo/enterprise#58253
Forward-Port-Of: odoo/enterprise#58326
Original PR description
Forward-Port-Of: odoo/enterprise#58326
Steps to reproduce: ------------------- 1. Install sale_planning (without demo data) 2. Create a service product with "Plan Services" activated 3. Create an SO with this product and confirm the SO 4. Click on "To Plan" stat button 5. Click on any pill to create a new slot 6. The traceback occurs The traceback also occurs in the following scenario: ------------------- 1. Install sale_planning (without demo data) 2. Open Planning > Schedule > By Role 3. Click on any pill to create a
Original PR description
Steps to reproduce: ------------------- 1. Install sale_planning (without demo data) 2. Create a service product with "Plan Services" activated 3. Create an SO with this product and confirm the SO 4.…
Steps to reproduce: ------------------- 1. Install sale_planning (without demo data) 2. Create a service product with "Plan Services" activated 3. Create an SO with this product and confirm the SO 4. Click on "To Plan" stat button 5. Click on any pill to create a new slot 6. The traceback occurs The traceback also occurs in the following scenario: ------------------- 1. Install sale_planning (without demo data) 2. Open Planning > Schedule > By Role 3. Click on any pill to create a new slot 4. The traceback occurs Fix: ------------------- When there is no demo data/records, the gantt view uses sample data. In which for instance, the role_id field is randomly generated. So when clicking on the pill to create a new slot with the given role_id, the corresponding 'planning.role' record is not found, resulting in a traceback. To fix that, we check if the sample data is enabled, in which case we ignore the "fake" ids given by the sample records. task-3777485 Forward-Port-Of: odoo/enterprise#58096
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products` smartbutton - Add any product to the SO. - Open the second task > access catalog via the `Products` smartbutton - Add the same product to the SO. - Open the first task > access catalog via the `Products` smartbutton - Try to add more of that product **IMPOSSIBLE : “You can’t edit this product in
Original PR description
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products`…
Steps to reproduce: - - Create an SO with two lines containing the product “Field Service” - Confirm the SO > 2 fsm tasks are created - Open the first task > access catalog via the `Products` smartbutton - Add any product to the SO. - Open the second task > access catalog via the `Products` smartbutton - Add the same product to the SO. - Open the first task > access catalog via the `Products` smartbutton - Try to add more of that product **IMPOSSIBLE : “You can’t edit this product in the catalog”** Cause of the issue: - The way the catalogue is computed was refactored between 16.4 and 17.0 see: odoo commit bc01c7bcec974ee095f5855f225667645ef40213 The above situtation is not yet handled by this refactoring. In 16.4, since the catalogue was acceced from the task linked to the Field service, the quantities it displayed were computed with respect to that task. However, in 17.0 the quantities appearing in the catalogue are computed from the main SO containing both `Field services` SOL instead of being computed contextually from the task they are linked to. To be more precise: - When clicking on the smart button, the quantities appearing in the calatalogue are computed by the `_get_product_catalog_order_line_info`. This method starts by grouping the SOL referencing each product of the catalogue using the `_get_product_catalog_record_lines`: https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/product/models/product_catalog_mixin.py#L91-L92 https://github.com/odoo/odoo/blob/c7f982774654459a2db6decd6ae1948e05e7d622/addons/sale/models/sale_order.py#L1823-L1829 But here is the problem, since both SOL were able to reference the same product of the catalogue the product of the catalog will be set to 'readOnly' here (because `self` will contain both SOL): https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1222-L1227 Hence, we will not be able to edit its value from the catalogue: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/product/static/src/product_catalog/order_line/order_line.xml#L18-L20 Fix: - As discussed with the PO of the Field Service module (see conversation of the ticket), the catalogue should be computed contextually using the task from which we access it and not from all tasks referring to that product in the main SO. Doing so will solve the problem since only one SOL will be associated to that product of the catalogue and the product will be set to `'readOnly' : False`: https://github.com/odoo/odoo/blob/c91ffa3bdbff845088111bc3036500c2c03fc357/addons/sale/models/sale_order_line.py#L1212-L1216 opw-3748833 --- Forward-Port-Of: odoo/enterprise#57561
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown did't close **Issue:** Dropdown did't close when clicking within the embedded view. **Technical Reason:** There is a function called onWindowClick in the dropdown.js file, inside which we get different values in 'this.ui.activeElement' and 'this.nyActiveEl', so the dropdown doesn't
Original PR description
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown…
**Step to reproduce:** - Insert a view using /item list or /item kanban in knowledge - Open dropdown on any of the view - Click within that view anywhere outside dropdown - you notice that dropdown did't close **Issue:** Dropdown did't close when clicking within the embedded view. **Technical Reason:** There is a function called onWindowClick in the dropdown.js file, inside which we get different values in 'this.ui.activeElement' and 'this.nyActiveEl', so the dropdown doesn't close. **Before this commit:** When we insert an embedded view, and the user opens any dropdown and after that, if the user clicks within the embedded view that dropdown is not closing. **After this commit:** Removing the condition related to 'this.ui.activeElement' and 'this.myActiveEl' means that now, In the embedded view, when opening the dropdown menu, clicking within that view close the dropdown. task-3717014 Forward-Port-Of: odoo/enterprise#57471 Forward-Port-Of: odoo/enterprise#56366
30 changes
Enhancements to existing features
This update consolidates repeated code from multiple payment terminal drivers into a shared parent class, making the system easier to maintain and update. All payment terminals now benefit from improved features like smarter sleep management and better handling of simultaneous requests, ensuring more reliable payment processing across all supported devices.
Original PR description
Currently, we have some code repeating in SixDriver, WorldlineDriver_L and WOrldlineDriver_W. The goal of this PR is to move this code to a parent class for easier maintenance and better code strcture Additionally, it applies the code to every ctypes dependant terminal driver, adding some features like "smart sleep" or rejecting double request processing when the terminal is busy for every single of them task-3707945 Forward-Port-Of: odoo/enterprise#57064
The report editor now displays meaningful error information when reports fail to load in debug mode, allowing administrators to see what went wrong and access the problematic views for troubleshooting. This improvement helps with report recovery and migration processes by providing visibility into issues that were previously hidden from users.
Original PR description
Since commit [1], the report editor never crashes at loading time. This is intended to ease the migration process, or report recovery in general, where the operator could reset the views, explore the diff of some views, or edit their plain XML. However, commit [1] did not offer a way to actually see the error in the reportEditor itself. This was on purpose as the lambda user would not know what to do anyway with that information. This commit aims at offering that piece of information in case we are in debug mode. The display of the error allows to open the incriminating views in a dialog, and see some basic information on them, as well as, obviously, the error message and type. opw-3735973 [1]: 62c167f87176674cbabad976d93eeb717f73df7a
Resolved issues and error corrections
This update fixes a critical bug in analytic accounting that was causing errors when viewing project updates after recent changes to how accounting IDs are stored. The system was not properly handling the new format for storing multiple analytic accounts, which prevented users from accessing project financial information. This fix ensures all accounting modules correctly process analytic data in the new format.
Original PR description
### Steps to reproduce issue: 1. Have Sales installed 2. Enable Analytic Accounting and create two Projects 3. Go into both Project Settings and add distinct Analytic Accounts 4. Create a Vendor Bill…
### Steps to reproduce issue: 1. Have Sales installed 2. Enable Analytic Accounting and create two Projects 3. Go into both Project Settings and add distinct Analytic Accounts 4. Create a Vendor Bill 5. Add a Product Line and put both accounts in the Analytic Distribution 6. Add an account in another column to one of the existing Analytic Distribution Lines 7. Go to Projects and open the Project Updates of the Project whose account was alone in the Analytic Distribution Line 8. You get the error: > invalid literal for int() with base 10: '[int],[int]' ### Explanation: With commit odoo@dc696c8ed4850a83b6af721002a90f2944891923, the way IDs are stored changed. They are now computed in a csv string. A part of the Analytic Accounting pipeline didn't get updated after that change, making a lot of the features not working properly. ### Suggested fix: - We must take into account the multiple analytic plans in any order possible in the ID search. - Because the amount of `account.move.line` can increase rapidly, the new ID search must be indexable. - We reworked the counting query to avoid `account.move` being counted multiple times. opw-3626619
This fix prevents inventory quantity records from being incorrectly deleted during system upgrades. When demo data is loaded after initial setup, certain inventory records were marked as temporary and would be removed during upgrades, causing inventory counts to become inaccurate. The fix marks these records as permanent so they are preserved during upgrades.
Original PR description
when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually…
when database uploaded without demo data and there is no any record in mrp production, and customer used load sample demo data, then it will create some demo record from this file which was actually defined in mrp/data/mrp_demo.xml with noupdate= True.
but as this xmlids has been created from python file using load samples it's noupdate='f' .
so without demo flag, we have `mrp.mrp_inventory_1` and `mrp.mrp_inventory_2` quant entry with noupdate='f'
so during upgrade as there was no demo file loaded, and this entry are with noupdate='f'
ORM try to remove those record quants record
in `_process_end` during upgrade from 17.0 to
saas-17.1, and which was create issues as
that quant contain some qty for storable product
so after upgrade as this qunts removed we have mismatched qty compare to before upgrade ( original database) so to fix that we need to pass noupdate='t'
and also need to fix in upgrade script with force_noupdate TRue.
```
Traceback (most recent call last):
File "/tmp/tmpf_o_71pk/migrations/testing.py", line 207, in test_check
self.check(value)
File "/tmp/tmpf_o_71pk/migrations/stock/tests/test_on_hand_quantity.py", line 58, in check
self.assertEqual(before_results, self.convert_check(after_results), self.message)
AssertionError: Lists differ: [[3, '1'], [4, '4'], [6, '2'], [7, '5'], [8[541 chars]36']] != [[6, '2'], [7, '5'], [8, '2'], [9, '1'], [1[521 chars]36']]
First differing element 0:
[3, '1']
[6, '2']
```Archived employee contracts will no longer appear in the contract menu, improving data organization and reducing clutter. Previously, archived contracts remained visible even though they were no longer active, which could cause confusion when managing current employment agreements.
Original PR description
Issue: ----------- Even if the contract is archived, the contract is still visible in the contract menu. Fixed: -------------- If the contract is archived, then the contract will not be visible task-3522177 Forward-Port-Of: odoo/enterprise#48534
The Sales report was incorrectly displaying inflated totals for subscription products when upsells were created. This fix removes upsell information from the Sales report to prevent duplicate counting, ensuring accurate revenue figures. Users will now see correct untaxed totals in the Sales report for subscription products.
Original PR description
Steps to reproduce: ------------------- - create a subscription with a recurring product (which costs 100); - confirm it and create an invoice; - create an upsell for the subscription; - add the same product with a discount of 30%; - go to Sales report and search the product (product variant); Issue: ------ The report displays 300 for "Untaxed Total" instead 170. Cause: ------ The report takes into account the upsells and when they are validated, the information is put back on the original subscription. As a result, the information is duplicated. Solution: --------- Do not include upsells in the sales report. Note: ----- With the fix, the value is 200 and not 170, because it is not possible to take upsell discounts into account in the sales report (we have to use the subscriptions report). opw-3646388 Forward-Port-Of: odoo/enterprise#58271 Forward-Port-Of: odoo/enterprise#57568
This update fixes an issue where switching to right-to-left (RTL) language mode would incorrectly reverse the email format display. Previously, emails would show as "domain@alias" instead of the correct "alias@domain" format. The fix ensures email addresses display correctly regardless of language direction, improving the user experience for RTL language users.
Original PR description
Before this commit:
Switching to RTL mode would inadvertently revert the domain picker,
causing a disruption in the email format. The expected format is Alias@domain,
but it was displaying as domain@alias.
After this commit:
Now, the domain picker remains intact in RTL mode, ensuring that
the email format is correctly displayed as alias@domain.
Task-3624012
Forward-Port-Of: odoo/enterprise#58263
Forward-Port-Of: odoo/enterprise#58251This update fixes an issue where the accounting system failed to properly match invoice amounts during reconciliation when no partner was specified. The problem was caused by floating-point precision errors in currency calculations (e.g., -208.73 not matching 208.730000000000002). The fix uses a more reliable database query method to ensure accurate amount matching, improving the reliability of automated reconciliation processes.
Original PR description
The orm doesn't match monetary amounts using the related currency. It means, -208.73 != 208.730000000000002. Let's match the amount using an sql query instead. ticket_id: 3741689 X-original-commit: ae848e9 Forward-Port-Of: odoo/enterprise#58333
A bug in the Belgian tax report validation was causing correct tax reports to be incorrectly flagged as invalid. This fix corrects the validation logic so that accurate tax reports are properly recognized and accepted by the system.
Original PR description
Currently, there's a mistake in the Belgian tax report checks, which can cause the tax report to fail validation even though it's correct. ### Steps to reproduce * install `l10n_be_reports` * switch to a Belgian company. * activate the `21% EU S` purchase tax * make sure you don't have any posted journal entry * create and confirm a vendor bill with a line for $5000 and the `21% EU S` tax * open the tax report The tax report is correct, but the system displays a validation error at the bottom: `[44] < ([00] + [01] + [02] + [03] + [45] + [46] + [47] + [48] + [49]) * 200 if [88] > 99.999` opw-3767675 Note: confirmed by TSB on the ticket Forward-Port-Of: odoo/enterprise#58343
This update removes a test for Mexican electronic invoicing (EDI) that was failing consistently due to missing test data. The fix also improves error messages to help diagnose future test failures. This ensures the test suite runs reliably without false failures.
Original PR description
The test for `sw` fails every time because we don't have identifiers. We don't have any, so we just get rid of the test. Also added the message to the error, so we can know why it failed. (Other tests failed some time, but we can't reproduce and know why it failed). Linked to runbot error 25908 Forward-Port-Of: odoo/enterprise#58443
Fixed two critical issues in Italian financial reporting: added missing account 2104 (owner withdrawals) to the Balance Sheet so it properly reflects capital changes, and corrected the Current Year Earnings line to show only the current year's profit/loss results while automatically moving prior year earnings to the appropriate section. These fixes ensure Italian companies' financial statements now balance correctly and comply with accounting standards.
Original PR description
* Account 2104 'Prelevamenti extra gestione' was not referenced in the Balance Sheet. This account tracks withdrawals made by an individual entrepreneur during the fiscal year, before determination of profits, and therefore decreases capital. ([source1](https://www.wincoge2.it/Manuale%20Con%20Esempi/Manuale_Contabilita8.html#:~:text=I%20%E2%80%9CPrelevamenti%20extra%20gestione%E2%80%9D%20sono,nell'arco%20dell'anno.&text=Al%2031%2F12%20la%20voce,la%20destinazione%20dell'utile%20stesso.)) ([source2](https://www.economiaziendale.net/scritture/spese_extragestione.htm)) * The Current Year Earnings line was not showing just the result from the Profit and Loss for the current fiscal year. This has been fixed. Any non-closed results from previous fiscal years now automatically appear under the Previous Years' Earnings line. taskid: 3060790 Forward-Port-Of: odoo/enterprise#58393 Forward-Port-Of: odoo/enterprise#57219
Fixed an issue where SMS template content was not appearing when sending messages from the Contacts form. The template body is now properly computed and displayed when users select an SMS template to send a message. This ensures users can see the full message content before sending.
Original PR description
Steps to reproduce: - - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template…
Steps to reproduce: - - Go to Settings > Technical > Phone > SMS > SMS Templates - Create a new SMS template that applies to contacts with any content and add context action to save the template (this will allow you to use this template from the contact form view). - Go to Contacts, select any, click on the gear icon and send an SMS using your new SMS template. Issue : the Body of the SMS template is not displayed. Cause of the issue: - The send SMS action generates an `sms.composer wizzard` that triggers a call of the `onchange` method to compute the values of the form view of the record from scratch. The body of the message is computed during the snapshot1 of the onchange of the `sms.composer` https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L1076 by the `_compute_body` method: https://github.com/odoo/odoo/blob/72c1a4f96a1219d98ce9b90ee54fd7297b9ab999/addons/sms/wizard/sms_composer.py#L167 To be processed correctly, this computation requires a `template_id` (field of the sms.composer model). This `template_id` information is present in the `self._context` of the onchange as a 'default_template_id'. However, since the template_id is not present in the form view of the sms.composer, it is not part of the `fields_spec` arguments of the onchange and this `default` value is not converted into a value before the snapshot1 at this step: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 Prior to Odoo 17.0, this was not a problem as the value was still used from the context the snapshot1. However, this value is now cleaned form the context during the snapshot1: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/api.py#L567 https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/odoo/tools/misc.py#L1010-L1014 As a result, there is no template_id during the call of the `_compute_body` and the body of the message stays empty. Fix: - In order to compute the body, correctly, we add the template_id as an invisible field of the `sms.composer` form view so that it becomes part of the `fields_spec` arguments of the onchange so that its default value 'default_template_id' is converted into a real value: https://github.com/odoo/odoo/blob/ad299c9325e0a0faf18ba8b2709d4be2829b7158/addons/web/models/models.py#L931-L938 that will be used as an argument of the snapshot1. opw-3733881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where searchbar text became invisible when using dark color themes. The text color now automatically adjusts based on the searchbar background color to ensure proper contrast and readability. This improves the user experience when customizing website themes.
Original PR description
Steps to reproduce the bug: - Open the homepage and enter edit mode. - Click on the "Theme" tab. - Select the 4th color from the theme options and choose "black". - Drag and drop a "Search" snippet onto the page. - Save the page to exit edit mode. - Enter text in the searchbar input. - Bug: The text is not visible because its color is the same as the background color of the input. This bug appeared since this commit [1] where the "bg-light" class was added to the searchbar input. This caused the text color of the input, which by default is the same as the body color, to become invisible when the background color of the body is dark. To fix this, we now adjust the text color of the input based on the background color of the input. [1]: https://github.com/odoo/odoo/commit/6b1d11a60d8e70b33c63da860bb81b015ce5ea20 task-3751401
This fix resolves an issue where user-defined filters would become invalid and cause errors after their parent action was deleted. Previously, filters were not automatically removed when actions were deleted, leading to broken references. Now, all associated filters are properly cleaned up when an action is removed.
Original PR description
When deleting records from ir.action.action, the user-defined filters(ir.filters) will not be deleted automatically, thus causing an error. Steps to reproduce: - Create a User-defined Filter under any action - Remove that action - Go to User-defined Filter again -> There will be an error message pop out that says action record does not exist Cause The User-defined Filters will not be automatically removed when the parent action gets deleted Solution Remove all the User-defined Filters when deleting the parent action
This fix resolves an issue in the mass mailing editor where text color would revert to black when changing font size. Previously, a default black color was being applied to text elements, overriding user-selected colors. Now, custom text colors are properly preserved when users adjust font sizes, providing a better editing experience.
Original PR description
**Current behavior before PR:** When we apply a text color and change its font size, the text color defaults to black. This occurs because the default black color is applied to a span within `o_basic_theme.o_layout`. **Desired behavior after PR is merged:** Now, when applying text color and adjusting its font size, the color of the text remains unchanged. task-3770351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#155715
This update fixes a bug in the email composer feature where different users could see inconsistent data when composing messages. The fix ensures that computed fields display the correct information regardless of which user is accessing the system, improving reliability and preventing confusion when multiple team members use the email composer simultaneously.
Original PR description
Avoid accessing inconsistent data based on the user
This fix resolves an issue where email addresses were displaying incorrectly when using right-to-left (RTL) language modes. Previously, the domain picker would reverse the email format from the correct "alias@domain" to "domain@alias". After this fix, emails now display in the correct format regardless of the language direction setting.
Original PR description
**Description of the issue/feature this PR addresses:** This PR resolves an issue where the domain picker was being unintentionally reverted in RTL mode, leading to a disruption in the email format. **Current behavior before PR:** Switching to RTL mode would inadvertently revert the domain picker, causing a disruption in the email format. The expected format is Alias@domain, but it was displaying as domain@alias. **Desired behavior after PR is merged:** Now, the domain picker remains intact in RTL mode, ensuring that the email format is correctly displayed as alias@domain. Task link: https://www.odoo.com/web#model=project.task&id=3624012 Task-3624012 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156892 Forward-Port-Of: odoo/odoo#154834
Fixed a bug in the recruitment module where phone numbers were not being transferred when creating employees from signed job applications. Now when an employee is created, their phone number is automatically copied to their employee record, or their mobile number is used if the phone number is not available. This ensures complete contact information is preserved during the hiring process.
Original PR description
When an employee is created from a signed application, the phone number or the mobile number was not copied to the employee private information. Now, the phone number is copied and if not present, the mobile number is copied. Task: 3659409 Forward-Port-Of: odoo/odoo#156538 Forward-Port-Of: odoo/odoo#152888
This fix resolves an issue where setting a past end date on a leave allocation would prevent the system from properly calculating the number of days when other allocation details are updated. Now the day calculation will correctly update whenever the start date, end date, or accrual plan is changed, regardless of whether the end date is in the past or future.
Original PR description
Description of the issue/feature this PR addresses:
Create an allocation for an accrual plan in the past will prevent number_of_days computation
- Create an accrual plan to give 1 day per month
- Create an allocation with this plan
- Update date_from and/or accrual_plan_id
- number_of_days is updated
- Set date_to in the past (1)
- Update date_from and/or accrual_plan_id (1)
- Set date_to in the future (1)
- Update date_from and/or accrual plan
- number_of_days is updated
Current behavior before PR:
- (1) number_of_days is not updated
- number_of_days is computed from date_from to now
Desired behavior after PR is merged:
- number_of_days updated on date_from/accrual_plan_id/date_to change
opw-3764865
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix resolves an image caching problem that occurred when displaying images from related records (like partner or user photos) in kanban and activity views. Previously, the system used an incorrect cache key that wasn't tied to the specific record being displayed, causing images to display incorrectly. This update ensures images are cached properly based on their source record.
Original PR description
The way we cache the image is not right when that image is not on the current record. For instance displaying a partner/user image. The unique key used is not related to that record. Introduced by https://github.com/odoo/odoo/pull/97544 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#157004
This update fixes two problems in how Odoo sorts records. First, it prevents unnecessary loss of cached data when sorting is performed. Second, it ensures that newly created records are not accidentally excluded from sorting operations. These fixes improve the reliability and performance of record sorting throughout the system.
Original PR description
BaseModel's sorted() has two problems: - It breaks the prefetch of self for no reason - When it is called without an argument, it filters out new records because the search() used in sorted() doesn't return new records. Keep the same prefetch as self to fix the first problem. We partially fix/support the second issue, we just avoid filtering out new records (but we don't actually sort them) Forward-Port-Of: odoo/odoo#157033 Forward-Port-Of: odoo/odoo#156729
This fix resolves an error that occurred when users deleted a company in Odoo. When a company was removed, the system would crash with an error message when trying to access the onboarding feature. The fix ensures that onboarding progress records are automatically cleaned up when their associated company is deleted, preventing the error and allowing users to continue working normally.
Original PR description
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open…
### Steps to reproduce issue: 1. Download Accounting (or Sales or just Invoices) 2. Open Accounting 3. Create Company 2 and switch to it 4. Open Accounting again 5. Remove Company 2 6. Open Accounting 7. You receive an error: > ValueError: Expected singleton: onboarding.progress(1, 2) ### Explanation: In `_compute_current_progress`, the filter to get `current_progress_id` accepts `onboarding.progress` with both the company in which the user is at the moment or no company at all. https://github.com/odoo/odoo/blob/77f9ff50db3cdb88397d0b1cc7042c772d0d417b/addons/onboarding/models/onboarding_onboarding.py#L55-L69 This is due to the fact that some onboardings are not related to a company while others are. After that, getting the `onboarding_state` will trigger an `ensure_one` check. In the current case, an `onboarding.progress` with a `company_id` is not deleted once the company is deleted. Therefore the value becomes `False`. The `ensure_one` that comes after will throw an error because of it. ### Suggested fix: `ondelete` decorator would require the module to be upgraded. For this issue, it is preferable to have a fix that is automatically applied. The added method simulates the `cascade` effect of `ondelete` and does not require the module upgrade. opw-3762382 Forward-Port-Of: odoo/odoo#155407
This fix resolves an issue where invoices were appearing twice in the invoice analysis pivot view when a product had different costs set across multiple companies. The system was incorrectly counting the same invoice multiple times due to how product cost properties were stored per company. Now invoices are properly filtered to show only once, regardless of multi-company product cost configurations.
Original PR description
Steps to reproduce: - have two companies; Company A and Company B - create a product Product A and set a different cost in each company - create an invoice for Company A with Product A and post it - Go in invocie analysis > pivot view and set the y-axis as 'move' Issue: The invoice will be taken twice Issue: for Product A, there are two ir_property lines (one per cost/company) opw-3753395
This fix resolves an issue where a second invoice created from the same sales order was incorrectly marked as paid. The system was mistakenly using old payment transactions from the first invoice to determine payment status. Now the system correctly checks each invoice's actual payment status instead of relying on transaction history, ensuring customers can properly pay additional invoices.
Original PR description
Steps to reproduce the issue - set up the test provider - order something from the website and pay - create an invoice for the SO (invoice is paid) and confirm it - add an extra item to initial SO - create a second invoice - check the invoice on the portal ==> second invoice is automatically marked as paid because of the transactions on the SO The transactions that were used on the SO are filled in on the new invoice in the transaction_ids field. In the view in the portal the method 'get_portal_last_transaction' is called which finds the transaction for the older invoice and assumes its paid. We will now rely on the payment status of the invoice instead of the state of the last transaction. opw-3594556 Forward-Port-Of: odoo/odoo#156403 Forward-Port-Of: odoo/odoo#155045
This fix corrects how products are packaged when using batch picking with the "Put in Pack" feature. Previously, products from multiple pickings could be incorrectly placed in the same package, causing inventory and shipping issues. The update ensures each picking's products are packaged separately and prevents invalid packaging scenarios that could result in double charges or incorrect shipping documents.
Original PR description
Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking…
Previous fix: odoo/odoo#139013 added in the ability to handle a use case specific avoided due to its complexity and it being an edge case. I.e. the ability to do a Put in Pack in a batch picking where there is a shipping connector involved (i.e. when the `choose_delivery_package` wizard is opened). Because the ability to handle this situation is now added to stable, we have to sort of support it now and handle it not breaking other flows. Here are the flows that need to be handled (and were broken by the previous PR): [In all cases, "Packages" setting needs to be activated and each picking needs at least 1 move of a consumable/storable product] Flow 1: batch picking + put in pack for single picking - Create 2 pickings of any operation type - Create a new batch picking with these 2 pickings - Open 1 of those pickings directly (i.e. not in the batch) - Click on "Put in Pack" Expected result: Only the move from the open picking is put into a package Result before this commit: Both pickings have their moves put into the same package Additional notes: Because this is not an obvious bug, users may already had this bug occur in their DBs without realizing it === Flow 2: batch picking (or multi-record calling of `action_put_in_pack`) [different in v17 onwards due to removal of immediate_transfer boolean] - Create 2 pickings (of different picking types) - Select both pickings (through direct call in shell or rpc) and call `action_put_in_pack` Expected result: Moves are blocked from being put into same package since this situation doesn't make sense (i.e. the products are moved to different locations but the package can only be in 1 location) Result before this commit: The moves will all be put into the same package Additional notes: In theory batch picking creation has checks to avoid batches where there are pickings with more than 1 picking type or have different `show_reserved` values, but because `_package_move_lines` is a method that can be called in different use cases (including multi-record pickings) via customizations/future code changes, we add in checks to prevent put in pack from finishing in those cases to avoid unexpected behavior/stack traces. I.e. remember to respect existing `self.ensure_one` checks since they're probably there for a reason. === Flow 3: batch picking w/pickings w/more than 1 delivery carriers (where none = a different carrier than having 1) - Create 2 delivery pickings with different `carrier_id` values (i.e. different shipping methods assigned to them) - Add both pickings to a batch - Click "Put in Pack" in the batch picking Expected result: None, we should not handle this case because if the products are in the same package then the same package info will be sent to both carriers and the user will be double charged for every move (or charged(/potentially create the wrong shipping documents) when it shouldn't be in case of no carrier for one of the pickings) Result before this commit: All moves are put in the same package and the double charging/potentially incorrect shipping documents will occur Additional notes: This is the use case that was intended to be avoided when flow was originally decided to not be handled --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157093 Forward-Port-Of: odoo/odoo#156068
This update fixes a test that was checking the same condition before and after moving an image, which could lead to unpredictable test failures. The test now includes an extra step to refresh the editor panel between actions, ensuring it properly validates that image filters are preserved when images are repositioned in the gallery.
Original PR description
[FIX] website: adapt test tour to avoid undeterministic error Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also…
[FIX] website: adapt test tour to avoid undeterministic error Since [1], image options like "Filter" are kept when a user changes the position of an image in an "Image Gallery" snippet. [1] also adapted the `snippet_image_gallery` tour (moved in `snippet_image_gallery_reorder` from version 16) to test this behavior. To do so, the test adds a filter on an image in an "Image Gallery" snippet, checks that the filter is displayed on the editor panel, moves the image, clicks on it and finally checks that the filter is still displayed on the editor panel. The problem is that the steps that check if the filter is displayed on the editor panel are the same before and after the move of the image which means that the second check is true also before the move of the image. This situation is a typical case where an undeterministic error could happen. Indeed, we do not know if the second check tests an old value or an updated one. To solve the problem, the test has been adapted; after the move of the image, the test clicks somewhere else (on the footer in this case), and then back on the moved image to finally check that the filter is still displayed on the editor panel. The goal of the click on the footer is to be sure to have a loaded version of the editor panel. By doing so, we remove the risk of an undeterministic error situation where a condition is already true before an action is done. Note: this problem has been discovered because the test `snippet_image_gallery_reorder` succeeds on version 16.3 without the fix of [1]. Now, the adapted test fails on version 16.3 without the fix of [1]. [1]: https://github.com/odoo/odoo/commit/0fd2477d993e822fe6fd4497aace9f746af7a481 task-3717041 Forward-Port-Of: odoo/odoo#156943 Forward-Port-Of: odoo/odoo#153014
This fix resolves an issue where payment methods would incorrectly remain from a previously selected journal when switching between journals. When creating a payment and switching from one journal to another and back, the payment method would not update properly. The fix ensures the journal ID is only computed during initial payment creation, not during subsequent field changes.
Original PR description
The goal of the `def new` override on `account.payment` is to have the `journal_id` computed when creating a payment in the form view. The problem is that it is also called by the onchange when a field is modified. This is causing a bug: - Go the the cash journal and change the name of its payment methods (so you can distinct them from the ones of the bank journal). - create a payment (do not save) - switch the journal to "Cash" then switch back to "Bank". -> the "Payment Method" is still one from the "Cash" journal. The fix is here is a hacky way of checking this is the call on the record creation. Forward-Port-Of: odoo/odoo#156832 Forward-Port-Of: odoo/odoo#155710
This fix ensures that when a live chat operator takes over from a chatbot, the operator's name and visitor information are properly displayed in the channel name. Previously, all channels were labeled only as "Chatbot," making it difficult for managers to identify and review individual chat sessions. This improvement helps live chat managers better organize and track conversations.
Original PR description
Description of the issue/feature this PR addresses: - Create a website - Create a chatbot with forward to operator --> Issue all mail.channel have 'Chatbot' in name field  @tde-banana-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156123 Forward-Port-Of: odoo/odoo#152223
Users assigned to specific websites can now successfully log in using the API (RPC). Previously, the system couldn't verify the correct website when logging in through the API, causing login failures even when using the correct domain. This fix enables the system to properly identify the website during API logins, allowing restricted users to authenticate successfully.
Original PR description
__Current behavior before commit:__ When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can only login if…
__Current behavior before commit:__ When the field `website_id` of a user is set, this user should only be able to login via this website (cfr. [this method][1]). This means that he can only login if [`get_current_website`][2] returns the same website as `website_id`. The issue is that when login with RPC, `dispatch_rpc` is making a [`borrow_request`][3] which hides the `request` object from the RPC layer. This has the consequence that `get_current_website` is not able to retrieve the website based on the url of the request. Thus preventing a user to login via RPC even if the domain used corresponds to the website set in its `website_id` field. __Description of the fix:__ Add the possibility to retrieve the current website via `threading.current_thread().url` (which is set [here][4]). This way it is possible to know the current website even if `borrow_request` has been used. opw-3742591 [1]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/addons/base/models/res_users.py#L779 [2]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/addons/website/models/website.py#L944 [3]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L361 [4]: https://github.com/odoo/odoo/blob/0f7cbf2969b3c4b6c496e5b54814c4a9b3081af4/odoo/http.py#L2037 Forward-Port-Of: odoo/odoo#157309 Forward-Port-Of: odoo/odoo#154447
This fix resolves a critical bug in the manufacturing module where starting a workorder was incorrectly unplanning all subsequent workorders in the production order. The issue was introduced in recent updates and affected versions 16.4 and later. This fix ensures that starting one workorder no longer disrupts the scheduling of other workorders in the same production order.
Original PR description
Commit https://github.com/odoo/odoo/pull/110550/commits/b347675c36cc5c3f54bf64f2e295d0afe9196be8 merges mo/wo scheduled & effective dates. Later commit https://github.com/odoo/odoo/pull/128043/commits/62590fa7d742267421a42cbf654352cd5b7e048c for 15.0 fixes the mo start date. Unfortunately, forward ports breaks 16.4 & later: starting a workorder unplan the subsequent ones. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#157345