Tuesday, January 7, 2025
37 changes · 18.0
Enhancements to existing features
The Israeli localization now loads Hebrew translations for tax account tag names such as VAT Sale and VAT Input. This improves compliance with local conventions and makes accounting labels clearer for Hebrew-speaking users.
Original PR description
Labels such as 'Vat Sale' or 'Vat Input' have to be translated for the israely conventions. Change: - Load the hebrew translation for the account tags name field in the try_loading function --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Kanban app cards now keep their action buttons aligned at the bottom, even when descriptions have different lengths. Description text is also easier to read thanks to improved line spacing, creating a more consistent and polished app list experience.
Original PR description
Before this commit, there was a misalignment issue with the buttons in the cards due to varying text lengths in the description. This caused the buttons to appear at different vertical positions, disrupting visual consistency. Now, the layout ensures that all buttons are aligned at the bottom of the cards regardless of the description length, and also the desc is a bit more readable with improved line spacing. | Before | After | |--------|--------| |  |  | task-4357026 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes an issue in the HTML editor where hidden collaborator avatars could still be selected and prevent users from moving content blocks. The change makes those avatars truly non-selectable when hidden, improving collaborative editing reliability.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: It was not possible to use the move node handler when the collaborator is on the same node, because the collaboration avatar is hidden using opacity 0 which still allowed the avatar to be selectable. Desired behavior after PR is merged: Hide the collaboration avatar using visibility hidden, ensuring it is not selectable. task-4348275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
On Virtual IoT Boxes, a landscape report was still printed in portrait. We added the argument required to handle landscape printing. opw-4081884 Forward-Port-Of: odoo/odoo#192634
Original PR description
On Virtual IoT Boxes, a landscape report was still printed in portrait. We added the argument required to handle landscape printing. opw-4081884 Forward-Port-Of: odoo/odoo#192634
Tests now keep Peppol in demo mode by default, so they use mocked behavior instead of contacting real or sandbox Peppol services. This makes automated testing safer and more reliable when Peppol is installed alongside other accounting modules.
Original PR description
Context: In Peppol, we have multiple EDI mode: - `production` that will call the real Peppol infrastructure, - `test` that will call the sandbox Peppol, - `demo` that makes no call at all, everything is mocked. By default, runbots and demo data are set to `demo`. In tests, the value is therefore also `demo`, which is what we want: No call to external services. Before this commit, we were doing some weird and useless override in the handling of demo functions, which is useless: if you want to test Odoo in a particular mode, just set it (this is what we do in Peppol tests' `setUpClass`), for all other tests, keeping the default demo mode should be preferred. This was a problem because tests ran by other modules with Peppol installed were trying to make external calls. task-no
Product margin reporting no longer triggers unnecessary database updates when grouping or aggregating product margin fields. This prevents misleading modification timestamps and reduces avoidable background work, without changing the reported business values.
Original PR description
When we aggregate one of the field of "product.product" introduced by 'product_margin' module, it will generate a SQL update on all records read. It is because we call the compute method manually without protecting computed fields, which will lead to call BaseModel.write() that update write_date/write_uid. Fix it by calling `compute_value` of one of the field. ### Notes - Should we backport it in 17.0 but then we need to backport https://github.com/odoo/odoo/pull/155585 too ? Also for the 16.0 ? - For master: remove the return of `_compute_product_margin_fields_values`, people shouldn't call that manually too avoid the issue mention in the commit message.
This update prevents the website editor from accidentally removing spaces between inline content and avoids errors when users outdent list items that contain only empty content. It helps make editing formatted text more reliable and reduces interruptions for users working with lists.
Original PR description
[FIX] html_editor: space removal by wrapInlinesInBlocks <- fix required for the following one [FIX] html_editor: outdent list item with empty nodes task-4398327
This fixes a point of sale issue where the product search bar disappeared after navigating back from the payment screen. Cashiers can now resume searching products immediately, reducing checkout friction.
Original PR description
Before this commit, when going back from the payment screen to the product screen, the search bar wasn't visible. opw-4318710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Importing a price list rule with only a product variant will now automatically fill in the related product template. This prevents imported rules from appearing incomplete or behaving unexpectedly, helping pricing data stay reliable.
Original PR description
Since recent changes to the pricelists rules, importing a rule with the 'Product Variant' field value specified but not the template field value led to incomplete rules not being displayed (and maybe not even behaving) as expected. This commit makes sure that if the template was forgotten in the create values, it's correctly deduced from the given product.product record. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adding rows or columns in the HTML editor no longer forces tables to adopt fixed widths or heights when they were originally flexible. This preserves the intended layout behavior and reduces unwanted formatting changes for users editing website or document content.
Original PR description
### Steps to reproduce: - Insert a table. - Observe the HTML, noticing that the table does not have a fixed width or height. - Insert a new column or row. - Observe the HTML, noticing that the width and/or height of the table has been fixed. ### Description of the issue/feature this PR addresses: - When a new column is inserted into the table, the table's width is fixed, and the widths of the first row/column cells (TDs and THs) are also fixed. - When a new row is inserted, the height is added to the table rows (TRs), even if the table initially did not have fixed dimensions. ### Desired behavior after PR is merged: - The width and height of the table will not be fixed when a new column or row is added, as long as the table did not have fixed dimensions (width/height) to begin with. task-4402552
This fixes demo mode for Peppol electronic invoicing after a previous internal change left some connection calls using an outdated path. Demo environments should no longer hit errors when testing Peppol flows, making demonstrations and trials more reliable.
Original PR description
With previous refactor, we simplified the demo mode by trying to mock the fewer methods possible. In particular, we are aligning all calls to proxy to go through the `_call_peppol_proxy(...)`. This should simplify future refactoring work to get rid of account_edi_x models. Some calls to make_request were still existing, since it's no longer mocked in demo mode, an error is raised. Replace all those calls to use the `_call_peppol_proxy` method. task-no
This fix makes automated website tours wait until popup windows are fully displayed before continuing. It reduces false test failures caused by tours trying to interact with popup content too early, improving reliability for event, forum, and newsletter website flows.
Original PR description
In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it. This fix add classes to ensure modal is shown before continuing the tour. 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 ensures Danish businesses using the 0184 identifier scheme send the VAT number in the format required by PEPPOL rules. It helps prevent electronic invoices from being rejected due to non-compliant company identifiers.
Original PR description
Based on PEPPOL-COMMON-R042 (https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-peppol/PEPPOL-COMMON-R042/) when using the 0184 scheme the VAT number should be used (CVR number prefixed by the country code) @JulienVR @smetl --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix ensures that when users create a new bank statement from the transaction list and enter a custom name, Odoo keeps that name instead of replacing it automatically. It prevents confusion and rework during bank reconciliation workflows.
Original PR description
Step to reproduce * open the reconcilation widget and toggle the list view * multi edit bank statement lines and assign them a new bank statement with name 'BLABLA 1' * click save and see how Odoo just didn't keep your name at all The reason is that during the initial creation of the statement, a value is given to end_date which triggers to recomputation of the name, regardless of if the statement already had a name or not. So to fix that, we simply only try to compute the name for statements that don't have one yet ticket-4424021 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users create warehouse transfers from the Project topbar, Odoo now preselects the appropriate transfer type based on their default warehouse. This prevents extra manual setup and reduces the chance of creating transfers with missing information.
Original PR description
Steps to reproduce: - Set default Warehouse in the profile. - From Project topbar open either "From WH" or "To WH". - Create a new stock picking Issue: - The stock picking type is not set by default Reason: - Non existence of supplied values. Solution: - Supply default picking type if user has a default warehouse. task-4207753
Creating an analytic account from a project now uses the project's company by default instead of the user's current company. This prevents company mismatches when projects have no company or belong to a different company, reducing accounting inconsistencies.
Original PR description
Before this commit, when creating a new analytic account in any plan from the project form, the default company of the account was set to the current company of the user. The problem that arises is when the project has no company, and the account is set to a company. Which creates inconsistency between the project and the account. After this commit, we set the company of the created account to the company of the project by default. task-4438410 version-18.0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents Odoo from reloading the same view unnecessarily when users schedule activities from different contact cards. It reduces avoidable background requests, making the interface more efficient and potentially more responsive.
Original PR description
Steps to reproduce (a bit technical): 1. Navigate to the "Contacts" kanban view. 2. Open the Network tab in the browser's developer tools. 3. Click on the first contact activities and "Schedule a new…
Steps to reproduce (a bit technical): 1. Navigate to the "Contacts" kanban view. 2. Open the Network tab in the browser's developer tools. 3. Click on the first contact activities and "Schedule a new activity". 4. Notice a call to `get_views` in the Network tab. 5. Click on a different contact activities, and "Schedule a new activity". 6. Notice a new call to `get_views` in the Network tab. Expected: The view is already cached, so the webclient should not attempt to load it. Explanation: This is likely a regression since f983703d, when the embedded actions were introduced. Now, the `embeddedParentResId` is part of the views cache key, and so we get much fewer cache hits. For most views, there isn't really an `embeddedActionId` set, and yet the `embeddedParentResId` was always set. The later is only used in combination with `embeddedActionId`, so it causes a lot of avoidable cache misses. The solution is to simply set the `embeddedParentResId` only if there's an `embeddedActionId`. Closes odoo/odoo#192261 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
The guided website helpdesk forum flow now waits until pop-up windows are fully ready before continuing. This helps prevent intermittent failures in automated checks, making releases more stable without changing the customer-facing experience.
Original PR description
In this commit, we wait the modal is shown (managed by jQuery) before to continue the tour. In these modals, if we don't wait for the modal is shown, as the tour engine can be too much fast, element in modal can be not focusable when we try to target it.
In odoo/addons/website/static/src/js/content/website_root.js the class modal_show is added in _onModalShown:
```javascript
_onModalShown: function (ev) {
$(ev.target).addClass('modal_shown');
},
```
This fix add classes in triggers to ensure modal is shown before continuing the tour.This fix prevents an error when creating a Mexican global invoice from a draft invoice that has no assigned number yet. Users now avoid a blocking crash and can receive the intended validation message instead.
Original PR description
When a customer creates a global invoice, a traceback will appear. Steps to reproduce the error: - Install ``l10n_mx_edi`` module > Switch to Mexican company - Create an invoice without customer and…
When a customer creates a global invoice, a traceback will appear.
Steps to reproduce the error:
- Install ``l10n_mx_edi`` module > Switch to Mexican company
- Create an invoice without customer and product > Save
- Go back to List view of invoices
- Select that invoice > Actions > Create Global Invoice
Traceback:
```
File "home/odoo/src/enterprise/18.0/l10n_mx_edi/wizard/l10n_mx_edi_global_invoice_create.py", line 23, in default_get
invoices = source_invoices._l10n_mx_edi_check_invoices_for_global_invoice()
File "home/odoo/src/enterprise/18.0/l10n_mx_edi/models/account_move.py", line 306, in _l10n_mx_edi_check_invoices_for_global_invoice
invoices_str = ", ".join(failed_invoices.mapped('name'))
TypeError: sequence item 0: expected str instance, bool found
```
https://github.com/odoo/enterprise/blob/01f749f40fc4b5f9708696dc42eab7125e790b28/l10n_mx_edi/models/account_move.py#L306 When a customer creates a new invoice, ``name`` will be False,
When the customer tries to create global invoice,
So it will lead to the above traceback.
sentry-6197401330STEPS ----------- 1. Install Contact and 'base_vat' 2. Create a new Indonasian contact with VAT as ID1234567890123456 3. Save -> Connot save whilst the VAT is correct PROBLEM ----------- VAT could be 15 (old numbers) or 16 digits. If there are 15 digits long, the 10th digit is a luhn checksum. In some cases, the 15 digits can be transformed into a 16-digit by adding a 0 in front. In such case, we can verify the luhn checksum like for the 15 digits by removing the 0. However, for newl
Original PR description
STEPS ----------- 1. Install Contact and 'base_vat' 2. Create a new Indonasian contact with VAT as ID1234567890123456 3. Save -> Connot save whilst the VAT is correct PROBLEM ----------- VAT could be 15 (old numbers) or 16 digits. If there are 15 digits long, the 10th digit is a luhn checksum. In some cases, the 15 digits can be transformed into a 16-digit by adding a 0 in front. In such case, we can verify the luhn checksum like for the 15 digits by removing the 0. However, for newly created VAT 16-digits VAT number, there is no checksum. SOLUTION ----------- Allow 16-digit VAT that only contains numbers and does not start with a 0. opw-4402514 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192543
Before this commit, if you made a product available in PoS but set it to not be available in self order, it would still appear in the kiosk or mobile menu with an "out of stock" tag, which is confusing and not the expected behavior. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188663
Original PR description
Before this commit, if you made a product available in PoS but set it to not be available in self order, it would still appear in the kiosk or mobile menu with an "out of stock" tag, which is confusing and not the expected behavior. opw-4200540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#188663
**Issue:** When converting a PDF file into a PDF/A compliant file, the result may generate the following error message when parsing it by a PDF/A-3 validator: `The aforementioned EOL marker shall be immediately followed by a % (25h) character followed by at least four bytes, each of whose encoded byte values shall have a decimal value greater than 127 ` **Cause:** A previous fix has moved the four bytes in a conditional operation, but the `%` character has been forgotten. opw-4353108
Original PR description
**Issue:** When converting a PDF file into a PDF/A compliant file, the result may generate the following error message when parsing it by a PDF/A-3 validator: `The aforementioned EOL marker shall be immediately followed by a % (25h) character followed by at least four bytes, each of whose encoded byte values shall have a decimal value greater than 127 ` **Cause:** A previous fix has moved the four bytes in a conditional operation, but the `%` character has been forgotten. opw-4353108 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191326
Steps to reproduce: - Configure a kiosk to have multiple languages - Observe that the language can be changed in the kiosk UI as expected - Install the website module, and configure the website's languages to not include one of the kiosk languages - For example, kiosk has EN and FR, website just has EN - Observe that the language can no longer be changed in the kiosk opw-4403828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-O
Original PR description
Steps to reproduce: - Configure a kiosk to have multiple languages - Observe that the language can be changed in the kiosk UI as expected - Install the website module, and configure the website's languages to not include one of the kiosk languages - For example, kiosk has EN and FR, website just has EN - Observe that the language can no longer be changed in the kiosk opw-4403828 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191817 Forward-Port-Of: odoo/odoo#191137
Before this commit, if you validated an order while offline and then synced the order when back online, the post-process loyalty actions would not occur, resulting in data not being updated on the server. opw-4290171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187238
Original PR description
Before this commit, if you validated an order while offline and then synced the order when back online, the post-process loyalty actions would not occur, resulting in data not being updated on the server. opw-4290171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#187238
In Panama, the Tax ID is the Registro Único de Contribuyentes (RUC) and not the Número de Identificación Fiscal (NIF). This is a double fix: 1. Update the `vat_label` to use "RUC" instead of "Tax ID", but this will only be available for new created DBs (because of noupdate) 2. Update the translation of Tax ID for Panama which only requires to update the translations to have the correct translation of Tax ID. opw-4388758 Forward-Port-Of: odoo/odoo#192514
Original PR description
In Panama, the Tax ID is the Registro Único de Contribuyentes (RUC) and not the Número de Identificación Fiscal (NIF). This is a double fix: 1. Update the `vat_label` to use "RUC" instead of "Tax ID", but this will only be available for new created DBs (because of noupdate) 2. Update the translation of Tax ID for Panama which only requires to update the translations to have the correct translation of Tax ID. opw-4388758 Forward-Port-Of: odoo/odoo#192514
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the `can_image_1024_be_zoomed` field 3. Change the image and save The product will be updated, but this error will be thrown: ``` binascii.Error: Incorrect padding ``` **CAUSE** https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/product/models/product_tem
Original PR description
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the…
Changing a product template's image with the `can_image_1024_be_zoomed` field present in the view produces a crash on save. **STEPS TO REPRODUCE** 1. Open a product form view 2. Using studio, add the `can_image_1024_be_zoomed` field 3. Change the image and save The product will be updated, but this error will be thrown: ``` binascii.Error: Incorrect padding ``` **CAUSE** https://github.com/odoo/odoo/blob/a74684777c27e26639b75b0668bb15afadb78c4f/addons/product/models/product_template.py#L186-L188 In the `RecordSet`'s context, `bin_size=True`, so accessing `image_<size>` returns a size instead of a binary. `_compute_can_image_1024_be_zoomed` calls `tools.is_image_size_above` with this binary size, while the method expects the full base64 encoded image. Ultimately, this causes `base64.b64decode` to crash with the above error. **FIX** Update the `RecordSet`'s context to `bin_size=False`. Accessing `image_<size>` from the `RecordSet` will then return the full binary instead of the size. **NOTES** In versions <17.0, read and write were done in separate network calls causing the recompute to happen during the flush of the write, which doesn't have `bin_size=True` in the context. Because the field is stored, the read will not cause a recompute and thus avoids any error. In >=17.0, because the read occurs before the flush, and the write has invalidated the field, the recompute will occur with the context of the read (`bin_size=True`), causing the issue. opw-4413647 Forward-Port-Of: odoo/odoo#192409 Forward-Port-Of: odoo/odoo#192047
In 862ede43e5910ae6954f3574f45c213e5d3a1886 the added test depended on being in year 2024, so it failed in eg. 2025. With this change we don't harcode the invoice name in assert data. runbot-error-111390 opw-4050777 Forward-Port-Of: odoo/odoo#192451 Forward-Port-Of: odoo/odoo#192192
Original PR description
In 862ede43e5910ae6954f3574f45c213e5d3a1886 the added test depended on being in year 2024, so it failed in eg. 2025. With this change we don't harcode the invoice name in assert data. runbot-error-111390 opw-4050777 Forward-Port-Of: odoo/odoo#192451 Forward-Port-Of: odoo/odoo#192192
Purpose of this PR: Enhance the UI styling to address issues caused by the absence of the `o_livechat_no_rating` and `o_livechat_operator_avatar` classes,might removed by other PR's. before:  after:  --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: o
Original PR description
Purpose of this PR: Enhance the UI styling to address issues caused by the absence of the `o_livechat_no_rating` and `o_livechat_operator_avatar` classes,might removed by other PR's. 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#188754
Before this commit, adding lot tracked products would result in an error because the picking type was not loaded in self ordering. opw-4439558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192351
Original PR description
Before this commit, adding lot tracked products would result in an error because the picking type was not loaded in self ordering. opw-4439558 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192351
Description of the issue/feature this PR addresses: - for model 'pos.pack.operation.lot', `id` is the [identifier](https://github.com/odoo/odoo/blob/18.0/addons/point_of_sale/static/src/app/models/data_service_options.js#L21) but `setPackLotLines` method [uses](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/models/pos_order_line.js#L144) `uuid`, making operation weird and faulty. - As `eg: lotline.uuid => undefined` - This pr attempts to fix the issue lin
Original PR description
Description of the issue/feature this PR addresses: - for model 'pos.pack.operation.lot', `id` is the…
Description of the issue/feature this PR addresses:
- for model 'pos.pack.operation.lot', `id` is the [identifier](https://github.com/odoo/odoo/blob/18.0/addons/point_of_sale/static/src/app/models/data_service_options.js#L21) but `setPackLotLines` method [uses](https://github.com/odoo/odoo/blob/saas-17.4/addons/point_of_sale/static/src/app/models/pos_order_line.js#L144) `uuid`, making operation weird and faulty.
- As `eg: lotline.uuid => undefined`
- This pr attempts to fix the issue linked with modifying orderlines with sn/lots
Steps to reproduce considering [this diff](https://github.com/odoo/odoo/pull/187796/files#diff-3bfb78fa74ffa64630e11266674f185a18e3c97587590b4b55da6388cb8ba487R148) :
- Open POS.
- Add a products which is tracked by sn and add two sn
- removing the last sn, will remove all sn from orderline
Note: this pr would make more sense if [this pr](https://github.com/odoo/odoo/pull/187796) is backporterd to saas-17.4,
as there is an oversight in replacing all `uuid` references to `id` the mentioned commit. [see](https://github.com/odoo/odoo/pull/187796/files#diff-3bfb78fa74ffa64630e11266674f185a18e3c97587590b4b55da6388cb8ba487R148)
Also, root issue was in saas-17.4, while a fix was made in v18.0
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#188203Problem --------- Currently, powerpoints attachments received by a mail alias are deleted. We want to allow them. Solution --------- Add the relevant mimetypes to the white list. no-task no-opw --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192221
Original PR description
Problem --------- Currently, powerpoints attachments received by a mail alias are deleted. We want to allow them. Solution --------- Add the relevant mimetypes to the white list. no-task no-opw --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192221
**Problem**: When deleting columns in the editor, if the start and end points of the selection are inside the columns, the `range.extractContents` method extracts the content but leaves behind `div` elements for the first and last columns (or sometimes only one of them). This occurs because the columns are partially selected (content but not container). **Solution**: To ensure `range.extractContents` removes the columns completely, extend the selection to encompass the entire content of the
Original PR description
**Problem**: When deleting columns in the editor, if the start and end points of the selection are inside the columns, the `range.extractContents` method extracts the content but leaves behind `div`…
**Problem**: When deleting columns in the editor, if the start and end points of the selection are inside the columns, the `range.extractContents` method extracts the content but leaves behind `div` elements for the first and last columns (or sometimes only one of them). This occurs because the columns are partially selected (content but not container). **Solution**: To ensure `range.extractContents` removes the columns completely, extend the selection to encompass the entire content of the `o_text_columns` element when the selection starts at the first leaf and ends at the last leaf within the columns. **Steps to reproduce**: 1. Open the editor. 2. Create columns (any number). 3. Select all content (e.g., with `Ctrl+A`). 4. Press `Backspace` to delete the content. 5. Observe that the DOM still contains `o_text_columns` and `row` elements, even though the content appears deleted. opw-4350486 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#191671 Forward-Port-Of: odoo/odoo#189978
Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix th
Original PR description
Steps to reproduce: - Install hr_timesheet (with demo data) - Navigate to portal > timesheet - Group by project Issue: When only the hr_timesheet module is installed and timesheets are grouped in the portal view, the column alignment is broken due to an incorrect colspan. Cause: When groupby is applied, the colspan is manually set to 4, causing misalignment between the header and row columns. Fix: This commit sets the last column's colspan to 2 when grouping is applied to fix the alignment issue. task-4294780 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192201 Forward-Port-Of: odoo/odoo#186532
Issue: In Czech Republic, the rate of the 15% tax has changed to 12%. The new rate has already been handled in l10n_cz, but the OSS mapping still uses the old rate. opw-4310264 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192458
Original PR description
Issue: In Czech Republic, the rate of the 15% tax has changed to 12%. The new rate has already been handled in l10n_cz, but the OSS mapping still uses the old rate. opw-4310264 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192458
When the scale precision is half or quarter, the number of grid columns is this.columnCount * this.model.metaData.scale.cellPart + 1 and not this.columnCount + 1 as was assumed in aggregatePills. This led to a bad computation of aggregates in columns sufficiently far on the right of the gantt view in precision half or quarter. Note that this error was not detected before because many gantt views do not use that precisions or split groups anyway (via shouldMergeGroups). Forward-Port-Of: odoo/en
Original PR description
When the scale precision is half or quarter, the number of grid columns is this.columnCount * this.model.metaData.scale.cellPart + 1 and not this.columnCount + 1 as was assumed in aggregatePills. This led to a bad computation of aggregates in columns sufficiently far on the right of the gantt view in precision half or quarter. Note that this error was not detected before because many gantt views do not use that precisions or split groups anyway (via shouldMergeGroups). Forward-Port-Of: odoo/enterprise#76610
task-4418589 Forward-Port-Of: odoo/enterprise#76089
Original PR description
task-4418589 Forward-Port-Of: odoo/enterprise#76089
Before this PR: - The bill type was determined based only on whether the section code was 'cdnr'. This resulted in all documents under this section being classified as credit notes, regardless of their actual type. After this PR: - The bill type is now determined by checking both the section code and the document type. If the section code is 'cdnr' and the document type is 'C', the bill is classified as a credit note. Otherwise, it defaults to a regular bill or debit note as applicable.
Original PR description
Before this PR:
- The bill type was determined based only on whether the section code was 'cdnr'. This resulted in all documents under this section being classified as credit notes, regardless of their actual type.
After this PR:
- The bill type is now determined by checking both the section code and the document type. If the section code is 'cdnr' and the document type is 'C', the bill is classified as a credit note. Otherwise, it defaults to a regular bill or debit note as applicable.
Why:
- This change ensures accurate classification of documents under the 'cdnr' section, distinguishing between credit notes ('C') and debit notes ('D').
Forward-Port-Of: odoo/enterprise#76427