Daily updates from Odoo
Tuesday, March 12, 2024
38 changes · saas-17.1
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