Wednesday, February 12, 2025
24 changes · master
Enhancements to existing features
The sales subscription performance test was adjusted to reflect a small extra system check introduced by new default quotation document settings. This keeps automated testing aligned with the updated sales order process without changing the user experience.
Original PR description
A new feature in the community version allows users to set default quotation documents for sales orders. This introduces an additional query in the sale order creation flow. This commit increases the max query count of a performance test to accommodate these new queries. task-4307011
This update streamlines how planning and shift links are created by using one shared method instead of two separate ones. It helps keep Planning access links consistent and easier to maintain, with updated parameters for dates, employees, and access tokens.
Original PR description
In this PR we merge the _planning_get_url and _slot_get_url method and make a single method _planning_get_url. we also change the some parameters 1. date_start 2. date_end 3. employees 4. planning_access_token task-4156813
The Sign app no longer keeps an unused availability marker for signing options. This simplifies internal option handling now that options are created when needed and reused, with no expected change for everyday users.
Original PR description
This commit removes the 'available' field from the 'sign.item.option' model as it is not used anymore neither its logic. After odoo/enterprise#75291 we create options on demand and reuse the previous options for avoiding duplicating it, with the available field being True or False. issue-from: 75291 task-4387560
The Web Studio editor now displays existing fields in alphabetical order. This makes it quicker and more predictable for users to find the field they need when customizing views.
Original PR description
**Before:** The fields under `Existing Fields` were not displayed in alphabetical order. **After:** The fields under `Existing Fields` are displayed in alphabetical order. task-4544703
Resolved issues and error corrections
This fixes an error that occurred when loading sample appraisal data in databases without demo data. The sample data now matches the updated goal manager setup, so users can try the Appraisal app without hitting a crash.
Original PR description
STEPS TO REPRODUCE: 1- Install a database without demo data 2- Go on Appraisal 3- Click on Load sample data You will have a traceback Reason: Before a goal only has one manager, and now multiples managers can be linked to a goal (introduced by this commit : https://github.com/odoo/enterprise/commit/dd90f66a536539413a3886e0f165d30d8f79ef89 ) task-4563359
Miscellaneous changes
If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones. task-4557882 Forward
Original PR description
If a custom handler handles the caret builder, it used to only consider this function, and therefore not benefiting from the generic keys provided by the default function of the report engine. This can cause minor disadvantage such as when a user change himself the groupby keys of a report with a custom engine. In this case, the caret options won't be visible at all. With the change of this commit, the custom handler caret options will be used on top of the default ones. task-4557882 Forward-Port-Of: odoo/enterprise#78800
This update fixes two minor issues in the Czech reports module: a duplicated read-only setting in an accounting screen and inconsistent internal logic for a reporting code calculation. These changes help keep accounting report behavior cleaner and more consistent without changing user workflows.
Original PR description
This commit fixes the following issues of the module l10n_cz_reports: 1. The readonly attribute was duplicated in account move view. 2. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical). X-original-commit: https://github.com/odoo-dev/enterprise/commit/71279841b3db65f577804e0749b594aea386d67b
This fixes two small visual inconsistencies on the Helpdesk website form page. The form title now matches the standard front-end title styling, and the card background no longer depends on a theme color that may vary by customer setup.
Original PR description
This PR fixes two minor color issues on the `website_helpdesk` form page. Prior to this PR, the title of the form was using a `text-muted`, which is inconsistent with the other titles design across the front-end. There was also an issue about the card using a `bg-secondary` utility class to tweak its design, which doesn't work anymore with the new secondary color we introduced in 13d4d48 and highlight the fact we can't rely on utility classes for this scenario since we don't know what color will be set by the user. | Master | This PR | |--------|--------| |  |  | task-4498381
Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of the alias 4. You are asked to configure servers again and you cannot set any value for the alias. Redirecting to the company settings is cumbersome and unlikely useful. Erp managers should be able to quick create here as in the company settings, as aliases are not company specific when
Original PR description
Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of…
Commit 1: [FIX] documents: fix showing alias fields on details panel Reproduce: 1. Go to a folder on the kanban view 2. If not configured, configure Email Servers, then redo 1. 3. Clear the domain of the alias 4. You are asked to configure servers again and you cannot set any value for the alias. Redirecting to the company settings is cumbersome and unlikely useful. Erp managers should be able to quick create here as in the company settings, as aliases are not company specific when receiving. Technically, removing `load=False` on `documents_unique_folder_id` (added when there is a `search_panel_default_folder_id` without `no_documents_unique_folder_id` in context) is necessary to load the existing `alias_domain_id`'s `display_name`. Commit 2: [FIX] documents: fix reloading only search panel It is not necessary to reload the model when we want to reload the search panel. Commit 3: [FIX] documents: fix validation error on saving container These records' methods are sometimes called when there is no point (and don't work), because the record is not part of the view. This can be seen for example when adding alias tags. Commit 4: Reproduce: As an internal user not documents manager, open the details panel on a company root folder with access_internal="edit". The fields are not rendered as readonly as they should. Test data updated in documents_spreadsheet. Task-4543501 Forward-Port-Of: odoo/enterprise#79019 Forward-Port-Of: odoo/enterprise#78375
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/enterprise#79077 Forward-Port-Of: odoo/enterprise#74412
Original PR description
When creating a SOL on the fly from a project or a ticket, we try to match an existing product from what was typed in the field. However, we should be excluding recurring services Task-4354482 Forward-Port-Of: odoo/enterprise#79077 Forward-Port-Of: odoo/enterprise#74412
In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when creating a Boleta Electronica and adding a Cross Reference Document, the EDI system will not validate correctly the xml, with error `Error en Schema [0] LSX-00204: extra data at end of complex element` This occurs because the system first creates a dte from a common xml schema, then wrap
Original PR description
In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when…
In Chile localization it is possible to add a Related Document when creating an Invoice Document. These documents info are then added to the Electronic Invoice sent to the government. Currently, when creating a Boleta Electronica and adding a Cross Reference Document, the EDI system will not validate correctly the xml, with error `Error en Schema [0] LSX-00204: extra data at end of complex element` This occurs because the system first creates a dte from a common xml schema, then wrap it with the appropriate envelope. However the schema of Boletas slighly differs[1], as it doesn't have the field FchRef, so it gets rejected by SII A solution is to modify the code of dte_subtemplate to make sure that FchRef only appears if the Schema corresponds to http://www.sii.cl/SiiDte EnvioDTE_v10.xsd, and not to http://www.sii.cl/SiiDte EnvioBOLETA_v11.xsd [1] https://www.sii.cl/factura_electronica/factura_mercado/formato_boletas_elec_202412.pdf opw-4433202 Forward-Port-Of: odoo/enterprise#78177
ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#79026 Forward-Port-Of: odoo/enterprise#64454
Original PR description
ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#79026 Forward-Port-Of: odoo/enterprise#64454
A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78927 Forward-Port-Of: odoo/enterprise#77991
Original PR description
A standard such as RiBa that everyone calls RiBA should not have any invented translation like Payment Receipt (IT). Followup for the Ri.Ba. task: odoo/enterprise#74097 Documentation PR: odoo/documentation#11847 Task [link](https://www.odoo.com/odoo/project/967/tasks/4497749) task-4497749 Forward-Port-Of: odoo/enterprise#78927 Forward-Port-Of: odoo/enterprise#77991
Before this commit, the leaderboard data is fetched even if we are sure the feature is disabled. This commit checks the feature is enabled before getting leaderboard data. task-4509858 Forward-Port-Of: odoo/enterprise#79060 Forward-Port-Of: odoo/enterprise#78858
Original PR description
Before this commit, the leaderboard data is fetched even if we are sure the feature is disabled. This commit checks the feature is enabled before getting leaderboard data. task-4509858 Forward-Port-Of: odoo/enterprise#79060 Forward-Port-Of: odoo/enterprise#78858
The subsidy is now computed based on the daily UMA and a new rule parameter, a percentage. Task: 4465315 Forward-Port-Of: odoo/enterprise#78075
Original PR description
The subsidy is now computed based on the daily UMA and a new rule parameter, a percentage. Task: 4465315 Forward-Port-Of: odoo/enterprise#78075
*: barcode, barcode_mrp This commit includes updates to and serial/lot number display features: - When the 'show sn/lot' feature is disabled for an operation type, unreserved serial/lot lines will no longer be highlighted with a red background. - The '/qty' demand field for sn/lot sublines is hidden when `Show Reserved SN/Lot` is disabled. Task: [3926998](https://www.odoo.com/odoo/my-tasks/3926998) Forward-Port-Of: odoo/enterprise#79118 Forward-Port-Of: odoo/enterprise#68153
Original PR description
*: barcode, barcode_mrp This commit includes updates to and serial/lot number display features: - When the 'show sn/lot' feature is disabled for an operation type, unreserved serial/lot lines will no longer be highlighted with a red background. - The '/qty' demand field for sn/lot sublines is hidden when `Show Reserved SN/Lot` is disabled. Task: [3926998](https://www.odoo.com/odoo/my-tasks/3926998) Forward-Port-Of: odoo/enterprise#79118 Forward-Port-Of: odoo/enterprise#68153
Previously, the database view generated for the meal vouchers report in the Belgian localization didn't have an id which caused an error on the runbot. This commit fixes this issue by generating the id. task-4463505 Forward-Port-Of: odoo/enterprise#76735
Original PR description
Previously, the database view generated for the meal vouchers report in the Belgian localization didn't have an id which caused an error on the runbot. This commit fixes this issue by generating the id. task-4463505 Forward-Port-Of: odoo/enterprise#76735
ADHOC ticket 85864 Forward-Port-Of: odoo/enterprise#76488
Original PR description
ADHOC ticket 85864 Forward-Port-Of: odoo/enterprise#76488
Problem --------- Currently, there is a discrepancy between the year filter in the reports and spreadsheet. In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year. For example, if the fiscal year starts on the 1st of April (01/04), - in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024; - in spreadsheet, the 2024
Original PR description
Problem --------- Currently, there is a discrepancy between the year filter in the reports and spreadsheet. In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the…
Problem --------- Currently, there is a discrepancy between the year filter in the reports and spreadsheet. In the reports, when using the YEAR filter, it will use the fiscal year that ENDS in the set year. On the contrary, in spreadsheet, the filter will use the fiscal year that STARTS in the set year. For example, if the fiscal year starts on the 1st of April (01/04), - in the reports, the 2024 date range filters the moves between 01/04/2023 and 31/03/2024; - in spreadsheet, the 2024 date range filters the moves between 01/04/2024 and 31/03/2025. This behavior is explained by the fact that we use the current day to compute the fiscal year in the reports. Objective --------- Make the report year filter behave like in spreadsheet. Solution --------- Update the initiation of the date option in the report options so that, if the year filter is used, we compute the start of fiscal year that will begin in the selected year rather than the fiscal year we currently are in. We then use this fiscal year value to compute the relevant date range like before. opw-4493556 Forward-Port-Of: odoo/enterprise#78486
The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces. [1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip [task-4373106](https://www.odoo.com/odoo/project.task/4373106) Forward-Port-Of: odoo/enterprise#78540
Original PR description
The taxonomy for the Dutch tax reports was updated from [NT18 to NT19][1]. There were only changes in the namespaces. [1]: https://www.sbr-nl.nl/sites/default/files/bestanden/taxonomie/NT19_BD_20241211%20Versioning_rpt-from_NT18_20231213_to_NT19_20241211.zip [task-4373106](https://www.odoo.com/odoo/project.task/4373106) Forward-Port-Of: odoo/enterprise#78540
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77 Steps to reproduce the bug: - Create a storable product “P1” - Create two different MOs: - First MO: 1 unit of P1 - Second MO: 2 units of P1 - Confirm and mark them as done - Go to the manufacturing list view - Select both MOs - Print Cost Analysis Problem: The mo_qty is 2 units instead of 3; only the quantity of the last MO is taken into account. This is beca
Original PR description
Bug introduced by this commit: https://github.com/odoo/enterprise/commit/4b312d56e7fa01ab4e8f534a1e62ef59e1421f77
Steps to reproduce the bug:
- Create a storable product “P1”
- Create two different MOs:
- First MO: 1 unit of P1
- Second MO: 2 units of P1
- Confirm and mark them as done
- Go to the manufacturing list view
- Select both MOs
- Print Cost Analysis
Problem:
The mo_qty is 2 units instead of 3;
only the quantity of the last MO is taken into account. This is because, to calculate the total quantity of all MOs, we use a variable mo_qty, but it is initialized twice, once before the loop and again within the MO loop, so for each MO, the counter is reset to 0.
opw-4529333
Forward-Port-Of: odoo/enterprise#78731### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor, click on the instruction to open a dialog. - Spam the Pass button #### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId') ### Cause of the issue: Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a
Original PR description
### Steps to reproduce: - Create a bom for a product FP: - 1 x COMP (component) - operations: OP1: - instruction: - type: pass/fail, - Create and confirm an MO for 1 unit of FP - Go to the shopfloor,…
### Steps to reproduce:
- Create a bom for a product FP:
- 1 x COMP (component)
- operations: OP1:
- instruction: - type: pass/fail,
- Create and confirm an MO for 1 unit of FP
- Go to the shopfloor, click on the instruction to open a dialog.
- Spam the Pass button
#### > Traceback: Uncaught Promise: Cannot read properties of undefined (reading 'resId')
### Cause of the issue:
Clicking on a footer button of the `MrpQualityCheckConfirmationDialog` will trigger a call of the `doActionAndClose` method: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/dialog/mrp_quality_check_confirmation_dialog.js#L93-L113 A the end of this call a `qualityCheckDone` is called to complete the operation which to work properly expects a `lastOpenedQualityCheck` to be set. However, at the end of this call, `displayInstruction` is called to generate a new MRP dialog for the next instuction if even exist. And, during this call if th ecurrent record (instruction) correspond to the `lastOpenedQualityCheck`, the value will be erased: https://github.com/odoo/enterprise/blob/55c6292ff9d59ff09b1d81a61752765cf70d72c0/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L337-L340 This causes the error because if you click too fast you will clean the value that you are suppose to use in the next call `qualityCheckDone` which will explode.
### Fix:
We diasble the buttons of the Dialog once a a call of the `doActionAndClose` is triggered. That way, it becomes impossible to spam an action that is already processing the info. This is a backport the part of e4190f1ea2c89439d2cd4afa5137d0fedb06431e related to our issue. In addition to this bacport we apply this change on the `MrpRegisterProductionDialog` extending the `MrpQualityCheckConfirmationDialog` to limit the amount of rpc called performed by validating a registration (prior, you could spam the validate button to encode the exact same value multiple times).
### Note:
By opposition to e4190f1ea2c89439d2cd4afa5137d0fedb06431e we do not disable the buttons during the `openWorksheet` since a priori this action does not close the dialog and we might want to press other buttons on the dialog once this action has been performed.
opw-4352828
Forward-Port-Of: odoo/enterprise#79017
Forward-Port-Of: odoo/enterprise#74795Forward-Port-Of: odoo/enterprise#79083
Original PR description
Forward-Port-Of: odoo/enterprise#79083
Before this PR: AEC file is sent encoded as base64. After this PR: we decode the file properly Forward-Port-Of: odoo/enterprise#79007
Original PR description
Before this PR: AEC file is sent encoded as base64. After this PR: we decode the file properly Forward-Port-Of: odoo/enterprise#79007