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