Wednesday, November 13, 2024
38 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)
This update adds a dedicated anchor for alerts on sales orders, making it easier to direct users to important warning messages. It is a small usability improvement that can help teams quickly find relevant information during sales order review.
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
The HR module now automatically selects the relevant default company in the left search panel based on the company the user is working with. This makes employee searches more accurate and reduces manual filtering for users who work across multiple companies.
Original PR description
This PR improves the left search panel in the HR module by automatically selecting the default company based on the user's selected company. task-4265695
Employee profile sections for resumes and skills now show empty-state text with styling that looks more like standard placeholder text. This creates a more consistent and polished experience when employees or HR users view profiles with missing information.
Original PR description
This commit shows the text in employee profile with a style that is more consistent with placeholders. Before:  After:  task-4265968 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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
The Manufacturing Orders page now shows the correct breadcrumb label when opened from a transfer's Manufacturing button. This removes a confusing 'Unnamed' label and makes navigation more consistent for users working with transfers and manufacturing orders.
Original PR description
Before this commit: ======================= When accessing the manufacturing order tree view through the smart Manufacturing button on a transfer, the breadcrumb displayed 'Unnamed' instead of 'Manufacturing Orders.' After this commit: ===================== The breadcrumb now correctly shows 'Manufacturing Orders' when accessing the manufacturing order tree view via the smart button on a transfer, ensuring consistency with the normal tree view. task-4190266
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.
Miscellaneous changes
This PR fixes a typo introduced by this commit ce0f8d9e608acdcc6fd8495e7b9cd8f7d2757349. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186870
Original PR description
This PR fixes a typo introduced by this commit ce0f8d9e608acdcc6fd8495e7b9cd8f7d2757349. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186870
This change improves how Odoo finds text that needs translation when one translatable message appears inside another. It helps ensure more labels and messages are correctly included for translation, reducing missing translations in localized versions.
Original PR description
The current Babel library doesn't allow to extract gettext calls that are nested. Specifically:
- The Python extractor only supports a directly nested gettext call in another gettext call, like `_("Text %s", _("Nested"))`.
- The Javascript extractor doesn't supported nested calls at all.
In this commit, we patch both extraction functions, so they supported arbitrarily deep nested gettext calls, like e.g.
```python
_("Text %s", other_function(_("Deeply Nested")))
```
or the Javascript equivalent.
task-3940389This fixes a recent issue that caused automated checks to fail when web views handled monetary and date fields. It helps keep the user interface stable and prevents disruptions from incompatible field types.
Original PR description
Build errors in click all since #183882: see: https://runbot.odoo.com/runbot/build/70474087 build-error: 106152
A field used for links in the base system profiling area now uses the right format so URL links display and behave correctly. This helps users open related links reliably without changing business workflows.
Original PR description
This commit, change the field type from text to char to correctly use the url widget.
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
This fixes how certain money and date fields are handled in approval requests and rental sales orders. It helps ensure users see and enter these values consistently, reducing confusion and potential mistakes in day-to-day workflows.
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)
This pull request reorganizes the underlying engine used to run automated guided flows and tests across several Odoo apps. The change should make these flows easier to maintain and more reliable over time, without introducing a direct visible change for everyday users.
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 renames internal unit-of-measure fields so sales, purchasing, pricing, and reporting records use consistent naming. The change reduces custom workarounds and makes future shared processes, such as EDI handling, easier to build and maintain without changing day-to-day business workflows.
Original PR description
Purpose of this PR to have name of field according to guidelines so it can be consistent with other models and we don't have to add some hacks if they are not like in invoice lines `product_uom_id`…
Purpose of this PR to have name of field according to guidelines so it
can be consistent with other models and we don't have to add some hacks
if they are not like in invoice lines `product_uom_id` is properly named
according to guidelines and in other modules it's not so if we want to
add generic method which will work for invoice lines and sale order lines
then we have to remove `product_uom_id` from data and add `product_uom`
and it can get ugly if we want to do more complex operations.
This commit rename field `product_uom` on SOL to `product_uom_id` to be
consistent with other models specifically with `account.move.line` in order
to properly extract common logic from EDI for invoice and have consistent
name across file so it'll make future code simpler.
We also have to change purchase line `product_uom` field to `product_uom_id`
because in generic accounting code they create sale or purchase order
depending on condition so Sale order line and Purchase order line should
have same field names also there is task to add EDI import for purchase
order 4286172 so it can be useful for that task also
Following uom field names updated to follow guideline and proper naming:
(Related to SOL and POL `product_uom` field)
- Rename `product_uom` to `product_uom_id` in {`sale.order.line`,
`purchase.order.line`, `sale.report`, `purchase.report` , `project.milestone` ,
`product.supplierinfo`} models.
- Rename `product.pricelist.item` model's field `product_uom` to
`product_uom_name` as it was related to product's `uom_name` field and
it was char type field.
task-4206350
See also:
https://github.com/odoo/enterprise/pull/73293
https://github.com/odoo/upgrade/pull/6732This update reorganizes internal test helper tools and clarifies their naming so development teams can write and maintain automated tests more reliably. It also fixes timing and service-mocking issues that could cause small inconsistencies in test results, reducing noise and improving confidence in quality checks.
Original PR description
This PR moves some helper functions away from the main 'web_test_helpers' file and rename the `step` and `assertStep` functions to reduce confusion. Enterprise: https://github.com/odoo/enterprise/pull/73569 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update aligns enterprise modules with a broader naming cleanup by changing product unit references to a clearer, consistent field name. It reduces technical inconsistency across sales, rental, subscription, delivery, field service, purchasing, stock, and accounting-related workflows without changing business functionality.
Original PR description
This commit adept changes done in community PR to rename `product_uom` field to `product_uom_id` also rename related fields in following models: - sale.subscription.report - sale.rental.schedule - sale.rental.report task-4206350 See also: https://github.com/odoo/odoo/pull/186250 https://github.com/odoo/upgrade/pull/6732
This update reorganizes and renames internal testing helper functions so automated tests are easier to understand and maintain. It affects test code only, helping developers reduce confusion without changing business workflows or user-facing behavior.
Original PR description
This PR moves some helper functions away from the main 'web_test_helpers' file and rename the step and assertStep functions to reduce confusion. Community: https://github.com/odoo/odoo/pull/186636
This draft change appears to reorganize internal code and automated walkthroughs for field service reporting, external tax sales flows, and document signing. It is not expected to change day-to-day behavior for users, but should help keep these areas easier to maintain and test.
Currently, when a discount is applied on a specific pos order line, the receipt does not reflect the original price of the article. Steps to reproduce: ------------------- * Open shop session * Add any product to the order * Apply a discount on that order line * Validate and pay order > Observation: The original price of the order is not reflected Why the fix: ------------ We now show the original price, without the discount, on the receipt. opw-4179118 Before: ---------
Original PR description
Currently, when a discount is applied on a specific pos order line, the receipt does not reflect the original price of the article. Steps to reproduce: ------------------- * Open shop session * Add any product to the order * Apply a discount on that order line * Validate and pay order > Observation: The original price of the order is not reflected Why the fix: ------------ We now show the original price, without the discount, on the receipt. opw-4179118 Before: ---------  After: -------  Forward-Port-Of: odoo/odoo#186557 Forward-Port-Of: odoo/odoo#183506
Debugging websocket can be tough as we don't know when a session is downgraded. Some messages can be received, giving the impression that everything is working fine while the socket is actually linked to a public user. This PR introduces some logs to help debugging this scenario. opw-4218953 Forward-Port-Of: odoo/odoo#186911
Original PR description
Debugging websocket can be tough as we don't know when a session is downgraded. Some messages can be received, giving the impression that everything is working fine while the socket is actually linked to a public user. This PR introduces some logs to help debugging this scenario. opw-4218953 Forward-Port-Of: odoo/odoo#186911
Fix a failing test that was incorrectly patching a class method, instead of patching the base object. Indeed, before this fix the test was only patching `account_edi_ubl_cii._get_ubl_cii_formats_info()` and not extensions such as `l10n_ro_edi._get_ubl_cii_formats_info()`). Therefore extensions could add data to the returned value of the method, and could make the test fail. Related runbot error id: 104916 task-no Forward-Port-Of: odoo/odoo#186935
Original PR description
Fix a failing test that was incorrectly patching a class method, instead of patching the base object. Indeed, before this fix the test was only patching `account_edi_ubl_cii._get_ubl_cii_formats_info()` and not extensions such as `l10n_ro_edi._get_ubl_cii_formats_info()`). Therefore extensions could add data to the returned value of the method, and could make the test fail. Related runbot error id: 104916 task-no Forward-Port-Of: odoo/odoo#186935
Steps to reproduce ================== - Use a mobile device - Enable analytic accounting - Go to Expenses - Open a record - Click on the analytic field - Search more on the project - Click on the search input => The popup closes Cause of the issue ================== There is a resize handler that closes the popup. When the keyboard appears, the window is resized to reserve space for it Solution ======== Dont close the popup when we are using a mobile OS opw-4174514
Original PR description
Steps to reproduce ================== - Use a mobile device - Enable analytic accounting - Go to Expenses - Open a record - Click on the analytic field - Search more on the project - Click on the search input => The popup closes Cause of the issue ================== There is a resize handler that closes the popup. When the keyboard appears, the window is resized to reserve space for it Solution ======== Dont close the popup when we are using a mobile OS opw-4174514 Forward-Port-Of: odoo/odoo#186606
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#186456
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#186456
Add a check on adyen callback when paying. Verify if the pending payment line exist before processing the callback. opw-4242322 Forward-Port-Of: odoo/odoo#186842 Forward-Port-Of: odoo/odoo#186580
Original PR description
Add a check on adyen callback when paying. Verify if the pending payment line exist before processing the callback. opw-4242322 Forward-Port-Of: odoo/odoo#186842 Forward-Port-Of: odoo/odoo#186580
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#186847 Forward
Original PR description
In large database, the compute of the field l10n_it_payment_method and l10n_it_document_type can raise a timeout. Step to reproduce: - On a large database (tested with +10M account.move), try to install the module l10n_it_edi_ndd - The installation will raise a timeout New behavior: The fields l10n_it_payment_method and l10n_it_document_type will no longer be computed during module installation. This will avoid the timeout. opw-4273165 Forward-Port-Of: odoo/odoo#186847 Forward-Port-Of: odoo/odoo#185266
Before this commit, when loading the data for the point of sale, all the uom categories were not being loaded due to a wrong domain declaration. The domain was comparing uom categories ids with uom ids, which is wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185843 Forward-Port-Of: odoo/odoo#185807
Original PR description
Before this commit, when loading the data for the point of sale, all the uom categories were not being loaded due to a wrong domain declaration. The domain was comparing uom categories ids with uom ids, which is wrong. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#185843 Forward-Port-Of: odoo/odoo#185807
There was `opacity-0` on muted item, but due to `opacity-50` being mistakenly present at all time, it had precedence over the `opacity-0` thus the unread indicator was always visible.  Forward-Port-Of: odoo/odoo#186843
Original PR description
There was `opacity-0` on muted item, but due to `opacity-50` being mistakenly present at all time, it had precedence over the `opacity-0` thus the unread indicator was always visible.  Forward-Port-Of: odoo/odoo#186843
Opening the corporate tax report more than once resulted in an error, making it impossible to open the report. The reason for this was an undefined comparison filter when opening the report for the second time. This was a result of setting the export mode to `file` when opening the report, which in turn makes the comparison undefined. This commit fixes this by temporarily setting the export mode to `file` when creating the entry. ticket: https://www.odoo.com/odoo/project/49/tasks/4288546 For
Original PR description
Opening the corporate tax report more than once resulted in an error, making it impossible to open the report. The reason for this was an undefined comparison filter when opening the report for the second time. This was a result of setting the export mode to `file` when opening the report, which in turn makes the comparison undefined. This commit fixes this by temporarily setting the export mode to `file` when creating the entry. ticket: https://www.odoo.com/odoo/project/49/tasks/4288546 Forward-Port-Of: odoo/enterprise#73644
1. When an applicant (who doesn't have an employee record yet) signs a contract their name is shown as `simulation employee` instead of their actual name. 2. Dependent benefits are visible although the mandatory benefits aren't selected. For example: the dialog box showing the number of insured children under ambulatory insurance is visible although the abulatory insurance isn't selected on the salary configurator. 3. The dropdown menus on the salary configurator have a grey color which ma
Original PR description
1. When an applicant (who doesn't have an employee record yet) signs a contract their name is shown as `simulation employee` instead of their actual name. 2. Dependent benefits are visible although the mandatory benefits aren't selected. For example: the dialog box showing the number of insured children under ambulatory insurance is visible although the abulatory insurance isn't selected on the salary configurator. 3. The dropdown menus on the salary configurator have a grey color which makes the user think that they aren't editable. These changes fixes the above issues. task-4280657 Forward-Port-Of: odoo/enterprise#73000
Purpose ======= Create a new group, so admin don't see all document by default. Task-4313355 Forward-Port-Of: odoo/enterprise#73372
Original PR description
Purpose ======= Create a new group, so admin don't see all document by default. Task-4313355 Forward-Port-Of: odoo/enterprise#73372
The tour is failing because the test folder ("Folder1") is not always selected when starting the test with its access token. As the test is checking the folder deletion, we select the test folder manually by clicking on it. Task-4247011 Forward-Port-Of: odoo/enterprise#71653
Original PR description
The tour is failing because the test folder ("Folder1") is not always selected when starting the test with its access token. As the test is checking the folder deletion, we select the test folder manually by clicking on it.
Task-4247011
Forward-Port-Of: odoo/enterprise#71653The test was using a common class from website while not depending on the module and turns out the class was not necessary. Runbot Error 69687 Forward-Port-Of: odoo/enterprise#73377
Original PR description
The test was using a common class from website while not depending on the module and turns out the class was not necessary. Runbot Error 69687 Forward-Port-Of: odoo/enterprise#73377
Before this commit : - Glovo was selected as default delivery provider. - Extra Dot(Bullet Point) is visible in the Order notes - Label to be changed under Food delivery connector field. Following this commit : - Default delivery provider is removed. - Extra dot is been removed in order notes. - Label is been updated to Food Delivery Platforms. task - 4315841 Forward-Port-Of: odoo/enterprise#73553
Original PR description
Before this commit : - Glovo was selected as default delivery provider. - Extra Dot(Bullet Point) is visible in the Order notes - Label to be changed under Food delivery connector field. Following this commit : - Default delivery provider is removed. - Extra dot is been removed in order notes. - Label is been updated to Food Delivery Platforms. task - 4315841 Forward-Port-Of: odoo/enterprise#73553
When the appointment duration is not a multiple of hours, ex: 2 hour 30 minutes it is not able to fit in one line. Thus change appointment duration format to short when duration exceeds a day or is not a multiple of an hour. And some other UI/UX changes. Task-4209912 Forward-Port-Of: odoo/enterprise#70645
Original PR description
When the appointment duration is not a multiple of hours, ex: 2 hour 30 minutes it is not able to fit in one line. Thus change appointment duration format to short when duration exceeds a day or is not a multiple of an hour. And some other UI/UX changes. Task-4209912 Forward-Port-Of: odoo/enterprise#70645
Limit calendar view to show only dates within the currently selected month. Task-4294202 Forward-Port-Of: odoo/enterprise#73637
Original PR description
Limit calendar view to show only dates within the currently selected month. Task-4294202 Forward-Port-Of: odoo/enterprise#73637