Daily updates from Odoo
Navigate
Branch
Tuesday, April 1, 2025
52 changes
1 change
Miscellaneous changes
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field
Original PR description
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given…
In v16 (and it's still the case in master) fields default values are not batched. They are added one by one for each vals dict in `_prepare_create_values`. The main reason for that is that a given default could be a callable returning a randomly generated value. Still, that can be a bottleneck when batch creating records, during imports for instance. That's especially true for a model such as account.move, which is already pretty heavy to create. When the sale module is installed, a new field `team_id` is added. This field is a computed-stored field with a callable set as default. Because the default attr is defined, the ORM skips the call to the compute method and calls the default function instead when the team_id param is not given upon creation. That means that for each account.move, `_get_default_team_id` is called. Since the purpose of a compute function is already to give default values to record, removing the default callable allows to benefit from the batching of compute functions. #### speedup Test database with account_accountant and sale. Trying to create batches of account.moves | Batch size | Before PR | After PR | |:----------:|:---------:|:--------:| | 1 | 70ms | 58ms | | 50 | 150ms | 100ms | | 100 | 275ms | 188ms | | 250 | 660ms | 450ms | | 1000 | 2.43s | 1.75s | | 3000 | 7.55s | 5.33s | Average speedup: 68%. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160313 Forward-Port-Of: odoo/odoo#157887
34 changes
Enhancements to existing features
Preparation time settings for Urban Piper point of sale integrations are now shown in minutes instead of seconds. This makes the timing easier for restaurant staff and managers to understand and configure accurately.
Original PR description
**pos_urban_piper_enhancements Following this commit: - Preparation time would be displayed in minutes instead of seconds. Related PR - https://github.com/odoo/upgrade/pull/7412 task-4581925
This update removes a duplicate internal way of scheduling activities in Belgian reports and uses the existing standard process instead. It helps keep the module simpler and reduces the chance of inconsistent behavior, with no expected change for everyday users.
Original PR description
Due to an oversight, we added an unnecessary activity scheduling method in d684d074af82fbd0fac6b3a1c56b4e01a17dd74a. This should be replaced by the already existing `activity_schedule` method in `account.move`. No task ID.
The Documents app now offers a cleaner right-side panel with better access to details, chatter, and record linking across views. Users can review document information, navigate lists, and manage folder downloads more smoothly, improving day-to-day document handling.
Original PR description
Task-4596337
Indian localization now offers a trial balance XLSX export with account balances broken down by partner. This gives finance teams more detailed reporting for reconciliation, review, and partner-level analysis without manual spreadsheet work.
Original PR description
Enhance Trial Balance XLSX Export with Partner-Level Breakdown for Indian Localization. This update introduces an XLSX export variant for the trial balance, featuring a detailed breakdown per partner for each account. The implementation extends the grouping functionality to include partners, aligning with the requirements and providing more detailed reporting. >Task:4339611
Payslip reports now show clearer section headings for items such as taxes, pre-deductions, and post-deductions. This makes payslips easier for employees and payroll teams to read, while avoiding unnecessary validation of heading-only lines.
Original PR description
This PR improves the salary rules in the payslip report by adding bold and underlined titles for different groups such as taxes, pre-deductions, and post-deductions. task-4615212
Resolved issues and error corrections
The subscription dashboard has been corrected so monetary totals display and aggregate properly again. This ensures business users can rely on dashboard figures after a recent platform change affected how currency-based values are calculated.
Original PR description
Since https://github.com/odoo/odoo/pull/199958, monetary fields can now only be aggregated (from the web client) if the currency field is also aggregated. Unfortunately, the sale_subscription dashboard explicitly uses some monetary aggregates where the currency is a compute (`sale.order.log.report.currency_id`). Change it to get it from the view table. https://github.com/odoo/odoo/pull/203901
This fixes an internal project scheduling test so it correctly checks when a user is overbooked in the Gantt view. The change helps keep project planning behavior reliable without changing day-to-day user workflows.
Original PR description
Before this commit, the test "/project_enterprise/tests/test_ui.py:ProjectEnterpriseTestUi.test_01_ui" fails in no demo because the task created before starting the tour is not planned for the whole gantt period displayed. Which means the user does not overwork as expected when the tour plans another task. This commit makes sure the task is planned during the whole period displayed in the gantt view to correctly check the gantt progress bar detects the user overworks. runbot-error-161930
Code cleanup and technical improvements
The appointment validation flow was moved to a newer internal interaction framework without changing the intended user experience. This helps keep the appointment module maintainable and easier to evolve in future updates.
The appointment type selection page was reorganized behind the scenes to use Odoo's newer interaction framework. This should preserve the same customer-facing behavior while making the appointment module easier to maintain and evolve.
Miscellaneous changes
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial
Original PR description
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test opw-3993305 Forward-Port-Of: odoo/enterprise#68949 Forward-Port-Of: odoo/enterprise#67589
Installing stock_barcode without base_import installed results in errors in the assets when loading `ImportBlockUI`. This occurs because `stock_barcode` requires a component from `base_import` but does not explicitly declare it as a dependency. opw-4613302 Forward-Port-Of: odoo/enterprise#82266 Forward-Port-Of: odoo/enterprise#81368
Original PR description
Installing stock_barcode without base_import installed results in errors in the assets when loading `ImportBlockUI`. This occurs because `stock_barcode` requires a component from `base_import` but does not explicitly declare it as a dependency. opw-4613302 Forward-Port-Of: odoo/enterprise#82266 Forward-Port-Of: odoo/enterprise#81368
Before this commit, compare_amount could be called with nonetype taskid: 4671141 Forward-Port-Of: odoo/enterprise#82098
Original PR description
Before this commit, compare_amount could be called with nonetype taskid: 4671141 Forward-Port-Of: odoo/enterprise#82098
The partena code on work entry type should be 5 characters long and not 3. task-4658021 Forward-Port-Of: odoo/enterprise#81738
Original PR description
The partena code on work entry type should be 5 characters long and not 3. task-4658021 Forward-Port-Of: odoo/enterprise#81738
**Before this fix:** https://tinyurl.com/2y5zluop **Technical:** The 'name' field in the documents became translatable(from commit https://github.com/odoo/enterprise/commit/9efa58c442e1892fef3fa5ce3901d697de22beaa), causing the 'o_field_translate' to be applied to the name input, including the padding style on the right. **After this fix:** Fields in the document details panel will be properly aligned for an enhanced UI. Task-4636414 Forward-Port-Of: odoo/enterprise#81115
Original PR description
**Before this fix:** https://tinyurl.com/2y5zluop **Technical:** The 'name' field in the documents became translatable(from commit https://github.com/odoo/enterprise/commit/9efa58c442e1892fef3fa5ce3901d697de22beaa), causing the 'o_field_translate' to be applied to the name input, including the padding style on the right. **After this fix:** Fields in the document details panel will be properly aligned for an enhanced UI. Task-4636414 Forward-Port-Of: odoo/enterprise#81115
### Issue When using the `Send HR Documents Access Link` action, Odoo always assumes that the company has set a `documents_hr_folder` already. However, this can easily not be the case if the customer has never activated `documents_hr_setting` and chosen a Workspace. If this is the case, we'll encounter an error when creating the `document.share` record, since `folder_id` is required. ### Solution Display an error directing the customer to activate an HR Workspace folder so they can properly
Original PR description
### Issue When using the `Send HR Documents Access Link` action, Odoo always assumes that the company has set a `documents_hr_folder` already. However, this can easily not be the case if the customer has never activated `documents_hr_setting` and chosen a Workspace. If this is the case, we'll encounter an error when creating the `document.share` record, since `folder_id` is required. ### Solution Display an error directing the customer to activate an HR Workspace folder so they can properly use the feature. opw-4559772 Forward-Port-Of: odoo/enterprise#81523
Fix incorrect reference to `group_hr_payroll_user`, as it is defined in `hr_payroll`, not `hr_contract`. Forward-Port-Of: odoo/enterprise#82227
Original PR description
Fix incorrect reference to `group_hr_payroll_user`, as it is defined in `hr_payroll`, not `hr_contract`. Forward-Port-Of: odoo/enterprise#82227
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode a
Original PR description
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory >…
### Issue: Currently, the `use_create_components_lots` of the manufacturing picking type is not used in barcode to allow/forbid the creation of new lots. ### Steps to reproduce: - Inventory > Configuration > Warehouse Management > Operation Types - Manufacturing > uncheck: Create New Lots/Serial Numbers for Component - Create a product tracked by SN and put one SN in stock. - Create and confirm an MO for an other product using your tracked product as component. - Go to the barcode app > Manufacturing > your MO - Click on the component line and scan a string that do not correspond to an existing SN of your tracked product. > The Scanned string is added as a "lot_name" on a new line. In particular, at validation a new move line without lot and with a set lot_name will be created. This line without lot will be used in all the `pre_button_mark_done` checks like: `_check_sn_uniqueness` which btw will fail if you scanned 2 non-existing lots. And, if you manage to pass all check for instance by scanning a non-existing lot and the initially reserved one, the validation of the new move line will create the lot. Cause of the issue: Scanning the non existing lot will correctly fail to find a match via the barcode parser: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L963 As such and since a line is selected, you will end up setting the barcode as a lotName: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode/static/src/models/barcode_model.js#L1018-L1034 This happens notably because you `this.canCreateNewLot` is always set to `True` on productions but should not: https://github.com/odoo/enterprise/blob/026a5b8a83bd6b94588baa9a35530495d9e067cd/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L126-L128 opw-4618963 Forward-Port-Of: odoo/enterprise#82202 Forward-Port-Of: odoo/enterprise#81272
Same logic as: https://github.com/odoo/enterprise/pull/81763 https://github.com/odoo/enterprise/pull/79947 rb-145524 Forward-Port-Of: odoo/enterprise#82433
Original PR description
Same logic as: https://github.com/odoo/enterprise/pull/81763 https://github.com/odoo/enterprise/pull/79947 rb-145524 Forward-Port-Of: odoo/enterprise#82433
An error is encountered in the `Modify Asset` wizard when resuming `Asset Depreciation` after manually increasing `Non Depreciable Amount`. The system attempts to record the change as a gain, requiring a `Depreciation Account`. However, this field is hidden, preventing users from fixing the problem, so they are blocked. Steps to reproduce: - Create a running asset - Click `Modify Depreciation` > `Pause` - Click `Resume Depreciation` and open the `asset.modify` wizard. - Increase `Not Depr
Original PR description
An error is encountered in the `Modify Asset` wizard when resuming `Asset Depreciation` after manually increasing `Non Depreciable Amount`. The system attempts to record the change as a gain, requiring a `Depreciation Account`. However, this field is hidden, preventing users from fixing the problem, so they are blocked. Steps to reproduce: - Create a running asset - Click `Modify Depreciation` > `Pause` - Click `Resume Depreciation` and open the `asset.modify` wizard. - Increase `Not Depreciable Amount`, realizing a gain - Press the `Resume` button Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4472309) opw-4472309 Forward-Port-Of: odoo/enterprise#82512 Forward-Port-Of: odoo/enterprise#79181
- Fix the problem of company information that was not diplayed in the libro giornale report task-4502158 Forward-Port-Of: odoo/enterprise#82528
Original PR description
- Fix the problem of company information that was not diplayed in the libro giornale report task-4502158 Forward-Port-Of: odoo/enterprise#82528
Since we are changing the parent view in https://github.com/odoo/odoo/pull/202946/commits/5430b209c6f968108e0e43f9ff7fc6166239833a we are gonna need to adjust the inherited view in documents_project to use the groups attribute instead of invisible attribute opw-4633771 Forward-Port-Of: odoo/enterprise#82530
Original PR description
Since we are changing the parent view in https://github.com/odoo/odoo/pull/202946/commits/5430b209c6f968108e0e43f9ff7fc6166239833a we are gonna need to adjust the inherited view in documents_project to use the groups attribute instead of invisible attribute opw-4633771 Forward-Port-Of: odoo/enterprise#82530
https://www.awesomescreenshot.com/image/53270541?key=2bf6f954c641f8dcfc8d0a524bb6e0e0 How to reproduce: - Make comment on any of the post under any social media. Just one condition, make sure to include any of the following characters (&, <, >, ', , `). - Post the comment. - Now try to edit the comment. - You will see that the special characters which I have mentioned above have been replaced with their HTML entities. Issue: - When we click on edit, we first `escape()` the conte
Original PR description
https://www.awesomescreenshot.com/image/53270541?key=2bf6f954c641f8dcfc8d0a524bb6e0e0 How to reproduce: - Make comment on any of the post under any social media. Just one condition, make sure to include any of the following characters (&, <, >, ', , `). - Post the comment. - Now try to edit the comment. - You will see that the special characters which I have mentioned above have been replaced with their HTML entities. Issue: - When we click on edit, we first `escape()` the contents of the message and then display it in the `textarea`. Fix: - We now display the comment through the value attribute of the `textarea` element, which by default displays the contents as plaintext. Hence, eliminating the need to escape it. Task-4184968 Forward-Port-Of: odoo/enterprise#82414
Fix an issue with the formula of the Other gain (loss) line. It was "-57 + -59" which in theory is a correct formula, but in practice it is not handled well by the report engine and the + will match many other accounts that we don't want. It is corrected to be "-57 - 59". Forward-Port-Of: odoo/enterprise#82387
Original PR description
Fix an issue with the formula of the Other gain (loss) line. It was "-57 + -59" which in theory is a correct formula, but in practice it is not handled well by the report engine and the + will match many other accounts that we don't want. It is corrected to be "-57 - 59". Forward-Port-Of: odoo/enterprise#82387
The calendar view of appointment booking in smaller screens is overflowing the screen with some columns in the calendar not appearing and cut. Steps to reproduce: - install website and appointment - go to website and go to mobile mode - open an appointment to book The change is tested on all screen sizes supported by google chrome inspect tool. opw-4487796 Forward-Port-Of: odoo/enterprise#79198
Original PR description
The calendar view of appointment booking in smaller screens is overflowing the screen with some columns in the calendar not appearing and cut. Steps to reproduce: - install website and appointment - go to website and go to mobile mode - open an appointment to book The change is tested on all screen sizes supported by google chrome inspect tool. opw-4487796 Forward-Port-Of: odoo/enterprise#79198
Steps to reproduce the bug: - Create a quality point: - Operations: Receipt - Control per: Product - Control frequency: All - Type: Worksheet - Template: Select any one - Success conditions: Match all the following rules - Created by: Is set - Create a receipt order: - Product: Select any product - Confirm the receipt → A quality check is created - Click on the "Quality Check" smart button - Open the Worksheet" - Complete the worksheet Pro
Original PR description
Steps to reproduce the bug: - Create a quality point: - Operations: Receipt - Control per: Product - Control frequency: All - Type: Worksheet - Template: Select any one - Success conditions: Match…
Steps to reproduce the bug:
- Create a quality point:
- Operations: Receipt
- Control per: Product
- Control frequency: All
- Type: Worksheet
- Template: Select any one
- Success conditions: Match all the following rules
- Created by: Is set
- Create a receipt order:
- Product: Select any product
- Confirm the receipt → A quality check is created
- Click on the "Quality Check" smart button
- Open the Worksheet"
- Complete the worksheet
Problem:
The quality check is not being automatically marked as passed or failed.
When accessing the worksheet through the quality check view, the
function “action_quality_worksheet” is called instead of
“action_open_quality_check_wizard” , which means that the key
“quality_wizard_id” is not added to the context:
https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L64
However, when clicking on save, the function “action_worksheet_check”
is triggered:
https://github.com/odoo/enterprise/blob/b51da60213232ccbc537c399e1c007d6051e40ae/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L19
At this point, the system checks whether “quality_wizard_id” is present
in the context to proceed with the quality check; otherwise, it simply
closes the wizard:
https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L95-L97
https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L98-L100
Opw-4652268
Forward-Port-Of: odoo/enterprise#82225- Adding Libro Diario as a standalone report type. - Adding Libro de Inventario y Balance as a subtype of Balance Sheet report. task-4483080 Forward-Port-Of: odoo/enterprise#82440 Forward-Port-Of: odoo/enterprise#77857
Original PR description
- Adding Libro Diario as a standalone report type. - Adding Libro de Inventario y Balance as a subtype of Balance Sheet report. task-4483080 Forward-Port-Of: odoo/enterprise#82440 Forward-Port-Of: odoo/enterprise#77857
Currently a ParseError is arising when the user installs the `hr_referral` module after deleting all Stages in Recruitment/Configuration. Steps to reproduce: --- - Install `hr_recruitment` application (without demo data). - Delete all `Stages` in Recruitment > Configuration - Now install `hr_referral` module Traceback: --- ``` Exception: Cannot update missing record 'hr_recruitment.stage_job3' ParseError while parsing /home/odoo/src/enterprise/saas-18.1/hr_referral/data/data.xml
Original PR description
Currently a ParseError is arising when the user installs the `hr_referral` module after deleting all Stages in Recruitment/Configuration. Steps to reproduce: --- - Install `hr_recruitment`…
Currently a ParseError is arising when the user installs the `hr_referral` module after deleting all Stages in Recruitment/Configuration.
Steps to reproduce:
---
- Install `hr_recruitment` application (without demo data).
- Delete all `Stages` in Recruitment > Configuration
- Now install `hr_referral` module
Traceback:
---
```
Exception: Cannot update missing record 'hr_recruitment.stage_job3'
ParseError
while parsing /home/odoo/src/enterprise/saas-18.1/hr_referral/data/data.xml:93, somewhere inside <record model="hr.recruitment.stage" id="hr_recruitment.stage_job3">
<field name="use_in_referral">True</field>
</record>
```
The error occurs because the user deleted all `Stages` in Recruitment, and then tried to install the other module.
This commit solves the above issue by using `forcecreate` False to bypass record creation if it violates checks.
https://github.com/odoo/odoo/blob/f5378fadf910d193cbb44a4d1c10a5a15d8b9a51/odoo/tools/convert.py#L364
sentry-5731062091
Forward-Port-Of: odoo/enterprise#80139When importing an ofx bank statement, we try to parse the raw attachment value, in case of UnicodeDecodeError, we try to get an encoding declaration in the file, and fallback on 'utf-8'. But we can still face a file that is not well encoded and we end up with a traceback. With this commit, we display a UserError instead of the ugly traceback. opw-4526766 Forward-Port-Of: odoo/enterprise#82482 Forward-Port-Of: odoo/enterprise#81561
Original PR description
When importing an ofx bank statement, we try to parse the raw attachment value, in case of UnicodeDecodeError, we try to get an encoding declaration in the file, and fallback on 'utf-8'. But we can still face a file that is not well encoded and we end up with a traceback. With this commit, we display a UserError instead of the ugly traceback. opw-4526766 Forward-Port-Of: odoo/enterprise#82482 Forward-Port-Of: odoo/enterprise#81561
The tests for assets are lacking a freeze_time, and so, fail beginning 31st of March runbot-162150 Forward-Port-Of: odoo/enterprise#82520
Original PR description
The tests for assets are lacking a freeze_time, and so, fail beginning 31st of March runbot-162150 Forward-Port-Of: odoo/enterprise#82520
Changes are introduced to ensure compliance with the regulations established by SUNAT in the context of inventory management, specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally, functionality and data presentation improvements are included to facilitate analysis and interpretation for end users. Main Changes: 1. Initial Balance for the Period - The initial balance of products in stock at the start of the fiscal period is added. - Code is introduced to identi
Original PR description
Changes are introduced to ensure compliance with the regulations established by SUNAT in the context of inventory management, specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally,…
Changes are introduced to ensure compliance with the regulations
established by SUNAT in the context of inventory management,
specifically as outlined in Resolution No. 234-2006/SUNAT. Additionally,
functionality and data presentation improvements are included to
facilitate analysis and interpretation for end users.
Main Changes:
1. Initial Balance for the Period
- The initial balance of products in stock at the start of the fiscal
period is added.
- Code is introduced to identify the initial balance.
2. Corrections in Inventory Valuation
- Fields related to product entries and exits in inventory valuation are
adjusted.
3. Optimized Presentation Order
- A new sorting criterion is established for the records:
- Priority 1: Sort by product code (column 7).
- Priority 2: Sort by date (column 10).
- This allows for better analysis and interpretation, as well as ensuring
correct printing.
4. Delivery Guide Number as the Primary Indicator
- Fields 11, 12, and 13 now use the delivery guide number as the primary
indicator, complying with regulations.
- This includes the delivery guide number corresponding to the transfer
document, payment voucher, internal document, or similar.
Forward-Port-Of: odoo/enterprise#79404
Forward-Port-Of: odoo/enterprise#72064**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests) When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations. This fix ensures the name field is set to False whenever the computed result is
Original PR description
**[FIX] account_asset: fix empty string and False/None inconsistencies** (adapting tests)
When empty, the name field of account.move.line could inconsistently hold either an empty string or False. This inconsistency led to different results when searching for lines with an empty label, as label->not set and label == "" yielded different outcomes. The latter behavior aligns with expected ORM operations.
This fix ensures the name field is set to False whenever the computed result is an empty string, standardizing search behavior. We also adapt some tests to the new behavior in enterprise.
opw-4167139
[community PR](https://github.com/odoo/odoo/pull/186079)
Forward-Port-Of: odoo/enterprise#80167
Forward-Port-Of: odoo/enterprise#73256When scanning a package, its content is added on the view, but we don't display the expiration date. To reproduce the issue: 1. In Settings, enable: - Packages - Expiration dates 2. Create a product - Tracked by lot - Expiration date 3. Update its quantity - Lot L - Package P - Quantity > 0 4. Set an expiration date on L 5. Open a new delivery through the barcode app 6. Scan P "Error": a line is added for the product, with its lot L, but we don't display
Original PR description
When scanning a package, its content is added on the view, but we don't display the expiration date. To reproduce the issue: 1. In Settings, enable: - Packages - Expiration dates 2. Create a product - Tracked by lot - Expiration date 3. Update its quantity - Lot L - Package P - Quantity > 0 4. Set an expiration date on L 5. Open a new delivery through the barcode app 6. Scan P "Error": a line is added for the product, with its lot L, but we don't display the expiration date. Once the line is saved (for instance, through the edit button), we will finally display it. This is because we don't provide any information about the expiration date when converting the package quant into relevant data. OPW-4516410 Forward-Port-Of: odoo/enterprise#82492 Forward-Port-Of: odoo/enterprise#81825
Steps to reproduce ================== 1. Go to appointment 2. Pick an appointment having bookings > 1 3. Go to the list view of bookings. 4. Multi edit the capacity_reserved --> Traceback Issue ===== In the inverse function for capacity_reserved, we used self to access resource_total_capacity_reserved. Use event of self to access the attribute. Task- 4680286 Forward-Port-Of: odoo/enterprise#82405
Original PR description
Steps to reproduce ================== 1. Go to appointment 2. Pick an appointment having bookings > 1 3. Go to the list view of bookings. 4. Multi edit the capacity_reserved --> Traceback Issue ===== In the inverse function for capacity_reserved, we used self to access resource_total_capacity_reserved. Use event of self to access the attribute. Task- 4680286 Forward-Port-Of: odoo/enterprise#82405
Before this commit: The test consist in extending a pill using drag & drop mouse event. When the mouse drag too close from the side of the gantt view, it will automatically scroll the view to allow to extend to further invisible month = side scrolling This was the case here as the browser window in test mode is set to 1366 x 768 which was making the pill very close from the side of the window. When the mouse drop happen (after the drag) this could end up being on a another month that the
Original PR description
Before this commit: The test consist in extending a pill using drag & drop mouse event. When the mouse drag too close from the side of the gantt view, it will automatically scroll the view to allow to extend to further invisible month = side scrolling This was the case here as the browser window in test mode is set to 1366 x 768 which was making the pill very close from the side of the window. When the mouse drop happen (after the drag) this could end up being on a another month that the expected one due to the automatic side-scroll.  After this commit: We initially scroll the gantt view so that the pill is centered to avoid side-scrolling to trigger rb-145661 Forward-Port-Of: odoo/enterprise#81843
17 changes
Enhancements to existing features
The Documents upload menu now has cleaner spacing between icons and text. This small visual adjustment makes the menu easier to scan and gives the interface a more polished, consistent appearance.
Original PR description
**before:**  **after:** 
Resolved issues and error corrections
Portal users will no longer see the “Load templates” button in Knowledge when they cannot access any templates. This avoids confusion by only showing actions that are actually available to the user.
Original PR description
The `load templates` button was shown for portal users even though no template was accessible to them. This commit hides the button for portal users. Explanation: In the `knowledge.WysiwygArticleHelper` xml template, `isPortalUser` is used without having being instantiated in its related Component. Commit where `knowledge_article_html_field.js` was removed (previous scope for `isPortalUser` property for this feature): https://github.com/odoo/enterprise/commit/1e0f2950d613d6cd82d8889fb07bc04d6c91c466 Commit where `wysiwyg_article_helper.js` was introduced without the `isPortalUser` property (oversight): https://github.com/odoo/enterprise/commit/e001efc750d25d5dfcc681e42adf7a46edc7f37b task-4687833
This fix updates the field service sales walkthrough so its on-screen help uses the correct tooltip setting. It helps keep guided steps displayed properly for users following the tour, with no expected change to business workflows.
Original PR description
In this commit, `position` has been replaced with `tooltipPosition`, as explained in the commit message. https://github.com/odoo/enterprise/commit/b7fc47fec39885ed1f9f99040ceaabefa539bc7b
This fix avoids unnecessary reading of all sales spreadsheets when users work with sale order spreadsheets. It improves performance without changing what users can access or how sales order security rules apply.
Original PR description
Users don't need to be able to read all spreadsheet. It hurts performance. Task: 4656165
Miscellaneous changes
To improve readability and performance, partners with a zero initial balance are now excluded from the partner ledger reports. task-4578612 Forward-Port-Of: odoo/enterprise#82593 Forward-Port-Of: odoo/enterprise#81642
Original PR description
To improve readability and performance, partners with a zero initial balance are now excluded from the partner ledger reports. task-4578612 Forward-Port-Of: odoo/enterprise#82593 Forward-Port-Of: odoo/enterprise#81642
In some cases, Amazon can confirm the delivery of a FBM order before the user confirm the picking. In these cases, 2 problems arise: - The synchronization of the picking will fail because Amazon will return an error, since the picking was already delivered. - If the user doesn't fill the Amazon required fields, there will be a user error, even if the carrier reference and tracking numbers are already available in Amazon's backend. To solve this, as we know when an order was successfully deliv
Original PR description
In some cases, Amazon can confirm the delivery of a FBM order before the user confirm the picking. In these cases, 2 problems arise: - The synchronization of the picking will fail because Amazon will return an error, since the picking was already delivered. - If the user doesn't fill the Amazon required fields, there will be a user error, even if the carrier reference and tracking numbers are already available in Amazon's backend. To solve this, as we know when an order was successfully delivered, we won't consider these pickings as being needed for Amazon any more. task-4524195 Forward-Port-Of: odoo/enterprise#78188
### Issue When using the `Send HR Documents Access Link` action, Odoo always assumes that the company has set a `documents_hr_folder` already. However, this can easily not be the case if the customer has never activated `documents_hr_setting` and chosen a Workspace. If this is the case, we'll encounter an error when creating the `document.share` record, since `folder_id` is required. ### Solution Display an error directing the customer to activate an HR Workspace folder so they can properly
Original PR description
### Issue When using the `Send HR Documents Access Link` action, Odoo always assumes that the company has set a `documents_hr_folder` already. However, this can easily not be the case if the customer has never activated `documents_hr_setting` and chosen a Workspace. If this is the case, we'll encounter an error when creating the `document.share` record, since `folder_id` is required. ### Solution Display an error directing the customer to activate an HR Workspace folder so they can properly use the feature. opw-4559772 Forward-Port-Of: odoo/enterprise#81523
This commit modifies Elvera and Roque demo data for hr mexican localization target: 17.0 -> master task-4486643 Forward-Port-Of: odoo/enterprise#80451 Forward-Port-Of: odoo/enterprise#78048
Original PR description
This commit modifies Elvera and Roque demo data for hr mexican localization target: 17.0 -> master task-4486643 Forward-Port-Of: odoo/enterprise#80451 Forward-Port-Of: odoo/enterprise#78048
`prevent_zero_price_sale` was not set according to the right prices for `website_sale_renting` and `website_sale_subscription` opw-4650460 See also: https://github.com/odoo/odoo/pull/202867 Forward-Port-Of: odoo/enterprise#82183 Forward-Port-Of: odoo/enterprise#82082
Original PR description
`prevent_zero_price_sale` was not set according to the right prices for `website_sale_renting` and `website_sale_subscription` opw-4650460 See also: https://github.com/odoo/odoo/pull/202867 Forward-Port-Of: odoo/enterprise#82183 Forward-Port-Of: odoo/enterprise#82082
An error is encountered in the `Modify Asset` wizard when resuming `Asset Depreciation` after manually increasing `Non Depreciable Amount`. The system attempts to record the change as a gain, requiring a `Depreciation Account`. However, this field is hidden, preventing users from fixing the problem, so they are blocked. Steps to reproduce: - Create a running asset - Click `Modify Depreciation` > `Pause` - Click `Resume Depreciation` and open the `asset.modify` wizard. - Increase `Not Depr
Original PR description
An error is encountered in the `Modify Asset` wizard when resuming `Asset Depreciation` after manually increasing `Non Depreciable Amount`. The system attempts to record the change as a gain, requiring a `Depreciation Account`. However, this field is hidden, preventing users from fixing the problem, so they are blocked. Steps to reproduce: - Create a running asset - Click `Modify Depreciation` > `Pause` - Click `Resume Depreciation` and open the `asset.modify` wizard. - Increase `Not Depreciable Amount`, realizing a gain - Press the `Resume` button Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4472309) opw-4472309 Forward-Port-Of: odoo/enterprise#82512 Forward-Port-Of: odoo/enterprise#79181
**Issue** When mergring two records with a chatter (e.g. Tasks), no log note appears in the chatter of the destination or source records. **Cause** The template changed modules when `data_cleaning` and `data_merge` were merged in 4fc497861fbefee7f4761c3341a3c2bd289edb31 opw-4513322 Forward-Port-Of: odoo/enterprise#81136
Original PR description
**Issue** When mergring two records with a chatter (e.g. Tasks), no log note appears in the chatter of the destination or source records. **Cause** The template changed modules when `data_cleaning` and `data_merge` were merged in 4fc497861fbefee7f4761c3341a3c2bd289edb31 opw-4513322 Forward-Port-Of: odoo/enterprise#81136
Steps to reproduce the bug: - Create a quality point: - Operations: Receipt - Control per: Product - Control frequency: All - Type: Worksheet - Template: Select any one - Success conditions: Match all the following rules - Created by: Is set - Create a receipt order: - Product: Select any product - Confirm the receipt → A quality check is created - Click on the "Quality Check" smart button - Open the Worksheet" - Complete the worksheet Pro
Original PR description
Steps to reproduce the bug: - Create a quality point: - Operations: Receipt - Control per: Product - Control frequency: All - Type: Worksheet - Template: Select any one - Success conditions: Match…
Steps to reproduce the bug:
- Create a quality point:
- Operations: Receipt
- Control per: Product
- Control frequency: All
- Type: Worksheet
- Template: Select any one
- Success conditions: Match all the following rules
- Created by: Is set
- Create a receipt order:
- Product: Select any product
- Confirm the receipt → A quality check is created
- Click on the "Quality Check" smart button
- Open the Worksheet"
- Complete the worksheet
Problem:
The quality check is not being automatically marked as passed or failed.
When accessing the worksheet through the quality check view, the
function “action_quality_worksheet” is called instead of
“action_open_quality_check_wizard” , which means that the key
“quality_wizard_id” is not added to the context:
https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L64
However, when clicking on save, the function “action_worksheet_check”
is triggered:
https://github.com/odoo/enterprise/blob/b51da60213232ccbc537c399e1c007d6051e40ae/quality_control_worksheet/static/src/views/quality_worksheet_fromview.js#L19
At this point, the system checks whether “quality_wizard_id” is present
in the context to proceed with the quality check; otherwise, it simply
closes the wizard:
https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L95-L97
https://github.com/odoo/enterprise/blob/d7cb885c93876259e9e72d7254f4a2e614abbe0d/quality_control_worksheet/models/quality.py#L98-L100
Opw-4652268
Forward-Port-Of: odoo/enterprise#82225https://www.awesomescreenshot.com/image/53270541?key=2bf6f954c641f8dcfc8d0a524bb6e0e0 How to reproduce: - Make comment on any of the post under any social media. Just one condition, make sure to include any of the following characters (&, <, >, ', , `). - Post the comment. - Now try to edit the comment. - You will see that the special characters which I have mentioned above have been replaced with their HTML entities. Issue: - When we click on edit, we first `escape()` the conte
Original PR description
https://www.awesomescreenshot.com/image/53270541?key=2bf6f954c641f8dcfc8d0a524bb6e0e0 How to reproduce: - Make comment on any of the post under any social media. Just one condition, make sure to include any of the following characters (&, <, >, ', , `). - Post the comment. - Now try to edit the comment. - You will see that the special characters which I have mentioned above have been replaced with their HTML entities. Issue: - When we click on edit, we first `escape()` the contents of the message and then display it in the `textarea`. Fix: - We now display the comment through the value attribute of the `textarea` element, which by default displays the contents as plaintext. Hence, eliminating the need to escape it. Task-4184968 Forward-Port-Of: odoo/enterprise#82414
When importing an ofx bank statement, we try to parse the raw attachment value, in case of UnicodeDecodeError, we try to get an encoding declaration in the file, and fallback on 'utf-8'. But we can still face a file that is not well encoded and we end up with a traceback. With this commit, we display a UserError instead of the ugly traceback. opw-4526766 Forward-Port-Of: odoo/enterprise#82482 Forward-Port-Of: odoo/enterprise#81561
Original PR description
When importing an ofx bank statement, we try to parse the raw attachment value, in case of UnicodeDecodeError, we try to get an encoding declaration in the file, and fallback on 'utf-8'. But we can still face a file that is not well encoded and we end up with a traceback. With this commit, we display a UserError instead of the ugly traceback. opw-4526766 Forward-Port-Of: odoo/enterprise#82482 Forward-Port-Of: odoo/enterprise#81561
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the bu
Original PR description
* stock{,_barcode, _barcode_quality_control}, quality_control ### Issue: Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a…
* stock{,_barcode, _barcode_quality_control}, quality_control
### Issue:
Quality checks per operation and per product are generated by an override of the action confirm of the move. However, if a move line is created on a non draft picking, it will end up in a move that will never be confirmed. This happends because the move is created with a state to match its already existing picking and hence is not confirmed at creation and since only draft pickings are confirmed at the start of the button validate. As a result, we will not create the quality checks related to these additional moves.
The above issue can be triggered in many situations. Here are the two major ones:
### Use case I:
Creating a delivery or an internal transfer on the fly from the barcode app.
### Steps to reproduce:
- Create a storable product P with a barcode: XXX
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product: Control per: "Operation" Operations: "Delivery"
- Go to the barcode app > Operations > Delivery > New
- Scan your product
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
The `save_barcode_data` will launch the creation of the move line related to the barcode line you edited from the barcode app. During the create of this 'stock.move.line', an associated move will be created and its initial "state" will be the current state of the picking: https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L354-L356 https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L942 At this point the picking state is "draft" and the move will be correctly created in draft. However, just a few lines after its creation, we will check if a reservation should be done with that move and if its state should be recomputed:
https://github.com/odoo/odoo/blob/ba799a020dd2b07c9d6c379e23acee1e6fcc5e0a/addons/stock/models/stock_move_line.py#L379-L396 the discrepancy is caused by the fact that `move._should_bypass_reservation` will be true if the picking is a receipt and false for the other types because you should bypass reservation for moves whose source is not an internal location but you should not for others. This will leave the moves and picking in draft state if its a receipt and update it for other types. However, only draft pickings are confirmed at the beginning of the button validate: https://github.com/odoo/odoo/blob/b0cfeecacfc6b95659778dfe4d62435556aaa92c/addons/stock/models/stock_picking.py#L1131-L1133
### Use case II:
Create and confirm a picking of any type so that it ends up being assigned. Add manually a move line via the detailed operations.
### Steps to reproduce:
- Create two storable product P1 and P2 put 10 units of both in stock
- Go to Quality > Quality Control > Quality Points > New
- Create a new quality point for your product P2: Control per: "Operation" Operations: "Delivery"
- Create and confirm a Delivery for 1 unit P1
- Go to Detailed Operations > create a new line for 1 unit of P2
- Validate the Delivery
#### > the picking is done but no QC was created nor processed.
### Cause of the issue:
For the same reasons as above, the newly created move is assigned as it mimics the state of the current picking which is assigned since we have already reserved the already existing move.
### Fix:
We ensure the creation of quality checks for moves that end up being created but will never be confirmed.
### Technical limitation:
Unfortunately, it is not possible to manage the use case of quality checks related the component of a kit product without disrupting the barcode flows. Indeed, in barcode flows, the move line as well as its related move is created by a `save_barcode_data`. If we were to confirm the newly created moves rather than just trying to create the QC, it would indeed first explode the bom and then create the related QC for each component. However, the barcode data would not coincide anymore with the back end data since the line we just saved would have been exploded at backend creation. For that reason we do not yet support the above use cases for kit products.
Community: https://github.com/odoo/odoo/pull/202725
opw-4480104
Forward-Port-Of: odoo/enterprise#81903
Forward-Port-Of: odoo/enterprise#81850The tests for assets are lacking a freeze_time, and so, fail beginning 31st of March runbot-162150 Forward-Port-Of: odoo/enterprise#82520
Original PR description
The tests for assets are lacking a freeze_time, and so, fail beginning 31st of March runbot-162150 Forward-Port-Of: odoo/enterprise#82520
Fix an issue with the formula of the Other gain (loss) line. It was "-57 + -59" which in theory is a correct formula, but in practice it is not handled well by the report engine and the + will match many other accounts that we don't want. It is corrected to be "-57 - 59". Forward-Port-Of: odoo/enterprise#82387
Original PR description
Fix an issue with the formula of the Other gain (loss) line. It was "-57 + -59" which in theory is a correct formula, but in practice it is not handled well by the report engine and the + will match many other accounts that we don't want. It is corrected to be "-57 - 59". Forward-Port-Of: odoo/enterprise#82387