Daily updates from Odoo
Monday, February 3, 2025
86 changes · 18.0
Enhancements to existing features
This update adds support for Spain's Bizkaia Batuz Modelo 140 reporting format, used by freelancers. It automatically identifies eligible companies by VAT format and adds the extra activity information needed for freelancer vendor bill reporting, helping businesses meet local tax filing requirements.
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
This update improves how Odoo handles manually adjusted tax and base amounts, making tax calculations easier to customize and more consistent. It also fixes an issue where point of sale cashiers could not print a proforma invoice after a failed Italian EDI document generation due to missing invoice line access rights.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change lets multiple own checks be recorded together in a single journal entry instead of creating separate split entries. This improves payment and invoice status accuracy and simplifies accounting workflows for businesses using Latin American check localization.
Original PR description
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split…
This PR introduces an improvement to the account and l10n_latam_check modules that allows for multiple liquidity lines (one per check) to be recorded in a single journal entry. Currently, a split journal entry is created for each liquidity line, which presents several disadvantages:
- Incorrect computation of payment and invoice states
- Simplified workflow: By using a single journal entry for all liquidity lines, the workflow is significantly simplified and accounting complexity is reduced.
- First step towards a refactor: This improvement is a first step towards a broader refactor that will allow adapting the own check flow in payment registration without the need to create journal entries.
Changes made:
- Enhanced _synchronize_to_moves() method:
- Allows for the creation and update of multiple liquidity lines within a single journal entry.
- Removes excess liquidity lines if _prepare_move_line_default_vals() returns fewer lines than currently exist.
- Account type-based counterparty identification: Replaces the previous position-based identification with an approach based on account types.
- The starting index for extra line values is now dynamic, determined by the number of liquidity lines
- Removed _l10n_latam_check_split_move method:
- This method is no longer necessary given the new implementation that supports multiple liquidity lines in a single journal entry.
- Modified _prepare_move_line_default_vals() method: - Now returns one liquidity line for each registered own check, simplifying the generation of journal entries.
- Preserved _l10n_latam_check_unlink_split_move() method:
- Maintained for backward compatibility purposes, allowing payments containing split moves to be set to draft status.
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
opw-4236815
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Mexico payroll module now includes the new official minimum daily wage value for 2025. This helps ensure payroll calculations use the correct wage reference for the new year.
Original PR description
There is a new value for the minimum daily wage for 2025. Task: 4510726
The Mexican payroll module now includes the official UMA value for 2025. This keeps payroll-related calculations aligned with the latest required reference amount, helping businesses remain accurate and compliant.
Original PR description
New UMA value for 2025. Task: 4465318
Financial reports can now group results using searchable fields even when those fields are not physically stored in the database. This gives businesses more flexibility for reporting scenarios such as consolidation, where custom related fields may be needed for analysis.
Original PR description
At the moment, the allowed groupbys for the standard report engines (account codes, domain, tax tags) need to be stored fields on `account.move.line`, or be defined in the custom handler. We want to be able to group by any field that is searchable and has `_field_to_sql` implemented for it. For example, for consolidation, users might want to create a non-stored field related to `account_id.code` and group by it. After this commit, groupbys can be any searchable field for which `_field_to_sql` is defined, regardless of whether it is stored or not. task-4259552
The Documents app is easier to use on mobile devices, with clearer navigation, better action button display, and a more practical folder and file layout. Selecting records on mobile no longer causes an error, making the experience more reliable for users working from phones or tablets.
Original PR description
Changes: 1. On click chatter button, scrolldown to chatter so that we know what happens. 2. Don't show 'Folders' if a record is selected. 3. Properly show control action buttons. 4. Display folder/files into 2 columns, 3 columns if landscape on mobile. Task-4380904
Resolved issues and error corrections
The editor no longer errors when users remove formatting from styled links. This makes content editing smoother and prevents interruptions when cleaning up text formatting.
Original PR description
**Current behavior before PR:** - Clicking the Remove Format button to remove the style from an anchor tag caused a traceback error. **Desired behavior after PR is merged:** - Clicking the Remove Format button now successfully removes any applied styles from the selected text. task: 4427649
The rating display was showing an unwanted border around rating images because of an incorrect styling class. This fix removes that class so rating images appear as intended, improving the visual polish of customer-facing rating views.
Original PR description
Related Ticket: https://www.odoo.com/odoo/my-tasks/4482430 Signing up the CLA [FIX] rating: Extra border line on the rating image The 'btn' class was incorrectly applied to the rating label in `rating_templates.xml`, which affected the styling, making extra border line displaying on the rating image. Removing this class restores the expected appearance. 
The point of sale now handles currencies that do not use decimal places without failing during product sales. This prevents checkout errors for businesses operating in zero-decimal currencies and keeps sales processing reliable.
Original PR description
Before this commit, if a currency had zero decimal places, it would cause an error when selling products. opw-4543742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where copying a link from tools like Visual Studio Code and pasting it into Odoo's editor did not create a proper link. The editor now recognizes single valid links even when they are pasted as HTML content, making link insertion more reliable for users.
Original PR description
**Problem**: When a link is copied with HTML content, `handlePasteText` is called after `handlePasteHtml`, and the content type is `text/html`. **Solution**: Extract the pasted content as text inside `handlePasteHtml` and check if it is a single valid link. If so, skip further processing. **Steps to Reproduce**: 1. Copy a link from Visual Studio Code. 2. Paste the link into the editor. 3. Observe that the link is not created. opw-4460599 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a display issue where customer-facing Chatter comments could disappear while scrolling when a portal page used the sidebar header layout. Users previewing documents such as sales orders should now have a steadier, more reliable page experience.
Original PR description
Since [1] ensures that the Chatter is positioned under the page header, the introduction of the new "sidebar" header template caused misplacement when scrolling. This commit adds a check to avoid applying padding when the header is a sidebar (o_header_sidebar), preventing unintended scrolling behavior in the sidebar layout. Steps to reproduce: - Install the Sales module. - On a sales order, add some comments in the Chatter. - Click on Preview. - Edit the header template and select the last option, "Sidebar". - Save the changes. - Scroll down and observe that the Chatter disappears. opw-4515419 [1]: https://github.com/odoo/odoo/commit/368eb78a9cedfce0802b64fd2782e1c018541e40
Point of Sale now loads only categories that contain products, instead of showing every configured category. This keeps product screens and self-order menus cleaner and easier for staff and customers to navigate.
Original PR description
Before this commit: ==== - All POS categories were being loaded, even if they had no associated products. After this commit: ==== - Only categories linked to products are loaded. Task-4517979
This fixes an issue in the HTML editor where converting certain paragraph-like content into a paragraph could remove the intended structure, especially inside list items. The change keeps the paragraph tag in place, helping edited content retain the correct layout and appearance.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: When converting paragraph related elements (other than the `<p>` tag itself) to a `<p>` tag, the tag would be unwrapped. Desired behavior after PR is merged: The tag is now converted directly to a `<p>` tag without unwrapping it. task-4488784 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents archived products from being shown again on the Point of Sale product screen when loading a previously paid order that used them. It helps keep sales screens clean and aligned with current product availability.
Original PR description
Before this commit, when a product used in a paid order was archived, loading the paid order would cause the product to appear on the product screen. opw-4493666 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The EAS field label has been widened so longer electronic invoicing codes are easier to read. This improves the form layout and reduces confusion when users review or enter these values.
Original PR description
Let's increase the label size since the EAS are quite long. task-no Before:  After: 
This fixes a visual issue in the HTML editor where collaborator avatars could briefly disappear and reappear during live editing. Users working together in the same document now get a smoother, less distracting editing experience.
Original PR description
### Steps to reproduce: - Open the same document in two tabs. - Press Enter multiple times in one tab. - Observe the avatar flickers on the other tab with each Enter press. ### Description of the issue/feature this PR addresses: - `refreshSelection` replaced `this.avatarOverlay` children and re-appended the avatar element in `drawPeerAvatar`, causing flicker. ### Desired behavior after PR is merged: - The avatar no longer flickers when pressing Enter. task-4367144
This fixes an error that could appear when exporting products and selecting related stock information from the export dialog. Users can now export these nested product details without the list filter being incorrectly applied to unrelated data.
Original PR description
**Steps to reproduce**
1. Have Stock and Sales installed.
2. Go to the Sales list view of products, have more than 1 page of products.
3. Select all the products on the current page by checking the checkbox
on the first line. After that, click on "Select all" to select all
products.
4. Actions > Export
5. Select "Products" (`product_variant_ids`) and then "Products/Stock Quant"
(`stock_quant_ids`).
`ValueError: Invalid field stock.quant.sale_ok in leaf ('sale_ok', '=', True)`
**Change**
Only use the domain of the list view to filter fields when the export dialog
is opened. The domain should only be used for that and not when `getExportFields`
is called when clicking on one of the children fields of the root model.
opw-4408457Fixes an issue where Italian invoices could fail to print or send after the tax agency submission option was initially skipped. This helps users complete invoice downloads and later submissions without encountering an error.
Original PR description
This error occurs when an invoice is not initially sent to the tax agency, but we later attempt to print it and send it to the agency. Steps to reproduce: --- - Install ``l10n_it_edi`` module - Switch to ``IT Company`` - Create Customers Invoice > ``Confirm`` > ``Print & Send`` - Disable ``Send to Tax Agency`` > ``Print & Send`` - Now again ``Print & Send`` and ``Print & Send`` Traceback: --- ``KeyError: 'l10n_it_edi_values'`` This commit resolves the error by checking that ``l10n_it_edi_values`` is present in ``move_data``. sentry-6191573767 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an issue where refreshing a form after moving between records could reload the originally opened record instead of the current one. This keeps users on the correct record and avoids confusion or accidental work on the wrong item.
Original PR description
From a list or kanban view with several records, open a record in form view. Then use the pager to navigate to another record. From this point, execute the `soft_reload` client action (e.g. call a python method from a view button, which returns that client action). This client action is supposed to reload the current controller (the form view in this case), without reloading the whole webclient. Before this commit, the form was indeed reloaded, but the reloaded record was the one we opened first, not the one we reached after navigating with the pager. With this commit, the correct record is reloaded. Issue spotted for task-3935688 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates report links in periodic digest emails so they use the current Odoo URL format. Users clicking “Open Report” links from digest emails will no longer hit missing-action errors across affected apps such as CRM, Sales, Accounting, Projects, Recruitment, Point of Sale, and eCommerce.
Original PR description
Some URLs in the digest emails are currently broken due to an outdated URL format. ### Steps to reproduce * Install `digest` and `crm` modules * Go to Settings > Technical > Digest Emails * Select the "Your Odoo Periodic Digest" digest and send it * Check the sent email and click on any of the "Open Email" links You should encounter an error indicating that the action does not exist. Although the reproduction steps use the `crm` module as an example, this issue occurs with all the modules listed in the title. ### Cause The "Open Report" URLs were not updated to account for the new URL format. opw-4405288 opw-4502625
This fixes an issue where a delivery removed from a wave after its quantity was set to zero was left without a new wave assignment. Affected warehouse operations now remain properly grouped, helping teams avoid lost or unmanaged delivery work during wave validation.
Original PR description
Steps to reproduce the bug:
- Enable the multi-step route.
- Go to the Delivery Operation Type:
- Enable "Automatic Batches". - Enable "Wave Grouping". - Product Category: All
- Create two storable products: "P1" and "P2".
- Create a first delivery:
- One unit of P1.
- Mark it as "To Do" → a wave transfer is created.
- Create a second delivery:
- One unit of P2.
- Mark it as "To Do" → it is added to the first wave.
- Go to the wave:
- Update the quantity of P2 to 0.
- Validate the wave
Problem:
The picking of P2 is detached but not linked to a new wave.
opw-4444263This fixes a Point of Sale loyalty issue where loyalty cards could still receive an expiration date even though that behavior was meant to be disabled. Businesses using POS loyalty programs will see card validity handled consistently with the intended loyalty program settings.
Original PR description
In commit https://github.com/odoo/odoo/commit/837e67e82d4cf662b2dcd5d5750253dbc080bd96 we prevent setting expiration date on `loyalty` type programs for UI and wanted to ensure expiration date is not set on loyalty cards. This PR remove a line which is setting expiration date on `loyalty` type program in POS which missed during forward port PR https://github.com/odoo/odoo/pull/183044
Cancelling POS order lines now sends the required information to produce a proper kitchen ticket instead of an empty or incomplete receipt. This helps staff clearly see cancelled items and avoids confusion during order preparation.
Original PR description
steps to reproduce: === - open POS - make an order - click on order - open this order - delete order lines - click on order (negatives qty) Issue: === - insufficient data to display in receipt fixed: === - configured data required to print task: 4507218
This fix prevents errors when exporting selected products that use inherited property fields. It helps users complete product exports reliably without encountering a traceback.
Original PR description
Try to export one selected product.product generate a traceback due to the `_get_property_fields` that doesn't manage inherited properties. opw-4438752
Swiss invoice PDFs generated without payment details no longer include an unexpected blank page at the end. The invoice report is now correctly identified so the Swiss QR code handling works as intended.
Original PR description
### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create a new invoice with a Swiss customer - Confirm - In the actions, select "PDF without payments" - The generated PDF has a blank page at the end ### Cause: The report "account.report_invoice" does not have a field `is_invoice_report` set to `True`. When generating an invoice with Swiss localization. It reads the field `is_invoice_report` to add or not the QR code. The bug appears after this [commit](https://github.com/odoo/odoo/commit/bb60952c944db27d71d7fe32ead2dff05c3fe922#diff-b6e108b605fbefba066e3b20f8e030ea78881bbed816f8ac5cb38e745c542739R50) which modified the `_is_invoice_report` method to use the field, but only added the field in "account_invoices". ### Solution: Set the field to True for the report. opw-4467250
Fixes a Point of Sale issue that could show an error when a user tried to change cashier and no cashier options were available. The cashier selection dialog now opens correctly, improving reliability during store operations.
Original PR description
Description of the issue/feature this PR addresses: - Fixed an issue where changing the cashier with no available cashiers caused a traceback due to an undefined `this.dialog` Replaced it with the correct `dialog` reference. ## step to reproduce - install `point of sale` - setup a new point_of_sale , as shown  - start session in that pos. - try to change the cashier 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
The web interface now keeps the database name clearly visible when debug mode and dark mode are both enabled. This improves readability for users and administrators working in dark mode.
Original PR description
Previously after activating debug mode and then dark mode, the letters of database name are not visible clearly. It is happening because in new bootstrap version we are having a color attribute in mark tag which was previously not there. After this commit the database name will be clearly visible in dark mode. Task-4389154 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Discuss now displays exact message times using the browser's locale settings, so users see either 12-hour or 24-hour time based on their personal environment. This makes chat timestamps feel more familiar and avoids layout issues caused by AM/PM labels in compact message views.
Original PR description
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so…
Exact time are shown in discuss since version 18.0. Format was always 24-hour, which is ok for some users but not for others. This commit uses time format of luxon browser based on user locale, so that this is the expected format as the user is used to see in all browser apps. Note that we don't choose DB date format, because discuss app are used by many other users and the custom format on whole DB might make some users happy but others not. In particular, the default en_US language time format in Odoo uses 24-hour when lots of english americans are used and prefer 12-hour format. Using the locale format of browser, which tend to rely on OS settings, makes (almost) everyone happy. Also the extra AM/PM could lead to size issue on small squashed messages, this commit also fixes it. opw-4482727 Before / After  
The translation button is now visible again when editing report source files in Studio. This lets users translate report field labels as expected, avoiding confusion and restoring an important workflow for multilingual businesses.
Original PR description
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- 1. Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones 2. On the left hand side - in the studio editor select "Edit Source" 3. On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402
The contract details screen now shows the labels in the part-time section when Belgian payroll group S is installed. This fixes a display issue that could make contract information harder for HR and payroll users to read.
Original PR description
Steps to reproduce: - Install the l10n_be_hr_payroll_group_s module. - Open any contract in employee or payroll. - Check the part-time section under the Details tab. Issue: - Labels do not display. Reason: - The view is inherited in both hr_payroll and l10n_be_hr_payroll_group_s modules. - In hr_payroll, the fields are not grouped, while in l10n_be_hr_payroll_group_s, they are. Solution: - Change the position of the "group_s_code" in l10n_be_hr_payroll_group_s module from inside to after task-4440190
This fix ensures Italian Point of Sale orders correctly handle products whose prices exclude tax. It improves the accuracy of receipts, order totals, and related accounting documents when tax is added at checkout.
This fixes an incorrect connection mapping in the Shopee sales integration that was introduced shortly before the module was merged. The correction helps ensure Shopee data is interpreted properly, reducing the risk of failed or inaccurate sales synchronization.
Original PR description
Bug introduced in the last changes before merging the module that wasn't caught
Digest emails now use the updated link format so users can open reports directly from their emails without hitting missing-action errors. This restores expected access to report links across affected business apps such as accounting, helpdesk, and website sales dashboards.
Original PR description
Some URLs in the digest emails are currently broken due to an outdated URL format. ### Steps to reproduce * Install `digest` and `crm` modules * Go to Settings > Technical > Digest Emails * Select the "Your Odoo Periodic Digest" digest and send it * Check the sent email and click on any of the "Open Email" links You should encounter an error indicating that the action does not exist. Although the reproduction steps use the `crm` module as an example, this issue occurs with all the modules listed in the title. ### Cause The "Open Report" URLs were not updated to account for the new URL format. opw-4405288 opw-4502625
The update removes date-dependent information from a Mexican electronic invoicing test file so automated checks no longer fail when the calendar changes. This keeps validation reliable without changing customer-facing behavior.
Original PR description
Now we move to february, the test is failing on runbot... See (similar): https://github.com/odoo/enterprise/commit/e29b2265fe60e90443d753558e6c9a071ee23d33 task-no
Miscellaneous changes
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
Original PR description
In case of manipulations with new records, ensure the computation of bank_partner_id field is well recomputed if company is changed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195962
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
Original PR description
[FIX] l10n_hu_edi: price include tax Price unit was not properly calculated: * Didn't remove the discount. * Didn't take into account price included taxes. We also removed a test use case that didn't make sense. Task-id: 4236755 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190095
steps to reproduce: -Create a new time off type. -Set the approval radio button to either "By Time Off Officer" or "By Employee's Approver and Time Off Officer." -Leave the "Notified Time Off Officer" field empty. -Try to create a new allocation for the newly created time off type. -Notice that an activity is created for the user who created the allocation. cause: When the "Notified Time Off Officer" field is left empty, no activity or email should be created. solution: Remove sel
Original PR description
steps to reproduce: -Create a new time off type. -Set the approval radio button to either "By Time Off Officer" or "By Employee's Approver and Time Off Officer." -Leave the "Notified Time Off Officer" field empty. -Try to create a new allocation for the newly created time off type. -Notice that an activity is created for the user who created the allocation. cause: When the "Notified Time Off Officer" field is left empty, no activity or email should be created. solution: Remove self.env.user.ids to prevent the creation of an activity for the user. task-4351747 Forward-Port-Of: odoo/odoo#189407
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Original PR description
On a server with low activity, the log is bloated with messages containing `[...] Closed 0 connections`. It is only useful to know if a connection was closed, so we skip logging otherwise. 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#196012
Steps to reproduce: - In V17.0 drag and drop an "Image Gallery" block into the page. - Upgrade to 18.0 - Click on the last "Image Gallery" indicator and then quickly on the first one. - Traceback: "TypeError: Cannot read properties of null (reading 'classList') at Carousel._setActiveIndicatorElement ..." This issue is caused by the front-end code of the image gallery, which updates the active indicator during a slide event. When the crash happens, it cannot find the active slide in the
Original PR description
Steps to reproduce: - In V17.0 drag and drop an "Image Gallery" block into the page. - Upgrade to 18.0 - Click on the last "Image Gallery" indicator and then quickly on the first one. - Traceback: "TypeError: Cannot read properties of null (reading 'classList') at Carousel._setActiveIndicatorElement ..." This issue is caused by the front-end code of the image gallery, which updates the active indicator during a slide event. When the crash happens, it cannot find the active slide in the DOM. After investigation, everything already works with Bootstrap, and the purpose of this code remains unclear. However, in the stable version, we are not taking any risks and will not modify it. In this commit, we simply added a return; in case the active slide is not found. opw-4519455 Forward-Port-Of: odoo/odoo#195606
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test
Original PR description
Since commit [1], the test "snippets_all_drag_and_drop" is failing randomly on the runbot. This is due to the fact that it is now possible to drop an "inner snippet" next to the "phone number" in the "header". Since the "phone number" is in the middle of the "header" (horizontally), its drop zone overlaps with the one of the "#wrap" during the test. As a result, "inner snippet" is being dropped in the "header" instead of the "#wrap". This happens because the "drag_and_drop" function in the test by default drops at the middle and top of the drop zones. To avoid this kind of situation, in this commit, we add a step at the beginning of the test to hide the header. [1]: https://github.com/odoo/odoo/commit/e0c16bb9a90dfb378b75e0de059e71f0aebd84fb opw-4494945 Forward-Port-Of: odoo/odoo#195996 Forward-Port-Of: odoo/odoo#195554
[FIX] survey: fix final leaderboard layout - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the question correctly - On the survey manager, go to the end of the survey (Final leaderboard) The stats only occupies a small portion of the width and the button are very cl
Original PR description
[FIX] survey: fix final leaderboard layout - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple…
[FIX] survey: fix final leaderboard layout - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the question correctly - On the survey manager, go to the end of the survey (Final leaderboard) The stats only occupies a small portion of the width and the button are very close to the title. We solve the problem by enlarging the stats like the previous result screens to get a layout similar as in v16.0. [FIX] documents: fix close buttons - Install survey - Create a survey “Live Session” - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the question correctly - On the survey manager, go to the end of the survey (Final leaderboard) - Click on the "Close" button Nothing happens while it should close the session and get back to the survey form. Actually, the code was closing the session but failed to get back to the survey as it was using "window.history.back()" and the button "create session" launches the session in a new tab that has no history as all the survey happens on the same URL. We solve the problem by reloading the page instead. As the session is closed, the page then displays "Thank you". We change slightly the tour as it expects that at the end, the close button leads to the survey back-end form (as it checks the presence of the button "Create Session" which is the action "action_start_session"). But as the session is started in a new tab, we have decided that it is better to display the final "Thank you" screen rather than returning to the back-end survey form as this is meant to be displayed in public. [FIX] documents: fix infinite line when max score is 0 How to reproduce: - Create a live survey - Add a “Single Line Text Box” and check “Save as user nickname” - Add a second question (ex.: multiple choice with 1 correct, score: 1) - Click on “Create Live Session” - Join the session with another browser - Answer the wrong answer to the question At the end of the survey, the score bar size is very big (multiple time of the screen width). We solve the problem by avoiding dividing by 0. Task-4381603 Forward-Port-Of: odoo/odoo#195706 Forward-Port-Of: odoo/odoo#190442
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 --- I confirm I have si
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195468
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have s
Original PR description
At two different places, we try to determine if the value of an html field is empty. To do so, we create a node on the fly and set its innerHTML to that value. Then, we check if the element has a non-empty innerText. However, this doesn't work as expected if the given value is a text instead of a markuped html. This commit fixes the issue. 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#196036 Forward-Port-Of: odoo/odoo#195909
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Original PR description
After commit ddda5d4a2623d03699d5cb6860d5c984807b6e3d public users were allowed to tokenize their payments with the exception of donation the tokenize field was forced to be False. However Stripe threw an error when the received intent was different than the one on the frontend. Fix: Hide option to tokenize for unlogged in users for donations. opw-4389881 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195001
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange meth
Original PR description
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from…
Currently, a traceback is occurring when the user tries to create a new put-away record and remove the `location_in_id`. To reproduce this issue: 1) Install Inventory 2) Enable multi-step routes from inventory settings 3) Create a new putaway rules record from inventory configuration 4) Remove the `when product arrives in` value Error:- ``` TypeError: startswith first arg must be str or a tuple of str, not bool ``` When the user removes the `location_in_id`, an onchange method `_onchange_location_in` triggers. https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/product_strategy.py#L80-L83 We get the `loc_in` value as an empty recordset, because the user removed the `location_in_id` value. So it will lead to the above traceback from the below line https://github.com/odoo/odoo/blob/239d18c8689d38e11783716b7e14a5204daed98a/addons/stock/models/stock_location.py#L453-L455 sentry-6210564390 Forward-Port-Of: odoo/odoo#195555
There were problems reported on some invoices caused by rounding errors. This PR solves these problems, and adds more test cases to the precision unit tests. Moreover, handling special tax amount across different tax groups was not done correctly before this commit. Finally, this commit removes the method _aggregate_totals, and relies on accurate subtotals to always calculate the totals. Along with other refactoring and comments added to the code, this commit makes the code more clear an
Original PR description
There were problems reported on some invoices caused by rounding errors. This PR solves these problems, and adds more test cases to the precision unit tests. Moreover, handling special tax amount across different tax groups was not done correctly before this commit. Finally, this commit removes the method _aggregate_totals, and relies on accurate subtotals to always calculate the totals. Along with other refactoring and comments added to the code, this commit makes the code more clear and sound. task-4464702 task-4509607 X-original-commit: https://github.com/odoo-dev/odoo/commit/88f0254f8db263c75d972520226fa17fdef1c96b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194813
For my friends at tech support Exceptions in RPC are handled and a Response is returned directly. It is a different behaviour than jsonrpc where the exception is raised and the dispatcher wraps it is a Response after logging the exception. The xmlrpc code should also raise an exception so that it can be handled in http.py. Adding here a way to detect if a Response was already generated for an exception in the exception handler of HTTP. Related: #193208 Forward-Port-Of: odoo/odoo#194467 Fo
Original PR description
For my friends at tech support Exceptions in RPC are handled and a Response is returned directly. It is a different behaviour than jsonrpc where the exception is raised and the dispatcher wraps it is a Response after logging the exception. The xmlrpc code should also raise an exception so that it can be handled in http.py. Adding here a way to detect if a Response was already generated for an exception in the exception handler of HTTP. Related: #193208 Forward-Port-Of: odoo/odoo#194467 Forward-Port-Of: odoo/odoo#193421
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any other
Original PR description
Description of the issue/feature this PR addresses: Fix a traceback with the partner merging wizard. Current behavior before PR: Currently, the partner merging wizard doesn't support fields of type `reference`, because this type of field is never used by Odoo on model `res.partner`. This will never happend in native Odoo, but some external addons can trigger this traceback. Desired behavior after PR is merged: The traceback is fixed and reference fields are treated like any others field types. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195432
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#196104 Forward-Port-Of: odoo/odoo#194843
Original PR description
Revert changes from [commit] due to `m.facebook.com` using 'X-Frame-Options' header set to 'deny', which prevented iframe embedding across domains. META has now fixed this issue, so this PR restores the snippet's visibility on mobile devices. [commit]: https://github.com/odoo/odoo/commit/588f910da03d6284a57c2fab8fd042ef3169666f task-4507102 Forward-Port-Of: odoo/odoo#196104 Forward-Port-Of: odoo/odoo#194843
[opw-4421055](https://www.odoo.com/odoo/project.task/4504454) Forward-Port-Of: odoo/odoo#195786
Original PR description
[opw-4421055](https://www.odoo.com/odoo/project.task/4504454) Forward-Port-Of: odoo/odoo#195786
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n
Original PR description
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina -…
### Steps to reproduce the issue: 1. Create two Argentinian Companies 2. In _Accounting > Configuration > Settings_ select the following Fiscal Localization Package for both companies: _Argentina - Argentine Generic Chart of Accounts for Exempt Individuals_ 2. In _Accounting > Configuration > Accounting > Chart of Accounts_, duplicate an account and change its code to 6.0.0.00.020 3. Install _Argentina - Payment Withholdings_ 4. The following issue occurs: ### Explanation: In `_l10n_ar_withholding_post_init`, for each company, we will compare a previously created dict to the existing accounts. If an account already exists, the data is removed from the dict, and since it is created before we start looping through the Companies to make the comparison, any removed data is removed for the companies that follow as well. ### Fix reasoning: We will copy the original dict to keep a safe version of the data and only modify the copy during the comparison process. opw-4446501 Forward-Port-Of: odoo/odoo#194329
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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
Original PR description
Description of the issue/feature this PR addresses: I can't reproduce the error in Runbot, but the error is real. Try opening the project settings.   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#179592
This fix updates the taxes and the modelo 390 tax report Task: 4453629 Enterprise PR: https://github.com/odoo/enterprise/pull/77941 Forward-Port-Of: odoo/odoo#196064 Forward-Port-Of: odoo/odoo#195380
Original PR description
This fix updates the taxes and the modelo 390 tax report Task: 4453629 Enterprise PR: https://github.com/odoo/enterprise/pull/77941 Forward-Port-Of: odoo/odoo#196064 Forward-Port-Of: odoo/odoo#195380
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a wr
Original PR description
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On…
### Steps to reproduce: - Create a storable product tracked by lot/serial - Click on "On Hand" - Create a new line with 10 "On Hand Quantity" WITHOUT lot/serial - Go back to the product: The "On Hand" quantity is still at 0. - Click back to the "On Hand": the quantity of the line is back to 0. ### Cause of the issue: When a new line is created and the "On Hand Quantity" is edited from the `view_stock_quant_tree` view, we actually performs a create of the stock.quant followed by a write on the `inventory_quantity_auto_apply`. At this point the 'quantity' field of the new quant is not set and the `action_apply_inventory` of the `inventory_quantity_auto_apply` is expected to create and validate a move line in order to update our quant quantities here: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L230-L235 However, this steps will never be performed as we return the call before the `_apply_invetory` because our quant is set without lots: https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L447-L449 https://github.com/odoo/odoo/blob/e041e890b91e5bc515e1827683f073781788f253/addons/stock/models/stock_quant.py#L465-L477 ### Fix: Since the return value of the `action_apply_inventory` is only expected to be used in the `view_stock_quant_tree_editable` (Inventory adjustment ) where it is not possible to set the `inventory_quantity_auto_apply` inventory, we skip this return in case the calls has been performed from setting the `inventory_quantity_auto_apply` and proceed with the `_apply_inventory`. opw-4428050 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194068
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet
Original PR description
Since [1] and later [2], the activation logic when removing a snippet relied on the `o_snippet_invisible` class to determine whether to activate the previous or next sibling. However, additional classes like `o_snippet_desktop_invisible` and `o_snippet_mobile_invisible` were introduced, making it insufficient to rely solely on `o_snippet_invisible``. This commit ensures that the correct snippet is activated upon removal. Steps to reproduce: - Navigate to Web editor - Drop text snippet 1 - Drop text snippet 2 and hide it for desktop - Drop text snippet 3 - Remove text snippet 3 - Bug => text snippet 1 is not activated as expected [1]: https://github.com/odoo/odoo/commit/2cdd95f140b6ec5f3b95ee19bde2f281de21f337 [2]: https://github.com/odoo/odoo/commit/2de0ad7259993f654ca8d826f5430f78090a28c5 task-4531506 Forward-Port-Of: odoo/odoo#195941 Forward-Port-Of: odoo/odoo#195743
Steps: - Install `purchase` or any other model with analytic_mixin - Install `analytic` - Install `web_studio` - Enable analytic in configuration - Add a new approval on 'button_confirm' in `purchase.order` - Set a domain with analytic_distribution e.g - - e.g. ("order_line.analytic_distribution", "=", "Administrative") - Click on Refresh button - The refresh button preview shows x records - Create a new purchase.order - Add analytic on op
Original PR description
Steps: - Install `purchase` or any other model with analytic_mixin - Install `analytic` - Install `web_studio` - Enable analytic in configuration - Add a new approval on 'button_confirm' in…
Steps:
- Install `purchase` or any other model with analytic_mixin
- Install `analytic`
- Install `web_studio`
- Enable analytic in configuration
- Add a new approval on 'button_confirm' in `purchase.order`
- Set a domain with analytic_distribution e.g
- - e.g. ("order_line.analytic_distribution", "=", "Administrative")
- Click on Refresh button
- The refresh button preview shows x records
- Create a new purchase.order
- Add analytic on optional column
- Add a new product with analytic_distribution Administrative
- Try to use `button_confirm`
- Approval is not working while the refresh shows record is available
The json fields, in particular the `analytic_distribution` fields, are not designed to be searched via a `filtered_domain` (which is what studio approval uses to check whether or not a button can be used by the current user), this is currently a technical limitation.
To avoid any future problems, this commit prevents users from using a json field to search on them, since this is not supported.
opw-4416646
Forward-Port-Of: odoo/odoo#195916
Forward-Port-Of: odoo/odoo#195765Issue Before This Commit: ============================ A traceback occurs when attempting to sort pickings by zip if any picking has a False or empty zip value. Steps to Reproduce: ===================== 1. Install the stock_fleet module. 2. Navigate to Batch Transfer in the Stock module under the Operations tab. 3. Create a new batch and add pickings, ensuring some have a zip value while others do not. 4. Save the batch, which triggers a traceback error: TypeError: '<' not
Original PR description
Issue Before This Commit: ============================ A traceback occurs when attempting to sort pickings by zip if any picking has a False or empty zip value. Steps to Reproduce: ===================== 1. Install the stock_fleet module. 2. Navigate to Batch Transfer in the Stock module under the Operations tab. 3. Create a new batch and add pickings, ensuring some have a zip value while others do not. 4. Save the batch, which triggers a traceback error: TypeError: '<' not supported between instances of 'bool' and 'str'. With This Commit: ===================== The issue occurred because sorting directly on the zip caused an error when the zip was False. this fix ensures that sorting treats zip as an empty string () when it is False, preventing the error. task - [4535113](https://www.odoo.com/odoo/my-tasks/4535113) Forward-Port-Of: odoo/odoo#195957
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c
Original PR description
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id.…
When opening a new (virtual) 'stock.move' to create a 'stock.move.line' and directly validating the picking afterward, the created 'stock.move.line' was not directly associated to the picking_id. This happens because the virtual record does not have the picking_id because this field is not present on the tree view. One impact of this issue has is that the stock.move.line created doesn't show on the Delivery Slip report. ## HOW TO REPRODUCE https://github.com/odoo/odoo/assets/29302288/5c17e601-4d67-4515-8d5a-286460b9a9cd - On TODO picking, do the following steps WITHOUT CLICKING ON SAVE - Operations -> Add a line: (demand 0, quantity 0) - Click on 'Open Move' button (fa-list icon) - Popup 'Open: Stock move': Add a line - Popup 'Add line: <product>': click on 'New' - Popup 'Create Move Line': click on 'Save & Close' - Popup 'Open: Stock move': set Quantity = 1, click on 'Save & Close' - Validate picking -> Create backorder => Check picking move_line_ids = EMPTY ## Solution Add picking_id field on view_picking_form -> move_ids_without_package tree view (Operations list). OPW-3974109 Forward-Port-Of: odoo/odoo#171766
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195496 Forward-Port-Of: odoo/odoo#194500
Original PR description
When creating a new database or activating a new currency, the first rate fetched will often be set only starting "today". This can lead to issues when creating invoices in the past, especially if the conversion rate is very different from 1. Instead of only using a fallback on 1, we also fallback on the oldest rate in the database if available. Forward-Port-Of: odoo/odoo#195496 Forward-Port-Of: odoo/odoo#194500
**[FIX] account: Account Journal Late Bills Count** This fix mitigates an issue when a line of a Bill is paid but appears in the late Bills count in the dashboard. **Steps to reproduce:** 1. Create a payment term to pay in installemts. 2. Create a bill an X amount back in the past to have one installment as late. 3 - Pay the late installment **Issue**: The paid installment will still be counted as late in the dashboard. **Fix**: filter out line with residual amount different than
Original PR description
**[FIX] account: Account Journal Late Bills Count** This fix mitigates an issue when a line of a Bill is paid but appears in the late Bills count in the dashboard. **Steps to reproduce:** 1. Create a payment term to pay in installemts. 2. Create a bill an X amount back in the past to have one installment as late. 3 - Pay the late installment **Issue**: The paid installment will still be counted as late in the dashboard. **Fix**: filter out line with residual amount different than zero. _opw-4327227_ --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191600
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill
Original PR description
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product…
- Create a customer invoice with **Product A** priced at 1000 and a quantity of 2. - Add a line with **Product A** at the same price but with a quantity of -1. Confirm the invoice. In the product margin report, the `total_margin` for **Product A** is shown as 3000, even though we only sold for 1000 (as shown in the balance report). A similar issue occurs when a line on an invoice has a negative price, for instance, due to a discount on a sales order. Similarly: - Create a vendor bill with **Product B**, with a cost of 1000 and a quantity of 2. - Add a line with **Product B**, with the same cost but a quantity of -1. In the product margin report, the `total_cost` for **Product B** is shown as 3000, even though we only bought for 1000. In `_compute_product_margin_fields_values`, the SQL query takes the absolute value of the balance of every account move line to compute `total`. This means negative values become positive and are added to the positive values instead of canceling each other out, creating the above issues. As a result, the product margin report does not align with the balance sheet. The absolute value is used because `total` is used to compute statistics related to both `out_invoice` (e.g., turnover) and `in_invoice` (e.g., total cost), which both need to be positive. However, the same result can be achieved by inverting the sign for `out_invoice`. opw-4342691 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193440
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field
Original PR description
Steps to Reproduce: - Go to the website editor. - Add a form to the page. - Select the form and change the default action from "Send an email" to "Create an opportunity." - Select the "Subject" field. - Set the visibility condition of the "Subject" field to "visible only if the phone number is set." - Since this is a mandatory field, define a default value for the "Subject" field. - Save the changes. - Fill out the form but leave the phone number field empty so that the "Subject" field does not appear. - Attempt to submit the form. - Bug: the form is not sent and there is an error message. The error occurs preventing the record from being created because all required fields are not present, we should use the default value as it has been provided. This commit prevents adding the "disabled" attribute to inputs that are required for models. opw-4447039 Forward-Port-Of: odoo/odoo#195660 Forward-Port-Of: odoo/odoo#194902
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent
Original PR description
Steps to reproduce: - Edit a page - open "Optimize SEO" dialog - Add a tag with a parenthesis. eg. "Webinar Tools (OBS, YouTube)" - Save - Reload the page - Reopen the "Optimize SEO" dialog - ... crash Since [1], the application crashes because keywords are dynamically used in a regular expression, and special characters (e.g., parentheses) are not properly escaped. We address the keywords issues by escaping control characters before using them in the regular expression to prevent crashes. [1]: https://github.com/odoo/odoo/commit/ac55f2bb113ecf7c774fe6e96d28e716184a97d1#diff-b51336c1ad97255bfb3646f013327eca1904ca194078f4ce671e517096233c58 task-4420262 Forward-Port-Of: odoo/odoo#195940 Forward-Port-Of: odoo/odoo#194976
Steps to reproduce: - Open any editable project from portal - Open any task - Create a task using Form New button. - Give the changes and save Issue: - A validation error Reason: - The timesheets ids field in project sharing view has readonly attruibute which it shouldn't have. - Due to this changes are fetched and context in evaluated this field becomes writable. Fix: - Remove the readonly attribute as timesheet_ids is already a readonly field in portal side. task
Original PR description
Steps to reproduce: - Open any editable project from portal - Open any task - Create a task using Form New button. - Give the changes and save Issue: - A validation error Reason: - The timesheets ids field in project sharing view has readonly attruibute which it shouldn't have. - Due to this changes are fetched and context in evaluated this field becomes writable. Fix: - Remove the readonly attribute as timesheet_ids is already a readonly field in portal side. task- 4494040 Forward-Port-Of: odoo/odoo#194465
Steps: - Install E-learning app and E-commerce app. - Go to E-commerce setting and make Ecommerce access to logged in user. - Try to add a course with on payment setting with out login. Issue: User can't able to add course in cart. Cause: - No specific condition to allow adding course type product into cart. Fix: - Add condition to allow course product add into account even with Ecommerce access is `logged in user`. opw-4384616 Forward-Port-Of: odoo/odoo#191103
Original PR description
Steps: - Install E-learning app and E-commerce app. - Go to E-commerce setting and make Ecommerce access to logged in user. - Try to add a course with on payment setting with out login. Issue: User can't able to add course in cart. Cause: - No specific condition to allow adding course type product into cart. Fix: - Add condition to allow course product add into account even with Ecommerce access is `logged in user`. opw-4384616 Forward-Port-Of: odoo/odoo#191103
**Steps to Reproduce:** - Navigate to /shop . - Open editor mode and select a product. - Use the reorder widget from the editor panel to change the product's position. - Notice the product jumps 2 positions instead of 1 when reordered. **Issue:** - Two products, 'Warranty' and 'Chair Floor Protection', have the same website_sequence. This causes the reorder logic to malfunction, making products jump 2 positions when one is placed in front or behind these two. **Fix:** - Updated the w
Original PR description
**Steps to Reproduce:** - Navigate to /shop . - Open editor mode and select a product. - Use the reorder widget from the editor panel to change the product's position. - Notice the product jumps 2 positions instead of 1 when reordered. **Issue:** - Two products, 'Warranty' and 'Chair Floor Protection', have the same website_sequence. This causes the reorder logic to malfunction, making products jump 2 positions when one is placed in front or behind these two. **Fix:** - Updated the website_sequence of conflicting products to ensure all products have unique values. **Affected Versions:** 16.0~master opw-4150099 Forward-Port-Of: odoo/odoo#195880 Forward-Port-Of: odoo/odoo#191297
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from
Original PR description
Since [1], the `_enumerate_pages` method could include duplicate URLs in the sitemap due to bound method instances being treated as distinct functions. This issue became observable from 17.4, where the effect is more noticeable. To fix this, `__func__` is used on `rule.endpoint.func`, ensuring that the same function is not processed multiple times, preventing redundant entries in the sitemap. This fix is applied in 16.0 as the issue originates there. Steps to reproduce (observable from 17.4): - Install website_sale module - Go to /sitemap.xml - Observe that all the products and category urls are duplicated. [1]: https://github.com/odoo/odoo/commit/1b52b00d2aa96b9360d50a0f0960f1febb5e607e opw-4420398 task-4074719 Forward-Port-Of: odoo/odoo#195949
Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527
Original PR description
Mod349 tax report in Spanish localization report the total number of intra-community operations. This counter however, does not take into account paid invoices Steps to reproduce: - With an ES company setup - Create an invoice to an EU partner - Register payment for the invoice - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) Issue: Total number of intra-community operations is 0 opw-4403287 Forward-Port-Of: odoo/enterprise#77527 Forward-Port-Of: odoo/enterprise#77238
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when tr
Original PR description
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the…
### Steps to reproduce: - Install 'l10n_es' and switch to Spanish company - Go in Accounting > Tax Report and select the report "Mod 390" - Click on the button to download the BOE - Fill the information in the wizard - Click on generate BOE - An error pops up ### Cause: The report Mod 390 is composed of several sections. The method `dispatch_report_action` is called on the first section instead of the entire report. As the first section has no custom handler, an error is raised when trying to read on it. When exporting a report with sections, `dispatch_report_action` is called on the first section, it detects that this is a section and calls the same method on the parent report. This commit (https://github.com/odoo/enterprise/commit/8213813e68f02d88934285a44a3413505f6ca187) removed the line getting the options for the parent report call to keep the specific options of each section. Specifically, the "report_id" key in the options is the id of the first section, causing the method to be called on the section. ### Solution: Setting the key "report_id" in the options of the parent report. This way the fix of the commit introducing the bug is still active. opw-4501376 Forward-Port-Of: odoo/enterprise#78185
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 F
Original PR description
If "Unfold All" is not selected and "Group by Account" is, printing the Depreciation Schedule won't print the unfolded lines. Furthermore, if you unfold some lines and then refresh, all the lines are refolded. This behaviour is different than the other reports, where the lines you unfold are printed and remembered during a refresh. The fix is to mark the parent lines generated by `group_by_account` as unfolded if the line is present in `options['unfolded_lines']`. task-4507580 Forward-Port-Of: odoo/enterprise#78074
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 Forward-Port-Of: odoo/ente
Original PR description
Before this commit, depositing money for a customer with a zero balance could result in the creation of an empty order upon refreshing the browser. This issue arose because empty orders without payments were being synchronized, leading to unintended empty orders in the system. This commit addresses the problem by ensuring that empty orders without payments are not synchronized and prevents the creation of such empty orders during the deposit process. opw-4483049 Forward-Port-Of: odoo/enterprise#78085
Before this commit, if a user was an attendee of an event linked to an appointment type, but did not have access to the appointment (not part of the staff_user_ids), an access error would occur when trying to sync their calendar with Google or Microsoft. This error happened inside the `_get_customer_description` function overridden in the appointment module. opw-4402859 Forward-Port-Of: odoo/enterprise#76113
Original PR description
Before this commit, if a user was an attendee of an event linked to an appointment type, but did not have access to the appointment (not part of the staff_user_ids), an access error would occur when trying to sync their calendar with Google or Microsoft. This error happened inside the `_get_customer_description` function overridden in the appointment module. opw-4402859 Forward-Port-Of: odoo/enterprise#76113
Steps to reproduce ================== - Install hr_timesheet - Use an android device - Click on a time field => A numeric virtual keyboard appears. This prevents us from entering the `:` character. Cause of the issue ================== The inputmode attribute is set to numeric Solution ======== Set the inputmode to it's default value: text. See also [float_time_field] --- [float_time_field]: https://github.com/odoo/odoo/commit/8b919ae51d7deb34169b7c6970964056ef2e
Original PR description
Steps to reproduce ================== - Install hr_timesheet - Use an android device - Click on a time field => A numeric virtual keyboard appears. This prevents us from entering the `:` character. Cause of the issue ================== The inputmode attribute is set to numeric Solution ======== Set the inputmode to it's default value: text. See also [float_time_field] --- [float_time_field]: https://github.com/odoo/odoo/commit/8b919ae51d7deb34169b7c6970964056ef2eb632 opw-4344083 Forward-Port-Of: odoo/enterprise#77339
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
Original PR description
- -i helpdesk - create company named in Arabic, Chinese or something - BUG: can't create alias -> can't install helpdesk opw-4420662 Forward-Port-Of: odoo/enterprise#76564
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
Original PR description
Problem ---------- With low values of Gross, the PAYE can be negative. The must be always positive or equals to 0 Objective ---------- Make the PAYE computation positive. Check the PAYE computation. Solution ---------- It will be now the maximum between the previous computation and 0. To be always >= 0. Order the Gross Taxable with the sequence number. PAYE computation is correct, check the task for more details. task-4255918 Forward-Port-Of: odoo/enterprise#76189
[This commit][1] changed the Sign action helper to onboard users. However, in doing so the text was put inside conditional `t-esc` attributes, causing it to not be translatable. This change fixes that by properly using text nodes. [1]: https://github.com/odoo/enterprise/commit/a5fc0b098c4a4b61d7ce7fd87180ed32dcb1f6f5 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78147
Original PR description
[This commit][1] changed the Sign action helper to onboard users. However, in doing so the text was put inside conditional `t-esc` attributes, causing it to not be translatable. This change fixes that by properly using text nodes. [1]: https://github.com/odoo/enterprise/commit/a5fc0b098c4a4b61d7ce7fd87180ed32dcb1f6f5 [opw-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#78147
Step: - Install colombian localisation and other localisation which is part of latam localisation and contains `Identification Type` field in checkout address for example Argentina. - Install Ecommerce app. - Set Argentina as country on company and in accounting settings. - Go to shop page. - Add an product in cart and goto checkout address page. - Try to change `Identification Type` field. Issue: - Traceback cannot find parentElement. Cause: - For setting visibility of colombian r
Original PR description
Step: - Install colombian localisation and other localisation which is part of latam localisation and contains `Identification Type` field in checkout address for example Argentina. - Install Ecommerce app. - Set Argentina as country on company and in accounting settings. - Go to shop page. - Add an product in cart and goto checkout address page. - Try to change `Identification Type` field. Issue: - Traceback cannot find parentElement. Cause: - For setting visibility of colombian related fields depending on `ID Type` field we forgot to check website country and selected country is columbian country and which cause issue when multiple latam related localisation install in same db. Fix: - Check colombian country before setting visibility for colombian related field. task-3628329 Forward-Port-Of: odoo/enterprise#77829
When creating a shift in planning from the top bar, the shift is created but does not appear. task-4446957 Forward-Port-Of: odoo/enterprise#76563
Original PR description
When creating a shift in planning from the top bar, the shift is created but does not appear. task-4446957 Forward-Port-Of: odoo/enterprise#76563
This commit updates the BOE mod390 export for 2024 Task: 4453629 Community PR: https://github.com/odoo/odoo/pull/195380 Forward-Port-Of: odoo/enterprise#78319 Forward-Port-Of: odoo/enterprise#77941
Original PR description
This commit updates the BOE mod390 export for 2024 Task: 4453629 Community PR: https://github.com/odoo/odoo/pull/195380 Forward-Port-Of: odoo/enterprise#78319 Forward-Port-Of: odoo/enterprise#77941
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Sen
Original PR description
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- *…
Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Send the request to terminal * Disconnect ethernet cable from the worldline terminal * Cancel the payment > Observation: After the timeout, two errors appear: 1: underfined:undefined (Bug) 2: Please check if your iot box is still connected. (Normal) Why the fix: ------------ This commit https://github.com/odoo/enterprise/commit/35a392c27e70ffb5f4a5d8ca32bf10c38d7f709c added one more error throwing other than `_onActionFail()` when sending requests. In our case since the error is due to a timeout, it will raise the `_onActionFail()` but also the `Promise.reject(e)`. We consider that the `_onActionFail()` is enough for all potential failure here. opw-4414175 Forward-Port-Of: odoo/enterprise#77606 Forward-Port-Of: odoo/enterprise#77555
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
Original PR description
Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892
The date field description was saying "customs number", but it should be "Customs Number Date". opw-4507567 Forward-Port-Of: odoo/enterprise#78252 Forward-Port-Of: odoo/enterprise#78165
Original PR description
The date field description was saying "customs number", but it should be "Customs Number Date". opw-4507567 Forward-Port-Of: odoo/enterprise#78252 Forward-Port-Of: odoo/enterprise#78165
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
Original PR description
Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;  - Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`). ___ **Issue:** Can't access `EC Sales List` o
Original PR description
**Steps to reproduce:** - Use the `NL Company`; - Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`): - Remove `l10n_nl.tax_report_rub_3bg_tag` and/or…
**Steps to reproduce:**
- Use the `NL Company`;
- Go to `External Identifiers` (via `Settings / Technical / Sequence & Identifiers`):
- Remove `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers;
- Try to access `EC Sales List` (via `Accounting / Reporting / Statement Reports`).
___
**Issue:**
Can't access `EC Sales List` of the Dutch company after deleting any or both of the `l10n_nl.tax_report_rub_3bg_tag` and/or `l10n_nl.tax_report_rub_3bg_tag` identifiers.
___
**Expected:**
Users should be able to access `EC Sales List` even when an identifier is deleted as there is a fallback.
___
**Cause:**
The fallback doesn't refer to the good tax options.
https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/models/account_sales_report.py#L82-L84
___
**Fix:**
Adapt the fallback references' module for retrieval as done for testing in: https://github.com/odoo/enterprise/blob/b2368558afdf922fdf04bdcfa8a98b4e690ddccd/l10n_nl_intrastat/tests/test_sales_report.py#L22-L24
___
opw-4425376
Forward-Port-Of: odoo/enterprise#78032
Forward-Port-Of: odoo/enterprise#76366### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab)
Original PR description
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries…
### The Issue: In `l10n_es` 347 serves to declare operations within Spain. 349 serves to declare operations in other EU countries https://github.com/odoo/enterprise/commit/9d79ed1128e76e8553a7cc39e790de4369345eec However, when creating an invoice for a Spanish customer, the field `Type for mod 349` is set despite the field `Available for Mod349` being False. ### How to Reproduce: 1. Install `l10n_es`. 2. Create an invoice for a Spanish customer and check that field 347 (AEAT tab) is set as regular operation. 3. Add both fields (type for 347 and type for 349) to the customer invoices list view using Studio. 4. Observe that for invoices where 347 is set, 349 is also set (E-Suministros/Supplies). ### Cause: In the `account_move` model of `l10n_es_reports`, the field `l10n_es_reports_mod349_invoice_type` was being set with a default value even when `Available for Mod349` is False. opw-4339292 Forward-Port-Of: odoo/enterprise#77699 Forward-Port-Of: odoo/enterprise#76042