Monday, January 20, 2025
53 changes
1 change
Resolved issues and error corrections
The Lebanon accounting demo company setup now correctly recognizes demo data during installation. This avoids an unnecessary warning and helps demo environments install more smoothly.
Original PR description
The install_demo is missing from the try_loading of the Libanese demo company. runbot-109449 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
24 changes
Resolved issues and error corrections
Portal chatter messages now load the needed Discuss translations on the website frontend. This prevents untranslated labels or text from appearing to portal users and improves the experience for multilingual websites.
Original PR description
Portal chatter now uses discuss, thus it relies on translation of Discuss in `mail` module. Frontend translations need to be available, they aren't by default unless the module is prefixed by `website`. This isn't the case for `mail`, and the module `website_mail` does not share the translations. This commit fixes the issue by enabling `mail` in the translations of available translations in the frontend Task-4423556
This fixes an Accounting issue where companies using February 29 as their fiscal year end could encounter errors when journal entry placeholder names were created in non-leap years. The system now safely uses February 28 in those years, allowing accounting records to be created or updated without interruption.
Original PR description
### Description of the issue/feature this PR addresses: If the customer sets their last fiscal day and month to February 29th, a ValueError may be raised when creating a placeholder name for…
### Description of the issue/feature this PR addresses: If the customer sets their last fiscal day and month to February 29th, a ValueError may be raised when creating a placeholder name for account.move records if their dates are not in a leap year. More precisely, a ValueError is thrown when creating the starting sequence of the placeholder name, as a new date object is created using the company's last fiscal day and month and the year of the account.move. This commit adjusts the day of the created date to February 28th if the last fiscal day and month is set to February 29th and if the account.move year is not a leap year. This date was chosen since that's 365 days after February 29th. ### Current behaviour before PR: If the company's last fiscal day and month is set to February 29th, creating a placeholder name for account.move records whose date is not in a leap year raises a ValueError. Steps to reproduce: 1. Set the last fiscal day to February 29th. 2. Go to Accounting > Journal Entries (account.move). 3. Trigger the computation of the placeholder name for account.move() (edit journal_id, create record, edit date field...) 4. A ValueError exception is raised. ### Desired behaviour after PR is merged: The placeholder name for account.move records is successful and less prone to errors. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix corrects the layout of a stock location table so it expands across the available form width as intended. It improves readability and avoids a cramped display caused by the previous automatic layout handling.
Original PR description
Commit 239e75b1385fa0 removes `colspan="2"` to guess it from the `nolabel` attribute. This is not working because of the `string=` attribute in the `group` tag that makes the DOM having two elements instead of only one. The rule in https://github.com/odoo/odoo/blob/0ba664bace1e6bbb256bd98570866df19d35f401/addons/web/static/src/views/form/form_controller.scss#L474 is not applied. 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
Purchase requests for quotation and purchase orders now show their title properly when the folder document layout is selected. This prevents malformed report headers and keeps printed documents easier to read for users and customers.
Original PR description
Steps to reproduce: ------------------ - Go to settings - Change the Document Layout to folder - Go to purchase - Print a RFQ or a PO Issue: ------ Currently the display of the folder wants the layout_document_title to fit in the upper right corner, which is not always possible especially in the purchase. This leads to the title being malformed. However this fix will also changes other apps display for this layout. Fix: ---- The fix replace the ```html <h2 t-out="layout_document_title"/> ``` where it is in every other layout. This fix the issue and does not break other apps display. opw-4380886 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds extra checks to an automated Studio test so it follows the intended path during module export validation. It helps reduce false test failures and improves confidence in the Studio export process without changing user-facing behavior.
Original PR description
In this commit, we add 2 additionnal check steps to ensure the tour take the good way. runbot-error-id~109456
The settle due flow now searches only among open orders, so already finalized orders are no longer selected by mistake. This helps cashiers avoid confusion and reduces the risk of handling payment follow-ups on orders that are already paid.
Original PR description
Before this commit, when searching after an empty order, sometime a finalized order was returned. This commit fixes the issue by only checking open orders.
When a file upload fails in Documents, users will now see a clear error message instead of being left without feedback. This helps users understand that the upload did not complete and reduces confusion when resolving upload issues.
Original PR description
**Before this PR:** Upload fails(normal) but there is no proper error message. **Technical:** We previously received an error message in the "handleUploadError" function, such as "result.error." However, after the commit https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e, the error now appears directly in the "result". **After this PR:** An appropriate error message will be shown. Task-4357390
Automatic bank reconciliation now records the reason when a validation issue prevents a statement line from being matched. This helps support teams investigate reconciliation problems after the fact without changing the reconciliation flow for users.
Original PR description
During the auto bank reconciliation, user error when validating the matching are ignored which hides why a statement line is not matched by a reconciliation model. This PR adds logs including the user error so it can be retrieved from the logs when doing post mortem analysis. opw-4393854
The update fixes an internal test setup so project profitability checks can run correctly even when demo data is not installed. This helps ensure the manufacturing work order accounting integration remains reliable across more deployment configurations.
Original PR description
This commit's purpose is to make the profitability test works without demo data. The issue is that without some specific groups, the 'workorder_ids' field is not visible inside the views, making the creation of record impossible. Adding these groups in the config of the test fixes the issue version 18.0-master
The grid view now respects configured time steps, such as showing one column for a full month instead of loading daily columns. This prevents incorrect or overly detailed grid displays when businesses customize date ranges.
Original PR description
Before this commit, if the user alters the grid view to have this kind of ranges: ```xml <range name="month" string="Month" span="month" step="month"/> ``` the `step="month"` will not be used to load the data for the grid view and will continue to load data per day (when this range is the current one in the grid view). This commit makes sure the step is correctly used to fetch the data for each columns displayed in the grid view (in this case only one column for the whole month should be displayed).
Miscellaneous changes
In the forward port #190318 while fixing conflict, a new empty file from another projet was accedentally sled in the commit. This commit removes this empty useless file. Forward-Port-Of: odoo/odoo#193907
Original PR description
In the forward port #190318 while fixing conflict, a new empty file from another projet was accedentally sled in the commit. This commit removes this empty useless file. Forward-Port-Of: odoo/odoo#193907
@qrtl ------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#194087
Original PR description
@qrtl ------------------------------- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#194087
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount will still include the amount of the downpayment tax line Steps to reproduce (with SA localization installed and SA company): - Create a SO of 1000$ with 15% tax - Make a downpayment of 100$ with 15% tax and confirm - Make the final invoice with downpayment deducted - Confirm and send e-invo
Original PR description
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount…
When exporting a SA E-invoice file, the system needs to collect invoice line without downpayment lines. However, when collecting tax values, because of an error correction mechanism, the tax amount will still include the amount of the downpayment tax line Steps to reproduce (with SA localization installed and SA company): - Create a SO of 1000$ with 15% tax - Make a downpayment of 100$ with 15% tax and confirm - Make the final invoice with downpayment deducted - Confirm and send e-invoice for validation Issue: The invoice is validated, but a warning is logged ``` Invoice was Accepted by ZATCA (with Warnings) The invoice was accepted by ZATCA, but returned warnings. Please, check the response below: BR-CO-17: VAT category tax amount (BT-117) = VAT category taxable amount (BT-116) x (VAT category rate (BT-119) / 100), rounded to two decimals. BR-S-09: The VAT category tax amount (BT-117) in a VAT breakdown (BG-23) where VAT category code (BT-118) is Standard rated shall equal the VAT category taxable amount (BT-116) multiplied by the VAT category rate (BT-119). ``` As the warning states the is an issue with the tax computation. When collecting amounts from the final invoice, we should filter out downpayment amounts, but due to the error correction mechanism introduced to account for manual modification of the journal items, the filter is ignored, so we will have the filtered base amount (1000) and the unfiltered tax amount (135 instead of 150) A possible solution is to avoid the error correction when we know we need to filter invoice lines opw-4380798 Forward-Port-Of: odoo/odoo#192596 Forward-Port-Of: odoo/odoo#191867
The docstring of `@route` states that it accepts any iterable for the `methods` argument, but several places in the source code wrongly expected a list, and break if it is a tuple. Forward-Port-Of: odoo/odoo#193733 Forward-Port-Of: odoo/odoo#193621
Original PR description
The docstring of `@route` states that it accepts any iterable for the `methods` argument, but several places in the source code wrongly expected a list, and break if it is a tuple. Forward-Port-Of: odoo/odoo#193733 Forward-Port-Of: odoo/odoo#193621
'TestQwebFieldContact' used a demo partner to work, but we want to test independent of demo data. Forward-Port-Of: odoo/odoo#193716
Original PR description
'TestQwebFieldContact' used a demo partner to work, but we want to test independent of demo data. Forward-Port-Of: odoo/odoo#193716
**Issue:** when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice. **Steps To Reproduce:** On POS, for an order totaling $120. - Add a customer and ensure the "Invoice" box is checked. - pay using two payments methods bank 100$ Cash 50$ - the change is $30, everything looks fine on the ticket on the pos. - Notice on the invoice on the db backend the $30 change is inco
Original PR description
**Issue:**
when making a payment using 2 different payment methods (cash and bank), the change gets deducted from the bank payment not the cash payment in the invoice.
**Steps To Reproduce:**
On POS, for an order totaling $120.
- Add a customer and ensure the "Invoice" box is checked.
- pay using two payments methods bank 100$ Cash 50$
- the change is $30, everything looks fine on the ticket on the pos.
- Notice on the invoice on the db backend the $30 change is incorrectly deducted from the bank payment. As a result, the invoice displays: bank : $70 cash: $50
**Soltution:**
- In the `_create_payment_moves` method, ensure that cash payment method creates an `account.move` including the change amount.
opw-4076246
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194284
Forward-Port-Of: odoo/odoo#187727Fix issue that was always displaying popup "The session is being closed by another user. The page will be reloaded." each time you close a session. Now the `login_number` is correctly send in the context and can then be used inside `close_session_from_ui` correctly. task-id: 4485659 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.co
Original PR description
Fix issue that was always displaying popup "The session is being closed by another user. The page will be reloaded." each time you close a session. Now the `login_number` is correctly send in the context and can then be used inside `close_session_from_ui` correctly. task-id: 4485659 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#194082
**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory
Original PR description
**Problem**: When `lot['lot_record'].product_id.valid_ean` is `False`, the `final_barcode` variable retains the value from the previous iteration. This leads to incorrect concatenation with the current `lot['name']` when `lot['lot_record'].product_id.tracking == 'lot'`. **Solution**: Reset the `final_barcode` variable at the start of each iteration. **Steps to Reproduce**: 1. Go to Inventory > Settings and enable "Print GS1 Barcodes for Lots & Serial Numbers". 2. Navigate to Inventory > Products > Lots/Serial Numbers. 3. Select all records and click Print > Lot/Serial Number (ZPL). 4. Observe that some barcodes incorrectly include the previous barcode as a prefix. opw-4437745 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193519 Forward-Port-Of: odoo/odoo#192651
**Steps to reproduce:** - Configure `Analytic Accounting` via `Accounting` module's settings; - Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`: - Select any record and change its name for a really long one;  - Go to `Expenses` app: - Select any expense in the list; - Open the `Analytic Distribution` widget. ___ **
Original PR description
**Steps to reproduce:** - Configure `Analytic Accounting` via `Accounting` module's settings; - Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`: - Select any record…
**Steps to reproduce:**
- Configure `Analytic Accounting` via `Accounting` module's settings;
- Go to `Analytic Plans` through `Accounting / Configuration / Analytic Accounting`:
- Select any record and change its name for a really long one;
- Go to `Expenses` app:
- Select any expense in the list;
- Open the `Analytic Distribution` widget.
___
**Issue:**
Long `Analytic Plans` names are wrapped and may lead to unreadable texts.
*(from the ticket - Odoo 17)*
___
**Expected:**
A smooth UI should display `Analytic Plans` as when accessed through an invoice line from `Accounting` app.
___
**Cause:**
The `Analytic Distribution` widget style of the invoice view inherits from the list renderer, forcing a `nowrap` style while the expense view of the same widget does not.
___
**Fix:**
Force a `nowrap` style for that specific widget.
___
opw-4357324
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#194162
Forward-Port-Of: odoo/odoo#192203Issue: ======= Combo product lines in the POS frontend displayed incorrect prices when order from self Order Cause: ======= The `price_unit` was being calculated without considering the `combo_item_id`. For example: price_unit += pos_order_line.combo_price + price_extra_child` Fix: ===== The `combo_item_id` was included in the calculation to ensure accuracy: price_unit += pos_order_line.`combo_item_id`.combo_price + price_extra_child Task-4464002 Forward-Port-Of: odoo/odoo#1
Original PR description
Issue: ======= Combo product lines in the POS frontend displayed incorrect prices when order from self Order Cause: ======= The `price_unit` was being calculated without considering the `combo_item_id`. For example: price_unit += pos_order_line.combo_price + price_extra_child` Fix: ===== The `combo_item_id` was included in the calculation to ensure accuracy: price_unit += pos_order_line.`combo_item_id`.combo_price + price_extra_child Task-4464002 Forward-Port-Of: odoo/odoo#193356
Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering. This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered. The main cause of re-render comes from `setInset()` that is invoked whenever th
Original PR description
Before this commit, during a discuss call while sharing screen and enabling camera, the inset card (= small video stream preview in bottom right of call view of the participant, either camera or screen-sharing depending on other stream being main active) was flickering. This happens because each rendering of the call view re-renders the inset, which leads to the perceived flickers from stream being re-rendered. The main cause of re-render comes from `setInset()` that is invoked whenever the `visibleMainCards` getter is called with inset, which is triggered on renderings like mouse-hovering on call view to display the call actions. Even when the inset card is unchanged, `setInset()` produces another object, which forces OWL to re-render the inset component. This commit fixes the issue by having `setInset` reusing the inset data object if the inset to render refers to the same inset session. Task-4484908 Forward-Port-Of: odoo/odoo#194103
…ique FITID To replicate the issue: 1. Install the brazilian localization (enterprise) 2. In the accounting app dashboard, click Import Statement 3. Upload an .OFX file with duplicate FIDID 4. A validation error appears and the upload is not done Cause: The bank statement import assumes the FIDID is a unique identifier for the transactions in the .OFX file. A sql constraint is set in place to ensure this uniqueness. However, some Brazilian banks may generate files with transactions wi
Original PR description
…ique FITID To replicate the issue: 1. Install the brazilian localization (enterprise) 2. In the accounting app dashboard, click Import Statement 3. Upload an .OFX file with duplicate FIDID 4. A…
…ique FITID To replicate the issue: 1. Install the brazilian localization (enterprise) 2. In the accounting app dashboard, click Import Statement 3. Upload an .OFX file with duplicate FIDID 4. A validation error appears and the upload is not done Cause: The bank statement import assumes the FIDID is a unique identifier for the transactions in the .OFX file. A sql constraint is set in place to ensure this uniqueness. However, some Brazilian banks may generate files with transactions with the same FITID. An example is when PIX transfers have the same FITID as the fee charged for the PIX, which appears as another bank statement line with the same FITID. Fix: The function _parse_bank_statement_file is altered to call a function that fills the vals_line dictionary with the transaction's values. This function is then overwritten in l10n_br_reports to not include the FITID (unique_import_id) for journals of Brazilian companies. opw-4317681 Forward-Port-Of: odoo/enterprise#76556
When we click on the waning the action does not show the correct list. - replace the `self.env['fleet.vehicle']` with `self.env['hr.employee']` as `employees_multiple_vehicles` is a list with employee_ids not vehicle_ids Task: 4458500 Forward-Port-Of: odoo/enterprise#77115 Forward-Port-Of: odoo/enterprise#76679
Original PR description
When we click on the waning the action does not show the correct list. - replace the `self.env['fleet.vehicle']` with `self.env['hr.employee']` as `employees_multiple_vehicles` is a list with employee_ids not vehicle_ids Task: 4458500 Forward-Port-Of: odoo/enterprise#77115 Forward-Port-Of: odoo/enterprise#76679
In this PR: - Refactored error handling for better clarity and organization. - Grouped errors by section and invoice for structured reporting. - Added clickable invoice links in error messages for easy navigation. - Scheduled detailed activities for invoices with errors. - Enhanced code readability and maintainability. This ensures clearer error reports, efficient activity creation, and easier future updates. Forward-Port-Of: odoo/enterprise#76880
Original PR description
In this PR: - Refactored error handling for better clarity and organization. - Grouped errors by section and invoice for structured reporting. - Added clickable invoice links in error messages for easy navigation. - Scheduled detailed activities for invoices with errors. - Enhanced code readability and maintainability. This ensures clearer error reports, efficient activity creation, and easier future updates. Forward-Port-Of: odoo/enterprise#76880