Monday, April 15, 2024
25 changes · saas-17.1
Miscellaneous changes
Rewrite the mapping from xmlid to tax to only take into account standard taxes from the 'account' module Related to blocking upgrade request [upg-1494099](https://upgrade.odoo.com/web#id=1494099&model=upgrade.request) If there is a custom tax created by the user with a external id that doesn't contain '_', the mapping fails. Traceback: ``` File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 280, in <dictcomp> xml_id.split('.')[1].split('_', maxsplit=1)[1]:
Original PR description
Rewrite the mapping from xmlid to tax to only take into account standard taxes from the 'account' module
Related to blocking upgrade request [upg-1494099](https://upgrade.odoo.com/web#id=1494099&model=upgrade.request)
If there is a custom tax created by the user with a external id that doesn't contain '_', the mapping fails.
Traceback:
```
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 280, in <dictcomp>
xml_id.split('.')[1].split('_', maxsplit=1)[1]: self.env['account.tax'].browse(record)
IndexError: list index out of range
```
Only standard taxes (from `account` module) should be taken into account.
Forward-Port-Of: odoo/odoo#161877`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form` All these extension views have the same priority and in this case the later is trying to access the div before it is even created. We fix this issue by changing the priority of the view that creates the div from 16 to 15. This is currently blocking around 60~ upgrades Forward-Port-Of: odoo/odoo#160329
Original PR description
`base_vat.view_partner_base_vat_form` creates a new div `vat_vies_container` referenced by other views such as `l10n_mx_edi_stock.mx_partner_operator_form` All these extension views have the same priority and in this case the later is trying to access the div before it is even created. We fix this issue by changing the priority of the view that creates the div from 16 to 15. This is currently blocking around 60~ upgrades Forward-Port-Of: odoo/odoo#160329
In IT localization open tax "0% S (Services)" Issue: invoice repartition line tax tag is "+02", it should be "+03" opw-3860109 Forward-Port-Of: odoo/odoo#161696
Original PR description
In IT localization open tax "0% S (Services)" Issue: invoice repartition line tax tag is "+02", it should be "+03" opw-3860109 Forward-Port-Of: odoo/odoo#161696
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160844
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160844
Steps to reproduce: - Drop an Text - Image block - Click on the Image - Click on the link button next to replace - Try typing a URL => Typing a URL is hard because the widget keeps re-rendering Reason: Since [1], the jQueryUI urlcomplete widget was changed into an OWL widget. This added a call to `urlChosen` on input, which leads to the SnippetsMenu re-rendering the options. This commit fixes that by remove the call to `urlChosen`. Nothing is lost since the input is already handling it
Original PR description
Steps to reproduce: - Drop an Text - Image block - Click on the Image - Click on the link button next to replace - Try typing a URL => Typing a URL is hard because the widget keeps re-rendering Reason: Since [1], the jQueryUI urlcomplete widget was changed into an OWL widget. This added a call to `urlChosen` on input, which leads to the SnippetsMenu re-rendering the options. This commit fixes that by remove the call to `urlChosen`. Nothing is lost since the input is already handling its own changes. Instead, urlChosen is only called when selecting an element from the dropdown. [1]: https://github.com/odoo/odoo/commit/86a9171ec7790aa09f2b9a50dcb26deb029e8bed Forward-Port-Of: odoo/odoo#161045
Steps to reproduce the bug: - Enable the “byproduct” option in the settings - Enable 3 steps for manufacturing operation - Create a storable product “P1”: - Component: C1, qty: 1 unit - By-product: C2, qty: 0 unit - Create a MO: - Confirm it - Update the qty produced of C2 to 1 - Mark as done the MO - Go to the picking Problem: The quantity of the byproduct (C2) is not updated to 1. When the MO is marked as done, the "_action_done" for finished moves is calle
Original PR description
Steps to reproduce the bug: - Enable the “byproduct” option in the settings - Enable 3 steps for manufacturing operation - Create a storable product “P1”: - Component: C1, qty: 1 unit - By-product:…
Steps to reproduce the bug:
- Enable the “byproduct” option in the settings
- Enable 3 steps for manufacturing operation
- Create a storable product “P1”:
- Component: C1, qty: 1 unit
- By-product: C2, qty: 0 unit
- Create a MO:
- Confirm it
- Update the qty produced of C2 to 1
- Mark as done the MO
- Go to the picking
Problem:
The quantity of the byproduct (C2) is not updated to 1.
When the MO is marked as done, the "_action_done" for finished moves is called:
https://github.com/odoo/odoo/blob/34c192761fa375b56d617fec78fb63d8008f6451/addons/mrp/models/mrp_production.py#L1465
Then, we will check, if we should create an extra move:
https://github.com/odoo/odoo/blob/6a114cc97e0ee0648751194c1ffe3e70d900062c/addons/stock/models/stock_move.py#L1507
However, since we ignore moves with a product_uom_qty of 0, we do not check if this move has a different done quantity and thus do not create an extra move:
https://github.com/odoo/odoo/blob/eb4f5fc929217dea7d97a66b6aeeaa8b0bd1e3f1/addons/stock/models/stock_move.py#L1779-L1780
opw-3815481
Forward-Port-Of: odoo/odoo#161127Since [1] positioning of popovers targeting an element contained in an iframe is permitted. This commit will ensure the popper's element positioning is correct in the following case: have a popper - outside an iframe - targeting an element that is inside it - and no container element has been given (default is used) **Before this commit** The default container that is used is the target's owner document element, a.k.a. the iframe's html element. **After this commit** The default co
Original PR description
Since [1] positioning of popovers targeting an element contained in an iframe is permitted. This commit will ensure the popper's element positioning is correct in the following case: have a popper - outside an iframe - targeting an element that is inside it - and no container element has been given (default is used) **Before this commit** The default container that is used is the target's owner document element, a.k.a. the iframe's html element. **After this commit** The default container that is used is now the popper's owner document. ** Side notes ** This bug has been found when working for the following taskid-3603843 It is required for this task and will get fw-ported through the master branch. [1]: d6afa9f32512774908a2076f5ece2522efa44042 Forward-Port-Of: odoo/odoo#161568 Forward-Port-Of: odoo/odoo#161078
After `_check_combo_inclusion` was added, it broke product creation for users without sales rights (e.g. stock managers). This commit fixes the issue by using `sudo().search`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161313
Original PR description
After `_check_combo_inclusion` was added, it broke product creation for users without sales rights (e.g. stock managers). This commit fixes the issue by using `sudo().search`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161313
Issue ----- Reconciliation models are not searchable by specific fields (e.g. name). Steps ----- - Open Accounting -> Configuration -> Reconciliation Models. - Try typing something into search. - No field are suggested to search on. Cause ----- No search fields are defined for `account.reconcile.model`, only filters. opw-3847744 Forward-Port-Of: odoo/odoo#161040
Original PR description
Issue ----- Reconciliation models are not searchable by specific fields (e.g. name). Steps ----- - Open Accounting -> Configuration -> Reconciliation Models. - Try typing something into search. - No field are suggested to search on. Cause ----- No search fields are defined for `account.reconcile.model`, only filters. opw-3847744 Forward-Port-Of: odoo/odoo#161040
-Step to reproduce: create a custom module and try to extend method in website_slides controller like this: ``` @http.route(sitemap=sitemap_slide_view) def slide_view(self, slide, **kwargs): return super(WebsiteSlidesSeo, self).slide_view(slide, **kwargs) ``` From there, 'rule.endpoint.original_routing' will take the value from the extend method not the original one therefore user will one again go to the the forbidden error page which is'n friendly. We shouldn't access original_
Original PR description
-Step to reproduce: create a custom module and try to extend method in
website_slides controller like this:
```
@http.route(sitemap=sitemap_slide_view)
def slide_view(self, slide, **kwargs):
return super(WebsiteSlidesSeo, self).slide_view(slide, **kwargs)
```
From there, 'rule.endpoint.original_routing' will take the value from
the extend method not the original one therefore user will one again go
to the the forbidden error page which is'n friendly. We shouldn't access
original_routing because that's the "function's specific @http.route"
-Solution: we only need rule.endpoint.routing because it is the one holding the "merged @http.route accross inherited controllers".
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#160864… invisible Have a form view that has twice the same x2many field, excpet the first one is invisible=1. The second occurence has a context with the form_view_ref key. The x2many should have at least one record. ```xml <form> <field name="x2m" invisible="1" /> <field name="x2m" context="{'form_view_ref': 'some_ref'}"> <tree> <field name="display_name" /> </tree> </field> </form> ``` When opening a record, the context was not taken into
Original PR description
… invisible
Have a form view that has twice the same x2many field, excpet the first one is invisible=1. The second occurence has a context with the form_view_ref key.
The x2many should have at least one record.
```xml
<form>
<field name="x2m" invisible="1" />
<field name="x2m" context="{'form_view_ref': 'some_ref'}">
<tree>
<field name="display_name" />
</tree>
</field>
</form>
```
When opening a record, the context was not taken into account, yielding the wrong form view to open that record.
After this commit, the form_view_ref context key is taken into account, and the right form view opens.
opw-3845448
Description of the issue/feature this PR addresses:
Current behavior before PR:
Desired behavior after PR is merged:
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#161253When writing in a discuss channel, the updated value sent to the client should be read from the database, not directly from the values passed to the write method. Partially backport of https://github.com/odoo/odoo/pull/139563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158860
Original PR description
When writing in a discuss channel, the updated value sent to the client should be read from the database, not directly from the values passed to the write method. Partially backport of https://github.com/odoo/odoo/pull/139563 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#158860
Steps to reproduce: - Create a vendor bill with landed costs - Add section and note lines - Try posting the bill (ERROR) Bug: display lines should be skipped opw-3715660 Forward-Port-Of: odoo/odoo#161692 Forward-Port-Of: odoo/odoo#161269
Original PR description
Steps to reproduce: - Create a vendor bill with landed costs - Add section and note lines - Try posting the bill (ERROR) Bug: display lines should be skipped opw-3715660 Forward-Port-Of: odoo/odoo#161692 Forward-Port-Of: odoo/odoo#161269
### Steps to reproduce: Create and print an SO for a customer based in Luxembourg ### Expected behavior: According to Bpost and to the Post of Luxembourg, the zip code should be displayed before the city name in the address format in Luxembourg. ### Current behavior: The zip code is displayed after the city name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Ticket [link](https://www.odoo.com/web#model=project.task&id=3791142) on O
Original PR description
### Steps to reproduce: Create and print an SO for a customer based in Luxembourg ### Expected behavior: According to Bpost and to the Post of Luxembourg, the zip code should be displayed before the city name in the address format in Luxembourg. ### Current behavior: The zip code is displayed after the city name. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Ticket [link](https://www.odoo.com/web#model=project.task&id=3791142) on Odoo opw-3791142 Forward-Port-Of: odoo/odoo#159240
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161279 Forward-Port-Of: odoo/odoo#160968
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#161279 Forward-Port-Of: odoo/odoo#160968
There is 2 issues with it: - People that want to use multiple picking type or multiple store after manufacturing locations. It's not possible since the equals is strict on the warehouse store after manufacturing picking type. - The procurement group always use the default manufacture picking type and ignore the picking type on the manufacture rule that will be use. This commit checks if the location is a child of the post production in order to create the procurement group. It would be an i
Original PR description
There is 2 issues with it: - People that want to use multiple picking type or multiple store after manufacturing locations. It's not possible since the equals is strict on the warehouse store after…
There is 2 issues with it: - People that want to use multiple picking type or multiple store after manufacturing locations. It's not possible since the equals is strict on the warehouse store after manufacturing picking type. - The procurement group always use the default manufacture picking type and ignore the picking type on the manufacture rule that will be use. This commit checks if the location is a child of the post production in order to create the procurement group. It would be an issue for people having multiple step in post prod. But it could be fix by using a subset of the warehouse post production location. Check if we have a manufacture rule with the same warehouse in the current route. It's not perfect but it could give a more accurate result than today. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#159647 Forward-Port-Of: odoo/odoo#159418
Currently, when there is only one loyalty program available for an order, we apply it automatically without opening the wizard. This is a problem when the reward is a free product among all with a specific tags because the user can not choose it (it takes the first one by default) We now automatically apply only when there is only one reward possible opw-3774944 Forward-Port-Of: odoo/odoo#161442
Original PR description
Currently, when there is only one loyalty program available for an order, we apply it automatically without opening the wizard. This is a problem when the reward is a free product among all with a specific tags because the user can not choose it (it takes the first one by default) We now automatically apply only when there is only one reward possible opw-3774944 Forward-Port-Of: odoo/odoo#161442
### Steps to reproduce: - Change the recruitment access rights of Marc Demo to "Interviewer". - Go to Recruitment > Applications > All Applications. - Create a new application and add Marc Demo as follower of the chatter. - Write and send a message on the chatter. #### > Marc Demo will not be notified ### Expected behavior: As discussed the PO of the recruitment module (gmf), since users with "interviewer" access rights have access to the chatter and since the sensible information
Original PR description
### Steps to reproduce: - Change the recruitment access rights of Marc Demo to "Interviewer". - Go to Recruitment > Applications > All Applications. - Create a new application and add Marc Demo as…
### Steps to reproduce: - Change the recruitment access rights of Marc Demo to "Interviewer". - Go to Recruitment > Applications > All Applications. - Create a new application and add Marc Demo as follower of the chatter. - Write and send a message on the chatter. #### > Marc Demo will not be notified ### Expected behavior: As discussed the PO of the recruitment module (gmf), since users with "interviewer" access rights have access to the chatter and since the sensible informations are now shared via the salary offer model instead of relying on the chatter of the application model, the followers of the chatter with "interviewer" access rights should be notified if pinged on a log note or if a general message is sent. ### Cause of the issue: Since sensitive informations used to pass through the chatter, users with "interviewer" access rights did not have access to it, and were removed on purpose from the recipients of the notifications: https://github.com/odoo/odoo/blob/cd6ed7f9fd2e0654cfb0672d7a9536dca21035cf/addons/hr_recruitment/models/hr_applicant.py#L376-L379 to avoid any leak of sensible information. #### Note: This access right did not exist before saas-16.4 opw-3783965 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160130
Steps to reproduce: ----------------- - install project module - create new project - click on project,and click on see examples button - click on use this for my project - create tasks and click on list view - unhide the start date and end date - give start date and end date for more than 1 records Issue: - Bug when mass editing the task's date_deadline (always showing the wrong date for one of the records) Cause: - this is because the for single record it is not accepting work
Original PR description
Steps to reproduce: ----------------- - install project module - create new project - click on project,and click on see examples button - click on use this for my project - create tasks and click on list view - unhide the start date and end date - give start date and end date for more than 1 records Issue: - Bug when mass editing the task's date_deadline (always showing the wrong date for one of the records) Cause: - this is because the for single record it is not accepting work intervals Solution: - by giving condition using len then issue will be solved task-3561946 Forward-Port-Of: odoo/enterprise#60557 Forward-Port-Of: odoo/enterprise#53164
**Current behavior:** On the pivot view for the budget analysis view, the percentage column total is the sum of each row's percentage. **Expected behavior:** This value is the mean of all percentages. **Steps to reproduce:** 1. In the Accounting app, create a budget that has a non-zero Achievement value in at least 2 rows 2. Go to *Reporting* -> *Budgets Analysis* and expand the y-axis to show the lines created, observe that the Achievement total is displaying the sum of all percenta
Original PR description
**Current behavior:** On the pivot view for the budget analysis view, the percentage column total is the sum of each row's percentage. **Expected behavior:** This value is the mean of all percentages. **Steps to reproduce:** 1. In the Accounting app, create a budget that has a non-zero Achievement value in at least 2 rows 2. Go to *Reporting* -> *Budgets Analysis* and expand the y-axis to show the lines created, observe that the Achievement total is displaying the sum of all percentages **Cause of the issue:** The percentage field is being aggregated by summation in the read_group() method of the `crossovered.budget.lines` model. **Fix:** Calculate the mean instead of the sum. opw-3761952 Forward-Port-Of: odoo/enterprise#59103
https://github.com/odoo/odoo/commit/7e9a87388e1d20c1b194f312f8149a2c3f096038 introduced a new id on a div to use it in an xpath in account_reports. However, on existing databases, this broke at update of account_reports, as long as account module wasn't updated itself. We fix that by directlly targeting the condition of the associated t-if. In master, we'll keep the xpath on the class; which is cleaner. Forward-Port-Of: odoo/enterprise#60648
Original PR description
https://github.com/odoo/odoo/commit/7e9a87388e1d20c1b194f312f8149a2c3f096038 introduced a new id on a div to use it in an xpath in account_reports. However, on existing databases, this broke at update of account_reports, as long as account module wasn't updated itself. We fix that by directlly targeting the condition of the associated t-if. In master, we'll keep the xpath on the class; which is cleaner. Forward-Port-Of: odoo/enterprise#60648
Since [1], when attempting to uninstall web_enterprise, the webclient will no longer start with website_enterprise installed. The reason for this is because the patch to color_scheme_service imports the service from web_enterprise, but `__manifest__` was not updated to mention the dependency. This commit fixes that. [1]: https://github.com/odoo/enterprise/commit/90df39603b07 Forward-Port-Of: odoo/enterprise#60231
Original PR description
Since [1], when attempting to uninstall web_enterprise, the webclient will no longer start with website_enterprise installed. The reason for this is because the patch to color_scheme_service imports the service from web_enterprise, but `__manifest__` was not updated to mention the dependency. This commit fixes that. [1]: https://github.com/odoo/enterprise/commit/90df39603b07 Forward-Port-Of: odoo/enterprise#60231
Adapted the tax report to 2024. There does not seem to be any other changes to do. To avoid this kind of issue, let's make the version's year dynamic opw-3859628 Forward-Port-Of: odoo/enterprise#60634 Forward-Port-Of: odoo/enterprise#60507
Original PR description
Adapted the tax report to 2024. There does not seem to be any other changes to do. To avoid this kind of issue, let's make the version's year dynamic opw-3859628 Forward-Port-Of: odoo/enterprise#60634 Forward-Port-Of: odoo/enterprise#60507
Purpose ======= Fix the tags count which isn't updated in the search panel when adding or removing the tag from a document using the inspector. Specifications ============== When removing or adding a tag to a document using the inspector, the record tag was updated but the search panel wasn't notified of the tag update. Notifying the search model after the tag update to modify the tag count. Task-3837247 Forward-Port-Of: odoo/enterprise#60541 Forward-Port-Of: odoo/enterprise#59764
Original PR description
Purpose ======= Fix the tags count which isn't updated in the search panel when adding or removing the tag from a document using the inspector. Specifications ============== When removing or adding a tag to a document using the inspector, the record tag was updated but the search panel wasn't notified of the tag update. Notifying the search model after the tag update to modify the tag count. Task-3837247 Forward-Port-Of: odoo/enterprise#60541 Forward-Port-Of: odoo/enterprise#59764
Steps to reproduce =================== 1. Go to activity view. 2. Click on schedule activity. 3. Select any document to schedule an activity. Nothing happens Technical ========== The commit https://github.com/odoo/enterprise/commit/e35017719d0996279f362423a7b4b1c6e30b9766 prevents the default behavior of the list view, but it's required for list view pop-up when prompted to schedule an activity from activity view. Note : - The schedule activity dialog box renders the list view of
Original PR description
Steps to reproduce =================== 1. Go to activity view. 2. Click on schedule activity. 3. Select any document to schedule an activity. Nothing happens Technical ========== The commit https://github.com/odoo/enterprise/commit/e35017719d0996279f362423a7b4b1c6e30b9766 prevents the default behavior of the list view, but it's required for list view pop-up when prompted to schedule an activity from activity view. Note : - The schedule activity dialog box renders the list view of the related module. In our case, it renders the base list view from the documents and loads its JS. - We cannot change this in stable so we fixed the issue in JS. After this PR ================ The activity view opens up to schedule an activity for the document. Task-3718760 Forward-Port-Of: odoo/enterprise#56359