Daily updates from Odoo
Friday, November 8, 2024
31 changes
2 changes
Resolved issues and error corrections
This fixes website search so businesses can again use tailored result templates for different search types. It restores expected customization behavior, helping websites present search results in the intended format without workarounds.
Original PR description
With commit [1], `qweb.has_template` was replaced with its owl equivalent. Later, commit [2] further refactored this and consequently broke the possibility to use custom templates based on search type for website search. [1]: https://github.com/odoo/odoo/commit/123ba4ffccd6fc3895a18f3503690ba1593e3023 [2]: https://github.com/odoo/odoo/commit/21ecc7400f2211773713781c619f066a5fb37963
The spreadsheet component was updated to a newer version with fixes for handling broken cell references. This improves reliability when opening, parsing, and exporting spreadsheets, especially to Excel files.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/40d42f880 [REL] 17.2.25 Task: 0 https://github.com/odoo/o-spreadsheet/commit/00841949f [FIX] xlsx: convert #REF at export to xlsx Task: 4207052 https://github.com/odoo/o-spreadsheet/commit/f20d87a9a [FIX] parser: inconsistent handling of #REF Task: 4207052 https://github.com/odoo/o-spreadsheet/commit/a36121f66 [FIX] test: skipped test in `renderer_plugin.test.ts` Task: 4276968 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
1 change
Resolved issues and error corrections
The spreadsheet document tests were adjusted to match a recent change in how chart trend lines are calculated. This prevents unreliable test failures for an unrealistic chart setup and helps keep spreadsheet chart functionality stable.
Original PR description
Since o-spreadsheet/commit/9909fa98d data points are normalized to compute the trend line. Those 2 tests were computing a 2nd order polynomial trend line based on 2 data points only, which doesn't really makes sense. With only 2 points, the normalized labels become [0, 1]. The matrix is of the form x1 x2 x1^2 x2^2 it gives 0 1 0 1 with [0, 1] as the labels. This matrix is not invertible since the two lines are the same and the determinant is 0.
15 changes
Resolved issues and error corrections
This fix corrects misleading location labels and help text shown when configuring stock and repair operation types. It makes the wording more consistent and avoids confusion for users working with repairs, inventory transfers, or manufacturing flows.
Original PR description
Followup to task: 4028900 Fixes the following issues: - The label of "Default Component Destination Location" was applied to all operation types, not just `repair_operation`. This resulted in…
Followup to task: 4028900 Fixes the following issues: - The label of "Default Component Destination Location" was applied to all operation types, not just `repair_operation`. This resulted in confusing labeling for all the other operation types when Repair was installed - The "help" of `default_location_src_id` and `default_location_dest_id` referred to stock pickings, but these fields are also used for MRP and Repair. So the help has been updated to be more generic to avoid confusion - Task: 4034713 removed the "Default" from the label of the default location fields for picking types, therefore we remove them from the repair ones for consistency - cleaned up the inheritance of the picking type form view in repair so that the `default_location_src_id` field isn't in the same view twice (or have inconsistent attributes) - reordered the Repair default locations to follow a more logic ordering --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update brings the spreadsheet component to a newer version with fixes for pivot tables, formulas, chart display, and Excel export. Users should see more reliable spreadsheet calculations and clearer chart behavior, especially around errors, empty references, pie charts, and translated chart labels.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/5fa5fbb4a [REL] 18.0.3 Task: 0 https://github.com/odoo/o-spreadsheet/commit/09860796e [FIX] pivot: skip cells on…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/5fa5fbb4a [REL] 18.0.3 Task: 0 https://github.com/odoo/o-spreadsheet/commit/09860796e [FIX] pivot: skip cells on manipulated pivot array formulas Task: 4292134 https://github.com/odoo/o-spreadsheet/commit/03d7080d3 [FIX] functions: FILTER with strings and errors Task: 4307604 https://github.com/odoo/o-spreadsheet/commit/eb4c13091 [FIX] charts: do not show zero values in pie charts Task: 4277144 https://github.com/odoo/o-spreadsheet/commit/3eac11e86 [FIX] index: export chart translation terms Task: 3978443 https://github.com/odoo/o-spreadsheet/commit/262b1bc2a [FIX] tests: remove WAIT funtion Task: 4306250 https://github.com/odoo/o-spreadsheet/commit/70f58fa2d [FIX] tests: bad separator in xlsx export Task: 4306250 https://github.com/odoo/o-spreadsheet/commit/ec41486b9 [FIX] tests: remove async function export test Task: 4306250 https://github.com/odoo/o-spreadsheet/commit/c78551c57 [FIX] xlsx: convert #REF at export to xlsx Task: 4207052 https://github.com/odoo/o-spreadsheet/commit/bebac5f29 [FIX] parser: inconsistent handling of #REF Task: 4207052 https://github.com/odoo/o-spreadsheet/commit/c53e76933 [FIX] charts: correct stacked checkbox label Task: 4251670 https://github.com/odoo/o-spreadsheet/commit/5ebba297c [REM] charts: clean createLineOrScatterChartRuntime Task: 0 https://github.com/odoo/o-spreadsheet/commit/d3a2181b7 [FIX] charts: fix trend line for datetime Task: 0 https://github.com/odoo/o-spreadsheet/commit/69a8602cd [FIX] chart: missing checkbox label for combo chart Task: 4283173 Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fixes an error that could stop invoice PDFs from being generated in the Argentina and Chile localization modules. Users can now print affected invoices without the system failing due to an internal naming mismatch.
Original PR description
The function `_exclude_tax_group_from_tax_totals_summary` does not exist. It should be `_exclude_tax_groups_from_tax_totals_summary` instead. This is the same issue for the l10n_cl and l10n_ar module…
The function `_exclude_tax_group_from_tax_totals_summary` does not exist. It should be `_exclude_tax_groups_from_tax_totals_summary` instead.
This is the same issue for the l10n_cl and l10n_ar module since it's just a call to a non-existent function.
### Steps to reproduce:
- Install the l10n_ar module
- Create an invoice with the document type set to "Invoice C"
- Add a line that includes a tax
- Try to print using the "PDF without payment" button
### Traceback:
```
File "/Users/louis/Development/odoo_src/core/odoo/odoo/addons/base/models/ir_qweb.py", line 600, in _render
result = ''.join(rendering)
^^^^^^^^^^^^^^^^^^
File "<778>", line 107, in template_778
File "<778>", line 89, in template_778_content
File "<778>", line 77, in template_778_t_call_0
File "<1056>", line 2228, in template_1056
odoo.addons.base.models.ir_qweb.QWebException: Error while rendering the template AttributeError: 'account.tax' object has no attribute '_exclude_tax_group_from_tax_totals_summary' Template: l10n_ar.report_invoice_document
Path: /t/t/div[2]/div/div[4]/div[1]/div[1]/div/table/t[1]/t[2]
Node: <t t-set="currency" t-value="o.currency_id"/>
```
opw-4253265The loyalty card point update wizard now automatically shows the card's existing point balance. This helps users adjust loyalty points with the correct starting value and reduces the chance of manual errors.
Original PR description
Issue: -The old balance field in loyalty card point update wizard is not set by default Fix: -Added `card_id` in form view
This update improves automated checks for website shop features so they run faster and fail less often. It fixes several test flow issues around product search, autocomplete, gift cards, loyalty, and delivery, helping maintain stability without changing customer-facing behavior.
Original PR description
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 update fixes a typo in the Expenses app. It is a minor cleanup that improves text clarity without changing business workflows or functionality.
Original PR description
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 change fixes the setup of an automated Mail discussion walkthrough so it starts after other functional tours and opens at the correct place. This helps ensure the tour reliably shows the expected in-app guidance during testing and validation.
Original PR description
In this commit, we fix the sequence and the url of discuss_channel_tour tour with the aim to start in last position after all the functional and with the aim to see the baball on the app. task~4309858 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 update fixes an automated test so it works correctly when only the Community edition is installed. It helps keep quality checks reliable and avoids false failures during validation, with no expected impact on users.
Original PR description
Fixes a test to work without enterprise installed. Runbot Error 105489
This fixes how import batch size limits are passed to the file handling component. It ensures the configured size is understood correctly, helping imports respect the intended limits and avoid incorrect batching behavior.
Original PR description
This commit fixes the parameters send to the BinaryFileManager. There was a typo `maxBatchSize` and not `maxSizePerBatch` also has the unit on the web interface is in mega we should multiply the unit by 1024 ^ 2 to have the correct value. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an automated Studio walkthrough so it properly handles the export confirmation window. The change helps keep quality checks reliable without changing how business users work in Studio.
Original PR description
At the end of the tour, when we want to export all modifications, it opens a modal from v18.0. But, as it is not allowed to do action on element that's below a modal, the tour fails. In this commit, we click on export button to test the export feature and then close the modal before continuing the tour.
This update improves how ISO 20022 payment files are generated, especially for SEPA and Swiss payments. It prevents incorrect SEPA labels on non-SEPA payments, removes unnecessary transfer wording, and restores important batch payment validation so payment issues are caught earlier.
Original PR description
[FIX] account_iso20022: Don't report 'SEPA' as Service Level in ISO20022 files 'SEPA' used to be the default for SvcLvl files, which meant even non-SEPA files would have it set to 'SEPA', unless they…
[FIX] account_iso20022: Don't report 'SEPA' as Service Level in ISO20022 files 'SEPA' used to be the default for SvcLvl files, which meant even non-SEPA files would have it set to 'SEPA', unless they explicitly overrode the function defining the value of the node. This commit fixes this, by not setting any value to SvcLvl by default, and overriding for SEPA payments. ========================================================= [REF] account_iso20022: compute BIC tag depending on the payment method consistently The CdtrAgt node did not compute the tag of its BIC node in the same way as the DbtrAgt node, calling the dedicated helper. Because of that, it required a bit more payment method-specific code in SEPA, so that BIC becomes BICFI in the latest version. This commit removes that and calls the appropriate helper everywhere. ========================================================== [IMP] account_iso20022: Don't put 'SCT' in InstrId anymore Before this commit, each payment's InstrId always contained 'SCT' (unless a memo was set on the payment), standing for "SEPA Credit Transfer". For non-SEPA ISO20022, this did not make sense. Since this having this additional info in the field has not additional informative value anyway, we simply remove it. ========================================================== [FIX] account_iso20022: fix batch payments' error check 'posted' state does not exist on payments anymore. Anyway, this check was useless. Though, it prevented any of the error checks to run. Also, a condition had been mistakenly removed in the handling of payments with a too big amount. [IMP] account_iso20022: proper check on maximum amounts SEPA Credit Transfer documentation gives a maximum of 999,999,999.99 € to instructed amounts (https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2023-11/EPC132-08%20SCT%20C2PSP%20IG%202023%20V1.1.pdf page 101). Swiss ISO 20022 uses 9,999,999,999.99 instead (https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf, page 52). The check we ran before this commit was wrong. It checked 11 characters (coma included), while it's actually not included, for payments in EUR, and added another limit of 15 characters for other amounts. We relax it to put the proper restrictions when we know them, and not enforce another when we don't.
This fix updates spreadsheet chart tests so they match the latest trend line calculation behavior. It helps keep automated checks reliable after a calculation change, with no expected impact on everyday users.
Original PR description
Since o-spreadsheet/commit/9909fa98d data points are normalized to compute the trend line. Those 2 tests were computing a 2nd order polynomial trend line based on 2 data points only, which doesn't really makes sense. With only 2 points, the normalized labels become [0, 1]. The matrix is of the form x1 x2 x1^2 x2^2 it gives 0 1 0 1 with [0, 1] as the labels. This matrix is not invertible since the two lines are the same and the determinant is 0.
This update fixes several issues affecting payroll, rental sales, customer portal access, live chat messages, accounting reports, and inter-company stock validation. It improves reliability and user experience by preventing unnecessary payslip recalculations, removing access errors for portal users, restoring correct report layout, and ensuring business workflows continue without blocking errors.
The map view now removes an unnecessary gap between each group title and its list of records. This makes grouped map results easier to scan and gives the interface a cleaner, more polished appearance.
Original PR description
Before this commit: There is an excessive gap between the group title and the list of records. After this commit: The excessive space between the group title and the list of records has been removed. Task-4295965
The Sign app now avoids an error that could occur after choosing an option from the Tools dropdown and then scrolling. This keeps document preparation smoother and prevents users from being interrupted by a crash.
Original PR description
Before this fix, clicking any item in the dropdown under "Tools" caused a traceback when scrolling vertically or horizontally. This commit ensures that we check if the canvas is rendered before proceeding with the code, preventing the error. task-4212762
13 changes
Resolved issues and error corrections
This update resolves an issue where users could accidentally book appointments for dates in the past or different months due to how the system displayed available slots. Now, the system correctly shows only previously selected dates within the current month, ensuring accurate appointment booking and a consistent user experience. This prevents confusion and improves the reliability of the appointment scheduling process.
Original PR description
TO REPRODUCE =========== 1. Create an appointment with users A and B 2. ...using 'no picture' and 'user then time' 3. go to front end 4. pick a date D both users have slots in 5. go to next month 6.…
TO REPRODUCE =========== 1. Create an appointment with users A and B 2. ...using 'no picture' and 'user then time' 3. go to front end 4. pick a date D both users have slots in 5. go to next month 6. change user in the dropdown (or change TZ) 7. slots appear for day D in previous month ISSUE ===== When selecting an other resource or user in the dropdown in resource_time mode, even if the selected one has no available slot for the current month, slots will appear in the slot list, corresponding to the first availability overall. This leads to a very strange mismatch between the calendar dates and the slots. The user may select a slot and book for a month they do not currently see on the calendar. SOLUTION ======== Now, we will select the previously selected date if it is in the current month and has slots. Otherwise we select the first day with slots in the currently displayed month (NOT overall). This way, the day is selected and displayed as so in the calendar. The slots match that day. If no availability exist for the current month, we do not click on any day, and show no slots. Task-4169513
This update resolves an issue where electronic debit notes for Chilean customers were being rejected due to a missing 'SII Reference Code'. The code has been updated to make this field mandatory, ensuring compliance with Chilean tax regulations and preventing invoice processing errors. This improves the reliability of electronic invoicing for Chilean businesses.
Original PR description
**Steps to reproduce:** (production credentials required) - Install l10n_cl_edi - Switch to a Chilean company (e.g. CL Company) - Create an invoice for a Chilean customer - Confirm the invoice and process the electronic invoice - Create a credit note and process the electronic credit note - Create a debit note from the credit note (Do not set "SII Reference Code") - Process the electronic debit note **Issue:** The debit note will be rejected because "SII Reference Code" is not set. **Solution:** Set "SII Reference Code" field as required. opw-4182451 Forward-Port-Of: odoo/enterprise#72679
This update resolves an issue where users were receiving an error when modifying the unit amount field on non-timesheet analytic account lines with large numbers (over 6 digits). The change now correctly validates the unit amount field only for timesheet lines, preventing this error and improving data entry reliability.
Original PR description
Before this commit, when the user alters the unit_amount field of an analytic account line which is not a timesheet and the amount has more than 6 digits then the user will get a user error saying he cannot encode a number with more than 6 digits for the unit amount field. This commit makes sure the check made on the unit amount is only made when the analytic line altered is a timesheet. closes odoo/odoo#174964
This update ensures that the 'Extra Quotations' setting in the project management interface takes up the full screen width, regardless of the screen size. Previously, this setting was limited in its display space, which has now been corrected for a more consistent and user-friendly experience.
Original PR description
Before this commit, the `Extra Quotations` setting displayed in the form view of `project.project` model does not take the maximal width available on larger screen. This commit makes sure the width of that setting takes all available space as the other settings. task-4294845
This update fixes an issue where changing the quantity of a shopfloor component registration incorrectly updated the MO's raw move quantity. The change ensures that the MO's reservation state remains accurate after adjustments to the component quantity, preventing unexpected state changes and ensuring proper production tracking.
Original PR description
### Steps to reproduce: - Create 2 storable products: Final product (FP) and Component (COMP) - Put 10 units of COMP in stock - Create a Bill of Material for FP: - raw move: 10 x COMP - 1 operation:…
### Steps to reproduce:
- Create 2 storable products: Final product (FP) and Component (COMP)
- Put 10 units of COMP in stock
- Create a Bill of Material for FP:
- raw move: 10 x COMP
- 1 operation: "Register COMP"
- Add an instruction on your operation:
- type: "Register consumed component"
- Product To Register: COMP
- Create and confirm an MO for 1 Unit of FP
- Go to the shopfloor > "Register COMP"
- Change the quantity to 3 > Validate
#### > Go back to the MO the quantity of the raw move is still 10
### Cause of the issue:
Clicking on "Validate" as well as on "Continue consumption" will trigger a call of the `_next` method with `continue_production=False` and `True` respectively:
https://github.com/odoo/enterprise/blob/e86b97f57e2388b3b65326cecedd3c14ca02ddb1/mrp_workorder/models/quality.py#L346-L352 However, if you underconsume, a new move ine will be created for the remaining quantity in both cases and it should only when you `Continue consumption`.
### Note:
If you underconsume, and change the quantity of the raw move without changing its original demand. As such, its state will itself change. Hence, if you come back to the MO, the reservation sate of the MO will be recomputed and be updated from assigned to confirmed. However, as the raw move is picked it should not alter the reservation state of the MO anymore:
https://github.com/odoo/odoo/blob/9918e8f3d627f3c52238d6b04bcd15c05d34e40c/addons/mrp/models/mrp_production.py#L613 This is the purpose of the community PR.
opw-4216910This update resolves an issue preventing users from applying sign actions to documents. The fix ensures that users with appropriate access to both the document and the sign process can successfully initiate the signing workflow. Additionally, new testing has been added to prevent duplicate attachment creation.
Original PR description
[FIX] documents{_sign}: fix access error applying sign action How to reproduce: - Install documents_sign and log as admin - In documents, create an action (Workspace: Finance, Create: PDF to Sign) -…
[FIX] documents{_sign}: fix access error applying sign action
How to reproduce:
- Install documents_sign and log as admin
- In documents, create an action (Workspace: Finance, Create: PDF to Sign)
- Then upload a pdf in the workspace Finance
- Log as Marc Demo
- In documents, select the PDF uploaded as admin
- Click on the action created
You get the error: "Sorry, you are not allowed to access this document." while the expected behavior is that users who have access to the document and to Sign should be able to use the action. We solve that in this commit.
We also add a test checking that applying an action to sign a pdf document not owned by the user that perform the action, doesn't duplicate the attachment if the attachment is owned by the document (res_id and res_model pointing to the document; the ownership is transferred to the sign.template created) and duplicate it otherwise.
Technical note: the error was caused by the trick used in the override of sign_template.create in documents_sign which was setting the res_model to False and res_id to 0 for attachment linked to document to allow the super method to link that attachment to the created sign_template (by releasing the ownership of the attachment from the document). But as ir_attachment prevents to link an attachment with res_id = 0 to a record if it is not done by the owner of that
attachment, there was an error. We remove that tricks by defining a method that determine if sign_template can take the ownership of the attachment or not which we override in document_sign and make it return True when the attachment is owned by a document.
Task-4000988
Forward-Port-Of: odoo/enterprise#65206This update fixes an issue where subscription billing wasn't correctly generating subsequent delivery periods. The change ensures that delivery periods are accurately linked to their scheduled dates, resolving a problem caused by using the validation date instead of the scheduled date for stock movements. This prevents missed invoices and deliveries for subscription customers.
Original PR description
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted…
StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.
To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
* Recurring plan: Monthly
* Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.
---
Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
self.assertTrue(bool(second_picking))
AssertionError: False is not true
```
OPW-4280155This update resolves an issue where completion certificate reports displayed dates based on the user's local timezone, leading to potential inconsistencies. The fix ensures all dates are recorded in UTC, guaranteeing accurate and reliable reporting regardless of user location. This improves data integrity and simplifies certificate generation.
Original PR description
**Version:** - 17.0 **Steps to reproduce:** 1. In the Sign app, send a request for a signature. 2. Complete the signature and submit the request. 3. Observe the completion certificate that is generated. **Issue:** The log_date in the completion certificate report is displayed based on the user's timezone, causing inconsistencies. **Solution:** replaced `t-field` with `t-out` to retain the log_date in UTC, ensuring consistency regardless of the user's time zone. task-4014378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug in the account reports module where zero values were incorrectly interpreted as True, leading to inaccurate data when performing group-by operations. The fix ensures that zero values are handled correctly, preventing unexpected behavior and improving the reliability of report data. This resolves a potential issue with data discrepancies.
Original PR description
When the value to store into a generic id was zero (which can typically happen when doing a non-relational groupby), None was stored into the generic id instead. On groupby lines, this lead the unfold of that line to behave weirdly and not show the proper results. The reason was that, in Python, doing 0 == False gives True. So, when doing 0 in (False, None), we ended up with a True result. Forward-Port-Of: odoo/enterprise#72808
This update fixes an issue where the font in the sign request process was changed to Times New Roman after an app upgrade, and where sign elements were rendering slowly. The changes restore the original font and reduce the rendering time, resulting in a smoother and more professional user experience for sign requests.
Original PR description
After the sign's app OWL upgrade, the guidance dialog's ('Click to start', 'Fill in', etc...) font got unformatted from Helvetica to Times New Roman. Additionally, the sign elements were tooking too long to render, making the user experience also slow.
This commits restores the original font for the guidance dialogs and also decrease the rendering refresh from 2s to 500ms for providing a smoother user experience.
task-4147887This update corrects a bug where commission calculations were failing for subscription invoices due to missing subscription dates. The fix adjusts the commission description to accurately reflect the subscription amount when subscription dates aren't present, preventing purchase order creation errors. This ensures accurate commission tracking for subscription sales.
Original PR description
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when…
Version: 16.0+ Issue: When we make commission on a subscription sale order, the subscription end and start dates are not passed through the order lines -> invoice lines and we run into an error when trying to create the corresponding purchase order. Purpose of this PR: If there are no subscription dates on the invoice lines then we do not calculate the length of the subscription in months and instead create the purchase order line description just as the commission for the corresponding subscription. Steps to reproduce on runbot: install partner_commission set up a subscription with a referrer and a commission plan create invoice for the subscription try to register the payment for the invoice error raised regarding a max function with no args Notes: looking to investigate further why the subscription dates are not passed from the subscription to the order lines to the invoice lines in 17.0+ field name is changed from `subscription_end_date` to `deferred_end_date` (same for `start` date), will have to adjust in fw ports opw-4240937 Forward-Port-Of: odoo/enterprise#73428
This update corrects a bug in the bank statement import process. The issue occurred when the CSV file didn't include the required 'debit' and 'credit' columns, leading to an error. This fix ensures the import function now handles CSV files with the correct format, preventing import failures.
Original PR description
This issue is coming from importing a CSV File in the 'account.bank.statement.line' model was caught by a sentry. Because if the CSV file does not have two columns, which are 'debit' and 'credit', that time getting error is 'amount' is not in the list. step to reproduce- - Install the Accounting. - Go to Dashboard > click on import statement button of Bank card - Upload the statement ([bank statement](https://drive.google.com/file/d/1s_a3Ym27QKRDh63BwPb-3P4g4kjmbH2l/view?usp=drive_link)) - After, click on Test button - Error will be generated.  Sentry: -3931578971 Forward-Port-Of: odoo/enterprise#37315
This pull request reverts a previous change that was causing issues with the mail-chatter dropzone feature in the documents module. The change was rolled back to restore the previous, stable behavior. This ensures consistent functionality for users.
Original PR description
This reverts commit fd46e62809544702193e636ec388103eea11f788. Task-4314619