Thursday, August 15, 2024
8 changes · saas-17.2
Resolved issues and error corrections
This change prevents upgrades from incorrectly reassigning the short Spanish URL code when a regional Spanish language is already using it. It helps avoid upgrade errors for databases that enabled Spanish variants such as Argentina Spanish before moving to newer versions.
Original PR description
Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered…
Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered when upgrading to a `17.3+` version by the code trying to set the `'es'` url code while it was already available in another record. Starting from [1], we allow using the short url code `'es'` when a Spanish sub-language is enabled (as long as `es_419` is not) [A]. We also update the records in XML to set the Spanish LATAM (`es_419`) as the one with the default `'es'`, assuming that the `base.lang_es` record will always hold the `'es'` url code. Running the XML updates again in the situation of [A] will try to set the unique `es` url code on a record while another record (other than `base.lang_es`) is holding it (`"es_AR"` in this case). The goal of this commit is to simply add a `noupdate` for the XML updates so they are only loaded on initialization. [1]: https://github.com/odoo/odoo/commit/a992d2deab9d582cc33dc31f0b1bd610f82add0d 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
This fixes an internal automated test for user presence updates so it no longer depends on timing-sensitive websocket behavior. The change helps keep test results stable and reduces false failures in development and release validation.
Original PR description
The `test_notify_on_status_change` ensures user presences are received when updated. To do so, they send a websocket message to the server. However, there is no guarantee the presence was updated after sending the message as the processing is asynchronous. This PR fixes the issue by directly calling `_update_presence` and waitng for the answer through the websocket. runbot-74017
Miscellaneous changes
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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#176560
Original PR description
Commit 775c113382231 change the variable name from `i` to `picking` but the fw-port 9a3b2940da55f keeps the old name. Resulting on the access token is never found. 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#176560
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Original PR description
steps: - be connected as someone with no accrual - give accrual allocation to an employee - go to his time offs using the smart button on his employee profile -> no settings to set the date, has_accrual_allocation is false because our user's employee doesn't have accrual allocation expected -> see the date picker on the leave dashboard if the employee has accrual allocations, not the connected user Forward-Port-Of: odoo/odoo#175686
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is
Original PR description
Problem --------- Currently, when reversing a move, the current company is used as recipient bank. 1. Set a bank on a partner A 2. Go to Accounting 3. Set A as the customer of the invoice 4. Set a bank under 'recipient bank' in Other Info tab 5. Post the invoice 6. "Add Credit Note" 7. Fill in with wathever and press Reverse -> The Other Info tab of the reverse move has the company bank and not the customer's Objective --------- Obtain a similar behavior as when a credit note is created directly: have the customer's bank set as recipient bank. Solution --------- Provide a default bank id that is set, if possible, to one of the customer's bank. opw-4035448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173640
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when
Original PR description
Steps to reproduce: - Create a product - Update its quantity and set 4 in Stock - Create two MO that consume each 2 units of that product with the same scheduled date - Create a scrap order with 1 quantity of that product and validate it Issue: The unreserve will be done on the first MO. When going through the candidate move lines in the `_free_reservation()`, we sort them depending on their picking, their date if they have a move, or their id if they don't. The issue is that when their related move have an equal date, then the order becomes underministic. Now, always sort by their id as a last resort, so we have a consistent order no matter what. opw-4046240 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#176399 Forward-Port-Of: odoo/odoo#174442
Steps to reproduce: 1. Install `l10n_in_withholding` and `l10n_it_edi_withholding` 2. Create a new company with country `India` and load CoA TDS taxes doesn't get created After this commit: We resolve the above issue. Since the issue was caused by a typo in the method name in `l10n_in_withholding` which had a definition in `l10n_it_edi_withholding` Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: ---
Original PR description
Steps to reproduce: 1. Install `l10n_in_withholding` and `l10n_it_edi_withholding` 2. Create a new company with country `India` and load CoA TDS taxes doesn't get created After this commit: We resolve the above issue. Since the issue was caused by a typo in the method name in `l10n_in_withholding` which had a definition in `l10n_it_edi_withholding` 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#176565
Steps: - install 'purchase' and 'analytic' - open purchase/RFQ - create a new rfq - add a new line in the subview list - Toggle `Analytic Distribution` optional column - Edit 'Analytic Distribution' col with the widget (`analytic_disribution`) - Select first column to edit it (`Projects (100%)`) - Click on `Search More` in the dropdown - A new dialog is opened `Search: Projects` - Go to filters and click `Add Custom Filter` - Another modal is now opened `Add Custom Filter` - Click on
Original PR description
Steps: - install 'purchase' and 'analytic' - open purchase/RFQ - create a new rfq - add a new line in the subview list - Toggle `Analytic Distribution` optional column - Edit 'Analytic Distribution'…
Steps:
- install 'purchase' and 'analytic'
- open purchase/RFQ
- create a new rfq
- add a new line in the subview list
- Toggle `Analytic Distribution` optional column
- Edit 'Analytic Distribution' col with the widget (`analytic_disribution`)
- Select first column to edit it (`Projects (100%)`)
- Click on `Search More` in the dropdown
- A new dialog is opened `Search: Projects`
- Go to filters and click `Add Custom Filter`
- Another modal is now opened `Add Custom Filter`
- Click on the first domain input
- After clicking on this input, the initial `analytic_distribution` drodown is closed
- This is the cause of the problem
- Validate your domain
- Traceback `Component is destroyed`
The initial problem comes from `AnalyticDistribution` Component.
There's a listener on `click`on `document` to manage whether or not to close the widget.
There are several cases that prevent the widget from closing:
- having an active modal containing a list view or kanban view with the following selectors:
- `'.o_modal:not(.o_inactive_modal) .o_list_view'`
- `'.o_modal:not(.o_inactive_modal) .o_kanban_view'`.
- if the click occurred in the widget element
- if the dropdown is closed
However in many other cases we have undesired behavior (unwanted closing of the widget):
- a click on dialog that is open and not modal (as in the steps above)
- a click on a popover
- drag and drop an active modal to the side
This fix normally corrects the first three cases, but unfortunately I haven't found a way to correct the case of the palette command where the `ev.target` is at the point where the element selected in the palette points into the dom, especially as this is not currently the customer's problem.
Here's how the other cases are fixed:
instead of having a condition for each case
(as there used to be for modal list view and modal kanban view)
```js
const modal = document.querySelector('.modal:not(.o_inactive_modal)');
const clickedInSearchMoreDialog = modal && modal.querySelector('.o_list_view') && modal.contains(ev.target);
const clickedInKanbanSelectorDialog = modal && modal.querySelector('.o_kanban_view') && modal.contains(ev.target);
```
I create a list of css selectors corresponding to the elements in which the `ev.target` must not be located in order to close. In particular, I include the two cases already handled by the code, as well as the new ones.
Instead of having the two previous conditions, I just have one selector in my list.
https://github.com/odoo/odoo/blob/4637514b4b1550014fc6affff1b0753ab9bc0f69/addons/analytic/static/src/components/analytic_distribution/analytic_distribution.js#L611
So I add the `o_popover` and `o_dialog` selectors to correct my initial problem.
When dragging and dropping a modal, the `ev.target` is always equal to the document, so to prevent the `analytic_distribution` widget from closing in this case I check that it's not equal to `documentElement`.
https://github.com/odoo/odoo/blob/4637514b4b1550014fc6affff1b0753ab9bc0f69/addons/analytic/static/src/components/analytic_distribution/analytic_distribution.js#L617
opw-3954404
Forward-Port-Of: odoo/odoo#168920