Friday, April 12, 2024
35 changes
1 change
Resolved issues and error corrections
Fixes display issues in the calendar month view when opening the "+X more" popover. Users can now see properly styled events and scroll the popover when it contains many items or appears near the bottom of the page.
Original PR description
This commit fixes some problems in the calendar view: * event's style in the popover * the scroll when the popover is at the bottom of the view * the inner style of the popover to be able to scroll if too tall Steps to reproduce: * Open the Planning App * Go on the month view if not already in * Click on the "+X more" link => BUG the style and the popover can't be scroll. task-3833629 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
1 change
Resolved issues and error corrections
This update resolves an issue where changes to how IDs are stored in the Analytic Accounting module caused errors in features like project accounting and vendor bills. The fix ensures that the system correctly identifies and processes analytic accounts, preventing disruptions to financial reporting.
Original PR description
### Steps to reproduce issue: 1. Have Sales installed 2. Enable Analytic Accounting and create two Projects 3. Go into both Project Settings and add distinct Analytic Accounts 4. Create a Vendor Bill…
### Steps to reproduce issue: 1. Have Sales installed 2. Enable Analytic Accounting and create two Projects 3. Go into both Project Settings and add distinct Analytic Accounts 4. Create a Vendor Bill 5. Add a Product Line and put both accounts in the Analytic Distribution 6. Add an account in another column to one of the existing Analytic Distribution Lines 7. Go to Projects and open the Project Updates of the Project whose account was alone in the Analytic Distribution Line 8. You get the error: > invalid literal for int() with base 10: '[int],[int]' ### Explanation: With commit odoo@dc696c8ed4850a83b6af721002a90f2944891923, the way IDs are stored changed. They are now computed in a csv string. A part of the Analytic Accounting pipeline didn't get updated after that change, making a lot of the features not working properly. ### Suggested fix: - We must take into account the multiple analytic plans in any order possible in the ID search. - Because the amount of `account.move.line` can increase rapidly, the new ID search must be indexable. - We reworked the counting query to avoid `account.move` being counted multiple times. opw-3626619 Forward-Port-Of: odoo/odoo#147664
2 changes
Enhancements to existing features
Point of Sale now uses the standard customer edit form instead of custom screens in localized and settlement-related flows. This reduces maintenance overhead and gives users a more consistent experience when editing customer details.
Original PR description
In the corresponding comunity commit we replace the custom form view for editing `res.partner`records with the default `view` component from `web`. This allows us to remove a very large quantity of code, while providing for a smoother and more uniform user experience. In this commit we remove the overrides that we no longer need. https://github.com/odoo/odoo/pull/157881 Task: 3816230
Grid views now show more rows on low-resolution screens by reducing cell height, while keeping larger touch targets on mobile. Column highlighting has been removed and cell highlighting softened to make the view less visually distracting.
Original PR description
We were not seeing enough data on a low-res screen and the column highlight was too distracting (fp request). This PR reduces the cell height but keeps it big on mobile to ease finger selection. The column highlight is removed. Since we do not highlight the column anymore and the cell height is smaller. It also removes the cell highlight on add a line and the dates, thus we have to adapt the tests accordingly. The cell highlight is also slightly less gray. task-3751591 | Before | | :--: | | | | After | |  |
31 changes
Enhancements to existing features
Partner tax identification numbers (VAT IDs) are now included in the DateV export files for German General Ledger reporting. This addition ensures auditors can verify the validity of taxes applied to each transaction, meeting DATEV compliance requirements for customer and vendor CSV files.
Original PR description
Added partners tax id to DateV export. When exporting the DateV zip file from the General Ledger (in Germany namely), the Customers and Vendors CSV files miss the TAX ID of the partners. The auditors demand it to check the validity of the taxes applied to each transaction. VAT number should be added to the csv files (10th column) according to the DATEV documentation: https://developer.datev.de/datev/platform/de/dtvf/formate/debitoren_kreditoren task-3806969
This update improves invoice clarity for Indian businesses by adding a notice stating "Tax is Payable on Reverse Charge Basis" when reverse charge mechanism (RCM) taxes apply. This helps ensure customers immediately understand their tax obligations on invoices, improving compliance and reducing confusion.
Original PR description
In this PR =============== Added the line "Tax is Payable on Reverse Charge Basis" to the invoice print format for cases where reverse charge taxes are applied. task-3681686
This update improves the speed of spreadsheet cell interactions by eliminating redundant calculations. The system was checking the same condition twice when determining which cells are clickable, which was unnecessary. This fix reduces processing time by about 26-31%, making spreadsheets more responsive for users working with large numbers of cells.
Original PR description
In `SET_FILTER_MATCHING_CONDITION` we would call `SEE_RECORDS_PIVOT_VISIBLE` twice but since the function returns a boolean value, the second call was useless as we already knew the outcome. This revision alleviates a bit the cost of computing the cells' clickable actions. On A sheet with 480 visible cells, each of them matching the full condition, the time spent in `getClickableCells` goes from 19ms to 14 ms on Google Chrome and from 42ms to 29 ms on Firefox. 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
Resolved issues and error corrections
This fix resolves an error that occurred when posting tax closing entries for tax reports with multiple sections (such as Luxembourg tax reports). The issue was caused by a technical mismatch in how the system identified which report to update. The fix ensures tax closing entries can now be successfully posted without errors.
Original PR description
### Steps to reproduce * install `l10n_lu` * open the Tax Report * create a tax closing and attempt to post it You will be met with a traceback: `Trying to dispatch an action on a report not…
### Steps to reproduce * install `l10n_lu` * open the Tax Report * create a tax closing and attempt to post it You will be met with a traceback: `Trying to dispatch an action on a report not compatible with the provided options` ### Cause The bug occurs when attempting to post a tax closing for a tax report that includes sections. This issue originates from the behavior of the `get_options()` method, which, when invoked on a report containing sections, retrieves the `report_id` of a section instead of the main report's ID. This discrepancy occurs because of a feature in the code known as 'rerouting', which intentionally changes the `report_id` to that of the section. Consequently, when an action is dispatched to the main report using these options, an error is triggered due to the mismatch between the expected report ID and the one provided through the options. ### Fix To resolve this issue, the fix involves utilizing the `on_sections_source` parameter when dispatching the action for tax closing. By setting this parameter to true for composite reports, it effectively disables the rerouting behavior, ensuring that the action is directed to the correct report ID, thus avoiding the error. opw-3816175 opw-3833979
This fix corrects an unnecessary validation check when fetching CODA bank statements for Belgian companies. The system was incorrectly verifying company VAT/registry numbers at an early stage, when this verification is already performed later in the process. Removing this redundant check streamlines the CODA fetching workflow and prevents potential false validation failures.
Original PR description
### [FIX] l10n_be_codabox: condition while fetching CODAs The condition regarding the Company VAT/Registry number is wrong. There is no need to verify the verify at this point if there is a VAT/Company registry number as it is done later on in `_l10n_be_codabox_verify_prerequisites`.
This fix prevents kitchen staff from receiving duplicate orders when a waiter splits a bill after the meal has already been prepared. Previously, splitting an order would create a new order entry that appeared on the kitchen display, causing the same meal to potentially be prepared twice. Now, split orders no longer appear on the preparation display, ensuring the kitchen only prepares each meal once.
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. Community PR: https://github.com/odoo/odoo/pull/161498 opw-3809693
This update fixes a bug that prevented users from generating return labels when using FedEx International shipping. Previously, the system would crash when attempting to process return labels for international shipments. The fix corrects how the system handles package data to ensure return labels can be created successfully.
Original PR description
### Steps to reproduce: - Go to Settings > Shipping > Fedex > Fedex Shipping Methods - Click on "Fedex international" and unable: "Generate Return Label" - Create a new sale order for a product -…
### Steps to reproduce: - Go to Settings > Shipping > Fedex > Fedex Shipping Methods - Click on "Fedex international" and unable: "Generate Return Label" - Create a new sale order for a product - Click on "add shipping" and select "Fedex international" - Confirm the SO and go to the related delivery - Add the qty as done and validate the delivery #### > you will have a traceback (if not stopped by a user/config error) ### Cause of the issue: The `packages` defined here: https://github.com/odoo/enterprise/blob/b3fe7d2bef7e0992d5ae7461a91861f5be059a0e/delivery_fedex/models/delivery_fedex.py#L369 is a list of records. However, these two lines: https://github.com/odoo/enterprise/blob/b3fe7d2bef7e0992d5ae7461a91861f5be059a0e/delivery_fedex/models/delivery_fedex.py#L377 https://github.com/odoo/enterprise/blob/b3fe7d2bef7e0992d5ae7461a91861f5be059a0e/delivery_fedex/models/delivery_fedex.py#L380 try to access the `.commodities` field of that object. A list comprehension is therefore needed for that operation to work properly. opw-3810796 --- Forward-Port-Of: odoo/enterprise#59736
This fix corrects how transactions are displayed in the General Ledger report when multiple transactions occur on the same date. Previously, transactions were incorrectly ordered by their creation date rather than their sequence number, causing them to appear out of order. The fix ensures transactions are now properly sorted by their sequence number, improving the accuracy and reliability of financial reports.
Original PR description
To reproduce the issue: 1) Create an account.move move_1, leave it in draft 2) Create another account.move move_2, using the same accounts as move_1 and at the same date, leave it in draft 3) Make sure move_1 and move_2's sequence numbers are empty (so that their sequence number will be recomputed at posting) 3) Post move_2 4) Post move_1 5) Open the General Ledger, unfold the lines of the accounts touched by move_1 and move_2. ===> Problem: the move_1's move lines appear before move_2's, even though move_2 has a lower sequence. This is due to the fact move lines with identical dates were ordered by id by the GL. Since move_1 was created first, its lines had a lower id. We fix that by adding the move_name to the ordering criteria. Move lines will still be primarily ordered by date, but if they have the same date, we'll now use the move_name before falling back to their id. Forward-Port-Of: odoo/enterprise#60411 Forward-Port-Of: odoo/enterprise#59213
This fix resolves a crash that occurred when updating the account_reports module on existing databases without also updating the account module. The issue was caused by a recent change that added a new ID reference in the code. We've corrected this by using a more flexible approach that doesn't depend on that ID, ensuring smooth updates regardless of whether other modules are updated at the same time.
Original PR description
https://github.com/odoo/odoo/commit/7e9a87388e1d20c1b194f312f8149a2c3f096038 introduced a new id on a div to use it in an xpath in account_reports. However, on existing databases, this broke at update of account_reports, as long as account module wasn't updated itself. We fix that by directlly targeting the condition of the associated t-if. In master, we'll keep the xpath on the class; which is cleaner.
This fix prevents preparation displays from reloading when processing orders from POS locations that aren't assigned to them. Previously, any order containing products in the display's categories would trigger a reload, regardless of which POS location created the order. Now the system correctly checks that the order originates from an assigned POS location before updating the display.
Original PR description
Issue --> When creating a POS order via any pos config, any active preparation display that has any of the product categories used in the order will cause the customer display to reload. This happens regardless of the `pos_config_ids` set on the preparation display record. Therefore, an order from a `pos.config` **not** on the preparation display will still cause the display to reload Solution --> Edit the search domain on `pos_preparation_display.display` to check the origin of the order to keep the display from reloading unnecessarily. opw-3838879
This fix resolves an issue where marketing automation campaigns using the "SMS not clicked" trigger were not running because the scheduling date was not being set. The fix ensures that these campaigns now execute properly, allowing businesses to automatically follow up with customers who don't click on SMS messages.
Original PR description
When marketing activity is created with trigger sms_not_clicked it isn't being run because schedule_date stays null. task-3648034 Forward-Port-Of: odoo/enterprise#59135
This fix resolves an issue where users received a confusing error message when UPS authorization failed. Previously, the system would crash with a technical error about missing currency information. Now it displays a clear, user-friendly error message instead, making it easier for users to understand and resolve authorization problems with their UPS account.
Original PR description
Before this commit, in case of a 401 response by UPS, the user got a traceback `KeyError: 'currency_code'`
This happened because in that case, the `result` variable was set to `{'Unauthorized':1}`, but this was not caught in `ups_rest_send_shipping`
This commit raises a UserError to avoid the traceback.
opw-3848137
Forward-Port-Of: odoo/enterprise#60513
Forward-Port-Of: odoo/enterprise#60014This fix resolves an error that occurred when uninstalling the HR Organization Chart application and then accessing the HR application. The hierarchy view was not being properly removed during uninstallation, causing the HR app to fail. This update ensures a clean uninstallation process without errors.
Original PR description
STEP TO REPRODUCE:
=================
* Unistall hr_org_chart application
* Click on hr application
task: 3820149
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prFixed an issue where the attendance kiosk mode was displaying the wrong company's logo in multi-company environments. When employees selected a different company and entered kiosk mode, the system was showing the default company's logo instead of the selected company's logo. This fix ensures the correct company branding is displayed on the kiosk screen.
Original PR description
**Current behavior:** Entering kiosk mode in the webclient in a multi-company env will display the logo of the default company. **Expected behavior:** The logo on the kiosk screen will belong to the currently selected company. **Steps to reproduce:** 1. Make a second company, give the default company and the new one distinct logos 2. Select the second company from the company selector menu 3. Enter kiosk mode in the Attendance app, observe the logo is that of the inactive company **Cause of the issue:** After arriving at the URL route for the kiosk page from the _action_open_kiosk_mode() method, the context has been rebuilt to a somewhat default state which no longer informs the current company id. `self.env.company` references the default company of the user. **Fix:** Add an id slug in the URL route which identifies which company's kiosk we should be seeing. opw-3802916
The copy button in the Link Tracker feature was not working properly, returning undefined instead of copying the generated link. This fix updates the code to use the correct data format following recent system updates, ensuring users can now successfully copy tracking links with a single click.
Original PR description
Issue: In Link Tracker for our website, when generating the link, if we try to copy the generated url with the copy value, instead of copying the url we are getting undefined. Steps to reproduce: 1. Install website_links. 2. Go to the website and go to Site > Link tracker. 3. Generate a new link and try to copy. Solution: Due to the recent changes that came from the changes made in 9638423 where we replace the ClipboardJS with Web API and hombrew polyfill, there are still some button that is not adapted yet, and in this case what happens is that we have a difference dataset name for the clipboard content, being 'clipboardText' instead of 'clipboard-text' opw-3806495
This update fixes compatibility issues affecting users with older browsers and devices. The system now works properly with older versions of Safari and browsers that don't support newer JavaScript features, ensuring a better experience for all users regardless of their device age.
Original PR description
The patch function was changed at commit [1]. This introduced a call to `Object.hasOwn` which is the preferred way to check if an Object has a property as its own. However, after multiple user reports, it seems like a significant amount of user and website visitors still use browsers that do not have Object.hasOwn implemented. This commit introduces a fallback to Object.prototype.hasOwnProperty for browsers that do not have Object.hasOwn implemented. [1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe opw-3824593
This fix resolves a performance issue where typing URLs in the website image linking tool was difficult due to constant screen re-rendering. The problem occurred because the URL input widget was triggering unnecessary updates every time a character was typed. The fix ensures updates only happen when users select a URL from the dropdown suggestions, making the typing experience smooth and responsive.
Original PR description
Steps to reproduce: - Drop an Text - Image block - Click on the Image - Click on the link button next to replace - Try typing a URL => Typing a URL is hard because the widget keeps re-rendering Reason: Since [1], the jQueryUI urlcomplete widget was changed into an OWL widget. This added a call to `urlChosen` on input, which leads to the SnippetsMenu re-rendering the options. This commit fixes that by remove the call to `urlChosen`. Nothing is lost since the input is already handling its own changes. Instead, urlChosen is only called when selecting an element from the dropdown. [1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bed
This fix corrects an issue where payment terms were displaying the wrong currency when set for a company with a non-USD currency. When a company uses a different currency (like VND), the payment terms now correctly display that company's currency instead of showing an incorrect one. This ensures accurate financial information across multi-company environments.
Original PR description
Create company A with company currency USD, company B with company currency VND. Set company B-VND in payment terms expect: currency payment terms is VND Video: https://github.com/odoo/odoo/assets/11542778/155f8339-b3e5-470d-a590-70d180a72c36 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix addresses a technical issue where overly long reply-to email addresses were being improperly formatted, causing some email systems (like Microsoft Outlook and Rspamd) to reject or misread the emails. The system now limits reply-to address length to prevent formatting problems and warns users if their email address is too long, ensuring emails are delivered and verified correctly across different email platforms.
Original PR description
### Context In a previous fix https://github.com/odoo/odoo/pull/83276 , the `_notify_get_reply_to_formatted_email` method was introduced to prevent edge-cases where the cpython `email` library might…
### Context In a previous fix https://github.com/odoo/odoo/pull/83276 , the `_notify_get_reply_to_formatted_email` method was introduced to prevent edge-cases where the cpython `email` library might incorrectly fold the “Reply-To” email header. We identified an other corner case where DKIM signature verification might fail on the recipient’s end depending on the tech stack used to verify the DKIM signature vs the one used to DKIM sign it on the sending end. This might be related to how RFC5322 and RFC6376 interact with each other : In RFC5322 defines folding white spaces as follows : ``` FWS = ([*WSP CRLF] 1*WSP) / obs-FWS with obsolete FWS = 1*WSP *(CRLF 1*WSP) ``` While RFC6376 uses : `FWS = [*WSP CRLF] 1*WSP ` Based on this, it seems that for proper header content folding, the specifications expects at least one WSP (space or tab) before a CRLF. Currently when using the `email` cpython library to handle email objects, we observed that when the header value for the “Reply-To” is longer than 68 characters, it will return a folded string representation adding a linebreak after the colon. Example: `Reply-To:\r\n "Marc R.Long Name Jonhson" <catchall@very.long.subdomain@example.com>\r\n` Notice that the there is no WSP between the colon character an `\r\n`. It seems that in this corner case, certain DKIM verification tech stacks (from tests Microsoft Outlook and Rspamd) will miss-read the “Reply-to” header as empty, while others correct for it (Gmail). This in returns leads to the DKIM signature verification failing. As it is impossible to test every possible combination of DKIM tech stacks in the email ecosystem and that until the `email` cpython library handles this corner case correctly, this fix tries to preformat the “Reply-To” more defensively. We also print a warning log if the `record_email` alone is longer than 68 characters (as it will not be folded), inviting the user to shorten it to prevent DKIM verification issues. ### Unit test fixing: - shortened alias name to prevent the 68 character limit from being triggered during the `test_notification_reply_to_batch` performance test (as we are not testing the 68 char here) - changed language in `test_mail_message_values_fromto_long_name` to reflect the new 68 character limit and mutted logger, as it now print a warning message ### Considerations for the future This PR only prevents the “Reply-To” from being malformed. In theory, the miss-folding could happen to any email header constructed using the `email` cpython library. In practice, the probability of the “To” and “From” being affected is low, as they usually don’t exceed a total of 78 characters as per RFC. Nevertheless if the future shows that this might be a bigger issue, one should think about: * On Odoo side: add a more robust header value formatting applied to all affected headers before the email gets sent out * On Python’s side: work with the `email` library maintainer to find a longterm solution opw-3826296 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160760
This fix resolves an issue where byproduct quantities were not being properly updated when a manufacturing order was completed. Previously, if a byproduct was initially set to zero quantity but later updated to a different amount, the system would not reflect this change in the final inventory transfer. The fix ensures that quantity adjustments made during manufacturing are correctly applied to all related inventory movements.
Original PR description
Steps to reproduce the bug: - Enable the “byproduct” option in the settings - Enable 3 steps for manufacturing operation - Create a storable product “P1”: - Component: C1, qty: 1 unit - By-product:…
Steps to reproduce the bug:
- Enable the “byproduct” option in the settings
- Enable 3 steps for manufacturing operation
- Create a storable product “P1”:
- Component: C1, qty: 1 unit
- By-product: C2, qty: 0 unit
- Create a MO:
- Confirm it
- Update the qty produced of C2 to 1
- Mark as done the MO
- Go to the picking
Problem:
The quantity of the byproduct (C2) is not updated to 1.
When the MO is marked as done, the "_action_done" for finished moves is called:
https://github.com/odoo/odoo/blob/34c192761fa375b56d617fec78fb63d8008f6451/addons/mrp/models/mrp_production.py#L1465
Then, we will check, if we should create an extra move:
https://github.com/odoo/odoo/blob/6a114cc97e0ee0648751194c1ffe3e70d900062c/addons/stock/models/stock_move.py#L1507
However, since we ignore moves with a product_uom_qty of 0, we do not check if this move has a different done quantity and thus do not create an extra move:
https://github.com/odoo/odoo/blob/eb4f5fc929217dea7d97a66b6aeeaa8b0bd1e3f1/addons/stock/models/stock_move.py#L1779-L1780
opw-3815481Fixed a crash that occurred when users tried to select custom colors in the gradient color picker while editing email marketing content. The issue happened because color picker components were being removed from memory but the system still tried to update them, causing an error. This fix ensures the color picker works smoothly when customizing text colors in email campaigns.
Original PR description
Issue: ====== traceback when clicking on gradient colorpicker in mass_mailing Steps to reproduce the issue: ============================= - Got to email marketing - Add some text - Select the text and go to graadient and activate custom - click any color in the colorpalette -> traceback Origin of the issue: ==================== Some colorpickers are created inside the snippets sidebar and then gets removed by `_updateRightPanelContent` in `SnippetsMenu` so the owl components corrosponding to them will have `this.el = null` which will cause a problem when updating the props since we will use it in the update. task-3834112 Forward-Port-Of: odoo/odoo#159842
A recent change to the Point of Sale module prevented users without sales permissions (such as stock managers) from creating products. This fix restores product creation functionality for these users by adjusting how the system checks product combinations, ensuring all authorized users can perform their job duties.
Original PR description
After `_check_combo_inclusion` was added, it broke product creation for users without sales rights (e.g. stock managers). This commit fixes the issue by using `sudo().search`. 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 prevents kitchen staff from receiving duplicate orders when customers request to split their bill. Previously, splitting an order would create a new order entry that appeared on the kitchen display, causing the same meal to be prepared twice. Now, split orders no longer trigger duplicate preparation requests, improving kitchen efficiency and reducing waste.
Original PR description
Prior to this commit, splitting an order would create a new order, causing it to appear again on the preparation display. This could lead to the kitchen preparing the same order twice. The sequence of events was as follows: 1. The order is placed. 2. The kitchen receives and prepares the order. 3. The waiter delivers the order to the table. 4. The client receives the bill and requests a split. At the point of splitting, a new order is created. This duplicate order should not be sent to the kitchen as it represents a meal that has already been prepared and consumed. This commit resolves this issue by preventing display of duplicate orders to the kitchen during order splitting. Enterprise PR: https://github.com/odoo/enterprise/pull/60537 opw-3809693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix resolves an issue where the Stock Forecasted report would display all products instead of filtering to show only the relevant product when reloading the report. The problem occurred because the system wasn't properly maintaining the product context when the report was refreshed. The fix ensures the correct product information is preserved in the report context, so users see only the relevant inventory forecast data for their selected product.
Original PR description
Steps to reproduce: ------------------- - create a storable product and set a quantity on hand - create a delivery for this product and set to draft - add a demand for this product on the delivery -…
Steps to reproduce: ------------------- - create a storable product and set a quantity on hand - create a delivery for this product and set to draft - add a demand for this product on the delivery - click on "Mark as Todo" - go to the product form - click on the Forecasted smart button - click on "Unreserve" button (to process business logic ans reload report) Issue: ------ The report is reloaded with all products. Cause: ------ When we setup/start the `StockForecasted` component, if we can't find an active model in the action's context, we try to find it in the action's props (via res_model or on the original action if necessary). If the original action is used, the active model must be in the context of the original action. Unfortunately, this is not the case. Without `resModel` the domain determined in the `graphDomain` method will not filter on the product (which corresponds to the `active_id`). Solution: --------- If no resModel is found via the context, add it to the context when it is determined. Add the action id to handle the case of reloading the page directly via the browser's refresh button. opw-3793065 Forward-Port-Of: odoo/odoo#158063
This fix corrects how popup windows are positioned when they appear outside an iframe but target an element inside it. Previously, the system used the wrong reference point for positioning, which could cause popups to appear in incorrect locations. Now it uses the correct positioning reference, ensuring popups display properly in cross-iframe scenarios.
Original PR description
Since [1] positioning of popovers targeting an element contained in an iframe is permitted. This commit will ensure the popper's element positioning is correct in the following case: have a popper - outside an iframe - targeting an element that is inside it - and no container element has been given (default is used) **Before this commit** The default container that is used is the target's owner document element, a.k.a. the iframe's html element. **After this commit** The default container that is used is now the popper's owner document. ** Side notes ** This bug has been found when working for the following taskid-3603843 It is required for this task and will get fw-ported through the master branch. [1]: d6afa9f32512774908a2076f5ece2522efa44042 Forward-Port-Of: odoo/odoo#161078
This fix ensures that when exporting invoices to electronic formats (XML), the system uses the same language settings as the customer specified on the invoice, matching the behavior of PDF generation. This means product names, payment terms, and other translatable content will now appear in the correct language for each customer in the exported files.
Original PR description
When generating the PDF, the translatable fields (the note of the payment terms, the name of the products, etc) will use the language set on the partner_id of the invoice. The xml generated should do the same. opw-3842885 Forward-Port-Of: odoo/odoo#161140
This fix resolves errors that occurred when opening the product catalog from sales orders, field service management, and purchase orders. The product type information was not being properly loaded from the backend, causing the system to crash. This update ensures the product type data is correctly passed to the catalog interface so users can browse and select products without encountering errors.
Original PR description
The linked PR: https://github.com/odoo/odoo/pull/155157/files Added a default props 'productType' for ProductCatalogOrderLines, the value of this prop wasn't loaded by the backend correctly resulting in a traceback when in debug mode and trying to open the catalog from sale/fsm and another traceback when trying to open the catalog from the purchase form This PR loads the type of the product into the dictionnary correctly Should not be port forwarded, will be done by the following FW: https://github.com/odoo/odoo/pull/161262 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents users from accidentally creating incomplete conditional visibility rules on form fields that lack a comparison condition. Previously, users could set a field to "Visible Only If" without specifying what condition should trigger visibility, causing errors. Now the system ensures a valid comparison is always configured before allowing conditional visibility to be saved.
Original PR description
[This first commit] made it possible to have an error when there was no comparator for a field with conditional visibility. [This second commit] prevented an error from occurring in this case. The…
[This first commit] made it possible to have an error when there was no comparator for a field with conditional visibility. [This second commit] prevented an error from occurring in this case. The purpose of this commit is to prevent the user from getting a conditional visibility configuration for a form field where there is no comparator. Steps to reproduce the problem: - Go to /contactus. - Edit page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibility" option. - Click on "Visible Only If" again. => The comparator is not defined. Another way to have the issue was: - Drop a form on a page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibility" option. - Set visible only if Your Name is equal to "test" as condition. - Click on Your Name field. - Change the field type to Radio Buttons. => The comparator is not defined. This commit fixes those two cases. Technical information: When we change the field's visibility to conditional (`setVisibility`), we add a default visibility dependency (`_setVisibilityDependency`). At this point, the comparator is removed and added in `_renderCustomXML`. `_renderCustomXML` was only called if the visibility dependency had changed. [This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628 [This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27 opw-3806409 Forward-Port-Of: odoo/odoo#160464
This fix resolves an error that occurred when viewing products in a task's product catalog. The system was missing a required product type field, causing the product display component to fail. This fix ensures the product type information is properly included so users can successfully browse and manage products from tasks.
Original PR description
Steps to reproduce ================== - Go to project > Tasks > All tasks - Open the first line - Click on the "0 products" smart button => Invalid props for component 'ProductCatalogSaleOrderLine': 'productType' is missing (should be a string) opw-3864112
This fix resolves an issue where the accounting transfer wizard was not generating the required counterpart lines when processing transfers with zero amount in foreign currency. The fix ensures that transfers are properly balanced and counterpart entries are created correctly, maintaining accounting integrity.
Original PR description
- Transfer move line with amount_currency $0, balance 1000đ - Wizard transfer not generate counterpart lines 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#160946 Forward-Port-Of: odoo/odoo#157011
This update resolves problems with stock movements between company warehouses through inter-company locations. The fix ensures that stock transfers correctly apply the right warehouse and routing rules when pushing inventory between companies, preventing items from being assigned to the wrong company location.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161279 Forward-Port-Of: odoo/odoo#160968