Monday, April 15, 2024
33 changes · saas-17.2
Enhancements to existing features
This update improves internal web testing tools so simulated screens can better match real Odoo behavior. It also prevents iframe-related test errors, helping teams validate reporting and interface behavior more reliably before release.
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
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
… 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#161401
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#161185 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#161185 Forward-Port-Of: odoo/odoo#158860
The patch function was changed at commit [1]. This introduced a call to `Object.hasOwn` which is the preferred way to check if an Object has a property as its own. However, after multiple user reports, it seems like a significant amount of user and website visitors still use browsers that do not have Object.hasOwn implemented. This commit introduces a fallback to Object.prototype.hasOwnProperty for browsers that do not have Object.hasOwn implemented. [1]: https://github.com/odoo/odoo/commi
Original PR description
The patch function was changed at commit [1]. This introduced a call to `Object.hasOwn` which is the preferred way to check if an Object has a property as its own. However, after multiple user reports, it seems like a significant amount of user and website visitors still use browsers that do not have Object.hasOwn implemented. This commit introduces a fallback to Object.prototype.hasOwnProperty for browsers that do not have Object.hasOwn implemented. [1]: https://github.com/odoo/odoo/commit/04fddc19d4aedd8105e0fda5582288c2bb1833fe opw-3824593 Forward-Port-Of: odoo/odoo#160758
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#161127Steps 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
Description of the issue/feature this PR addresses: In the Point Of Sale app, when a receipt is created and the header or the email is long, the text is not centered. Moreover, the Unit Of Measure text of the receipt is not translated as well as the mean of payment. Current behavior before PR: Long header and email => text is **not** centered Unit Of Measure text is not translated Mean of payment text is not translated Desired behavior after PR is merged: Long and short header and ema
Original PR description
Description of the issue/feature this PR addresses: In the Point Of Sale app, when a receipt is created and the header or the email is long, the text is not centered. Moreover, the Unit Of Measure text of the receipt is not translated as well as the mean of payment. Current behavior before PR: Long header and email => text is **not** centered Unit Of Measure text is not translated Mean of payment text is not translated Desired behavior after PR is merged: Long and short header and email => text is centered Unit Of Measure text is translated Mean of payment text is translated opw-3822694 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#160513
**Current behavior:** Entering kiosk mode in the webclient in a multi-company env will display the logo of the default company. **Expected behavior:** The logo on the kiosk screen will belong to the currently selected company. **Steps to reproduce:** 1. Make a second company, give the default company and the new one distinct logos 2. Select the second company from the company selector menu 3. Enter kiosk mode in the Attendance app, observe the logo is that of the inactive company
Original PR description
**Current behavior:** Entering kiosk mode in the webclient in a multi-company env will display the logo of the default company. **Expected behavior:** The logo on the kiosk screen will belong to the currently selected company. **Steps to reproduce:** 1. Make a second company, give the default company and the new one distinct logos 2. Select the second company from the company selector menu 3. Enter kiosk mode in the Attendance app, observe the logo is that of the inactive company **Cause of the issue:** After arriving at the URL route for the kiosk page from the _action_open_kiosk_mode() method, the context has been rebuilt to a somewhat default state which no longer informs the current company id. `self.env.company` references the default company of the user. **Fix:** Add an id slug in the URL route which identifies which company's kiosk we should be seeing. opw-3802916 Forward-Port-Of: odoo/odoo#159702
This commit will make a `willDrag` information available to the draggable_hook_builder context. This is needed to fix a resize issue in the gantt view. See correlated enterprise pull request. Forward-Port-Of: odoo/odoo#161446 Forward-Port-Of: odoo/odoo#161096
Original PR description
This commit will make a `willDrag` information available to the draggable_hook_builder context. This is needed to fix a resize issue in the gantt view. See correlated enterprise pull request. Forward-Port-Of: odoo/odoo#161446 Forward-Port-Of: odoo/odoo#161096
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 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#160864Steps 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
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
This commit adds helpers that are used in a tour created in enterprise. opw-3802560 Forward-Port-Of: odoo/odoo#160961
Original PR description
This commit adds helpers that are used in a tour created in enterprise. opw-3802560 Forward-Port-Of: odoo/odoo#160961
[This first commit] made it possible to have an error when there was no comparator for a field with conditional visibility. [This second commit] prevented an error from occurring in this case. The purpose of this commit is to prevent the user from getting a conditional visibility configuration for a form field where there is no comparator. Steps to reproduce the problem: - Go to /contactus. - Edit page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibilit
Original PR description
[This first commit] made it possible to have an error when there was no comparator for a field with conditional visibility. [This second commit] prevented an error from occurring in this case. The…
[This first commit] made it possible to have an error when there was no comparator for a field with conditional visibility. [This second commit] prevented an error from occurring in this case. The purpose of this commit is to prevent the user from getting a conditional visibility configuration for a form field where there is no comparator. Steps to reproduce the problem: - Go to /contactus. - Edit page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibility" option. - Click on "Visible Only If" again. => The comparator is not defined. Another way to have the issue was: - Drop a form on a page. - Click on the "Your Company" field. - Select "Visible Only If" for the "Visibility" option. - Set visible only if Your Name is equal to "test" as condition. - Click on Your Name field. - Change the field type to Radio Buttons. => The comparator is not defined. This commit fixes those two cases. Technical information: When we change the field's visibility to conditional (`setVisibility`), we add a default visibility dependency (`_setVisibilityDependency`). At this point, the comparator is removed and added in `_renderCustomXML`. `_renderCustomXML` was only called if the visibility dependency had changed. [This first commit]: https://github.com/odoo/odoo/commit/910897fc97d87b08f01627094ec8c159f5267628 [This second commit]: https://github.com/odoo/odoo/commit/808780c89cfba940957f7410f787de31e31bda27 opw-3806409 Forward-Port-Of: odoo/odoo#161527 Forward-Port-Of: odoo/odoo#160464
Steps: - Install `web_studio` - Change language to French - Open any form view and enable `Studio` - Add a datetime field and click on it In french we have the following message: "Première date acceptée": Date formatée ISO ou "aujourd'hui" He says that we can use the string "aujourd'hui" when we only expect "today" in English. This commit changes the help text to display "today" in every language opw-3829954 Forward-Port-Of: odoo/odoo#161246 Forward-Port-Of: odoo/odoo#159654
Original PR description
Steps: - Install `web_studio` - Change language to French - Open any form view and enable `Studio` - Add a datetime field and click on it In french we have the following message: "Première date acceptée": Date formatée ISO ou "aujourd'hui" He says that we can use the string "aujourd'hui" when we only expect "today" in English. This commit changes the help text to display "today" in every language opw-3829954 Forward-Port-Of: odoo/odoo#161246 Forward-Port-Of: odoo/odoo#159654
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: 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
### 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
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
**Before this commit** At the start of a pill resize sequence, if you go fast and your pointer enters an adjacent pill right before the sequence starts you may end up resizing the wrong record. **After this commit** The draggable_hook_builder has been improved in order to inform us when a drag sequence will start. We take advantage of this in order to fix the above issue. Forward-Port-Of: odoo/enterprise#60510 Forward-Port-Of: odoo/enterprise#60328
Original PR description
**Before this commit** At the start of a pill resize sequence, if you go fast and your pointer enters an adjacent pill right before the sequence starts you may end up resizing the wrong record. **After this commit** The draggable_hook_builder has been improved in order to inform us when a drag sequence will start. We take advantage of this in order to fix the above issue. Forward-Port-Of: odoo/enterprise#60510 Forward-Port-Of: odoo/enterprise#60328
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
Currently, when trying to settle due accounts though the PoS session, the due balance doesn't change on the customer form. Steps to reproduce: ------------------- * Install **Point of Sale** and **Accounting** * Go to the **Point of Sale** App * Open a shop session * Navigate to a customer with a due ammount and select **Details** * Select **Settle due accounts** * Select any payment method * Validate * Close session * Under **Orders** select **Customers** * Select the customer for
Original PR description
Currently, when trying to settle due accounts though the PoS session, the due balance doesn't change on the customer form. Steps to reproduce: ------------------- * Install **Point of Sale** and…
Currently, when trying to settle due accounts though the PoS session, the due balance doesn't change on the customer form.
Steps to reproduce:
-------------------
* Install **Point of Sale** and **Accounting**
* Go to the **Point of Sale** App
* Open a shop session
* Navigate to a customer with a due ammount and select **Details**
* Select **Settle due accounts**
* Select any payment method
* Validate
* Close session
* Under **Orders** select **Customers**
* Select the customer for which you just settled the due accounts
> Observation: The due amount hasn't changed.
Why the fix:
------------
The following commit introduced a new relational system to be able to access data within the PoS frontend in the same way as it is done within the ORM in python: https://github.com/odoo/enterprise/commit/bb06fdead097bdec1582e3cdecb99fa63c2ff799
This commit modified the definition of `paylaterPaymentMethod`. Before the commit, it was defined as: https://github.com/odoo/enterprise/blob/4a5bb11bd59dd76f2df957225bf25d38ad5beb0c/pos_settle_due/static/src/overrides/components/payment_screen/payment_screen.js#L23-L26 and would return `{id: 3, name: 'Customer Account', is_cash_count: false, use_payment_terminal: false, split_transactions: true, …}`
Now it is defined as
https://github.com/odoo/enterprise/blob/daf09109a209f87e4f2fbb3275f55095e48d8b4d/pos_settle_due/static/src/overrides/components/payment_screen/payment_screen.js#L23-L26 and returns `undefined`.
We also notice a change in the value of `this.pos.config.payment_method_ids`. Where it previously returned
```js
Proxy(Array) {0: 1, 1: 2, 2: 3}
[[Handler]]: Object
[[Target]]: Array(3)
0: 1
1: 2
2: 3
length: 3
[[Prototype]]: Array(0)
[[IsRevoked]]: false
```
It now returns
```js
Proxy(Array) {0: Base, 1: Base, 2: Base}
[[Handler]]: Object
[[Target]]: Array(3)
0: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 1, …}
1: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 2, …}
2: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 3, …}
length: 3
[[Prototype]]: Array(0)
[[IsRevoked]]: false
```
Thus we need to use `.some()` to retreive the id.
opw-3802560
Forward-Port-Of: odoo/enterprise#59626Adapted 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