Daily updates from Odoo
Friday, November 22, 2024
78 changes · 18.0
Enhancements to existing features
Cashiers can now search for products in Point of Sale using their barcode, instead of only relying on product names or other details. This makes checkout faster and reduces confusion when barcode-based searches previously returned no results.
Original PR description
Before this commit, searching with the barcode of a product would not show any results. opw-4330143 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Default values for company-specific fields will now be chosen consistently, instead of varying based on the individual user who triggered them. This reduces unexpected behavior across companies and can improve performance by reusing cached defaults more effectively.
Original PR description
when an ir.default record with user_id is created, the result will be used as the fallback value for undefined company-dependent column value. It will cause user-dependent fallback which is logically wrong. This commit forces the fallback value to be fetched with SUPERUSER to make fallback always not user-dependent and increase the cache hit rate for _get_model_defaults 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
Restaurant point-of-sale orders now remain linked to their original table when tables are merged and later separated. This prevents lost or misplaced orders, making table management more reliable for restaurant staff.
Original PR description
Before this commit: =================== When merging tables, the order from the original table was transferred to the destination table, and the original table's order was deleted. As a result, when tables were unmerged, the original table's order could not be restored. After this commit: ================== When tables are merged and later unmerged, the original table's orders are successfully restored. This ensures that each table retains its initial order even after being merged and unmerged. Task- 4224207
The chart configuration panel now uses clearer wording for stacked line and bar chart options, changing labels such as “stacked linechart” to “stacked line chart.” The line chart panel spacing was also tightened so related options appear more consistently, making chart setup easier to understand.
Original PR description
Change the checkbox label of stacked charts from `stacked linechart` to `stacked line chart` in the chart configuration panel. Same for bar charts. Also removed padding between `stacked` and `cumulative` checkboxes in the line chart panel. Task: [4290275](https://www.odoo.com/web#id=4290275&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)
Kitchen preparation cards now show all table numbers involved when restaurant tables are merged, instead of only the destination table. This helps kitchen staff identify orders more clearly and reduces confusion during service.
Original PR description
Before this commit: ================ When tables were merged in the restaurant, the kitchen display only showed the destination table number on the preparation card. After this commit: ================== Now, if tables are merged (e.g., Table 1 & Table 2), the kitchen display will show both table numbers (e.g., 1&2) on the preparation card. This provides better clarity for the kitchen staff by reflecting the merged table arrangement Task- 4224207 Related Community PR: https://github.com/odoo/odoo/pull/183070
Financial report actions that require the main company and all branches are now clickable and show a clear message when the right company selection is missing. This helps users understand what to do instead of assuming a disabled button is a system issue, reducing confusion and support requests.
Original PR description
When you have a company with branches in a database, some reports only make sense when you have the main company with all its branches selected. Currently some report actions (buttons) were disabled if you didn't have your main company and its branches selected, without any information on why the buttons were disabled. This resulted in people creating tickets because they thought something was wrong. This change makes the buttons clickable again, but instead displays a message saying that the user should select the main company and its branches in order to save a sensible report. [task-4260501](https://www.odoo.com/odoo/all-tasks/4260501)
Resolved issues and error corrections
This update refines the look and spacing of Odoo Discuss messages, replies, reactions, mentions, and messaging menu items in both light and dark themes. The changes make conversations easier to scan and improve visual consistency without changing functionality.
Original PR description
- message bubble more distinct from background with darkened border - messaging menu item have less horizontal spacing in desktop - messaging menu item preview has bigger emojis like messages -…
- message bubble more distinct from background with darkened border - messaging menu item have less horizontal spacing in desktop - messaging menu item preview has bigger emojis like messages - messaging menu dark theme spacing matches white theme (was missing border color) - message reactions have slightly smaller emoji size - discuss sidebar quick search is more aligned with other items - message in reply background matches original message color and has is more distinct from replied message - mention in dark theme is shinier, somewhat same contrast with regular text content than in white theme Before / After (white) <img width="2555" alt="0-before-white" src="https://github.com/user-attachments/assets/a99a0873-ae93-4c8d-a3f3-a1c30f232c29"> <img width="1280" alt="0-after-white" src="https://github.com/user-attachments/assets/c826f29c-ed2c-47fe-bac3-77c967aeb39b"> Before / After (dark) <img width="2558" alt="0-before-dark" src="https://github.com/user-attachments/assets/f523a131-8765-4d57-b167-d8f370ca33b5"> <img width="2556" alt="0-after-dark" src="https://github.com/user-attachments/assets/06cb3cf5-ed2e-4527-bd57-27b54fe89bea">
Updates the spreadsheet component to the latest version with fixes for formula evaluation, copy/paste behavior, browser clipboard support, and collaboration in read-only mode. Users should see fewer crashes, clearer lookup errors, smoother spreadsheet editing, and small visual improvements to charts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9eb34d905 [REL] 18.0.5 Task: 0 https://github.com/odoo/o-spreadsheet/commit/434c06097 [FIX] composer: overflow on…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/9eb34d905 [REL] 18.0.5 Task: 0 https://github.com/odoo/o-spreadsheet/commit/434c06097 [FIX] composer: overflow on composer at end of screen Task: 4315958 https://github.com/odoo/o-spreadsheet/commit/e48b96bd2 [PERF] evaluation: early return errors Task: 4328215 https://github.com/odoo/o-spreadsheet/commit/70fe23b61 [FIX] conditional format: huge revisions on copy/paste cf Task: 4240668 https://github.com/odoo/o-spreadsheet/commit/ace25cfae [FIX] collaborative: don't snapshot in read-only mode Task: 4344187 https://github.com/odoo/o-spreadsheet/commit/23037c368 [FIX] clipboard: Fix clipboard cross-browser coverage Task: 4241877 https://github.com/odoo/o-spreadsheet/commit/65b519005 [FIX] functions: Fix error message of some Lookup functions Task: 4320993 https://github.com/odoo/o-spreadsheet/commit/b90326b0f [FIX] functions: XLOOKUP linear search crashes without lookup values Task: 4320993 https://github.com/odoo/o-spreadsheet/commit/d2e1e7ff9 [FIX] config: Update task url Task: 0 https://github.com/odoo/o-spreadsheet/commit/270308d61 [FIX] PivotDimension: Prevent DnD on dimension action buttons Task: 4095643 https://github.com/odoo/o-spreadsheet/commit/64a4cbc76 [FIX] Datavalidation: coreView plugin should not dispatch Task: 4241141 https://github.com/odoo/o-spreadsheet/commit/dab74e230 [FIX] evaluation: log when reaching maximum iterations Task: 4252800 https://github.com/odoo/o-spreadsheet/commit/07c48aa0d [FIX] evaluation: Ensure dependency invalidation for array formulas Task: 4252800 https://github.com/odoo/o-spreadsheet/commit/079a126ee [IMP] chart: improve bar chart borders Task: 4283212 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>
Sale order lines for products that initially calculate to a zero price now keep any manually entered price when the quantity or unit of measure changes. This prevents unintended price resets and helps sales teams preserve agreed custom pricing.
Original PR description
Recent commit c584a61697e4f4d196b4a485411135a96b0f6006 introduced a mechanism to avoid recomputing prices manually defined on sale order lines. Nevertheless, it didn't consider zero-priced products. If a product whose price was 0 (after pricelist computation) was set on the line, even if the price was manually changed to another amount, it was still recomputed when quantities or uom where changed. opw-4329474
The mail composer now keeps separate lines in chatter messages independent when applying formatting. This prevents a heading or similar style applied to one selected line from unintentionally changing the entire message.
Original PR description
Steps to reproduce the issue: ============================= - Go to chatter - Write content on 2 lines - Open composer - Select first line and change the heading - Both lines are changed Origin of the issue: ==================== The content of the textarea sent to the server is `abc<br>efg`. In 17.4: We don't sanitize the content so it stays the same and we put that content into the editor. The editor will create the `p` elements to wrap the inline elements at root. In 18.0: We sanitize the content and it will pass by `lxml.html.fromstring` and it will wrap the content in a `p` element. Now we put `<p> abc<br> efg</p>` in the editor which is valid but it's considered all as the same block. Applying block-level commands like list and heading will change the whole content. Solution: ========= Wrap the textarea content inside a div when we open the mail composer. opw-4350430 opw-4346348
This fixes how Odoo checks push notification permissions on iOS, especially for users running Odoo as a progressive web app. It prevents repeated or misleading permission prompts and helps users receive notifications only when their device can actually support them.
Original PR description
Follow-up of [1] and [2] iOS push notifications do not work on Safari: they only work in apps. The notifications are managed by the apps, whether with native mobile app or PWA. With PWA, it should…
Follow-up of [1] and [2] iOS push notifications do not work on Safari: they only work in apps. The notifications are managed by the apps, whether with native mobile app or PWA. With PWA, it should normally rely on `Notification.permission`, but somehow it doesn't work and always has value "default". Its showing has been limited to the PWA, but it keeps showing a persistent notification. Clicking on it the 1st time displays a prompt to either accept or deny the permissions. Afterwards, further clicks on the "odoobot has a request" automatically display "granted" or "denied" based on user initial choice. iOS push permissions seem to necessarily rely on `serviceWorker.getRegistration().pushManager`, which works only on HTTPS, hence why iOS push notifications do not work on HTTP. Also actual push permission state are correct there whereas on Notification.permission they are wrong. This commit fixes the issue by computing the push notification permisssion state correctly on iOS, using `serviceWorker.getRegistration().pushManager`. [1]: https://github.com/odoo/odoo/pull/178057 [2]: https://github.com/odoo/odoo/pull/187038
This fixes errors that prevented portal customers from paying overdue invoices, especially when paying multiple invoices together. It also ensures the correct payment amount is used so payments are not accidentally created for zero value.
Original PR description
Currently, multiple tracebacks are occurring when the portal user tries to pay the overdue amount. **To reproduce this issue:** 1) In accounting create multiple invoices with the customer as a portal…
Currently, multiple tracebacks are occurring when the portal user tries to pay the overdue amount. **To reproduce this issue:** 1) In accounting create multiple invoices with the customer as a portal user 2) Make sure to give the due date as past date while creating the invoices 3) Now login with portal user and try to pay the due amount in the batch **Error:-** ``` PaymentPortal.overdue_invoices_transaction() missing 1 required positional argument: 'payment_reference' ``` This error occurs because we didn't provide the `payment_reference` in `_prepareTransactionRouteParams`. when executing the `overdue_invoices_transaction()` transaction route. We can resolve this issue by providing the required arguments in the ` _prepareTransactionRouteParams() ` by overriding it in the account payment **Note:-** After resolving the above bug, we are encountering two more bugs. **Bug 1:-** When making a batch payment, we are getting an ensure_one() error if the due amount spans multiple invoices. This occurs from the following line: https://github.com/odoo/odoo/blob/65811ebaf309c462bf918b01d4401695d87b44d6/addons/account_payment/models/payment_transaction.py#L172-L173 **Bug 2:-** After resolving Bug 1, when we try to make a payment, the amount appears as 0.0 This is because we are passing the amount value in a dictionary with the key as `payment`. while rendering the `portal_overdue_invoices_page`. https://github.com/odoo/odoo/blob/65811ebaf309c462bf918b01d4401695d87b44d6/addons/account_payment/controllers/portal.py#L63 https://github.com/odoo/odoo/blob/65811ebaf309c462bf918b01d4401695d87b44d6/addons/account_payment/controllers/portal.py#L86-L90 While rendering the `payment.form` template from `portal_overdue_invoices_page`, the amount value is missing in `this.paymentContext`, resulting in the amount being null. https://github.com/odoo/odoo/blob/65811ebaf309c462bf918b01d4401695d87b44d6/addons/payment/static/src/js/payment_form.js#L414-L415 This leads to a successful payment with the amount as 0.0. sentry-5741581459
Users can now upload, create, or edit quote header and footer PDF files without triggering an error. This reduces disruption when configuring sales quote documents and makes PDF handling more tolerant of valid files that were previously rejected.
Original PR description
Currently a `PdfReadError` is arising when user try upload/create/edit the Headers/Footers from the menu. To get this error: - Go to "Headers/Footers" from the "Configuration" menu. - Click "New" or "Upload" to upload the PDF file. - For existing files, re-upload through "File Content(base64)". - The error appears in the console log. Sample File: [EA-20221231-13 (1).pdf](https://github.com/user-attachments/files/17813674/EA-20221231-13.1.pdf) Error: `PdfReadError: PDF starts with 'PK␃␄␔', but '%PDF-' expected` To fix this issue, set the parameter "strict" to "False" to be lenient in checking the file type while uploading/creating. sentry-6064981257
This fixes an inventory accounting issue when changing a product's category, especially for products with negative stock. It helps ensure valuation accounts and costing behavior are applied consistently, reducing the risk of incorrect stock accounting entries.
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 fix keeps website pages from unexpectedly jumping back to the top when a popup opens while animations are running. It improves the visitor experience by making animated pages and modal popups behave smoothly and reliably.
Original PR description
Since this commit [1], from which the scrolling element is no longer '#wrapwrap' but HTML, the test 'snippet_popup_and_animations' fails. This is because during animations, 'overflow-x: hidden' is added to the scrolling element (HTML). At the time a modal shows, an 'overflow: hidden' style is briefly added to the 'body' element, which causes the page to scroll to the top when a modal shows while an animation is playing on the page. To fix this unwanted behavior, we moved the 'overflow-x: hidden' rule added during animations from the HTML to the body." [1]: https://github.com/odoo/odoo/commit/189a7c96e6e26825dc05c0c6466576fe63aa091e task-4185877
Merging accounting accounts now also updates related company default settings, preventing contacts from failing to create after a merge. This avoids broken references to removed accounts when multiple companies or localizations are involved.
Original PR description
**Steps to reproduce:** - Install accountant and contacts - Create a new company - Set a fiscal localization for that company (e.g. Belgium) - Select the 2 companies in the company selector - Go to…
**Steps to reproduce:** - Install accountant and contacts - Create a new company - Set a fiscal localization for that company (e.g. Belgium) - Select the 2 companies in the company selector - Go to "Accounting / Configuration / Accounting / Chart of Accounts" - Add "Receivable" filter - Select: * [121000] Account Receivable (from the main company) * [400000] Customers (from the Belgian company) - Merge the 2 accounts - Select the Belgian company in the company selector as main company - Try to create a contact **Issue:** A traceback is raised due to a missing account record. **Cause:** There is a "User-defined default" with "property_account_receivable_id" and "property_account_payable_id" fields of "res.partner" model that is created automatically for each company. As its value (i.e. account ID) is not updated when the accounts are merged, it is using an account ID that doesn't exist anymore. **Solution:** Check the "User-defined defaults" that are linked to an "account.account" field when merging accounts. opw-4269925 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures Indian invoices and Point of Sale receipts show the correct reverse charge tax percentage in the HSN Summary. Customers now see the expected 18% rate instead of inflated percentages, improving document accuracy and compliance clarity.
Original PR description
Steps to re-produce in Invoicing app: 1. Create an customer invoice with `18% IGST RC` tax 2. Post the invoice 3. Print the PDF In the HSN Summary the expected tax percentage should be 18% but instead it displays 36% Steps to re-produce in Point Of Sale: follow the similar steps as above by creating a sale receipt in POS with `18% IGST RC` tax In the receipt HSN Summary the expected tax percentage should be 18% but instead it displays 72% By this commit we resolve the above mentioned issues --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds missing identifiers to French accounting bank data so the records can be reliably loaded during installs, reloads, and upgrades. It prevents upgrade checks from failing and ensures missing bank records can be created when needed.
Original PR description
Records in csv files also need an id column to create a data entry, and to be able to load the file in a mode other than init. The file can be loaded on module installation and all the records would be created without an xmlid, but once the module is reloaded or upgraded the file fails to load. It is a non blocking error for the module but if someone is missing the records then they will not be created. This issue is also blocking the CI on upgrades. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change brings back previously removed website sales stock methods because some existing websites still depended on them. It helps prevent disruptions for online stores after upgrading or running on the stable version.
Original PR description
See #181383, some methods were removed as unused anymore, but existing websites did rely on those apparently. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The HTML editor now waits until a user focuses on it before starting collaboration services. This reduces unnecessary server load and helps improve performance when editor fields are present but not being used.
Original PR description
Issue:
The Editor connect to the collaboration BUS
directly when initialized, resulting in
performances struggle on the server.
Fix:
Restore the previous default behavior to wait for the
focus before initializing the BUS connection.
task-4348299
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix ensures GST return period forms open with the correct active record context and prevents permission errors when checking e-invoicing settings. It helps users access Indian GST reporting workflows more reliably without unexpected access issues.
Original PR description
Before This Commit: - The `open_gst_return_period_form_view` method manually set context values for `active_id` and `active_model` instead of relying on the active context. - In `action_get_irn_data`, the logic directly accessed the configurations without using `sudo`, resulting in access errors in certain cases. After This Commit: - The `open_gst_return_period_form_view` method now uses the active context instead of manually setting context values. - The `action_get_irn_data` method has been updated to use `sudo` when checking `l10n_edi_production_env`, ensuring proper access rights and preventing permission issues.
The employee appraisal form now keeps the feedback section from covering the chatter area when feedback is unpublished. This makes the form easier to read and avoids confusion during appraisal reviews.
Original PR description
**Steps:** - Install the hr_appraisal module - Open the employee appraisal form view ---- **Description of the issue/feature this PR addresses:** In the appraisal form view, when feedback is unpublished, the feedback section overlaps with the chatter area. ---- **Cause:** This issue arises due to unhandled overflow in cases where feedback is unpublished. ---- **Fix:** This PR resolves the overlap by applying CSS overflow hidden, which hides the overflowing content and prevents overlap with the chatter section. task-4320069
This fixes a problem that prevented Mexican electronic invoice cancellations from working with the PAC SW provider after a recent certificate-related change. Businesses using PAC SW can cancel invoices normally again, reducing disruption in Mexican invoicing workflows.
Original PR description
Since https://github.com/odoo/enterprise/commit/84cc09959d82dbceb4fe673b85464ef3d8630606 the cancellation no longer works with the PAC SW opw-4349251
Recruiters can now refuse an application without encountering a system error. This keeps the recruitment workflow running smoothly when the referrals and salary package modules are installed together.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/70278 task-4345648
Closing a document preview now properly restores the page scrollbar. This prevents users from getting stuck without normal scrolling after viewing a file, improving day-to-day usability in Documents.
Original PR description
Purpose ======= Fix the view scrollbar which isn't restored when the file preview is closed. Specifications ============== When a file is previewed, the view scrollbar is hidden so that scrolling actions don't impact the view behind the file preview. However when the preview is closed, the scrollbar isn't restored. => Calling the documentList onDeleteCallback method to correctly restore the view and the scrollbar when closing the preview. Task-4296803
This fix restores the ability to remove tags in the Documents app without triggering an error. It ensures the tag deletion check uses the right data format, preventing a blocker for teams managing document organization.
Original PR description
**Issue:** Documents tags are impossible to remove. **Expected:** Documents tags removal allowed. **Steps to reproduce:** - Activate and navigate to the documents app; - Click on Configuration > Structure > Tags; - Attempting to delete a tag causes an error message. **Cause:** `external_ids` is a JSON object that can't be used in `search_count`, that method waiting for a list in that situation. **Fix:** Retrieve `external_ids` keys as a list. opw-4293294
Documentation and clarification updates
This update records that the contributor dianedelallee has signed the required Contributor License Agreement. It allows their contributions to be accepted under Odoo's contribution process without changing product functionality.
Original PR description
Description of the issue/feature this PR addresses: ADD cla for dianedelallee to be able to contribute Current behavior before PR: cla not signed for dianedelallee Desired behavior after PR is merged: cla signed for dianedelallee thanks --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Steps to reproduce: ------------------- - Make a sale order in the **Sale** app - Confirm sale order - Create invoice of Downpayment - Type 50% - Confirm invoice > Observation: Access error: pos_order_line_ids (allowed for groups 'Point of sale / Users') Why the fix: ------------ Users who do not belong to the point_of_sale.group_pos_user group get the error when they try to confirm an invoice of downpayment. User that have admin rights on accounting but are not users of pos shou
Original PR description
Steps to reproduce: ------------------- - Make a sale order in the **Sale** app - Confirm sale order - Create invoice of Downpayment - Type 50% - Confirm invoice > Observation: Access error: pos_order_line_ids (allowed for groups 'Point of sale / Users') Why the fix: ------------ Users who do not belong to the point_of_sale.group_pos_user group get the error when they try to confirm an invoice of downpayment. User that have admin rights on accounting but are not users of pos should still be able to invoice downpayments. Introduced here: https://github.com/odoo/odoo/commit/370f3bc opw-[4352799](https://www.odoo.com/web#id=4352799&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#188204
Issue: When using non-stored fields as trigger_field_ids in an automation rule, old values will not be updated due to the following condition: `and record._fields[field_name].store` This condition prevents a write from occurring, as old_vals will not be retrieved when we pass the context to: `old_vals = self._context['old_values'].get(record.id, {})` Without old_vals, there are no detected differences, so the _check_trigger_fields function returns False instead of recognizing the update
Original PR description
Issue: When using non-stored fields as trigger_field_ids in an automation rule, old values will not be updated due to the following condition: `and record._fields[field_name].store` This condition…
Issue:
When using non-stored fields as trigger_field_ids in an automation rule, old values will not be updated due to the following condition:
`and record._fields[field_name].store`
This condition prevents a write from occurring, as old_vals will not be retrieved when we pass the context to:
`old_vals = self._context['old_values'].get(record.id, {})`
Without old_vals, there are no detected differences, so the _check_trigger_fields function returns False instead of recognizing the updated field.
This condition was recently added as a bug fix in the following ticket:
Ticket: opw-4106799
PR: #180965
As a result, non-stored fields can no longer be used as trigger fields.
Current behavior before PR:
non-stored fields do not trigger automation rules
Desired behavior after PR is merged:
prevent users from selecting non-stored fields as trigger fields
------------Steps----------
Steps to reproduce (opw-4207855):
1.) Create an automated action.
2.) Trigger: Set to "On Save."
3.) Leave "Before Update" and "Apply On" as default.
4.) When updating (trigger_field_ids): any non-stored field
Step to reproduce prior to pr (PR: #180965, opw-4106799)
1.) Create an automation rule on the Project model.
2.) Set Trigger to "On Save."
3.) Leave the remaining settings as default.
4.) Try to prioritize or deprioritize a project
5.) the project will not be starred until refreshed, or if clicked again, causing the rule to run twice (toggling the star each time).
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#186160Problem: When both l10n_au and l10_nz are installed, the company form displays multiple labels for affected fields, vat and company_registry. Solution: The company form should only display a label per field to avoid confusions. Each view per localization will make the affected field on the parent view invisible and then add in the same affected fields but with a different label. Steps to Reproduce on Runbot: 1. Install l10_au and l10_nz 2. Observe the forms for all companies 3. See
Original PR description
Problem: When both l10n_au and l10_nz are installed, the company form displays multiple labels for affected fields, vat and company_registry. Solution: The company form should only display a label per field to avoid confusions. Each view per localization will make the affected field on the parent view invisible and then add in the same affected fields but with a different label. Steps to Reproduce on Runbot: 1. Install l10_au and l10_nz 2. Observe the forms for all companies 3. See that there's duplicate labels for fields, vat and company_registry opw-4250742 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#184806
*: l10n_account_edi_ubl_cii_tests Fix rounding issue with the early payment discount. I used the client's setup in the test to replicate the exact problem. opw-4245127 Forward-Port-Of: odoo/odoo#186811
Original PR description
*: l10n_account_edi_ubl_cii_tests Fix rounding issue with the early payment discount. I used the client's setup in the test to replicate the exact problem. opw-4245127 Forward-Port-Of: odoo/odoo#186811
Forward-Port-Of: odoo/odoo#187795 Forward-Port-Of: odoo/odoo#185343
Original PR description
Forward-Port-Of: odoo/odoo#187795 Forward-Port-Of: odoo/odoo#185343
Steps to reproduce: - Enter in Website edit mode. - Click on the "Contact Us" button in the header. - In the text toolbar, select "Link" as the "Style" option. - In the text toolbar, clear the URL input (remove "/contactus"). - Click anywhere on the page. - Save the page. - A traceback occurs: "Template fallback - An error occurred while rendering the template website.template_header_mobile" The header's CTA button cannot be removed because it has the class "oe_unremovable". However,
Original PR description
Steps to reproduce: - Enter in Website edit mode. - Click on the "Contact Us" button in the header. - In the text toolbar, select "Link" as the "Style" option. - In the text toolbar, clear the URL input (remove "/contactus"). - Click anywhere on the page. - Save the page. - A traceback occurs: "Template fallback - An error occurred while rendering the template website.template_header_mobile" The header's CTA button cannot be removed because it has the class "oe_unremovable". However, when the URL is cleared from the input field (see step 4 above), the "shouldUnlink" function in "link_tools.js" determines that the link around the "Contact Us" text should be removed. In this commit, we prevent links with the "oe_unremovable" class from being removed in this situation. opw-4308023 Forward-Port-Of: odoo/odoo#187947
**Problem**: When items come from a different JavaScript context (e.g., an iframe, a web worker, or a shadow DOM), their prototype chain may not match the `Attr` class in the current global scope. This mismatch leads to issues in detecting node types correctly. **Solution**: Use `attr.nodeType === Node.ATTRIBUTE_NODE` to check for attribute nodes. This approach is more resilient and works across different JavaScript contexts. **Steps to reproduce**: 1. Navigate to the Email Marketing ap
Original PR description
**Problem**: When items come from a different JavaScript context (e.g., an iframe, a web worker, or a shadow DOM), their prototype chain may not match the `Attr` class in the current global scope. This mismatch leads to issues in detecting node types correctly. **Solution**: Use `attr.nodeType === Node.ATTRIBUTE_NODE` to check for attribute nodes. This approach is more resilient and works across different JavaScript contexts. **Steps to reproduce**: 1. Navigate to the Email Marketing app. 2. Copy text with a hyperlink from any website. 3. Paste the copied text into the email body. 4. Observe that the text is pasted, but the link is empty due to incorrect node type detection. opw-4345535 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187988
Currently, if the `quick_encoding_vals` field becomes visible in a view (e.g., by toggling "Show invisible elements" in Studio), the system crashes. This happens because the field is currently a Binary field that cannot be represented as a string. ### Fix The `quick_encoding_vals` field is an **unstored computed** field that outputs a dictionary. To resolve the issue, we can safely convert it into a JSON field. Note: Fix confirmed by WAN on the ticket. opw-4241572 Forward-Port-Of: o
Original PR description
Currently, if the `quick_encoding_vals` field becomes visible in a view (e.g., by toggling "Show invisible elements" in Studio), the system crashes. This happens because the field is currently a Binary field that cannot be represented as a string. ### Fix The `quick_encoding_vals` field is an **unstored computed** field that outputs a dictionary. To resolve the issue, we can safely convert it into a JSON field. Note: Fix confirmed by WAN on the ticket. opw-4241572 Forward-Port-Of: odoo/odoo#187050
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it lea
Original PR description
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company…
Steps to reproduce: 1. Go to Accounting > Invoices and print any invoice. 2. Go to Settings > Configure your document layout. 3. Set the layout to "Boxed" (default is "Light"). 4. Add a Company Tagline (any value), save, then delete it completely. 5. Go back to Accounting > Invoices and print any invoice. You can notice that the grey line and the text on the top right corner is more down compare to the first printed report. When the Company Tagline `report_header` is cleared, it leaves an extra newline in the report because the HTML editor sets it to `<p><br></p>` instead of `false`. This causes the printed invoice layout to shift. As a solution I added a method that checks if `report_header` is empty or not and then display it only when it’s not empty (`<p><br></p>`). Alternative solutions considered: 1. Clean the `report_header` field before saving it to the database OR use an on-change function to remove empty values. 2. Implement a custom widget or JS hook for better control. The chosen solution is the simplest, requiring minimal code changes to address the issue effectively. opw-4247281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188055 Forward-Port-Of: odoo/odoo#186023
Commit ab5b806ced3a72f04af9b92f1ec8c32e9a03f4d7 introduced a regression by moving the computation logic for the DIN 5008 layout from Python into the XML template report_purchaseorder_document. However, the same logic was not applied to report_purchasequotation_document, which is used for RFQs, causing discrepancies in the RFQ layout. task-4089521 Forward-Port-Of: odoo/odoo#183953
Original PR description
Commit ab5b806ced3a72f04af9b92f1ec8c32e9a03f4d7 introduced a regression by moving the computation logic for the DIN 5008 layout from Python into the XML template report_purchaseorder_document. However, the same logic was not applied to report_purchasequotation_document, which is used for RFQs, causing discrepancies in the RFQ layout. task-4089521 Forward-Port-Of: odoo/odoo#183953
The method _get_customization_ids is overriden in other modules to add their schema. The issue is that we call explicitely a specific model with _check_document_type_support. As we call it, the overrident part is not taken into account, as they are overriden in model that changed name. Ex: account.edi.xml.pint_jp is not account.edi.xml.ubl_21. It causes issues if you create a company with an existing participant in the country of these other modules and with the default eas. To reproduce
Original PR description
The method _get_customization_ids is overriden in other modules to add their schema. The issue is that we call explicitely a specific model with _check_document_type_support. As we call it, the overrident part is not taken into account, as they are overriden in model that changed name. Ex: account.edi.xml.pint_jp is not account.edi.xml.ubl_21. It causes issues if you create a company with an existing participant in the country of these other modules and with the default eas. To reproduce: Create a company with the module l10n_jp_ubl_pint and account_peppol installed. Put Japan as country and put as Tax number the endpoint of an existing participant When saving, it will traceback, as the key is not in the dict --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188005
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Ori
Original PR description
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: =============================…
This fix is a continuation of this [commit]. Issue: ====== Inserting new image and image replacements don't get saved when switching tabs. Steps to reproduce the issue: ============================= - Create a mass mailing - choose welcome message template - add subject, mailing list and save - Add image using /image and switch directly to another tab like `a/b testing` - Go back to mail body => changes aren't saved. - Same if you replace an existing image with another one Origin of the issue: ==================== - For Newly inserted images we need to refocus in the editor like we did in the old commit. - Now for both of them after the refocus fix we still have an issue because the `saveModifiedImagesPromise` will take so much time so that after it gets resolved the component is already destroyed and we will not save the changes. Solution: ========= We force the commitChanges coming from mass_mailing as urgent so it will save the value before resolving any promise to make sure we don't loose the content. opw-3947516 [commit]: https://github.com/odoo/odoo/commit/146b0b9ff4b4c2cbabd5d71f869f31f4bbb649d2 Forward-Port-Of: odoo/odoo#182615
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. Ticket: 4221771 --- I confirm I have signed the CLA and read
Original PR description
Issue: When printing the PDF of a Purchase Order, if the company has multiple address, those appear on the same line. Steps to reproduce: - Create a Mexican Company with 2 address lines - Create a Purchase Order - Print the PDF of the Purchase Order Cause: The separator between the 2 address lines in the address format is set as a blank space. Solution: Replace the blank space separator with a new line. Ticket: 4221771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186926
This commit fixes the direction of the arrows in the stock rules diagram if the user languange is right-to-left. opw-4302429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187967 Forward-Port-Of: odoo/odoo#187921
Original PR description
This commit fixes the direction of the arrows in the stock rules diagram if the user languange is right-to-left. opw-4302429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187967 Forward-Port-Of: odoo/odoo#187921
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/enterprise/pull/73492 You'll see in the chatter that the confirmation email
Original PR description
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app…
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/enterprise/pull/73492 You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation. The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled. opw-4190402 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187944 Forward-Port-Of: odoo/odoo#183586
Steps to reproduce: - Employee > New - Time Off > Configuration > Accrual Plans > New - Accrued Gain Time: 'Start of the accrual period' - New Milestone > 20 days; Yearly; Carry over: None - Time Off > Management > Allocations > New - Accrual allocation; Start at the 1st Jan this year - Asign it to your new employee - Employees > Your employee > Time Off - Take 10 days off this year - Check balance at the beginning of next year Only 10 days are available when we should get 20 after
Original PR description
Steps to reproduce: - Employee > New - Time Off > Configuration > Accrual Plans > New - Accrued Gain Time: 'Start of the accrual period' - New Milestone > 20 days; Yearly; Carry over: None - Time Off…
Steps to reproduce: - Employee > New - Time Off > Configuration > Accrual Plans > New - Accrued Gain Time: 'Start of the accrual period' - New Milestone > 20 days; Yearly; Carry over: None - Time Off > Management > Allocations > New - Accrual allocation; Start at the 1st Jan this year - Asign it to your new employee - Employees > Your employee > Time Off - Take 10 days off this year - Check balance at the beginning of next year Only 10 days are available when we should get 20 after the carryover date. While the allocation is computed correctly, leaves taken prior to the carryover are still deducted from the available days. This should not happen for days reset on carryover as the allocated days should have already been taken from the previous year's days we no longer have access to. This happens because sudo drops the context when creating a new environment, meaning we lose the target date which simply defaults back to today, making the accrual computation wrong. Note that this fix only addresses the case where leaves are validated. opw-4326914 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187377
**To reproduce:** - Install sales, delivery - Create currency DUM with value 5 DUM = 1 USD - Enable pricelists - Create shipping method based on rules with one rule: (shipping cost = 100 if price >=0) and fixed margin of 10 - Create new pricelist in DUM currency with a price for any product P - Create SO with pricelist DUM for some quantity of product P - Add shipping using above created shipping method **Current behaviour:** Calculated shipping cost 510 DUM. **Expected behaviour:*
Original PR description
**To reproduce:** - Install sales, delivery - Create currency DUM with value 5 DUM = 1 USD - Enable pricelists - Create shipping method based on rules with one rule: (shipping cost = 100 if price…
**To reproduce:** - Install sales, delivery - Create currency DUM with value 5 DUM = 1 USD - Enable pricelists - Create shipping method based on rules with one rule: (shipping cost = 100 if price >=0) and fixed margin of 10 - Create new pricelist in DUM currency with a price for any product P - Create SO with pricelist DUM for some quantity of product P - Add shipping using above created shipping method **Current behaviour:** Calculated shipping cost 510 DUM. **Expected behaviour:** Calculated shipping cost 550 DUM as in (100 USD + 10 USD) * 5 DUM/USD. **Reason:** The fixed_margin field introduced in [1] is added to the shipping cost in the `_apply_margins` method added in [2] without any currency conversion. This will lead to mismatched currency additions in case the sale order currency doesn't match the shipping methods company currency. [1] https://github.com/odoo/odoo/pull/108794 [2] https://github.com/odoo/odoo/pull/157452 opw-4289754 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187860
Before this commit, adding products to the cart would become slow when there were several loyalty.card records and several pos.order.line records. opw-4317125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186797
Original PR description
Before this commit, adding products to the cart would become slow when there were several loyalty.card records and several pos.order.line records. opw-4317125 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186797
This commit addresses the issue where orders were created on a device with an open PoS session, even though the session had been closed on another device. Previously, the system would create a "rescue session" for these orders, which led to incorrect cash statements. With this fix, instead of creating a rescue session, the system now attempts to find any available open session. If no open session is found, the system prevents the order sync and raises an error, prompting users to open a new s
Original PR description
This commit addresses the issue where orders were created on a device with an open PoS session, even though the session had been closed on another device. Previously, the system would create a…
This commit addresses the issue where orders were created on a device with an open PoS session, even though the session had been closed on another device. Previously, the system would create a "rescue session" for these orders, which led to incorrect cash statements. With this fix, instead of creating a rescue session, the system now attempts to find any available open session. If no open session is found, the system prevents the order sync and raises an error, prompting users to open a new session. The decision to remove rescue sessions was driven by the fact that they caused inaccuracies in cash statements. Orders captured in a rescue session, especially those involving cash payments, would disrupt the cash control process. Furthermore, rescue sessions would initialize with a zero opening balance, which affected the accuracy of closing balances and cash flow. opw-4219284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#182058
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robo
Original PR description
Since [1], the _is_indexable_url() method was introduced to determine whether a website should be indexed. However, if a domain name contains uppercase letters, the method incorrectly returns a falsy value. This happens because browsers automatically convert URLs to lowercase, causing a mismatch. Steps to reproduce the issue: - Navigate to Website > Configuration > Website. - Set a domain name with uppercase letters (e.g., http://TEST.localhost:8069). - Go to settings and modify the robots.txt file. - Visit http://TEST.localhost:8069/robots.txt and notice that the changes are not reflected. This commit resolves the issue by handling uppercase letters in domain names correctly. [1]: https://github.com/odoo/odoo/commit/49c226a243864a935b7f8e13c79247a1d9405afa opw-4306840 Forward-Port-Of: odoo/odoo#187690
Before this PR, one-letter domain (like https://x.com) would not be linkified. This PR allows one-letter domain. Task-4344826 Forward-Port-Of: odoo/odoo#188037 Forward-Port-Of: odoo/odoo#187899
Original PR description
Before this PR, one-letter domain (like https://x.com) would not be linkified. This PR allows one-letter domain. Task-4344826 Forward-Port-Of: odoo/odoo#188037 Forward-Port-Of: odoo/odoo#187899
When new modules with coas are being installed, the matching coa based on country is autoinstalled if possible, but if multiple charts match then we overwrite the autoinstall and use the one from the last module. Here we make sure we do not overwrite the chart if it is not associated with the company's country. Using a chart not associated with any country (except generic_coa) during module installation will result in failure. Problem is reproduced on: 1- CI when any syscohada module is in
Original PR description
When new modules with coas are being installed, the matching coa based on country is autoinstalled if possible, but if multiple charts match then we overwrite the autoinstall and use the one from the last module. Here we make sure we do not overwrite the chart if it is not associated with the company's country. Using a chart not associated with any country (except generic_coa) during module installation will result in failure. Problem is reproduced on: 1- CI when any syscohada module is installed 2- start a new db and do not set a country on your company, then try installing any syscohada module --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187958 Forward-Port-Of: odoo/odoo#187271
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188077
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188077
In #173866, the IoT configuration files were merged into one file. However, a logic check in `wireless_ap.sh` was inverted in the process, causing it not to wait for an IP. This PR simply restores the `!` to fix the check. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187862
Original PR description
In #173866, the IoT configuration files were merged into one file. However, a logic check in `wireless_ap.sh` was inverted in the process, causing it not to wait for an IP. This PR simply restores the `!` to fix the check. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187862
The dependency `l10n_syscohada` doesn't get installed automatically when account is installed, therefore these l10n don't get installed either. Each localization that had `countries` set in the manifest should have an `auto_install` containing the main app it is for. Forward-Port-Of: odoo/odoo#187916
Original PR description
The dependency `l10n_syscohada` doesn't get installed automatically when account is installed, therefore these l10n don't get installed either. Each localization that had `countries` set in the manifest should have an `auto_install` containing the main app it is for. Forward-Port-Of: odoo/odoo#187916
opw-4325300 Forward-Port-Of: odoo/odoo#187706 Forward-Port-Of: odoo/odoo#187285
Original PR description
opw-4325300 Forward-Port-Of: odoo/odoo#187706 Forward-Port-Of: odoo/odoo#187285
Steps to reproduce: - Modify the invoice mail template by adding a default attachment - Create and confirm an invoice - Send and Print: delete the attachment from the wizard Issue: Back to the mail template, you will see that the attachment has been deleted Cause: The attachment is not protected from deletion and is added to list of attahcments to be deleted https://github.com/odoo/odoo/blob/ef424a9dc22a5abbe7b0a6eff61cf113826f04c0/addons/account/static/src/components/mail_attachments
Original PR description
Steps to reproduce: - Modify the invoice mail template by adding a default attachment - Create and confirm an invoice - Send and Print: delete the attachment from the wizard Issue: Back to the mail template, you will see that the attachment has been deleted Cause: The attachment is not protected from deletion and is added to list of attahcments to be deleted https://github.com/odoo/odoo/blob/ef424a9dc22a5abbe7b0a6eff61cf113826f04c0/addons/account/static/src/components/mail_attachments/mail_attachments.js#L59-L63 and is deleted https://github.com/odoo/odoo/blob/ef424a9dc22a5abbe7b0a6eff61cf113826f04c0/addons/account/static/src/components/mail_attachments/mail_attachments.js#L81-L82 Solution: Make sure that attachements from template are protected opw-4295826 Forward-Port-Of: odoo/odoo#187240
Prior to this commit, the `FormStatusIndicator` buttons were not properly aligned with the content of the breadcrumb in the control panel. This commit adjusts the alignment of `FormStatusIndicator` correctly according to the content of the breadcrumb. Also, to align the cog menu perfectly with the "save" and "cancel" buttons, we've removed the border around the latter two. task-3874495 | Before | After | |--------|--------| | ![Capture d’écran 2024-05-13 à 16 04 53](https://githu
Original PR description
Prior to this commit, the `FormStatusIndicator` buttons were not properly aligned with the content of the breadcrumb in the control panel. This commit adjusts the alignment of `FormStatusIndicator`…
Prior to this commit, the `FormStatusIndicator` buttons were not properly aligned with the content of the breadcrumb in the control panel. This commit adjusts the alignment of `FormStatusIndicator` correctly according to the content of the breadcrumb. Also, to align the cog menu perfectly with the "save" and "cancel" buttons, we've removed the border around the latter two. task-3874495 | Before | After | |--------|--------| |  |  | |  |  | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#186463
## 1st Issue **[FIX] l10n_es_reports: hanldle new expressions in mod349** In report line, if there is no related expression pointing at it, it is being created by shortcut syntaxes. Before this PR[^1], there were no expressions pointing at these report lines: 1. mod_349_supplies 2. mod_349_acquisitions 3. mod_349_triangular 4. mod_349_services_sold 5. mod_349_services_acquired 6. mod_349_supplies_without_taxes 7. mod_349_supplies_without_taxes_legal_representative 8. mod_349
Original PR description
## 1st Issue **[FIX] l10n_es_reports: hanldle new expressions in mod349** In report line, if there is no related expression pointing at it, it is being created by shortcut syntaxes. Before this…
## 1st Issue
**[FIX] l10n_es_reports: hanldle new expressions in mod349**
In report line, if there is no related expression pointing at it,
it is being created by shortcut syntaxes.
Before this PR[^1], there were no expressions pointing at
these report lines:
1. mod_349_supplies
2. mod_349_acquisitions
3. mod_349_triangular
4. mod_349_services_sold
5. mod_349_services_acquired
6. mod_349_supplies_without_taxes
7. mod_349_supplies_without_taxes_legal_representative
8. mod_349_supplies_refunds
9. mod_349_acquisitions_refunds
10. mod_349_triangular_refunds
11. mod_349_services_sold_refunds
12. mod_349_services_acquired_refunds
13. mod_349_supplies_without_taxes_refunds
14. mod_349_supplies_without_taxes_legal_representative_refunds
After that PR, all of the report lines now include expressions with `engine=custom` and `label=balance`. For databases on version >= `16.0` before the PR, these report lines already have expressions without an IMD. However, during an upgrade, the addition of new expressions with an IMD triggers the creation of duplicates, resulting in a UNIQUE constraint violation on `(report_line_id, balance)`.
Steps to reproduce the issue:
1. Install `l10n_es_reports` in version `16.0` before that PR
2. Try to upgrade it to `17.0` after that PR
You will get error similar to this:
```
2024-10-30 13:56:05,428 3470006 WARNING test_l10n_es_report odoo.modules.loading: Transient module states were reset
2024-10-30 13:56:05,430 3470006 ERROR test_l10n_es_report odoo.modules.registry: Failed to load registry
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 556, in _tag_root
f(rec)
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 462, in _tag_record
self._tag_record(child_rec, extra_vals={inverse_name: record.id})
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 462, in _tag_record
self._tag_record(child_rec, extra_vals={inverse_name: record.id})
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 462, in _tag_record
self._tag_record(child_rec, extra_vals={inverse_name: record.id})
File "/home/odoo/src/odoo/17.0/odoo/tools/convert.py", line 456, in _tag_record
record = model._load_records([data], self.mode == 'update')
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 5088, in _load_records
records = self._load_records_create([data['values'] for data in to_create])
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4999, in _load_records_create
return self.create(values)
File "<decorator-gen-216>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/17.0/addons/account/models/account_report.py", line 620, in create
result = super().create(vals_list)
File "<decorator-gen-123>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/upgrade-util/src/util/orm.py", line 244, in wrapper
return f(*args, **kwargs)
File "/home/odoo/src/upgrade/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
return super().create(vals_list)
File "<decorator-gen-12>", line 2, in create
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 415, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4627, in create
records = self._create(data_list)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4815, in _create
cr.execute(SQL(
File "/home/odoo/src/odoo/17.0/odoo/sql_db.py", line 332, in execute
res = self._obj.execute(query, params)
psycopg2.errors.UniqueViolation: duplicate key value violates unique constraint "account_report_expression_line_label_uniq"
DETAIL: Key (report_line_id, label)=(480, balance) already exists.
```
## 2nd Issue
**[FIX] l10n_es_reports: fix subformulas' of expressions in mod349**
In this PR[^1], the expressions `mod_349_statistics_invoices_total_amount_balance`
and `mod_349_statistics_refunds_total_amount_balance` was modified so the engine of
both of them changed from `domain` to `aggregation`. Also the subformula from both
of them were removed. But during the upgrade the engines are being modified but
the subformulas kept same.
Expected condition is having NULL on both of the expressions' subformula.
Because of they are not being changed during upgrade, they end up being `sum`
at the end.
When we try to open the `Tax report mod 349` after upgrade, the new engine and old
subformula are conflicting and facing issue here[^2].
Steps to reproduce
1. Install `l10n_es_reports` before the PR above in version `16.0`
2. Upgrade the db to `17.0` by solving the 1st issue of this PR
3. Try to open `Tax report mod 349`
you will see error like this:
```
.....
result = getattr(recs, name)(*args, **kwargs)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 4869, in get_report_information
all_column_groups_expression_totals = self._compute_expression_totals_for_each_column_group(self.line_ids.expression_ids, options, warnings=warnings)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 2826, in _compute_expression_totals_for_each_column_group
current_group_expression_totals = self._compute_expression_totals_for_single_column_group(
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 3011, in _compute_expression_totals_for_single_column_group
aggregation_formula_results = self._compute_totals_no_batch_aggregation(column_group_options, aggregation_formulas_dict, column_group_expression_totals, cross_report_expr_totals_by_scope)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 3208, in _compute_totals_no_batch_aggregation
expression_result = self._aggregation_apply_bounds(column_group_options, expression.subformula, formula_result)
File "/home/odoo/src/enterprise/saas-17.4/account_reports/models/account_report.py", line 3266, in _aggregation_apply_bounds
group_values = match.groupdict()
AttributeError: 'NoneType' object has no attribute 'groupdict'
```
[^1]: https://github.com/odoo/enterprise/pull/65074
[^2]: https://github.com/odoo/enterprise/blob/3a7a46ff2404a5c4ca1c0ad676529fc17d9a2234/account_reports/models/account_report.py#L3455-L3461
Forward-Port-Of: odoo/enterprise#74328
Forward-Port-Of: odoo/enterprise#73082Forward-Port-Of: odoo/enterprise#74128 Forward-Port-Of: odoo/enterprise#72823
Original PR description
Forward-Port-Of: odoo/enterprise#74128 Forward-Port-Of: odoo/enterprise#72823
All the Colorado and Washington taxes rules should be above the Post Tax Deductions and should all be of the category Taxes. Task: 4329645 Forward-Port-Of: odoo/enterprise#73762
Original PR description
All the Colorado and Washington taxes rules should be above the Post Tax Deductions and should all be of the category Taxes. Task: 4329645 Forward-Port-Of: odoo/enterprise#73762
When a whatsapp conversation is inactive after 1 day, they are automatically unpinned as long as user has seen all the messages. However, if the user never reads them, these whatsapp conversations keep being added to the pinned list of conversations, which adds more and more loads on Discuss fetched data over time. There is a practical limit of around 2000 pinned conversations, after which Discuss is very slow and hardly usable. This is a known limitation with the current implementation.
Original PR description
When a whatsapp conversation is inactive after 1 day, they are automatically unpinned as long as user has seen all the messages. However, if the user never reads them, these whatsapp conversations…
When a whatsapp conversation is inactive after 1 day, they are automatically unpinned as long as user has seen all the messages. However, if the user never reads them, these whatsapp conversations keep being added to the pinned list of conversations, which adds more and more loads on Discuss fetched data over time. There is a practical limit of around 2000 pinned conversations, after which Discuss is very slow and hardly usable. This is a known limitation with the current implementation. Whatsapp conversations usually involved many operators for a given conversation, even though usually a single operator is actively communicating with the whatsapp customer. This means that all the inactive operators are keeping many unread whatsapp conversations, thus lots of whatsapp conversations stay unpinned. This commit fixes the issue by forcing unpinning inactive whatsapp conversations after 2 weeks, regardless of whether current user has read the conversation or not. Most of the time whatsapp conversations are short-lived conversations, therefore after 2 weeks this is almost guarantee that there's no point keeping this conversation pinned. opw-4331007 Forward-Port-Of: odoo/enterprise#74101 Forward-Port-Of: odoo/enterprise#73923
… other country's invoices Forward-Port-Of: odoo/enterprise#74020
Original PR description
… other country's invoices Forward-Port-Of: odoo/enterprise#74020
### Steps to reproduce: - Create a new project and set it to be billable. - Set an analytic account on it - On the analytic account, set a plan that is not the default plan - Create a sale order for a subscription product with this analytic account and confirm it. - Create an invoice and confirm it. - Go to the project and click on Status Updates - Notice that the revenues show 0 in “Invoiced” even though we have invoiced the product - If we change the plan on the analytic accoun
Original PR description
### Steps to reproduce: - Create a new project and set it to be billable. - Set an analytic account on it - On the analytic account, set a plan that is not the default plan - Create a sale order for…
### Steps to reproduce:
- Create a new project and set it to be billable.
- Set an analytic account on it
- On the analytic account, set a plan that is not the default plan
- Create a sale order for a subscription product with this analytic account and confirm it.
- Create an invoice and confirm it.
- Go to the project and click on Status Updates
- Notice that the revenues show 0 in “Invoiced” even though we have invoiced the product
- If we change the plan on the analytic account, we will be able to see the invoiced amount on the profitability report
### Current behavior before PR:
When setting analytic account with different analytic plan than the default one the analytic account value will be stored in x_plan{plan_id}_id field when creating the analytic account line record. https://github.com/odoo/odoo/blob/39029710bbce55889c6b951fc423c1254e05ff22/addons/account/models/account_move_line.py#L3092
https://github.com/odoo/odoo/blob/17.0/addons/analytic/models/analytic_plan.py#L106:L122
So when fetching the profitability data for a project we are just checking the account_id field.
https://github.com/odoo/enterprise/blob/17.0/project_sale_subscription/models/project.py#L111:L115
### Desired behavior after PR is merged:
We are now using the same method of _column_name() to know which field should we use in the domain whether it is 'account_id' or 'x_plan{plan_id}_id'
opw-4137931
Forward-Port-Of: odoo/enterprise#70508### After this PR You can add new column to the account partner ledger Example: ``` def _get_additional_column_aml_query_values(self): res = super()._get_additional_column_aml_query_values() res +="account_move_line.date as date," return res ``` Forward-Port-Of: odoo/enterprise#74201 Forward-Port-Of: odoo/enterprise#74075
Original PR description
### After this PR
You can add new column to the account partner ledger
Example:
```
def _get_additional_column_aml_query_values(self):
res = super()._get_additional_column_aml_query_values()
res +="account_move_line.date as date,"
return res
```
Forward-Port-Of: odoo/enterprise#74201
Forward-Port-Of: odoo/enterprise#74075Since odoo/enterprise@4f162e7e1ea, the `voip.mode` ICP has been replaced by `voip.provider`'s mode. This commit update the neutralization script accordingly. Forward-Port-Of: odoo/enterprise#74035
Original PR description
Since odoo/enterprise@4f162e7e1ea, the `voip.mode` ICP has been replaced by `voip.provider`'s mode. This commit update the neutralization script accordingly. Forward-Port-Of: odoo/enterprise#74035
During the es_XX.po cleaning, the po file for l10n_co_reports was incorrectly not converted to es_419.po and only deleted. We now restore it + correctly rename it to es_419.po As part of this cleaning, the pot file has been re-exported and the po re-synced with it. Missing translations were also added it. A sentence that was obviously incorrect in the original Spanish was also translated to a correct sentence. opw-4336377 PR that deleted the original es_CO.po file: https://github.com/od
Original PR description
During the es_XX.po cleaning, the po file for l10n_co_reports was incorrectly not converted to es_419.po and only deleted. We now restore it + correctly rename it to es_419.po As part of this cleaning, the pot file has been re-exported and the po re-synced with it. Missing translations were also added it. A sentence that was obviously incorrect in the original Spanish was also translated to a correct sentence. opw-4336377 PR that deleted the original es_CO.po file: https://github.com/odoo/enterprise/pull/66317 Forward-Port-Of: odoo/enterprise#74248
An error will raise when users try to open a locked SO where taxes are automatically computed Set up Avatax on the current company In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' Add a partner and product having avatax category defined Compute taxes Confirm order, it will be automatically locked - With only sale_external_tax installed: Click "Preview" - With sale_subscription_external_tax installe
Original PR description
An error will raise when users try to open a locked SO where taxes are automatically computed Set up Avatax on the current company In Settings > Sales > Quotations& Orders active 'Lock Confirmed Sales' Create a SO with fiscal position 'Automatic Tax Mapping (AvaTax)' Add a partner and product having avatax category defined Compute taxes Confirm order, it will be automatically locked - With only sale_external_tax installed: Click "Preview" - With sale_subscription_external_tax installed: Click "Confirm" Issue: Action will be blocked by User Error ``` It is forbidden to modify the following fields in a locked order ``` This occurs because the system attempt to recompute external taxes after confirming the sale order, which has been locked, so the action will be blocked opw-4261396 Forward-Port-Of: odoo/enterprise#74169
When extracting data from a ticket expressed in a currency that's inactive in the company, the code crashed with a KeyError, because the 'currency_id' was not in the vals dictionary. This crashed some tests in hr_expense_extract when they were run in a db with only USD as active company. Forward-Port-Of: odoo/enterprise#74207 Forward-Port-Of: odoo/enterprise#72941
Original PR description
When extracting data from a ticket expressed in a currency that's inactive in the company, the code crashed with a KeyError, because the 'currency_id' was not in the vals dictionary. This crashed some tests in hr_expense_extract when they were run in a db with only USD as active company. Forward-Port-Of: odoo/enterprise#74207 Forward-Port-Of: odoo/enterprise#72941
Manual fw-port of translations since they're not on transifex for saas versions. To do this properly, the following was also done: - re-export pot files - fill in translations for new terms added in this version - remove leftover translation files from localizations they didn't make sense for - fixed typo in `l10n_be_social_balance_sheet` Note that within saas-17.4: `l10n_ch_hr_payroll_elm` was merged into `l10n_ch_hr_payroll`. Therefore the translations needed to be manually ported over
Original PR description
Manual fw-port of translations since they're not on transifex for saas versions. To do this properly, the following was also done: - re-export pot files - fill in translations for new terms added in this version - remove leftover translation files from localizations they didn't make sense for - fixed typo in `l10n_be_social_balance_sheet` Note that within saas-17.4: `l10n_ch_hr_payroll_elm` was merged into `l10n_ch_hr_payroll`. Therefore the translations needed to be manually ported over from the previous version's module into the new merged po file. Because translations for IT and DE don't appear to be completed for 17.0's localzations on transifex, these translations were not ported over as it's a very painful manual job cross checking the po files of the former version. Forward-Port-Of: odoo/enterprise#74111
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to
Original PR description
Let's say you have: - One statement line of 3000 USD / 1000 MXN (rate 1:3) - Three invoices of 1000 USD / 500MXN (rate 1:2) => If you reconcile in the bank widget, the statement entry amounts will be divided by 3 ending with 3 lines of 1000 USD and 333.33 MXN leaving a 0.01 unmatched. This can be an issue for the validation of payment EDI for localizations like Mexican one. This PR gives more flexibility to user when dealing when bank reconciliation in multiple currencies by allowing to edit amounts on generated exchange moves to allocate this small difference. opw-4128899 Forward-Port-Of: odoo/enterprise#72810 Forward-Port-Of: odoo/enterprise#72212
Introduced in https://github.com/odoo/enterprise/pull/73469 I made a mistake when checking module dependencies, `work_entry_source` attendance is not available in `hr_payroll`, the attendance module is separate. This move is needed to fix errors in runbot. opw-4266880 Forward-Port-Of: odoo/enterprise#74251
Original PR description
Introduced in https://github.com/odoo/enterprise/pull/73469 I made a mistake when checking module dependencies, `work_entry_source` attendance is not available in `hr_payroll`, the attendance module is separate. This move is needed to fix errors in runbot. opw-4266880 Forward-Port-Of: odoo/enterprise#74251
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/odoo/pull/183586 You'll see in the chatter that the confirmation email is se
Original PR description
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app…
Steps to reproduce: - Sales app > Configuration > Settings > Enable 'Quotation Templates' - Default template > Search more > New - Set 'Confirmation Mail' to 'Sales: Order Confirmation' - Project app > New > Enable 'Billable' in the project's settings - New Task > Set any Customer - Sales Order Item > Search More > New > Add product then save - Click 'Sales Order' button Coupled with https://github.com/odoo/odoo/pull/183586 You'll see in the chatter that the confirmation email is sent before the product is added to the sales order, resulting in a $0 quotation document being sent to the customer. This happens because we confirm the SO at the same time as we create it (After pressing the New button). Instead we would rather confirm the SO on save, after the order line creation. The SO confirmation is necessary because we don't want people to work on tasks/projects that are still in quotation since they could hypothetically still be cancelled. opw-4190402 Forward-Port-Of: odoo/enterprise#74200 Forward-Port-Of: odoo/enterprise#73492
Task id 4244702 Forward-Port-Of: odoo/enterprise#74287
Original PR description
Task id 4244702 Forward-Port-Of: odoo/enterprise#74287
Before this commit, attempting to print a bill early would result in an error because the account_move did not exist. opw-4336405 Forward-Port-Of: odoo/enterprise#73913
Original PR description
Before this commit, attempting to print a bill early would result in an error because the account_move did not exist. opw-4336405 Forward-Port-Of: odoo/enterprise#73913
**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account - Close POS session - Go to Accounting - Open Bank journal - Create a statement line and reconcile it with the POS payment - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Check the amount of the POS orders in the following journals: * [101300] Account Receivable (PoS) *
Original PR description
**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account -…
**Steps to reproduce:** - Install Accounting and Point of Sale - Open a "Point of Sale" session - Create a POS order and pay it by bank - Create another POS order and pay it by Customer Account - Close POS session - Go to Accounting - Open Bank journal - Create a statement line and reconcile it with the POS payment - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Check the amount of the POS orders in the following journals: * [101300] Account Receivable (PoS) * [121000] Account Receivable * [400000] Product Sales - Check "Cash Basis Method" in the options - Check again the amount of the POS orders in the same journals **Issue 1:** The amount for "[121000] Account Receivable" is present but it shouldn't because no payment has been done for it yet. **Extra steps:** - Create another statement line and reconcile it with the POS customer account payment - Check again the amount of the POS orders in the same journals **Issue 2:** The amount of the POS orders is double the original amount. **Issue 3:** If a partial payment is made for one line, the report has incorrect values. **Cause:** To retrieve the cash basis lines, a complex SQL query is executed. Let's take the following entries: - Invoice: | account | debit | credit | | ----------- | -------- | -------- | | Account Receivable 1 | 100 | 0 | | Account Receivable 2 | 200 | 0 | | Product Sales | 0 | 300 | - Payments: | account | debit | credit | | ---------------- | ------------ | ----------- | | Bank | 50 | 0 | | Account Receivable 1 | 0 | 50 | | account | debit | credit | | ------------ | ---------------- | ----------- | | Bank | 200 | 0 | | Account Receivable 2 | 0 | 200| A SELECT is executed to compute and get the percentage of the paid amount of each receivable/payable account by move, generating a temporary "table" as followed: | move_id | matched_percentage| | ------------------|---------------------------------| | 1 | 0.5 (50% paid for Account Receivable 1)| | 1 | 1.0 (100% paid for Account Receivable 2)| This table is then joined to account_move_line table on move_id where matched_percentage is applied to the amounts. Issues 1 and 2 are due to the fact that it was assumed that each account move would only contain 1 receivable/payable account, which is not the case here. As account_id is not present in the temporary table, it is not possible to identify to which account a line of that table refers to. As there is only a JOIN ON move_id when joining with account_move_line table, each aml from a move is taken into account even when it shouldn't. In this example, they are taken into account twice because the 2 entries have the same move_id. Issue 3 is coming from the fact that the WHOLE amount of "Product Sales" is computed with matched_percentage each time. For example, these 2 lines are computed from the tempory table for "Product Sales": * Product Sales = 300 * 0.5 = 150 (for Account Receivable 1) * Product Sales = 300 * 1.0 = 300 (for Account Receivable 2) The amount for "Product Sales" sums to 450, which is not correct. It should be 250. **Solution for issues 1 and 2:** Get account_id and join account_move_line table on it. An exception should be done for "Product Sales" when joining account_move_line table because it is not a receivable/payable account and the temporay table only contains receivable/payable accounts. **Solution for issue 3:** Compute a ratio for "Product Sales" for each receivable account. Its amount is 100 for "Account Receivable 1" and 200 for "Account Receivable 2" So its ratio should be: * 100 / 300 = 0.33 (for Account Receivable 1) * 100 / 300 = 0.66 (for Account Receivable 2) By applying this ratio, the correct amounts are computed for "Product Sales": * Product Sales = 300 * 0.5 * 0.33 = 50 (for Account Receivable 1) * Product Sales = 300 * 1.0 * 0.66 = 200 (for Account Receivable 2) opw-4224136 Forward-Port-Of: odoo/enterprise#74237 Forward-Port-Of: odoo/enterprise#73593
Add some hooks and tweaks to improve the experience to customize/improve on top of this module. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#72123
Original PR description
Add some hooks and tweaks to improve the experience to customize/improve on top of this module. Info: @wt-io-it Forward-Port-Of: odoo/enterprise#72123
Following 81dce8461c7, when only some of the invoice lines have subscription start/end date, the commission generation crash when computing the maximum end date or minimal start start: ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` This commit ensure we only try to max/min non-falsy values. Forward-Port-Of: odoo/enterprise#74112
Original PR description
Following 81dce8461c7, when only some of the invoice lines have subscription start/end date, the commission generation crash when computing the maximum end date or minimal start start: ``` TypeError: '>' not supported between instances of 'bool' and 'datetime.date' ``` This commit ensure we only try to max/min non-falsy values. Forward-Port-Of: odoo/enterprise#74112
This commit drastically reduces the spreadsheet thumbnails size. Go to CRM lead and insert the pivot in a spreadsheet: The size of the thumbnail: | Description | Size | |-----------------------|--------| | Before | 107Kb | | After quality=0.5 | 7.8Kb | | After quality=0 | 2.9Kb | Image quality is indeed reduced, but the thumbnails are always displayed so small that it doesn't really make any difference to the naked eye. Note: I'm not back
Original PR description
This commit drastically reduces the spreadsheet thumbnails size. Go to CRM lead and insert the pivot in a spreadsheet: The size of the thumbnail: | Description | Size | |-----------------------|--------| | Before | 107Kb | | After quality=0.5 | 7.8Kb | | After quality=0 | 2.9Kb | Image quality is indeed reduced, but the thumbnails are always displayed so small that it doesn't really make any difference to the naked eye. Note: I'm not backporting this fix to 16.0 because the code changed and webp was not supported at the time (even though we could use jpeg) Task: 4337496 Forward-Port-Of: odoo/enterprise#73881
…or the general ledger In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date. We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger. task-4270453 Forward-Port-Of: odoo/enterprise#73719 Forward-Port-Of: odoo/enterprise#72673
Original PR description
…or the general ledger In a previous pull request: https://github.com/odoo/enterprise/pull/46498, the columns date was switched to invoice date. We want to revert back to the state before this commit. So using the accounting_date instead of the invoice_date on the general ledger. task-4270453 Forward-Port-Of: odoo/enterprise#73719 Forward-Port-Of: odoo/enterprise#72673
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore,
Original PR description
**Steps to reproduce the bug:** - Create a tracked product by SN: “P1.” - Create a storable product: "P2." - Create a receipt for one unit of P1 and P2. - Mark it as "To Do." - Set the done quantity of P1 to 0. - Attempt to perform the quality check. **Problem:** You must perform a quality check for P1 even though it has yet to be received. Since the move_line is set to 0 rather than deleted in the original picking, it will be linked to the backorder when it is created. Therefore, to avoid unexpected behavior we can ignore linking its quality check to the backorder. https://github.com/odoo/odoo/blob/00057f8efd3c728e13a981290a725878e058d2c6/addons/stock/models/stock_picking.py#L832 opw-4187521 Forward-Port-Of: odoo/enterprise#73823 Forward-Port-Of: odoo/enterprise#73407