Monday, March 3, 2025
42 changes · saas-18.1
Resolved issues and error corrections
Fixes visual and interaction issues in the Discuss sidebar when it is compact and a channel call is active. Call participant menus now look consistent, user status appears on the correct avatar, and the compact sidebar no longer opens an avatar view that users cannot close.
Original PR description
When discuss sidebar is compact and there's a call in a channel, the call participant UI in discuss sidebar had the following issues: - The floating menu had harsh shadow, whereas all other floating…
When discuss sidebar is compact and there's a call in a channel, the call participant UI in discuss sidebar had the following issues: - The floating menu had harsh shadow, whereas all other floating menu have soft shadow `.shadow-sm`. - The short status of user was shown in the bottom-right of "+X" users in call, rather than bottom-right of the avatar. - The avatar stack could be expanded when sidebar is compact, but there's no way to compact it again. This commit fixes the issues as follow: - Adds `.shadow-sm` in the floating menu of call participant. - Position short status of active call participant in bottom-right as it should - Remove expand feature on click avatar stack of call participant when sidebar is compact Before / After <img width="222" alt="Screenshot 2025-03-03 at 14 46 39" src="https://github.com/user-attachments/assets/27b86dda-ab5e-4f70-b467-f8af28945a7e" /> <img width="224" alt="Screenshot 2025-03-03 at 14 45 49" src="https://github.com/user-attachments/assets/906b8e81-d1db-409b-a42a-a90af0804639" /> Expand bug: 
Miscellaneous changes
Certain certificates contain additional fields beyond those currently included (CN, OU, O, C), such as "2.5.4.97" and "L". Since these additional fields are not incorporated into the issuer name, attempts to validate the signed document on the following sites will result in errors: - https://face.gob.es/es/facturas/validar-visualizar-facturas - https://valide.redsara.es/valide/validarFirma/ejecutar.html These errors typically indicate that the signature is either invalid and that the cer
Original PR description
Certain certificates contain additional fields beyond those currently included (CN, OU, O, C), such as "2.5.4.97" and "L". Since these additional fields are not incorporated into the issuer name, attempts to validate the signed document on the following sites will result in errors: - https://face.gob.es/es/facturas/validar-visualizar-facturas - https://valide.redsara.es/valide/validarFirma/ejecutar.html These errors typically indicate that the signature is either invalid and that the certificate does not match the values within `<KeyInfo>`. This discrepancy occurs because all certificate fields are included in the signature, but some are missing from the `<X509IssuerName>` field. This fix adds the missing certificate fields to ensure consistency between the signature and the issuer name. Based on my tests, the order of these fields does not affect the validation process. opw-4484906 opw-4482626 Forward-Port-Of: odoo/odoo#199891 Forward-Port-Of: odoo/odoo#196576
Task Adhoc side: 44224 Update l10n_ar_withholding translations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197361
Original PR description
Task Adhoc side: 44224 Update l10n_ar_withholding translations. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197361
Before this commit, the sample payload displayed next to server actions of type 'webhook' didn't respect the format of the actual payload sent by `_run_action_webhook`. This commit fixes that by adjusting the `_compute_webhook_sample_payload` method so it includes the exact same keys and values that will be sent by the server action when ran. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199018
Original PR description
Before this commit, the sample payload displayed next to server actions of type 'webhook' didn't respect the format of the actual payload sent by `_run_action_webhook`. This commit fixes that by adjusting the `_compute_webhook_sample_payload` method so it includes the exact same keys and values that will be sent by the server action when ran. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199018
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR
Original PR description
Steps to Reproduce: - Log in with a user having no special access right in Employees. - Install point_of_sale and hr modules. - Try to download the "User Labels" from the "My Profile" section. Cause: - In the report barcode field has been used which is accessible only to users having "group_hr_user" group. Fix: - Added a check before accessing the barcode field, to ensure the user has the appropriate access right. task-4497441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#199592 Forward-Port-Of: odoo/odoo#196912
Currently in the italian e-invoice system it is not allowed to report negative lines so when the system needs to encode an invoice with negative lines it will dispatch them over the other lines with same tax, keeping the negative amount as discount. However when the discounted line amount is 0 this line is not reported in the e-invoice anymore Steps to reproduce: - With IT Company setup - Create an invoice for IT customer, with lines: 1. Quantity 1 | Price 0.0 | Tax 22% 2. Qua
Original PR description
Currently in the italian e-invoice system it is not allowed to report negative lines so when the system needs to encode an invoice with negative lines it will dispatch them over the other lines with same tax, keeping the negative amount as discount. However when the discounted line amount is 0 this line is not reported in the e-invoice anymore Steps to reproduce: - With IT Company setup - Create an invoice for IT customer, with lines: 1. Quantity 1 | Price 0.0 | Tax 22% 2. Quantity 1 | Price 150.0 | Tax 22% 3. Quantity 1 | Price 100.0 | Tax 22% 4. Quantity 1 | Price -200.0 | Tax 22% - Confirm & send - Check generated e-invoice xml Issue: Line 3 is missing This occurs because after dispatching negative lines on suitable candidates we ignore nulled lines opw-4501951 Forward-Port-Of: odoo/odoo#198497
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Original PR description
Description of the issue/feature this PR addresses: Task: https://www.odoo.com/odoo/my-tasks/4179478 Current behavior before PR: - Wrong names for certain accounts Desired behavior after PR is merged: - Fix names for accounts --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#190705
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Handling of notification data crashes when fetching a dict key: ```python payment_data = notification_data['payment'] ``` Cause ----- Commit c3c9c12d790e forwards rejected payments to handle the reason they were rejected. The issue is that notification data from rejected payments doesn't have an immediate `payment` key
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have an expired credit card; 2. have an Odoo subscription; 3. pay subscription with expired credit card. Issue ----- Handling of notification data crashes when fetching a dict key: ```python payment_data = notification_data['payment'] ``` Cause ----- Commit c3c9c12d790e forwards rejected payments to handle the reason they were rejected. The issue is that notification data from rejected payments doesn't have an immediate `payment` key. Instead, it contains the following keys: - `errorId` - `errors` - `paymentResult` The `payment` key we need is located in the `paymentResult` value. Solution -------- Use a new variable `payment_result`, and set it to the `paymentResult` value if it exists, otherwise to `notification_data`. We can ignore the `errors` value as it is identical to the one in the `statusOutput` value of `paymentResult`. opw-4481602 Forward-Port-Of: odoo/odoo#199211
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. - Cause an issue for MX and EC country code - VAT field is removed from mandatory fields - No need to remove the vat field manually, when the country changes the mandatory field list will be changed accordingly. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/enterprise/pull/79646 --- I confirm I have signed the CLA and read the PR guide
Original PR description
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. - Cause an issue for MX and EC country code - VAT field is removed from mandatory fields - No need to remove the vat field manually, when the country changes the mandatory field list will be changed accordingly. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/enterprise/pull/79646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198506
A traceback error occurs when creating an employee without working hours, setting up an accrual allocation for that employee, and choosing a start date before yesterday. **Steps to reproduce the issue:** 1- Create a new employee in the Employees module with an empty "Working Hours" field. 2- Create an accrual plan: - Go to Time Off > Configurations > Accrual Plans > New. - Create a new milestone for X amount of days hourly, source: Calendar. 3- Create an accrual allocation for t
Original PR description
A traceback error occurs when creating an employee without working hours, setting up an accrual allocation for that employee, and choosing a start date before yesterday. **Steps to reproduce the…
A traceback error occurs when creating an employee without working hours, setting up an accrual allocation for that employee, and choosing a start date before yesterday. **Steps to reproduce the issue:** 1- Create a new employee in the Employees module with an empty "Working Hours" field. 2- Create an accrual plan: - Go to Time Off > Configurations > Accrual Plans > New. - Create a new milestone for X amount of days hourly, source: Calendar. 3- Create an accrual allocation for that employee: - Go to Time Off > Management > Allocations > New. - Select the accrual plan created earlier. If you choose any start date before yesterday, a traceback error occurs (see screenshots attached) <img src="https://github.com/user-attachments/assets/03198eb8-5e9a-4633-a87f-b0c07aec600d" alt="traceback_error" width="400"/> The PO (GMF) confirmed that there should always be a fallback for "Working Hours" in this order: Working hours from Contract > Working Hours from Employee > Working Hours from company opw-4281311 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197505 Forward-Port-Of: odoo/odoo#185428
Steps: - Install account app. - Go to invoice add a product. - Update product description from invoice line. - Print invoice. Issue: - Product name is missing in PDF file. Cause: - Updating line name remove product name from line name and only add newly added string description. In `product_label_section_and_note_field` widget we only display description without product name in description input even description contains product name in it but when user update that description input
Original PR description
Steps: - Install account app. - Go to invoice add a product. - Update product description from invoice line. - Print invoice. Issue: - Product name is missing in PDF file. Cause: - Updating line name remove product name from line name and only add newly added string description. In `product_label_section_and_note_field` widget we only display description without product name in description input even description contains product name in it but when user update that description input we forgot to take product name into account. Fix: - Take product name into account when updating description from that widget. opw-4599839 opw-4603802 opw-4571431 Forward-Port-Of: odoo/odoo#199529
Steps to reproduce: 1) Configure pick up in store dm and publish it 2) Go to product page of a customizable desk 3) Choose the impossible combination (Aluminium and black) 4) Observe traceback Reason: Necessary fields are absent in combination info when the combination is not possible. Solution: Do not render the widget when a combination is not possible. Forward-Port-Of: odoo/odoo#199632
Original PR description
Steps to reproduce: 1) Configure pick up in store dm and publish it 2) Go to product page of a customizable desk 3) Choose the impossible combination (Aluminium and black) 4) Observe traceback Reason: Necessary fields are absent in combination info when the combination is not possible. Solution: Do not render the widget when a combination is not possible. Forward-Port-Of: odoo/odoo#199632
- Open a posted invoice - Reset to draft - Action > Switch into invoice/credit note Validation Error will raise `You cannot switch the type of a posted document.` However the message is misleading, because we check that the document has not been posted at all opw-4509455 Forward-Port-Of: odoo/odoo#199494 Forward-Port-Of: odoo/odoo#198592
Original PR description
- Open a posted invoice - Reset to draft - Action > Switch into invoice/credit note Validation Error will raise `You cannot switch the type of a posted document.` However the message is misleading, because we check that the document has not been posted at all opw-4509455 Forward-Port-Of: odoo/odoo#199494 Forward-Port-Of: odoo/odoo#198592
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because we render the header and footer in their own viewport. In the report editor however, the viewport is unique and the svg was then fixed to the top of the page. After this commit, the report layouts continue to work in wkhtmltopdf, but we removed the top = 0 attribute. Following https://stackove
Original PR description
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because…
Before this commit the wave and bubble layouts did not play well in the report editor. The svg was set to be an overlay, in fixed position, with a top = 0 property. In wkhtmltopdf it did work because we render the header and footer in their own viewport. In the report editor however, the viewport is unique and the svg was then fixed to the top of the page. After this commit, the report layouts continue to work in wkhtmltopdf, but we removed the top = 0 attribute. Following https://stackoverflow.com/a/12282107 it should work in the contexts: (TLDR: in position fixed, if top and bottom are not specified, the default position is the one the block should have taken if it were staticly positioned) - wkhtmltopdf: the footer is rendered in its own viewport and consequently the top of the viewport is also the top of the footer and thus the original static position - action report of type HTML: no worries here, this fix doesn't apply because of ifs in the qweb expressions - report editor in edition mode: The SVG is inisible anyway because it needs a fill value which is not present in that context. The svg is located outside of the iframe's port in practice with the fix. - report editor in preview mode: works because the iframe cannot be interacted with and that the default static position is within the footer opw-4508900 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#196468
## Versions: 17.0+ ## Issue: Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view. ## Steps to reproduce: 1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`; 2. Add 1 attribute value; 3. Go to any product available on the shop (e.g. Acoustic Bloc Screens); 4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value; 5. Go to the shop
Original PR description
## Versions:
17.0+
## Issue:
Multi-checkboxes attributes are displayed as filters in the shop view but are not displayed in mobile view.
## Steps to reproduce:
1. Create a `Multi-checkbox (option)` attribute called "Extra" via `Sales / Configuration / Products / Attributes`;
2. Add 1 attribute value;
3. Go to any product available on the shop (e.g. Acoustic Bloc Screens);
4. Via its `Attributes & Variants` tab, add the newly created attributes and select the value;
5. Go to the shop via the `Website` app;
- *In normal web view, the filter is available on the left*
6. Change view to mobile mode and open the filters;
7. Open the "Extra filter and see no filter under it.
## Cause:
Mobile displayed filters are restricted to avoid color attributes but didn't expand to allow multi-checkboxes.
opw-4383970
Forward-Port-Of: odoo/odoo#198087…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about t
Original PR description
…number Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. opw-3993305 Forward-Port-Of: odoo/odoo#181450 Forward-Port-Of: odoo/odoo#174950
### Steps to reproduce: - Install sale, project, and accountant. - Allow Analytic Accounting from settings. - Open project application. - Create a project with a billable feature. - Add invoices in the topbar. - Select invoices and create a new invoice. - Add a product to the invoice (you will see analytic is added). Go to the journal items tab. ### Issue: When the user opens the Analytical Account, the gross margin is shown incorrectly. ### Cause: When a bill or i
Original PR description
### Steps to reproduce: - Install sale, project, and accountant. - Allow Analytic Accounting from settings. - Open project application. - Create a project with a billable feature. - Add invoices in the topbar. - Select invoices and create a new invoice. - Add a product to the invoice (you will see analytic is added). Go to the journal items tab. ### Issue: When the user opens the Analytical Account, the gross margin is shown incorrectly. ### Cause: When a bill or invoice is created from the project topbar, the analytical distribution is set in the payable/receivable journal items, causing the gross margin to show as 0. ### Fix: In this commit, we remove the setting of the analytical distribution in the payable/receivable journal items. As a result, no journal items related to payable/receivable will be added to the Analytic Line. task-4377544 Forward-Port-Of: odoo/odoo#190675
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate
Original PR description
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time,…
**Steps to reproduce** - Create accrual plan with "Accrued gain time": at the start of the accrual period - Create a milestone with 10 days yearly on the 1st of the year, don't cap accrued time, milestone reached: 0 days after allocation start date, carry over: all accrued time carried over. - Create an allocation using this accrual plan. Set the start date a few years in the past (e.g. 3 years ago). Save the allocation. - Manually set the number of days of the allocation to 0. - Validate the allocation. - Time Off Dashboard > Check the number of days accrued on the 2nd day of next year. Actual: 20 days. Expected: 10 days (gained on the 1st of next year, 0 days before that as the allocation has been set to 0). **Cause** 0 days allocations (using an acrcual plan with gain time at start) are considered as not already accrued, even if they are marked as `already_accrued`. https://github.com/odoo/odoo/blob/8b339fdde161e81e1a00cecd3b1fd280de51fd08/addons/hr_holidays/models/hr_leave_allocation.py#L460 In this case, we process the accrual plans when changing the date, which triggers the `_onchange_date_from` and marks the allocation as `already_accrued`. opw-4340521 Forward-Port-Of: odoo/odoo#198110
Forward-Port-Of: odoo/odoo#198651 Forward-Port-Of: odoo/odoo#198352
Original PR description
Forward-Port-Of: odoo/odoo#198651 Forward-Port-Of: odoo/odoo#198352
The lack of borders in the modals of the front-end is problematic when there is some content overflowing the height of the modal. This PR restores the borders for a better visual hierarchy. Non-optimal design introduced in front-end redesign: https://github.com/odoo/odoo/pull/120302 task-4001380 | Before | After | |--------|--------| | <img width="979" alt="Screenshot 2024-06-20 at 11 41 54" src="https://github.com/odoo/odoo/assets/110090660/31e0d3c7-fcd9-43c9-9aae-7db3b4e49af2"> |
Original PR description
The lack of borders in the modals of the front-end is problematic when there is some content overflowing the height of the modal. This PR restores the borders for a better visual hierarchy. Non-optimal design introduced in front-end redesign: https://github.com/odoo/odoo/pull/120302 task-4001380 | Before | After | |--------|--------| | <img width="979" alt="Screenshot 2024-06-20 at 11 41 54" src="https://github.com/odoo/odoo/assets/110090660/31e0d3c7-fcd9-43c9-9aae-7db3b4e49af2"> | <img width="978" alt="Screenshot 2024-06-20 at 11 42 26" src="https://github.com/odoo/odoo/assets/110090660/09f12eb0-79e4-454f-9896-af238b26a7b3"> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#170105
Fix a typo introduced in 4ec8d2198a1a042cde397b73e2afd56e108c7892 Forward-Port-Of: odoo/odoo#199960
Original PR description
Fix a typo introduced in 4ec8d2198a1a042cde397b73e2afd56e108c7892 Forward-Port-Of: odoo/odoo#199960
Some "True"/"False" terms were incorrectly untranslated back into "True"/"False" in German. This cases a test to fail and was incorrect in these contexts. Revert it. Note: Some inconsistency reverts may have been applied, but should have no effect on code. More thorough revert will be done later on by translator. 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 t
Original PR description
Some "True"/"False" terms were incorrectly untranslated back into "True"/"False" in German. This cases a test to fail and was incorrect in these contexts. Revert it. Note: Some inconsistency reverts may have been applied, but should have no effect on code. More thorough revert will be done later on by translator. 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
When calling `account_move_line._compute_account_id` (via `action_update_fpos_values` for example), we wrongly delete a line after after assigning a new account here https://github.com/odoo/odoo/blob/22bdaf64ff3f2ee37cd51f0938d1bdd80f9e5ee8/addons/account/models/account_move_line.py#L599-L602 This is because we set a default value for `analytic_distribution` in `_prepare_base_line_tax_repartition_grouping_key`, therefore we enter in the wrong condition here https://github.com/odoo/odoo/blob/6ff
Original PR description
When calling `account_move_line._compute_account_id` (via `action_update_fpos_values` for example), we wrongly delete a line after after assigning a new account here…
When calling `account_move_line._compute_account_id` (via
`action_update_fpos_values` for example), we wrongly delete a line after
after assigning a new account here https://github.com/odoo/odoo/blob/22bdaf64ff3f2ee37cd51f0938d1bdd80f9e5ee8/addons/account/models/account_move_line.py#L599-L602
This is because we set a default value for `analytic_distribution` in
`_prepare_base_line_tax_repartition_grouping_key`, therefore we enter
in the wrong condition here https://github.com/odoo/odoo/blob/6ff943b30561f2d7415fdbdfc2246716428779be/addons/account/models/account_tax.py#L2407
because in `grouping_key`, we have `{'analytic_distribution': {}}` and in `tax_lines_mapping` we have`{'analytic_distribution': False}`
Steps:
- Have a fiscal position that map the default revenue account to another
- Create an invoice with the fiscal position created previously, add a
product line
- Unset fiscal position, and click on 'Update Taxes and Accounts' button
-> Error: "Record does not exist or has been deleted."
opw-4512877
Forward-Port-Of: odoo/odoo#198086Before this commit: This test was ignored by the runbot platform as the test was consistently failing. Starting version 18, the flow of the "Buy Now" button did change to redirect to the card after being pressed rather than the payment page as intended in the PR: https://github.com/odoo/odoo/pull/149020 After this commit: Remove irelevant part of the test to make it successful rb-56459 Forward-Port-Of: odoo/odoo#199616
Original PR description
Before this commit: This test was ignored by the runbot platform as the test was consistently failing. Starting version 18, the flow of the "Buy Now" button did change to redirect to the card after being pressed rather than the payment page as intended in the PR: https://github.com/odoo/odoo/pull/149020 After this commit: Remove irelevant part of the test to make it successful rb-56459 Forward-Port-Of: odoo/odoo#199616
Traceback when state (which is a non required field) is empty. Fix the express checkout flow. Bug introduced in 80507191 opw-4577470 Forward-Port-Of: odoo/odoo#199594
Original PR description
Traceback when state (which is a non required field) is empty. Fix the express checkout flow. Bug introduced in 80507191 opw-4577470 Forward-Port-Of: odoo/odoo#199594
**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551
Original PR description
**Issue:** The formula of the cross report line for the 2024 variant of the balance sheet report is referencing a report line from the main profit and loss report instead of its 2024 variant. opw-4566689 opw-4590293 opw-4572865 Forward-Port-Of: odoo/enterprise#80551
Update l10n_ar_reports and l10n_uy_edi translations. Task Adhoc side: 44224 Forward-Port-Of: odoo/enterprise#79104
Original PR description
Update l10n_ar_reports and l10n_uy_edi translations. Task Adhoc side: 44224 Forward-Port-Of: odoo/enterprise#79104
Steps to reproduce =================== Admin: 1. Create an article 2. Share the article 3. Add a portal user as a member 4. Write a comment (using the editor, select the text, and use the toolbar to write a comment) 5. Attach a file to the new message Portal: 6. Go to the created article 7. Go to the comment with the message and attachment 8. Download/view the attachment => No access to the document After this commit ================= Portal user who has read or write access t
Original PR description
Steps to reproduce =================== Admin: 1. Create an article 2. Share the article 3. Add a portal user as a member 4. Write a comment (using the editor, select the text, and use the toolbar to write a comment) 5. Attach a file to the new message Portal: 6. Go to the created article 7. Go to the comment with the message and attachment 8. Download/view the attachment => No access to the document After this commit ================= Portal user who has read or write access to the linked article is granted the access Task-4223292 Forward-Port-Of: odoo/enterprise#75819
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones On the left hand side - in the studio editor select "Edit Source" On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402 Forward-Port-Of: odoo/enterprise
Original PR description
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones On the left hand side - in the studio editor select "Edit Source" On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402 Forward-Port-Of: odoo/enterprise#78462
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
Original PR description
- update upper and lower limits for nssf parameter Task: 4599150 Forward-Port-Of: odoo/enterprise#80016
__Steps to reproduce:__ 1. Create a project (billable). 2. Give the user access to Company A + B, while the default is A 3. Add a task with a customer belonging to company B 4. Create a task and add products to it. __Description of the issue:__ - The **"Decrease"** button is disabled, with raised error message that the amount is delivered. - This happens because the domain fetching `stock.move` uses user’s default company instead of SO’s company which leads to the wrong default WH _
Original PR description
__Steps to reproduce:__ 1. Create a project (billable). 2. Give the user access to Company A + B, while the default is A 3. Add a task with a customer belonging to company B 4. Create a task and add products to it. __Description of the issue:__ - The **"Decrease"** button is disabled, with raised error message that the amount is delivered. - This happens because the domain fetching `stock.move` uses user’s default company instead of SO’s company which leads to the wrong default WH __Description of the solution:__ - Update warehouse logic to fetch the default warehouse using the SO’s company context, ensuring `stock.move` domain aligns with the sale order’s company - opw-4471366 Forward-Port-Of: odoo/enterprise#80007
…onus Forward-Port-Of: odoo/enterprise#80376
Original PR description
…onus Forward-Port-Of: odoo/enterprise#80376
Following feedbacks from partners and clients, we add the following improvements: - Employee Address on the payslip - Employee bank account on the payslip - Private phone and email on the employee view Forward-Port-Of: odoo/enterprise#80366
Original PR description
Following feedbacks from partners and clients, we add the following improvements: - Employee Address on the payslip - Employee bank account on the payslip - Private phone and email on the employee view Forward-Port-Of: odoo/enterprise#80366
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/odoo/pull/198506 Forward-Port-Of: odoo/enterprise#79646
Original PR description
This commit fixes the runbot test failures related to invoice generation when the user is not logged in and VAT values are missing. Runbot Errors: 111328, 111329 Related: https://github.com/odoo/odoo/pull/198506 Forward-Port-Of: odoo/enterprise#79646
Have a field in a view like this ```<field name="" options="{ some_boolean: 1 }" />``` And have the corresponding supportedOption (defined on the field widget): ```{ somme_boolean: { type: "boolean" } }``` Open studio and click on that field, in debug mode. Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean. Forw
Original PR description
Have a field in a view like this
```<field name="" options="{ some_boolean: 1 }" />```
And have the corresponding supportedOption (defined on the field widget):
```{
somme_boolean: {
type: "boolean"
}
}```
Open studio and click on that field, in debug mode.
Before this commit, there was a crash because 1 or 0 were directly passed to a component which expected a boolean value. After this commit, before displaying the options we convert 0 or 1 to the corresponding boolean.
Forward-Port-Of: odoo/enterprise#80014Before this commit, in the wave and bubble layouts, the SVG acting as an overlay background of the footer was displayed on top of the report when entering the XML Editor of the reportEditor. This is due to multiple factors, all of which linked to how wkhtmltopdf works: - header and footers seem to be rendered in their own viewport, the top parameter is the start of the footer itself, not that of the page. - absolute positioning wrecks havoc in z-index with SVG's ..... Even though the HTM
Original PR description
Before this commit, in the wave and bubble layouts, the SVG acting as an overlay background of the footer was displayed on top of the report when entering the XML Editor of the reportEditor. This is due to multiple factors, all of which linked to how wkhtmltopdf works: - header and footers seem to be rendered in their own viewport, the top parameter is the start of the footer itself, not that of the page. - absolute positioning wrecks havoc in z-index with SVG's ..... Even though the HTML of the waves' and bubbles' layouts doesn't seem very well written, it does work in the current state of the art of Odoo's PDF rendering. This commit adapts the JS code in the XML editor of the reportEditor to account for it. opw-4508900 Forward-Port-Of: odoo/enterprise#77863
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial
Original PR description
Steps to reproduce: [l10n_ec] - Create a credit note from the Bill journal - Set a foreign customer - Set a customized document number Issue: An error will be raised saying that the format is not correct But, as defined by VBE, "If a Credit Note is created from a Vendor Bill and the partner_id != "EC", [we should] allow the user to allocate any number without following the EC format." Solution: When we call `_format_document_number` we don't have any information about the initial move. Instead of using a context or adding new fields, we add a hook in which we can specify certain conditions to bypass the document check/formatting for localisations. We had to add `partner_id` to avoid the flow in wich the user set a foreign customer and a custom document type to change back the customer to an ecuadorian one; hence the second part of the test opw-3993305 Forward-Port-Of: odoo/enterprise#70673 Forward-Port-Of: odoo/enterprise#67589
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#78982 Forward-Port-Of: odoo/enterprise#52832
Original PR description
The term used by group by should be the same term in the select, avoiding the alias and posible error like ERROR: column "account_account.name" must appear in the GROUP BY clause or be used in an aggregate function Forward-Port-Of: odoo/enterprise#78982 Forward-Port-Of: odoo/enterprise#52832
Seems like the tour takes steps while there may have been a delay in the web_save... seeming like there is an open form view in edition mode. runbot-111772 Forward-Port-Of: odoo/enterprise#79473
Original PR description
Seems like the tour takes steps while there may have been a delay in the web_save... seeming like there is an open form view in edition mode. runbot-111772 Forward-Port-Of: odoo/enterprise#79473
In Knowledge, in the Calendar embed, event text descriptions and properties tend to overlap with each other, and the header. The Calendar embed also does not resize properly when the sidebar width or article width get changed. This commit makes it so that event descriptions and properties do not overlap ; and that calendar width (and, subsequently, column width) is affected by sidebar or article width changes. task-4558391 Forward-Port-Of: odoo/enterprise#79164
Original PR description
In Knowledge, in the Calendar embed, event text descriptions and properties tend to overlap with each other, and the header. The Calendar embed also does not resize properly when the sidebar width or article width get changed. This commit makes it so that event descriptions and properties do not overlap ; and that calendar width (and, subsequently, column width) is affected by sidebar or article width changes. task-4558391 Forward-Port-Of: odoo/enterprise#79164
Test changed in d5da2b62263f85fbce0f2548085c066cbbf10371 needs to be changed back because of https://github.com/odoo/odoo/pull/198086 opw-4512877 Forward-Port-Of: odoo/enterprise#79576
Original PR description
Test changed in d5da2b62263f85fbce0f2548085c066cbbf10371 needs to be changed back because of https://github.com/odoo/odoo/pull/198086 opw-4512877 Forward-Port-Of: odoo/enterprise#79576
Remove the restrictions of the make_scss_customizations from the website generator and instead let the website scraper have full control. Forward-Port-Of: odoo/enterprise#80266
Original PR description
Remove the restrictions of the make_scss_customizations from the website generator and instead let the website scraper have full control. Forward-Port-Of: odoo/enterprise#80266