Saturday, July 1, 2023
12 changes · master
Resolved issues and error corrections
Mobile users can now close an open chat window without the close control overlapping with the button to go to the backend. The chat header now uses a clearer close icon on the right, matching the desktop experience and restoring proper spacing.
Original PR description
While being logged in on mobile and having a chat window open in the frontend, the buttons to close the chat window and to go to the backend — both located on the top-left side of the screen — overlap, making it impossible to close the chat window. To solve this issue we've removed the chat window's `.fa-arrow-left` and replaced it with the `.fa-close` icon on the right which is the design we already have on desktop. Padding had been removed around the close button on mobile and has been put back. task-3120032 https://github.com/odoo/odoo/pull/126889 X-original-commit: 870fcce
Miscellaneous changes
For task-3347812, we needed to create the same Adapter used in l10n_eg_edi_eta. Moving the adapter to account.tools allows us to reuse the same class in different modules. Forward-Port-Of: odoo/odoo#125161
Original PR description
For task-3347812, we needed to create the same Adapter used in l10n_eg_edi_eta. Moving the adapter to account.tools allows us to reuse the same class in different modules. Forward-Port-Of: odoo/odoo#125161
This happens because last `<p>` of message was always `inline-block` to properly position "(edited)". However, this was breaking some non-editable content that relies on `<p>` default displays (`block`). This commit fixes the issue by only inlining the last `<p>` of an edited message. Non-edited message keeps the default styling of `<p>`. Also slightly improve alignment of edited on empty body messages. Related to Task-3374747 Before / After <img width="458" alt="before" src="https:
Original PR description
This happens because last `<p>` of message was always `inline-block` to properly position "(edited)". However, this was breaking some non-editable content that relies on `<p>` default displays (`block`). This commit fixes the issue by only inlining the last `<p>` of an edited message. Non-edited message keeps the default styling of `<p>`. Also slightly improve alignment of edited on empty body messages. Related to Task-3374747 Before / After <img width="458" alt="before" src="https://github.com/odoo/odoo/assets/6569390/568a923e-2d34-4411-9bb2-b0e188bd1be9"> <img width="460" alt="after" src="https://github.com/odoo/odoo/assets/6569390/51f10078-492b-46bd-a811-2b6e341463c8"> Forward-Port-Of: odoo/odoo#126939
Current behaviour: --- When reversing a bank statement, the partner id gets removed Steps to reproduce: --- 1. Go to Accounting, Journal Entries 2. Select/Create a bank statement with partner 3. Click on Reverse entry, then Reverse 4. Head back to Journal Entries 5. Reversal of the bank statement has no partner opw-3345594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126913 Forward-Port-Of: odoo/odoo#12597
Original PR description
Current behaviour: --- When reversing a bank statement, the partner id gets removed Steps to reproduce: --- 1. Go to Accounting, Journal Entries 2. Select/Create a bank statement with partner 3. Click on Reverse entry, then Reverse 4. Head back to Journal Entries 5. Reversal of the bank statement has no partner opw-3345594 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126913 Forward-Port-Of: odoo/odoo#125973
While being logged in on mobile and having a chat window open in the frontend, the buttons to close the chat window and to go to the backend — both located on the top-left side of the screen — overlap, making it impossible to close the chat window. To solve this issue we've removed the chat window's `.fa-arrow-left` and replaced it with the `.fa-close` icon on the right which is the design we already have on desktop. Padding had been removed around the close button on mobile and has been put
Original PR description
While being logged in on mobile and having a chat window open in the frontend, the buttons to close the chat window and to go to the backend — both located on the top-left side of the screen — overlap, making it impossible to close the chat window. To solve this issue we've removed the chat window's `.fa-arrow-left` and replaced it with the `.fa-close` icon on the right which is the design we already have on desktop. Padding had been removed around the close button on mobile and has been put back. task-3120032 https://github.com/odoo/enterprise/pull/43485 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#126865 Forward-Port-Of: odoo/odoo#109476
This PR fixes the missing margins on either side of the dropdown buttons in the control panel. Issue in the pad: [EDI] Dashboards: spacing issue between inputs https://tinyurl.com/2gzrpftg The CSS for the .o-filter-value wasn't targeting anything. This was fixed by moving the CSS into its correct parent. Note the whole layout for Dashboard needs reworking so I didn't make any further changes just yet. task-3326566 part of task-3326263 --- I confirm I have signed the CLA an
Original PR description
This PR fixes the missing margins on either side of the dropdown buttons in the control panel. Issue in the pad: [EDI] Dashboards: spacing issue between inputs https://tinyurl.com/2gzrpftg The CSS for the .o-filter-value wasn't targeting anything. This was fixed by moving the CSS into its correct parent. Note the whole layout for Dashboard needs reworking so I didn't make any further changes just yet. task-3326566 part of task-3326263 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#121372
In [1], one tour which ends on a form view was forgotten (because it does not end on a Knowledge form view but in Helpdesk), but the issue is the same: If a tour ends on a form view with ongoing changes without being discarded, it may cause `urgentSave` issues like mentionned in [2]. This commit aims to fix the runbot issue [3], in which a test running after the tour being fixed failed because the ressources it relied upon were flushed by the ongoing thread of the tour (the `helpdesk_tea
Original PR description
In [1], one tour which ends on a form view was forgotten (because it does not end on a Knowledge form view but in Helpdesk), but the issue is the same: If a tour ends on a form view with ongoing…
In [1], one tour which ends on a form view was forgotten (because it does not end on a Knowledge form view but in Helpdesk), but the issue is the same: If a tour ends on a form view with ongoing changes without being discarded, it may cause `urgentSave` issues like mentionned in [2]. This commit aims to fix the runbot issue [3], in which a test running after the tour being fixed failed because the ressources it relied upon were flushed by the ongoing thread of the tour (the `helpdesk_team` record). This could result in the `Help` menu button not being displayed in the navbar menu as it was needed by the following test tour, ending in a failure of the test. Add a check for a tour which add a file to send by message. It should also ensure that the file finished being uploaded before ending the tour. Modify the tour that sends a message so that it only ensures that the macro writes correctly in the message body on the form dialog. The message sending feature should be tested in mail. [1]: https://github.com/odoo/enterprise/pull/42555 [2]: https://github.com/odoo/odoo/pull/96517 [3]: https://runbot.odoo.com/web/#id=21676&view_type=form&model=runbot.build.error&menu_id=405&cids=1 task-3383231 Forward-Port-Of: odoo/enterprise#43486 Forward-Port-Of: odoo/enterprise#43056
Main - Wrong Computation of Matched Percentage when there are journal items for AR/AP for both the debit and credit. Explanation - When a Journal Entry bears at least one journal time in the debit and one journal item the credit. The computation of the `matched_percentage` gets computated in the wrong way. This is because the balance value gets ADDED prior to be converted into an ABSOLUTE value. The other way around provide the proper values. That is, First convert the balance into an
Original PR description
Main - Wrong Computation of Matched Percentage when there are journal items for AR/AP for both the debit and credit. Explanation - When a Journal Entry bears at least one journal time in the debit…
Main
-
Wrong Computation of Matched Percentage when there are journal items for AR/AP for both the debit and credit.
Explanation
-
When a Journal Entry bears at least one journal time in the debit and one journal item the credit. The computation of the `matched_percentage` gets computated in the wrong way. This is because the balance value gets ADDED prior to be converted into an ABSOLUTE value. The other way around provide the proper values. That is, First convert the balance into an ABS value and then ADD the values.
Have the following Journal Entry. It could not make sense but demonstrate the issue.
**FY0**
|account|debit|credit|
|-|-:|-:|
|AR|350||
|AR||150|
|INCOME||200|
<img width="1149" alt="Screenshot 2023-06-27 at 11 17 34" src="https://github.com/odoo/odoo/assets/7598010/b2e54b5e-219a-4e68-9ead-f037d7df3187">
Reconciliations
-
Let us apply two reconciliations in two different fiscal years.
**FY1**
|account|debit|credit|
|-|-:|-:|
|BANK|350||
|AR||350|
<img width="1156" alt="Screenshot 2023-06-27 at 11 19 09" src="https://github.com/odoo/odoo/assets/7598010/7bc578dd-17aa-4842-9ea8-10f5c39e574b">
**FY2**
|account|debit|credit|
|-|-:|-:|
|AR|150||
|OTHER INCOME||150|
<img width="1164" alt="Screenshot 2023-06-27 at 11 26 51" src="https://github.com/odoo/odoo/assets/7598010/6dbd9867-1eda-46c2-88d5-f7110f64d153">
Current Behavior
-
```
CASE WHEN (aml.balance = 0 OR sub_aml.total_per_account = 0)
THEN 0
ELSE part.amount / ABS(sub_aml.total_per_account)
END as matched_percentage
...
ABS(SUM(balance)) AS total_per_account
```
The computation of `total_per_account` will yield 200
For zero fiscal year:

For first reconciliation in FY1 the `matched_percentage` will be (350 / 200) = 1.75 - That is 175% the income to be reported. 200 * 1.75 = 350 income

For second reconciliation in FY2 the `matched_percentage` will be: For the first JE (150 / 200) = 0.75 - That is 75% the income to be reported. 200 * 0.75 = 150 income For the third JE (150 / 150) = 1.00 - That is 100% the other income to be reported. 150 * 1.00 = 150 other income

**Conclusion**
At the end of the whole process you have reported:
- 350 + 150 in income (wrong) exceeds the amount of income to be reported at the End of the Cycle
- 150 in other income. (right)
Expected Behavior
-
```
CASE WHEN (aml.balance = 0 OR sub_aml.total_per_account = 0)
THEN 0
ELSE part.amount / ABS(sub_aml.total_per_account)
END as matched_percentage
...
SUM(ABS(balance)) AS total_per_account -- here goes the change ABS(SUM(balance)) -> SUM(ABS(balance))
```
The computation of `total_per_account` will yield 500
For zero fiscal year:

For first reconciliation in FY1 the `matched_percentage` will be (350 / 500) = 0.70 - That is 70% the income to be reported. 200 * 0.70 = 140 income

For second reconciliation in FY2 the `matched_percentage` will be: For the first JE (150 / 500) = 0.30 - That is 30% the income to be reported. 200 * 0.30 = 60 income For the third JE (150 / 150) = 1.00 - That is 100% the other income to be reported. 150 * 1.00 = 150 other income

**Conclusion**
At the end of the whole process you have reported:
- 140 + 60 in income (right) the full amount of income to reported at the end of the cycle
- 150 in other income. (right)
Forward-Port-Of: odoo/enterprise#43460
Forward-Port-Of: odoo/enterprise#43255Before this commit, the field `total_value` was not rounded, leading to error messages from sendcloud: ``` "total_order_value":["Ensure that there are no more than 2 decimal places."]``` or: ```"total_order_value":["Ensure that there are no more than 10 digits in total."]``` opw-3378889 Forward-Port-Of: odoo/enterprise#43218
Original PR description
Before this commit, the field `total_value` was not rounded, leading to error messages from sendcloud: ``` "total_order_value":["Ensure that there are no more than 2 decimal places."]``` or: ```"total_order_value":["Ensure that there are no more than 10 digits in total."]``` opw-3378889 Forward-Port-Of: odoo/enterprise#43218
With an MX company setup Have multiple invoices signed Create a payment, reconcile with the invoices Send the payment for validation Due to the use of floating point values, when calculating the cfdi vals we may end up with a slightly off quantity of total tax paid (example: 3315.209999999999 instead of 3315.21) When we make a float_round with 'DOWN' rounding method 3315.209999999999 will round to 3315.20, worsening the error. As result the cfdi validation will fail A solution is to ma
Original PR description
With an MX company setup Have multiple invoices signed Create a payment, reconcile with the invoices Send the payment for validation Due to the use of floating point values, when calculating the cfdi vals we may end up with a slightly off quantity of total tax paid (example: 3315.209999999999 instead of 3315.21) When we make a float_round with 'DOWN' rounding method 3315.209999999999 will round to 3315.20, worsening the error. As result the cfdi validation will fail A solution is to make a first round of float_round with high precision to correct floating point errors opw-3337214 Forward-Port-Of: odoo/enterprise#41861
Issues generated during upgrading database from saas 16.1 to saas 16.2 and saas 16.3 on customer database there are `miscellanous` journal available but all are not set as Favourite ,so `show_on_dashboard` is False. so when it's try to find default `miscellanous` journal to use for `account_tax_periodicity_journal_id` field we got error : ``` null value in column "journal_id" of relation "account_move" violates not-null constraint ``` Forward-Port-Of: odoo/enterprise#43369
Original PR description
Issues generated during upgrading database from saas 16.1 to saas 16.2 and saas 16.3 on customer database there are `miscellanous` journal available but all are not set as Favourite ,so `show_on_dashboard` is False. so when it's try to find default `miscellanous` journal to use for `account_tax_periodicity_journal_id` field we got error : ``` null value in column "journal_id" of relation "account_move" violates not-null constraint ``` Forward-Port-Of: odoo/enterprise#43369
Before: trying to update the currencies while selecting the bank oof Turkey as the exchange service would raise a UserError. This was causes by an SSL error that happens with OpelSSL 3.0 when trying to connect to legacy websites that disable renegotiation without signaling it correctly. Now: an SSL context that enables legacy server connect is set up and used for the server request. task-3302273 Forward-Port-Of: odoo/enterprise#40936
Original PR description
Before: trying to update the currencies while selecting the bank oof Turkey as the exchange service would raise a UserError. This was causes by an SSL error that happens with OpelSSL 3.0 when trying to connect to legacy websites that disable renegotiation without signaling it correctly. Now: an SSL context that enables legacy server connect is set up and used for the server request. task-3302273 Forward-Port-Of: odoo/enterprise#40936