Wednesday, February 19, 2025
11 changes · 17.0
Resolved issues and error corrections
Inset participant cards in Discuss calls now use a solid black background when video does not fill the card. This prevents underlying interface elements from showing through, making calls look cleaner and less distracting.
Original PR description
Before this commit, inset call participant cards had no background, which would let some elements of the UI from below it to show when the video does not have a 16:9 aspect ratio. Before (inset card mask is transparent) <img width="198" alt="Screenshot 2025-02-19 at 15 58 56" src="https://github.com/user-attachments/assets/358a072d-d949-4e81-9ef7-7b09c2dd5c56" /> After (inset card mask is filled) <img width="189" alt="Screenshot 2025-02-19 at 15 59 34" src="https://github.com/user-attachments/assets/df32dbc8-d042-4802-a9b4-2f3d93e97963" />
This fix ensures Saudi EDI partner tax-related fields appear in the correct place on contact forms. It avoids a layout issue caused by another module wrapping the VAT field, helping users see and edit the fields where expected.
Original PR description
The module base_vat add a div around the vat field and so the xpath place the field in the div which is not what we want. By putting it after the address we are sure that those field are rightly placed task: 4543204 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of sale GSTR-1 reporting now uses the POS journal's default account when a product does not have its own income account set. This helps ensure HSN-related sales account information is filled correctly in Indian GST reports, reducing reporting gaps from incomplete product setup.
Original PR description
before this PR: - The income account was solely derived from the product's configuration. After this PR: - If the product’s income account is not set, we fall back to the default account defined on the POS journal. This ensures the Sales Account used in GSTR-1 computations is properly set. See: https://github.com/odoo/odoo/pull/149816
Receipts for customer account settlements no longer show the misleading “Start adding products” message when there are no product lines. This avoids confusing cashiers and customers during due account settlement transactions.
Original PR description
Issue: When settling user account, the order will not have any order lines, that will display a misleading empty state on the receipt, saying: "Start adding products". Fix: We only display the empty state if it's not an "account settling" order. Before: <img width="256" alt="image" src="https://github.com/user-attachments/assets/59b460de-10eb-41f7-aafb-dbd7baaba7dc" /> After: <img width="259" alt="Capture d’écran 2025-01-22 à 12 52 23" src="https://github.com/user-attachments/assets/06ad6806-acb9-492b-b13f-52f2475ee8ed" /> opw-4430325
Miscellaneous changes
Consider a recordset of new records, and a loop like ```py for record in records: for line in record.line_ids: line.value ``` The implementation of `record.line_ids` does not actually prefetch all `records`. It actually fetches the field on the records' origin (their corresponding real records), but only assigns the current new record in cache. As the prefetching relies on the cached values of `line_ids`, the prefetching mechanism is actually broken on `line`. The fix cons
Original PR description
Consider a recordset of new records, and a loop like
```py
for record in records:
for line in record.line_ids:
line.value
```
The implementation of `record.line_ids` does not actually prefetch all `records`. It actually fetches the field on the records' origin (their corresponding real records), but only assigns the current new record in cache. As the prefetching relies on the cached values of `line_ids`, the prefetching mechanism is actually broken on `line`.
The fix consists in assigning all the records to prefetch in this case. This does not add unexpected prefetching, since the origin records are prefetched as one batch anyway.
Forward-Port-Of: odoo/odoo#198124The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages.
Original PR description
The Debian control file is used when installing Debian packages needed by Odoo by using the `debinstall.sh` script. On the other hand, when the Odoo Debian package is built, the Debian dependencies are also computed by the `dh_python3` script. So finally the real dependencies may differ. The main issue is `python3-gevent` which is missing in the control file. With this commit, the packages are explicitely declared in the control file instead of relying on incidentally installed packages. * `python3-cryptography` is installed by `python3-openssl` * `python3-idna` and `python3-urllib3` are installed by `python3-requests` * `python3-markupsafe` is installed by `python3-jinja2` Forward-Port-Of: odoo/odoo#197302
Purpose of this commit: The command descriptions currently use an italic font style due to being wrapped in the emphasis tag, causing the text to appear cropped at the end of the sentence. This commit resolves the issue by replacing the emphasis tag with a span tag. task-4485553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193914
Original PR description
Purpose of this commit: The command descriptions currently use an italic font style due to being wrapped in the emphasis tag, causing the text to appear cropped at the end of the sentence. This commit resolves the issue by replacing the emphasis tag with a span tag. task-4485553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193914
Forward-Port-Of: odoo/enterprise#79561
Original PR description
Forward-Port-Of: odoo/enterprise#79561
An issue may occur where moves are unbalanced when FEC file lines contain a device with an imprecise rounding factor. Steps to reproduce: - Create or use a currency with rounding = 1. - Add rounding to debit or credit in a FEC file, ensuring the rounded unit amount is not equal; for example, two debit lines at 100.5 and one credit line at 201 (see example in test). - In the Idevise column of the file, use the name of the created device. - Attempt to import the file. An error will occur
Original PR description
An issue may occur where moves are unbalanced when FEC file lines contain a device with an imprecise rounding factor. Steps to reproduce: - Create or use a currency with rounding = 1. - Add rounding to debit or credit in a FEC file, ensuring the rounded unit amount is not equal; for example, two debit lines at 100.5 and one credit line at 201 (see example in test). - In the Idevise column of the file, use the name of the created device. - Attempt to import the file. An error will occur: Moves report incorrect balances: Move with name '<name>' has a balance of 1.00. The issue arises because the created device is used to round the amount instead of the company's device, resulting in 100.5 being rounded to 100, hence the two line of 100 no longer balances with 201. opw-4397836 Forward-Port-Of: odoo/enterprise#76932
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improv
Original PR description
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that…
After the [indentation fix] for xlsx exports, the styling logic was simplified to always show levels 0, 1 and 2 in bold and all deeper levels not in bold. Before that, there was a separate rule that defined that for any line having `caret_options`, we wouldn't use bold. Because of this, reports like the general ledger would display all detail lines indicating journal entries in bold (since they are in level 2). This looks very crowded and not very readable at all. In this commit, we improve the styling rules to always disable bold on the deepest line level. That way we can never have a XLSX file with all lines in bold, and it is much easier to read the file. Meanwhile, the style management was refactored a bit to make it simpler. [opw-4501822](https://www.odoo.com/odoo/project.task/4501822) [opw-4458752](https://www.odoo.com/odoo/project.task/4458752) [indentation fix]: https://github.com/odoo/enterprise/commit/9246a864f91e7facd06fa630fa0d23a0323ce497 Forward-Port-Of: odoo/enterprise#77510
During the execution of the validation cron of the OCR, the IAP account selected could sometimes be incorrect. In the context of the validation cron, we need to know to which company the document belong in order to get the correct IAP account (i.e. the one from the company, if it exists). If we use the generic IAP account (i.e. the one that isn't linked to any company), the mismatch of accounts will cause the validation to be ignored by the OCR server. Related ticket [#4522628](https://
Original PR description
During the execution of the validation cron of the OCR, the IAP account selected could sometimes be incorrect. In the context of the validation cron, we need to know to which company the document belong in order to get the correct IAP account (i.e. the one from the company, if it exists). If we use the generic IAP account (i.e. the one that isn't linked to any company), the mismatch of accounts will cause the validation to be ignored by the OCR server. Related ticket [#4522628](https://www.odoo.com/odoo/project.task/4522628) Forward-Port-Of: odoo/enterprise#79525