Wednesday, November 13, 2024
6 changes · master
Enhancements to existing features
Inventory users can now change product tracking settings through a confirmation step instead of being blocked by strict constraints. When tracking changes affect existing stock records, Odoo consolidates related quantities and valuations and updates reservations so operations can continue consistently.
Original PR description
With this commit ================ - Removed product tracking constraints and introduced a confirmation dialog for tracking changes. - When switching from no tracking to tracking, a confirmation dialog will appear if there are existing move lines linked to the products. - Changing tracking status from no tracking to tracking, or from tracking by lots/serial to tracking by product, will trigger a confirmation dialog. Upon confirmation, all associated quants will be merged into a single quant, including any valuation layers. Additionally, transfers will be unreserved from the previous quants with lots and re-reserved using the newly merged quants. [4189728](https://www.odoo.com/odoo/my-tasks/4189728)
Purchase users can now select purchase units of measure that stay consistent with the related sales unit, reducing transaction errors. Purchase orders also support more order lines and the variant selection grid is easier to use with a fixed header while scrolling.
Original PR description
In this commit: =================== - Set the domain on Purchase UOM selection based on the selected Sales UOM to ensure consistency across transactions. - Removed the limit on the number of Purchase Order lines, aligning with the behavior observed in Sales Orders. - Implemented a freeze header feature on the variant grid selection for improved user experience. task-4213738
The inventory location form has been streamlined by hiding non-essential fields for certain location types and making the subcontracting location option easier to find. Clearer tooltips should help users understand location settings faster and reduce configuration mistakes.
Original PR description
In this commit: ==================== - The current location form includes fields that may confuse users, especially with virtual location types. By removing non-essential field like 'dock location' from various location types, we reduce complexity and make the form more intuitive. - Additionally, 'Is a Subcontracting location' is moved to the normal mode to increase visibility for users, as it is a commonly used field. - The tooltips have been corrected and clarified to improve user understanding. task- 4149824
Resolved issues and error corrections
Website page addresses can now keep non-ASCII characters instead of removing them. This helps users create and visit pages with localized or international URL text without broken or automatically replaced slugs.
Original PR description
Description of the issue/feature this PR addresses: Any non-ascii character is removed from URLs. Current behavior before PR: If trying to create or navigate to a page in the website using URLs containing non ascii characters, the non ascii characters are removed from the URL, and if the URL was composed completely of non ascii characters, it gets replaced with -1,-2,-3... Desired behavior after PR is merged: The non ascii characters do not get removed from the URLs, allowing users to create and browse pages with URLs containing non ascii characters --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Code cleanup and technical improvements
Odoo’s automated website and app tours now wait more reliably for screens to finish updating before taking the next action. This reduces false failures and wrong clicks in tests, helping teams validate business flows with more confidence.
The stock forecast now correctly recognizes inventory stored in sublocations, such as warehouse shelves, when checking whether an order can be fulfilled. This prevents available stock from being incorrectly shown as unavailable, helping users reserve products accurately from the forecast view.
Original PR description
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated…
### Steps to reproduce: - Enable multisteps route in the settings - Create a storable product P and put 10 units in WH/Stock/Shelf - Create and confirm an SO for 1 unit of P - Go to the associated delivery and change the Source Location to WH/Stock/Shelf - Back to the SO, click on the chart icon > view forecast - Unreserve the 1 unit currently used by your picking ### Issue: While you have 10 units in WH/Stock/Shelf perfectly suitable to fulfill the demand of the picking, instead of displaying a line allowing you to reserve the 1 unit, you have a line telling you that the qty is "not available" -1 unit associated with the SO. ### Cause of the issue: Currently, in the `_get_report_lines` used to compute the forecast datas the `currents` dict used to compute both the reserved and the on hand quantity only updates the quantity of the warehouse if the location belongs to the warehouse: https://github.com/odoo/odoo/blob/7e8afedda2cdc5ec64c1f022c116d56ec90c907a/addons/stock/report/stock_forecasted.py#L330-L336 As such, 0 units are considered to be available in these locations and nothing can be taken from stock for these moves: https://github.com/odoo/odoo/blob/7e8afedda2cdc5ec64c1f022c116d56ec90c907a/addons/stock/report/stock_forecasted.py#L243-L249 opw-4220367 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
In macro.js, the advance() function calls itself at the end. The advance() function allows you to search for the trigger of a step and then call the run() function if it exists. There are 2 possible…
In macro.js, the advance() function calls itself at the end. The advance() function allows you to search for the trigger of a step and then call the run() function if it exists. There are 2 possible (parallel) paths to find the trigger of the current macro.js. Case 1. At the end of advance(), we move on to the next step, we look for the trigger DIRECTLY in the DOM. If we find it, we execute the action on it and move on to the next step. Case 2. In parallel with case 1, there is a MutationObserver. At any time, if a mutation occurs, we wait for a stable state (debounce 750ms without any mutation) then we look for the trigger in the DOM. When we find it, we execute the action. Corollary: In case 1. we can find the trigger DIRECTLY and the mutations that occur after (2.) will no longer have an impact. Consequence: We do not necessarily wait for a stable state of the DOM before looking for the trigger. Solution: When looking for a trigger, we must let the mutations take place (let the DOM have a stable state) before looking for the trigger. Question: When do we consider that we do not expect mutations? If the previous step is "just a check" and there is no interaction with the DOM => We can consider that there is no reason to expect mutations. (Note that this is specific to towers, hence a TourEngine) This allows among other things to correct scenarios where: - We wait for a modal to close before looking for an element in the DOM. - The tower takes a wrong path because it found an element that is not really the one we expected. i.e. Click on a first we-select, Click on an option which must modify the options of a second we-select, Click on the second we-select (case 1), the options are not available (because we did not wait for the mutations before clicking on the second we-select)