Daily updates from Odoo
Tuesday, March 12, 2024
75 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
1 change
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
36 changes
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
This update corrects how a tax destination field is hidden in the partner view table. The system was using an incorrect display attribute that wasn't working properly in table layouts. The fix ensures the field is properly hidden from users when viewing partner tax information.
Original PR description
In one2many, for the view, the attribute to hide a field should be column_invisible and not invisible --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Non-administrator users were unable to access the Journal Items page in Accounting due to a permission restriction on a system view. This fix removes the unnecessary access barrier, allowing users without admin rights to view journal items as intended. This improves usability for accounting team members who don't have full system administration privileges.
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
This fix corrects how product prices are displayed in the shopping cart when your store is configured to show prices with taxes included. Previously, cart prices were calculated differently than product page prices, causing incorrect amounts to be shown to customers. The fix ensures consistent price calculations across both the product page and shopping cart.
Original PR description
To reproduce: ============= - In the Settings: Product prices displayed on the website set as "Tax Included". - Created a test product (for example price 100$ tax 15%). - Created a price list with fixed price 15$ for all products - Pricelist configured as "Selectable" and set to "Show public price & discount to the customer". - on the product shop page, the price is 17.25$ instead of 115$ (which is the correct). - add product to cart and check the cart price, it's 17.25$ instead of 100$. Problem: ======== on the shop page the prices is calculated through combination. But in the cart, it's retrived directly from `sale.order.line`. Solution: ========= do same calculation in the cart as in the shop page through combination. opw-3771242 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a testing issue in the web module where image field tests were failing intermittently due to timing problems. The fix increases the delay in the test to ensure images are fully loaded before validation, improving test reliability and reducing false failures.
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 update brings the spreadsheet component to version 17.0.14 with multiple bug fixes and performance enhancements. Users will experience improved responsiveness when working with spreadsheets, fixes for data validation checkboxes, corrected automatic sum calculations, and better autofill functionality. These changes ensure the spreadsheet feature works more reliably across different browsers and scenarios.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6f6e1b9dd [REL] 17.0.14 https://github.com/odoo/o-spreadsheet/commit/540c525ed [FIX] header_positions: perfs of update…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6f6e1b9dd [REL] 17.0.14 https://github.com/odoo/o-spreadsheet/commit/540c525ed [FIX] header_positions: perfs of update style Task: 3797400 https://github.com/odoo/o-spreadsheet/commit/fdafd66c0 [FIX] automatic_sum: wrong behaviour with spreaded values Task: 3782971 https://github.com/odoo/o-spreadsheet/commit/8ac8ce53b [FIX] DataValidationCheckbox: Fix input positioning in FF Task: 3774645 https://github.com/odoo/o-spreadsheet/commit/4769c9ed4 [FIX] GridComposer: Reset the cell reference visibility on stop edition Task: 3736211 https://github.com/odoo/o-spreadsheet/commit/cd9bcee12 [FIX] data validation: checkbox not disabled in readonly Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/cb53fc249 [IMP] data validation: performance of icons Task: 3773923 https://github.com/odoo/o-spreadsheet/commit/035f42e00 [PERF] evaluation: apply compute function Task: 3775636 https://github.com/odoo/o-spreadsheet/commit/70c51deb6 [FIX] autofill: allow to autofill a mix of number values and formulas Task: 3700733
This fix ensures that when creating a new journal with restricted mode enabled, the secure sequence ID is properly generated immediately. Previously, the sequence was only created when the journal was edited, which could cause issues if certain modules weren't installed. This resolves an inconsistency in how journals are initialized.
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 removes an unnecessary step when loading sale orders in the Point of Sale system that was causing the system to retrieve excessive customer data from the database. By eliminating this redundant process, the system will run faster and more efficiently, especially when dealing with large numbers of customers.
Original PR description
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return…
Issue --> In `_onClickSaleOrder`, we load in the partner on the sale order using `load_new_partners()`. However, the search on the `res.partner` model made in this method has the potential to return every single `res.partner` record because of the domain that it uses --> https://github.com/odoo/odoo/blob/6c2dd5fbd9898f0efecdc35593af69bfd7d4eb50/addons/point_of_sale/static/src/js/models.js#L783-L785 This can cause SQL to overwork especially when computing the 'total_due' field. After doing so, we check if the partner has been loaded and we grab the id using `get_partner_by_id`. If the partner is not loaded, we use `_loadPartners` to load them. Since we are already checking and reloading the partner on the sale order using `_loadPartners`, using `load_new_partners()` earlier is redundant. Solution --> Remove the try-catch block that loads multiple `res.partner` records during the process of clicking on a sale order via POS. opw-3619941 Forward-Port-Of: odoo/odoo#157171 Forward-Port-Of: odoo/odoo#156836
This update corrects a typo in the stock move module where the cancellation state was incorrectly named. The proper state for cancelled stock moves is now correctly set to "cancel". This ensures inventory operations are properly tracked and reported when orders are cancelled.
Original PR description
Correct state for stock move is "cancel". **opw-3783252**