Wednesday, March 6, 2024
30 changes · 17.0
Resolved issues and error corrections
This update corrects two important issues in financial reporting. First, the aged receivables and payables reports now display the correct transactions by fixing how journal types and dates are filtered during audits. Second, when SEPA direct debit is enabled, the Amounts to Settle view now properly filters SEPA-related transactions. These fixes ensure your financial reports show accurate data for reconciliation and payment processing.
Original PR description
*: account_reports, account_sepa_direct_debit --- This PR contains two commits. The first one fixes wrong domains when auditing the aged reports by adjusting which journal types the aml's that are displayed can have and by adjusting the dates that are used. The second one fixes a missing filter for SEPA Mandates in the Amounts to Settle view when sepa is installed. --- odoo: https://github.com/odoo/odoo/pull/148476 task-3640027
Fixed an issue where selected resources were not being properly saved when booking appointments with the "Resource Then Time" setting. When users selected a resource (like a staff member) and then chose a time slot, the selection wasn't being recorded in the system, causing the details to not display correctly. This fix ensures the resource selection is now properly captured and shown.
Original PR description
For resource appointments with Resource Then Time setting, when clicking on a day to select a slot, for instance on update of the slots when changing users, or when simply when selecting a day, the resource_selected_id is not added properly to the url as it should, hence not showing the selection in the details column in the /info screen. This is only due to not using the value of the select for the resource. Fix the issue by using the value of the resource dropdown if any. Task-3603354
This fix resolves an issue where users couldn't generate BOE tax reports (MOD111, MOD115, MOD303) for Spanish companies without encountering an error about missing bank account information. The problem occurred because the system wasn't properly loading available bank accounts when opening the report generation dialog. This fix ensures the bank account field displays correctly and is only required when actually needed.
Original PR description
### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * ensure that the partner linked to your Spanish company has a bank account * open the tax report (MOD111, MOD115 or…
### Steps to reproduce * install `l10n_es_reports` * switch to a Spanish company * ensure that the partner linked to your Spanish company has a bank account * open the tax report (MOD111, MOD115 or MOD303) * on the top left, click 'BOE' > 'Generate BOE' You should be met with the following error: "Please select an IBAN account". The 'Direct Debit Account' field should not be required. Another issue is that even if your company has some bank accounts defined, none of them will be listed in the 'Direct Debit Account' field. ### Cause In `Mod111And115And303CommonBOEWizard`, `partner_bank_id` (Direct Debit Account) depends on `company_id` through `company_partner_id`. However, since `company_id` is not in the view, its associated default value will only be calculated when the wizard is saved. Before that, `company_id` will be empty, which will cause `partner_bank_id` to be empty as well. https://github.com/odoo/enterprise/blob/f512de0bcd32ab65bd3c91ffc7e7955c491d24da/l10n_es_reports/wizard/aeat_boe_export_wizards.py#L40-L42 The reason it works well in 16.4 is because before d2e099597c845e21f12bc0868c36ac5d4cf89b36, the wizard was initiated using `create()`, so the default values were calculated before displaying the wizard. https://github.com/odoo/enterprise/blob/59e9d1f9d705773091f86ccf5c6ba7bac9feaf5d/l10n_es_reports/models/aeat_tax_reports.py#L124-L136 opw-3719150 opw-3756722
This fix resolves a crash that occurred when viewing the General Ledger report with multiple companies and using horizontal grouping. Users were encountering an error when trying to expand report lines. The update properly handles empty data values that can occur in certain grouping configurations, ensuring the report displays correctly without interruption.
Original PR description
### Steps to reproduce * install `account_reports` * make sure you have multiple companies * create a new horizontal group with the following values: * Reports: General Ledger * Field: Company, Domain: [] * open the general ledger and apply the horizontal group you just made * attempt to unfold a line You should be met with a traceback: `KeyError: 'currency_id'` ### Cause Some possibly empty values are not accounted for. In this case, we arrive here with `eval_dict[column['column_group_key']]` being an empty dict, which produces the traceback at line `618`. https://github.com/odoo/enterprise/blob/74000d6d5c8435bcaad93f7baf143abdf8593064/account_reports/models/account_general_ledger.py#L617-L621 Depending on the horizontal group, `init_bal_by_col_group[column['column_group_key']]` can also be `None`, which can cause issue at line `621` opw-3746643
This update corrects how subscriptions are marked when using token-based payment methods. Previously, subscriptions were incorrectly flagged as having pending transactions even though the payment was already completed. Now the system properly recognizes when a transaction is complete and avoids the unnecessary pending status, ensuring accurate subscription records.
Original PR description
When using a token payment method the transaction will already be completed during the transaction creation. The subscription should not be marked with pending transaction as the transaction is already completed
This update prevents users from incorrectly selecting quantity-based quality checks when working with manufacturing operations. The system now displays a clear error message if someone attempts this invalid combination, ensuring quality control processes are set up correctly and reducing configuration errors.
Original PR description
Add an userError to prevent the user selecting quantity quality check Type with manufacturing operation types. opw-3770822
Portal users can no longer see template buttons in the Knowledge app, even if they don't have access to any templates. This change improves security and user experience by hiding irrelevant features from users who cannot use them.
Original PR description
Before this commit: Portal users could access template buttons even though they did not possess any templates, leading to undesired visibility. After this commit: Following this commit, template buttons will no longer be visible to portal users, ensuring appropriate access restrictions. Task-3758669
This fix restores the ability to drag, drop, and resize appointment slots in the calendar creation mode. A previous security update had inadvertently disabled this functionality for slots because they don't have participants. The fix ensures slots can be edited while maintaining the security restrictions on other calendar events.
Original PR description
Purpose ======= Restore the possibility to resize and drag and drop the slots when using the creation mode in the calendar. Specifications ============== The calendar events edition (drag and drop/resize actions) were previously limited to the participants of the event. This prevented, for example, users from changing the time-off events of other users. However this fix was applied on a method that is also used by the calendar slot renderers. As slots don't have any participants, their editable attribute was always set to false. Fixing the issue by forcing the slots editable attribute to true. Task-3756066 Forward-Port-Of: odoo/enterprise#57966
This update adds a required software dependency (pyjwt) to the Indian QR code bill scanning module. Without this dependency properly declared, the module would fail to function correctly. This fix ensures the module has all necessary components to work as intended.
This fix resolves an issue where timesheets were being lost when creating multiple timesheet entries for different helpdesk teams in a single operation. A variable naming conflict in the system's internal processing was causing some timesheets to be skipped. The fix corrects this variable name and includes a test to prevent this problem from happening again.
Original PR description
Steps to reproduce: ------------------- 1. Create 2 helpdesk teams. 2. Create timesheets with different helpdesk_team_id on a single create call by passing them as a list of timesheets. This will result in having missing timesheets, since the variable `vals_list` passed in the preprocess function had a conflict with another variable. This PR changes the variable name to resolve the issue, and a unit test for bulk creation of timesheets with seperated helpdesk tickets has been added. related Task-3669013 Forward-Port-Of: odoo/enterprise#58071
This update fixes a calculation issue in the account reconciliation wizard that occurs when dealing with extremely small currency exchange rates. When the balance is nearly zero, the system now correctly sets the write-off amount to zero instead of calculating an incorrect rate, improving accuracy for international transactions.
Original PR description
Fix the rate computation in case the rate is extremely small (thai case). If the balance is close to be 0 we want to have a write-off amount of 0. Forward-Port-Of: odoo/enterprise#58087
This update fixes an issue where survey result charts were displaying smaller than expected and disappearing entirely when users tried to print the page. The fix ensures charts now display properly at full size and remain visible when printing, improving the usability of survey reports for both screen viewing and printed documents.
Original PR description
Purpose ======= When you go on any survey results page, you notice charts are smaller than they used to be on version 16. But there are still readable. The annoying part is when you click on the `print` btn or press `CTRL + P`, the charts disappear from both the page and the window preview. How to fix ========== - add classes `w-100` and `h-auto` to the canvas elements containing the charts Also, remove after/before-print events in the public widget as they are no longer useful. see https://github.com/odoo/odoo/pull/135683 task-3667969 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix addresses accidental survey submissions in one-page surveys where pressing Enter would unexpectedly submit the form. Users can now only submit surveys by pressing Ctrl+Enter, making the submission process more intentional and reducing confusion when navigating through survey questions.
Original PR description
Previously, In "one_page & page_per_section" survey, pressing Enter would submit the survey, leading to confusion and accidental submissions, as users might press Enter intending to navigate through questions. With this PR, Now, requiring "Ctrl + Enter" to submit, ensures clarity in survey submission, reducing the chance of accidental submission. task-3707763
This fix resolves an issue where expense reports were incorrectly blocked with validation errors when using analytic plans across multiple companies. The system was checking all analytic applicability rules regardless of which company was active, causing false warnings about missing analytic distributions. Now the validation correctly considers only the rules applicable to the current company.
Original PR description
Have company A and company B With company B: - Create an analytic plan with default applicability 'Mandatory' - Add an applicability: domain 'Expense', applicability 'Mandatory' With company A: - Open the same analytic plan - Set default applicability 'Optional', no assigned applicability - Add an analytc account for the plan - Create an expense, add amount - Create report > Submit to Mananger > Approve Issue: Action will be blocked by Warning message "One or more lines require a 100% analytic distribution." This occurs because the system checks all applicabilities of the plan without taking into account the company opw-3709374
This fix resolves an error that occurred when users submitted survey answers to questions configured to save as nickname or email. The issue happened when surveys didn't allow users to go back and edit responses. The fix now allows answer updates for these special question types, restoring functionality that was inadvertently restricted in version 17.0.
Original PR description
Purpose ======= Fix the UserError which is raised when the user submits an answer to a question having the "save as nickname" or "save as email" option checked. In testing or non-testing mode.…
Purpose ======= Fix the UserError which is raised when the user submits an answer to a question having the "save as nickname" or "save as email" option checked. In testing or non-testing mode. Specifications ============== When the question is marked as "save as email" or "save as nickname" and when the user isn't public, the partner data is already saved as the question answer (in the form of a user input line). The answer is then pre-filled in the survey. This is an issue because when the survey has the "users can go back" option to False and the user tries to submit the answer, it thinks the user is trying to changed the already saved user input line and it crashes for security reasons. In addition of allowing the answer override if the user can go back, also allow the override if the question is marked as "save as nickname" or "save as email". This issue was introduced in 17.0 when the overwrite_existing optional parameter has been added on the _save_lines method. Before that, the existing user input lines were overwritten no matter what. related https://github.com/odoo/odoo/pull/129329 Task-3756749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where setting up multiple automation rules with the same trigger event (like "On incoming message") would cause errors. The problem was that automation rules were not properly isolated from each other when being applied. Now each automation rule gets its own independent function, allowing multiple rules to work together without conflicts.
Original PR description
Steps to reproduce: - Install base_automation_hr_contract and helpdesk - Setup two automation rules with model "Helpdesk Ticket" and "On incoming message" as trigger - Create a ticket in helpdesk Issues: Traceback is shown because `_message_post` doesn't have the origin attributes. This is due to the closure being wrong as explained here: https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L686-L691 Solution: Encapsulate the `_message_post` function definition, so that each times we patch message_post we patch it with a new function. This wasn't the case before since `_message_post` wasn't isolated. This solution is similar to the other method patched. https://github.com/odoo/odoo/blob/e2ad568e6cd4de2d721149eb76d04f58c8510191/addons/base_automation/models/base_automation.py#L711-L734 opw-3758851
This fix restores the display of product variant details on kitchen printer receipts in the Point of Sale restaurant module. Previously, only the product template name was shown, which made it difficult for kitchen staff to prepare orders correctly. Now variant information (such as size, color, or other options) will appear on printed receipts again.
Original PR description
Before this fix: Receipts printed with kitchen/preparation printer does not show the details of variants products. Just the product template name. This is ambigious for kitchen as the variant information is generally necessary in order to prepare the order correctly After this fix: Restore the previous behavior regarding the product name used This bug is a side effect of: https://github.com/odoo/odoo/pull/152213 due to the changes to `set_full_product_name` Was also a good occasion to add some tests on the changes name & qty opw-3755391
Customers can now successfully remove coupon codes from their shopping cart. Previously, when clicking the delete button next to a coupon code, the system failed to remove it because the coupon line lacked a proper identifier. This fix ensures that discount codes can be properly removed during checkout, improving the customer shopping experience.
Original PR description
## Steps to reproduce - Install **eCommerce** app - Go to **Settings** and enable **Discounts, Loyalty & Gift Card** option - Go to **Website** app > **eCommerce** > **Loyalty** > **Discount &…
## Steps to reproduce - Install **eCommerce** app - Go to **Settings** and enable **Discounts, Loyalty & Gift Card** option - Go to **Website** app > **eCommerce** > **Loyalty** > **Discount & Loyalty** - Create a new coupon by setting the **Program Type** to **Coupons** and then save - Generate a new coupon by clicking the **GENERATE COUPONS** button. - Go to **Website** > **site** > **Homepage** - Go to **Shop** page - Add a product to the cart - Apply the coupon code created - Remove the coupon code by clicking the bin icon next to the coupon code line - The coupon code is **_NOT_** removed. ## Investigation #### First, we'll take a look on what happens when a coupon code is applied - When a coupon code is applied, a new `sale.order.line` is created for it. - That triggers `super()._compute_website_order_line()` https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order.py#L111 which **_filters out_** the discount order line https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale/models/sale_order.py#L66 via the `_show_in_cart()` method https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order_line.py#L12 - Then a new **_temporary_** sale.order.line is created by https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order.py#L121 meaning that is has no `id` - ⚠️ Note that we can only apply one coupon from the same program type. #### Second, Let's take a look on what happens when we try to remove a coupon code - A call is made to `cart_update_json()` which calls https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale/controllers/main.py#L811-L819 which calls https://github.com/odoo/odoo/blob/d8ec7735aa8759fa94fc0223945ac9b19e05312e/addons/website_sale_loyalty/models/sale_order.py#L159 - But as noted above the coupon order line **`has no id`** being a **_temporary_** record. Hence the `line_id` is **None** which basically cancels the cart update. opw-3744910 Forward-Port-Of: odoo/odoo#156383 Forward-Port-Of: odoo/odoo#154680
This fix resolves an issue where holding Ctrl and clicking on a styled link in the web editor would not open the link. The problem occurred because the click target was the styled element rather than the actual link. The fix now correctly targets the nearest link tag, allowing Ctrl+click functionality to work as expected.
Original PR description
Current behavior before PR: Ctrl+clicking on a styled link is ineffective since the target is the styled element, which lacks an href. Desired behavior after PR is merged: The target should be set to the nearest `<a>` tag rather than on the styled tag. task-3773924 Forward-Port-Of: odoo/odoo#155820
Fixed an issue in the website forum where removing a filter on an author's profile would incorrectly redirect to the logged-in user's profile instead of showing all the author's questions. Now when users remove filters from an author's profile, they stay on that author's profile and see all their questions as intended.
Original PR description
Before this PR: - Navigate to the author's profile from a course on website forum. - Go to the Questions tab and remove the existing filter - It directs to the login user's profile instead of removing the filter. After this PR: Now when the filter is removed and all the questions of the author are shown from his profile. Task-3725329 Forward-Port-Of: odoo/odoo#154901 Forward-Port-Of: odoo/odoo#153986
This fix ensures that when a sales order with an assigned accounting code (analytic account) is confirmed, any manufacturing orders created to fulfill it will automatically inherit that same accounting code. Previously, manufacturing orders would be created without accounting codes, making it harder to track costs and profitability by project or department. This improves financial reporting accuracy for made-to-order products.
Original PR description
Steps to reproduce: - Enable MTO - Create a manufactured product (no analytic distribution on the bom) - Create an SO for that product and set an analytic account on it - Confirm the SO Bug: no analytic account on the created MO Fix: inherit MO analytic account from SO if none is set on the BOM opw-3708134 Forward-Port-Of: odoo/odoo#154354
This fix resolves an issue where the Journal field in payment provider settings would randomly appear or disappear depending on how system modules loaded. The payment_custom module now ensures it loads after account_payment, guaranteeing consistent visibility of the Journal field across all payment provider types.
Original PR description
Both the `payment_custom` and the `account_payment` modules made changes to the visibility of the `payment_followup` group in the view of the `payment.provider` model. As these modules didn't depend on each other, the visibility of the group was determined based on the (random) loading order or the modules, causing the "Journal" field to be either visible or invisible on other providers than Wire Transfer. With this commit, a priority is set on `payment_custom`'s view to force it to always load after that of `account_payment`.
Radio buttons in website forms were not maintaining their default selected state after a recent technical update. This fix restores the correct behavior so that pre-selected radio button options display properly when forms load, matching the behavior of checkboxes and dropdown menus.
Original PR description
Same fix as for checkbox (commit [1]) and select (commit [2]). The radio buttons were forgotten. Check commit [1] for in-depth explanation, but this is basically because since the qweb engine conversion to OWL (done at [3]), it would toggle the internal `checked` value and not the `checked` attribute anymore. [1]: https://github.com/odoo/odoo/commit/b42e9cc686e7d3ccf82cd091a5dc24028fff8a2b [2]: https://github.com/odoo/odoo/commit/dd504811303a2ace661259d05d1e3b88794dc5be [3]: https://github.com/odoo/odoo/pull/130467 opw-3755078
This update fixes a problem where placeholder text was appearing in purchase requisition reports when printing actual records. The fix adds conditions to prevent these placeholders from being displayed in real reports. Additionally, unnecessary placeholder elements that weren't being used have been removed to clean up the report template.
Original PR description
Previous PR: odoo/odoo#135739 added in report placeholders for the sake of easier editing of reports with studio. Unfortunately it didn't check that these placeholders aren't printed with real records which results in junk being included in the report, so we add in conditions to avoid this situation. Also, since the report was already being edited, clean up some of the placeholders because they didn't make sense/ didn't do anything (e.g. the `address` values weren't used + already have a special placeholder in studio => remove them). --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects a display issue where column values were misaligned with their headers when viewing grouped lists in the Planning app. The problem occurred when the "View" button was enabled on grouped rows, causing columns to shift one position to the right. The fix adjusts how the system calculates column spacing to ensure values always line up correctly with their headers, regardless of which optional fields are displayed.
Original PR description
### Steps to reproduce: - Install **planning** app. - Go to **planning** app, and convert the view to **List**. - Group by **Resource** -for example-. - Notice how the Allocated Time column values…
### Steps to reproduce: - Install **planning** app. - Go to **planning** app, and convert the view to **List**. - Group by **Resource** -for example-. - Notice how the Allocated Time column values are mis-aligned with the header label. ### Investigation: - in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8 - In the `getGroupNameCellColSpan` method: - the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1` - as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value) - but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column. ### The proposed fix: - As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method. - In our case: - the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1` - as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1` - Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct. - But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes! - the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0` - as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2` - Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct. - One last case, what if we have no aggregates - both firstAggregateIndex` = `lastAggregateIndex` = -1 - we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1` - if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`. opw-3764616
Product labels with special characters (like quotes) were displaying incorrectly when printed as ZPL text labels, showing encoded characters instead of the actual symbols. This fix ensures special characters print correctly in text-based product label reports.
Original PR description
Current behavior: When printing products ZPL Labels, special characters are not printed correctly. e.g. quotes become ' Steps to reproduce: - Modify a product name with special characters - Print a product label - Select ZPL Labels As the report is only rendered as text, the special characters are not dangerous and can be printed as is. opw-3684870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#156472 Forward-Port-Of: odoo/odoo#152657
This fix corrects how taxes are calculated when early payment discounts are included directly in invoice payments. Previously, a tax field was incorrectly hardcoded as "inverted," which caused incorrect tax reporting. The fix allows the system to calculate this field properly, ensuring accurate tax records for your financial statements.
Original PR description
When configuring the payment term to include the EPD within the payment's journal entry on a customer invoice, the tax_tag_invert field got wrongly set as True. This was hardcoded in the code; computing the field in the regular way gives the proper value. OPW 3754446
This fix resolves a crash that occurred when users tried to mention a contact using the @ symbol in the expanded message composer while the Live Chat module was installed. The issue was caused by the Live Chat module incorrectly assuming certain data would always be available. The fix ensures the system properly handles cases where this data is optional, allowing users to mention contacts without errors.
Original PR description
Making a mention in full composer when `im_livechat` is installed was making the following crash:
```
TypeError: Cannot read properties of undefined (reading 'type')
at SuggestionService.fetchSuggestions
```
Steps to reproduce:
- install module `im_livechat`
- open contacts app form view
- open full composer (e.g. Log note => expand icon)
- type @ + a character => throws error above
This happens because `SuggestionService` methods can optionally pass a thread, but livechat overrides wrongfully assume they were always provided.
This commit fixes the issue with optional chaining, taking into account it's optional.
No test because full composer doesn't work in unit tests, tours require adding steps blindly and I've already wasted too much time to no avail.This fix resolves an issue where the "Open in new window" setting for links in the website builder would not be remembered when re-entering edit mode, even though the setting was correctly saved. Users can now set links to open in a new window and the setting will properly persist across editing sessions.
Original PR description
Before this commit and most likely since commit [1], the "Open in new window" option of link would not persist through editions. Steps to reproduce: - Create a link in the website builder - Set its "Open in new window" property to true - Save, and see that it works as expected - Now enter edit mode again, the toggle will be off and not on as it should be since the `target="_blank"` was correctly added. For easy of debugging and understanding, you can just grep this line ```js this.initialNewWindow = this.initialNewWindow || this.linkEl.target === '_blank'; ``` [1]: https://github.com/odoo/odoo/commit/d7245d2abf528d093226c80e40975e63d61e8997# opw-3781477 Forward-Port-Of: odoo/odoo#156372
This fix improves error reporting in the Point of Sale system. Previously, when validation or user errors occurred, the system displayed a generic "Odoo Server Error" message that didn't help staff understand what went wrong. Now, the actual error details are shown, making it easier for users to identify and fix issues at the checkout.
Original PR description
Prior to this commit, in the event of an RPCError, such as UserError or ValidationError, it would display a generic 'Odoo Server Error' error. This error lacked useful information for diagnosing and addressing the issue. opw-3776047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr