Odoo Changelog — 2024-08-31

Saturday, August 31, 2024

7 changes · 17.0

Improvements(3)

Enhancements to existing features

[FIX] sale_stock_renting: allow visibility days and renting

Enterprise17.0sale_stock_rentingMEDIUM

This fix enables better inventory planning for rental businesses by allowing the visibility days feature to work with rental orders. A new parameter lets users ignore rental returns in forecasts, making it easier to plan weekly stock replenishment and organize warehouse transfers. This requires careful lead time configuration to ensure accurate forecasting of subsequent rental orders.

Original PR description

The case: - I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers The issue, rental…

The case:
- I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers

The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period)

An existing solution:
Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the replenishment report everyday and don't have weekend. And if they use automatic RR they lose the control over the warehouse that should resupply the product.

Also they can't use the visibility days feature and plan for a week.

In order to allow a better planning and flexibility we add a small parameter to ignore the returns of rental order. That way the forecast ignore returns and allow visibilty.

BUT it's DANGEROUS. Because it means that outgoing after return won't be correctly forecasted. So the user have to use a small lead time. E.g. Global lead days = 70 days, do a rental order in 10 days (for a day) and another in 20 days. With the parameter enable, it will suggest 2 units. However it should be one since one is returned.

#rental#forecasting#inventory-planning#replenishment#visibility-days

[IMP] l10n_mx_edi_website_sale: payment way many2one field

PR #68902

Enterprise17.0l10n_mx_edi_website_saleMEDIUM

This update adds a payment method selection field to the website checkout process for Mexican customers. This ensures that the required "Payment way" information is captured during purchase, which is mandatory for electronic invoicing compliance and helps prevent invoice cancellation requests due to missing information.

Original PR description

This commit adds the field `l10n_mx_edi_payment_method_id` to the website checkout, so that the customer can choose the correct option to be saved into the sale order and to fill the attribute in the XML.

Purpose:
In Mexican electronic invoicing, some fields are mandatory for signing an invoice. Now, on e-commerce, one field is missing to avoid requests to cancel invoices due to lack of information. This missing field is "Payment way" (l10n_mx_edi_payment_method_id).

This commit also restructures the placement of `t-if`/`div`s so that they appear in the right places and not generate empty divs.

task-id: 4064069

#Mexico#e-commerce#invoicing#compliance#checkout

[IMP] l10n_nz: Localization improvement

PR #62591

Enterprise17.0account_reportsl10n_nzMEDIUM

This update enhances the New Zealand localization in Odoo by translating key terms and improving how tax information appears on invoices. Invoices will now be properly marked as "tax invoices" with clearer tax labels, making them more compliant with New Zealand requirements and easier for users to understand.

Original PR description

This commit brings out some more improvement to
the New Zealand localization.
It will mostly be about translating a few terms,
improving tax labels on invoices and mark invoices as "tax invoices".

Task id #3753652

#localization#New Zealand#invoices#tax compliance

Bug Fixes(4)

Resolved issues and error corrections

[FIX] stock_barcode_mrp: not redirect to backend from barcode backorder

PR #69169

Enterprise17.0stock_barcode_mrpMEDIUM

Fixed an issue where users were unexpectedly redirected away from the barcode scanning interface to the backend system when a manufacturing backorder was automatically created. Now users remain in the barcode module to continue their work, improving workflow efficiency and reducing unnecessary navigation steps.

Original PR description

### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a…

### Steps to reproduce:

- Enable multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Operations types
- Click on Manufacturing and put "Always" on create a backorder
- Create a product P (no need for a bom)
- Create and confirm a manufacturing order for 2 units of the product
- Go to the barcode module > operations > manufacturing > the MO
- Register only one unit of P and produce
#### > A backorder is automatically created but you are redirected to the backend.

### Note:

If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module.

### Cause of the issue:

The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" flows.

opw-3890886

#barcode#manufacturing#backorder#user-experience#workflow

[FIX] knowledge: test checking that portal user can create/edit articles

PR #69157

Enterprise17.0knowledge

This update corrects a test that verifies portal users can create and edit knowledge articles. The test was passing incorrectly because it wasn't properly checking access permissions. The fix ensures the test now correctly validates that portal users have the right permissions to perform these actions.

Original PR description

Since odoo/enterprise#38575, portal users can create/edit knowledge articles.  However, the test that checks that feature is not correct:
 - it does not call `check_access_rights()` (for ACLs);
 - it uses a `res.partner` instead of a `res.users` in `with_user()`.

Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial.  In other words, the test passes by accident :-(

The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`.

#testing#portal-users#access-control

[FW][FIX] timesheet_grid: fix access rights error in timesheet

PR #68933

Enterprise17.0timesheet_gridhr_timesheetindustry_fsmHIGH

This update resolves multiple access permission issues in the timesheet system that were preventing users from creating timesheets and validating entries. Users with standard project access can now start timesheets from tasks without encountering permission errors, FSM projects are properly restricted from quick creation, and timesheet validation now works correctly for employees without assigned managers.

Original PR description

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid.…

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid.

This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised.

Step to reproduce:
- create a db with hr_timesheet installed
- have a user with 'user' access rights on project and 'own timesheet' on timesheet
- create an internal project
- create a task inside that internal project and assigned the user on it
- connect with the other user
- open timesheet app
- select the task from the internal project to start a new timesheet timer
- an error access right on 'project' is triggered

Solution:
Add a sudo inside the python method 'check can start timer'. Give the project name to the timerHeaderM2O, to prevent the call to the name_get on the project.

task - 3922511
affected version 16.0 - master

Forward-Port-Of: odoo/enterprise#63159

#access rights#timesheet#bug fix#user permissions#validation

[FIX] knowledge: fix missing dependency

PR #60125

Enterprise17.0knowledgeMEDIUM

The Knowledge module was missing required dependencies (web_cohort and web_gantt) in its configuration file, which caused the system to crash when installing the module. This fix adds these missing dependencies to ensure the Knowledge module installs and functions properly without errors.

Original PR description

In my enterprise db for some reason i didn't have the web_cohort installed and when installing Knowledge module my db crashed because knowledge module used web_cohort dependency but that dependency was not installed and was not listed on the manifest.py, the simple fix is to add to web_cohort as a dependency
![2024-04-04_18-35](https://github.com/odoo/enterprise/assets/23614127/06362193-d493-4471-8519-31813ecb108d)

#dependency#installation#stability

The case: - I want to organise all my shop in order to be able to serve all the rental orders I planed for a week. And resupply the shop with different interwarehouse transfers The issue, rental orders create a retun picking directly and their forecast could easily reach zero. (even more on small renting period) An existing solution: Correctly set a small lead time on reordering rule in order to have a fix day in order to have the forecast. However it only works if people check the replenishment report everyday and don't have weekend. And if they use automatic RR they lose the control over the warehouse that should resupply the product. Also they can't use the visibility days feature and plan for a week. In order to allow a better planning and flexibility we add a small parameter to ignore the returns of rental order. That way the forecast ignore returns and allow visibilty. BUT it's DANGEROUS. Because it means that outgoing after return won't be correctly forecasted. So the user have to use a small lead time. E.g. Global lead days = 70 days, do a rental order in 10 days (for a day) and another in 20 days. With the parameter enable, it will suggest 2 units. However it should be one since one is returned.

This commit adds the field `l10n_mx_edi_payment_method_id` to the website checkout, so that the customer can choose the correct option to be saved into the sale order and to fill the attribute in the XML. Purpose: In Mexican electronic invoicing, some fields are mandatory for signing an invoice. Now, on e-commerce, one field is missing to avoid requests to cancel invoices due to lack of information. This missing field is "Payment way" (l10n_mx_edi_payment_method_id). This commit also restructures the placement of `t-if`/`div`s so that they appear in the right places and not generate empty divs. task-id: 4064069

This commit brings out some more improvement to the New Zealand localization. It will mostly be about translating a few terms, improving tax labels on invoices and mark invoices as "tax invoices". Task id #3753652

### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to the backend. ### Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module. ### Cause of the issue: The issue was originally solved by commit d90acab by overriding the `action_backorder` however, since commit 1e5c82f the action_backorder is no more part of the flow in "always" flows. opw-3890886

Since odoo/enterprise#38575, portal users can create/edit knowledge articles. However, the test that checks that feature is not correct: - it does not call `check_access_rights()` (for ACLs); - it uses a `res.partner` instead of a `res.users` in `with_user()`. Because the test only checks access rules with a non-existing user, no rules are found, and the check is therefore trivial. In other words, the test passes by accident :-( The fix consists in creating a portal user for the corresponding "customer" contact, and add the expected calls to `check_access_rights()`.

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid. This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised. Step to reproduce: - create a db with hr_timesheet installed - have a user with 'user' access rights on project and 'own timesheet' on timesheet - create an internal project - create a task inside that internal project and assigned the user on it - connect with the other user - open timesheet app - select the task from the internal project to start a new timesheet timer - an error access right on 'project' is triggered Solution: Add a sudo inside the python method 'check can start timer'. Give the project name to the timerHeaderM2O, to prevent the call to the name_get on the project. task - 3922511 affected version 16.0 - master Forward-Port-Of: odoo/enterprise#63159

In my enterprise db for some reason i didn't have the web_cohort installed and when installing Knowledge module my db crashed because knowledge module used web_cohort dependency but that dependency was not installed and was not listed on the manifest.py, the simple fix is to add to web_cohort as a dependency ![2024-04-04_18-35](https://github.com/odoo/enterprise/assets/23614127/06362193-d493-4471-8519-31813ecb108d)