Friday, January 6, 2023
16 changes
Enhancements to existing features
This update prevents validation errors in specific Odoo views by removing an unsupported rental report directive and temporarily exempting the Knowledge article form from new validation rules. This helps keep affected screens working while stricter checks are introduced to improve system reliability.
Original PR description
[FIX] sale_renting: remove unsupported t-field in arch This commit is the enterprise counter part of odoo/odoo#107083. `t-field` isn't a valid qweb directive. As a matter of fact, the commit…
[FIX] sale_renting: remove unsupported t-field in arch This commit is the enterprise counter part of odoo/odoo#107083. `t-field` isn't a valid qweb directive. As a matter of fact, the commit introducing it noted that it wasn't working [1]. Now that we validate qweb directives used in archs, this one would throw an error. We thus remove it. Task 3085357 [1] https://github.com/odoo/enterprise/commit/11a41bb72a1f045702f37eddc0f583a025112d0c#diff-97c66f033e6f370fadfb24d5cea5f6a09ab3e95ceda55b0c90e38aa1c9d24425R75] [IMP] knowledge: ir.ui.view: bypass owl directives validation The arch of the knowledge article form view is written as an owl template. It uses several owl directives and a lot of js implementation details, which is forbidden. PR odoo/odoo#107083 adds validation steps to detect forbidden owl directives in archs. As a consequence, the knowledge form view would crash at validation. This commit bypasses the validation for the knowledge form view. This override could be removed as soon as that view is fixed (it should become a client action). Task 3085357
This update adds a validation check to ensure a view’s main structure matches its declared type. It helps prevent incorrectly configured views from being saved, reducing the risk of broken or inconsistent user interfaces.
Original PR description
This PR follows #108073
Just ensure the root node of the view architecture matches the view type.
e.g.
Valid:
```xml
<form>
...
</form>
```
Invalid:
```xml
<data>
<div>
...
</div>
<form>
...
</form>
</data>
```Resolved issues and error corrections
This fixes the app listing category for the IAP Extract feature, which had accidentally copied a setting from another module. The change helps keep the module organized in the right hidden tools area without affecting day-to-day users.
Original PR description
Before this commit, there was an unfortunate copy paste in the `iap_extract` module coming from the `hr_expense_extract` module.
Features or functions removed from Odoo
The timesheet reporting area no longer includes an unused grid view grouped by project, and related legacy logic has been removed. This simplifies the timesheet setup now that the relevant reports use pivot and graph views only, with minimal impact for users.
Original PR description
In that PR, we deprecated `_group_expand_project_ids` in stable: https://github.com/odoo/enterprise/pull/35402 This method was used in timesheet reporting. As only pivot and graph views are left in this action, it won't be called anymore. Also, we remove the corresponding view : grid grouped by project. task-3084945
Miscellaneous changes
The values of the field `l10n_co_edi_fiscal_regimen` have been changed by the DIAN several times in the past, the first version of UBL use the values with codes 48 and 49, but in the second version these codes didn’t match the new ones, so we decided to use the code of the Tax Type as it was the same code for the fiscal regimen. In the Anexo 1.8 two new values were added in the `l10n_co_edi_fiscal_regimen` that are not included in the Tax Type values. So in this commit, I have changed
Original PR description
The values of the field `l10n_co_edi_fiscal_regimen` have been changed by the DIAN several times in the past, the first version of UBL use the values with codes 48 and 49, but in the second version these codes didn’t match the new ones, so we decided to use the code of the Tax Type as it was the same code for the fiscal regimen. In the Anexo 1.8 two new values were added in the `l10n_co_edi_fiscal_regimen` that are not included in the Tax Type values. So in this commit, I have changed EMI_4, ITT_3 tags and GTE, GTA section values and added/updated the `l10n_co_edi_fiscal_regimen` selection in the partner. TaskID - 3095064 Forward-Port-Of: odoo/enterprise#35502 Forward-Port-Of: odoo/enterprise#35115
German financial reports now use English as the source text with German translations provided separately. This improves translation consistency and helps maintain the German reporting module more reliably.
Original PR description
Ideally, we develop in English any localization (then translate to the domestic language, in this case German) All the module has been translated in english and then a .po file has been create to translate back in German task-id: 3059115
There is two cases where the XAF export will cause tracebacks that can be easily improved: - When there is no move lines in the db, we should display an error and not a traceback. - When there is no tax lines in the db, the export should still go through, just without taxes. As of now, it would result in a traceback. Forward-Port-Of: odoo/enterprise#35521 Forward-Port-Of: odoo/enterprise#35354
Original PR description
There is two cases where the XAF export will cause tracebacks that can be easily improved: - When there is no move lines in the db, we should display an error and not a traceback. - When there is no tax lines in the db, the export should still go through, just without taxes. As of now, it would result in a traceback. Forward-Port-Of: odoo/enterprise#35521 Forward-Port-Of: odoo/enterprise#35354
How to reproduce: - Install l10n_be and go on a Belgian Company - create an account of type `Fixed Assets` - In automation tab of this account, tick 'Create in Draft' - tick 'Manage Items' - Create a bill with 2 invoice lines with the account and with tax '21% Car' - Confirm the bill - Create an asset by hand, selecting as related purchase the 2 lines you just created => Bug The problem was that we didn't consider that we could create an asset from there, only considering the automatic
Original PR description
How to reproduce: - Install l10n_be and go on a Belgian Company - create an account of type `Fixed Assets` - In automation tab of this account, tick 'Create in Draft' - tick 'Manage Items' - Create a bill with 2 invoice lines with the account and with tax '21% Car' - Confirm the bill - Create an asset by hand, selecting as related purchase the 2 lines you just created => Bug The problem was that we didn't consider that we could create an asset from there, only considering the automatically created ones. We now loop on each line to avoid this issue. Forward-Port-Of: odoo/enterprise#35509 Forward-Port-Of: odoo/enterprise#35263
Steps to reproduce: 1. Create a new user with admin rights to helpdesk and website. 2. Go to the helpdesk with the step1 user. 3. Go to Configration > Helpdesk teams > CREATE 4. Check the website form checkbox. 5. Save Bug: Access right error. Fix: access to ir_model_data is required to Create a website form opw-3083464 Forward-Port-Of: odoo/enterprise#35497 Forward-Port-Of: odoo/enterprise#35274
Original PR description
Steps to reproduce: 1. Create a new user with admin rights to helpdesk and website. 2. Go to the helpdesk with the step1 user. 3. Go to Configration > Helpdesk teams > CREATE 4. Check the website form checkbox. 5. Save Bug: Access right error. Fix: access to ir_model_data is required to Create a website form opw-3083464 Forward-Port-Of: odoo/enterprise#35497 Forward-Port-Of: odoo/enterprise#35274
## Current behaviour The planning templates names end time is not correct. ## Expected behaviour The end time should be coherent with the working schedule. A planning starting at 8AM with 10h duration should finish at 10AM the next day and not at 6PM the same day. ## Steps to reproduce - Install Planning - Go to Configuration > Shift Templates - Create a new template with start time at 8AM, duration 10h, Save - Observe the template name is incorrectly named 8AM - 6PM ## Reason for
Original PR description
## Current behaviour The planning templates names end time is not correct. ## Expected behaviour The end time should be coherent with the working schedule. A planning starting at 8AM with 10h…
## Current behaviour The planning templates names end time is not correct. ## Expected behaviour The end time should be coherent with the working schedule. A planning starting at 8AM with 10h duration should finish at 10AM the next day and not at 6PM the same day. ## Steps to reproduce - Install Planning - Go to Configuration > Shift Templates - Create a new template with start time at 8AM, duration 10h, Save - Observe the template name is incorrectly named 8AM - 6PM ## Reason for the problem Calculations for the end time of a planning wasn't taking into consideration the working schedule of the role. It was a simple `start_time + duration`. ## Fix Backport some code from 16.0 (there plannings takes work schedule into account on the model). Fix the template name to use the `end_time` of the model, which is correctly calculated, instead of the simple `start_time + duration`. ## Affected versions - 15.0 - saas-15.2 - saas-15.3 - 16.0 - master --- opw-3101105 Forward-Port-Of: odoo/enterprise#35510 Forward-Port-Of: odoo/enterprise#35412
This commit adds a `country_id` to the BR Balance Sheet report. At the moment the Brazilian BS report remains available when changing the company to one in another country. Also, the liabilities section should not be foldable. Forward-Port-Of: odoo/enterprise#35503
Original PR description
This commit adds a `country_id` to the BR Balance Sheet report. At the moment the Brazilian BS report remains available when changing the company to one in another country. Also, the liabilities section should not be foldable. Forward-Port-Of: odoo/enterprise#35503
Forward-Port-Of: odoo/enterprise#35459 Forward-Port-Of: odoo/enterprise#35414
Original PR description
Forward-Port-Of: odoo/enterprise#35459 Forward-Port-Of: odoo/enterprise#35414
In the tour `test_put_in_pack_scan_package`, we get the line for product1 and check its package. Before the v16.0, only the lines for the current location were displayed but it's not the case anymore, which means there is two lines for product1 now when we do this verification. To avoid issue, it's better to strengthen the selector to be sure to get only the wanted line. runbot build error: 12273 Forward-Port-Of: odoo/enterprise#35135
Original PR description
In the tour `test_put_in_pack_scan_package`, we get the line for product1 and check its package. Before the v16.0, only the lines for the current location were displayed but it's not the case anymore, which means there is two lines for product1 now when we do this verification. To avoid issue, it's better to strengthen the selector to be sure to get only the wanted line. runbot build error: 12273 Forward-Port-Of: odoo/enterprise#35135
Forward-Port-Of: odoo/enterprise#35478
Original PR description
Forward-Port-Of: odoo/enterprise#35478
On a list of pickings, it is currently not possible to scan a product with the camera of the device (and therefore, the user can't filter the pickings) To reproduce the issue: (Use demo data) 1. Create a product P: - Barcode: 123 2. Create and confirm a planned receipt R with 1 x P 3. Open the Barcode App - Note: There is a "Tap to Scan" button so a user can scan something thanks to the camera of the device 4. Operations > Receipts - There is a tip: "Scan a product to
Original PR description
On a list of pickings, it is currently not possible to scan a
product with the camera of the device (and therefore, the user can't
filter the pickings)
To reproduce the issue:
(Use demo data)
1. Create a product P:
- Barcode: 123
2. Create and confirm a planned receipt R with 1 x P
3. Open the Barcode App
- Note: There is a "Tap to Scan" button so a user can scan
something thanks to the camera of the device
4. Operations > Receipts
- There is a tip: "Scan a product to filter your records"
Error: According to the tip, it is possible to scan P to filter the
picking and get R. However, there isn't any button so the user can
scan a product with his camera.
Such a button is also present on a picking and an inventory adjustment.
So, considering this and the note of step 3, it seems it should
always be possible to scan with the camera of the device.
OPW-3110048
Forward-Port-Of: odoo/enterprise#35398
Forward-Port-Of: odoo/enterprise#35251…idelines Purpose ======= Those old and badly written tests were also bringing indeterministic issues. Forward-Port-Of: odoo/enterprise#35454 Forward-Port-Of: odoo/enterprise#35431
Original PR description
…idelines Purpose ======= Those old and badly written tests were also bringing indeterministic issues. Forward-Port-Of: odoo/enterprise#35454 Forward-Port-Of: odoo/enterprise#35431