Saturday, February 22, 2025
7 changes · saas-18.1
Miscellaneous changes
This PR adds the migration system previously implemented in Knowledge to update embedded components inside the html field/viewer, see odoo/enterprise@0df669159aaa1a9631ab12a68758bf78954071f7. It also makes use of it to replace excalidraw embedded components by normal links. task-4489076 Forward-Port-Of: odoo/odoo#194066
Original PR description
This PR adds the migration system previously implemented in Knowledge to update embedded components inside the html field/viewer, see odoo/enterprise@0df669159aaa1a9631ab12a68758bf78954071f7. It also makes use of it to replace excalidraw embedded components by normal links. task-4489076 Forward-Port-Of: odoo/odoo#194066
**Steps to reproduce:** - Install Accounting - Go to Accounting dashboard - Make sure that one journal has more action links than the other ones of the same row **Issue:** There is an offset between the bottom border of the kanban card and the graph that depends on the difference between the number of action links in the current card and the higher number of action links in a card on the same row.  **Cause:** The view has been refactored in version 18.0 and some css has been lost in the process. opw-4473451 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198106
**Problem**: When the selection is empty (`anchorNode` and `focusNode` are `null`), calling `getRangeAt(0)` results in an error in Firefox. **Solution**: Properly check for an empty selection before accessing the range. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198807
Original PR description
**Problem**: When the selection is empty (`anchorNode` and `focusNode` are `null`), calling `getRangeAt(0)` results in an error in Firefox. **Solution**: Properly check for an empty selection before accessing the range. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198807
**Problem**: After introducing `baseContainer`, the default `baseContainer` is `div`. To correctly update the selection to the banner, we need to update the selector to use the default baseContainer instead of hardcoding `p`. **Solution**: Modify the selector to use the default baseContainer for banner selection updates instead of `.o_editor_banner > div > p` **Steps to Reproduce**: 1. Type `/banner`. 2. Press Enter on any banner. 3. Traceback occurs. --- I confirm I have signe
Original PR description
**Problem**: After introducing `baseContainer`, the default `baseContainer` is `div`. To correctly update the selection to the banner, we need to update the selector to use the default baseContainer instead of hardcoding `p`. **Solution**: Modify the selector to use the default baseContainer for banner selection updates instead of `.o_editor_banner > div > p` **Steps to Reproduce**: 1. Type `/banner`. 2. Press Enter on any banner. 3. Traceback occurs. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197798
When using JSONB for company-dependent many2one fields, references to non-existing records in the comodel can lead to MissingError. This commit introduces validation during fetch and comparison by taking advantage of index-only scan to ensure that referenced records exist. 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
Original PR description
When using JSONB for company-dependent many2one fields, references to non-existing records in the comodel can lead to MissingError. This commit introduces validation during fetch and comparison by taking advantage of index-only scan to ensure that referenced records exist. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#198057
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This com
Original PR description
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the…
Before this commit, the invoice cancelled with payment state set to "Invoicing App Legacy" is actually not really cancelled, it seems to just be a way to create accounting entry. However, the timesheets are considered as not billed if there is no invoice linked to them or if the invoice is cancelled (that is, if the state is set to "Cancelled"), which means, if the invoice is in "legacy status", the timesheets could move in a new invoice since those ones are considered as not billed. This commit adds a condition to determine to know if a timesheet is not billed. The timesheet should now be: - not linked to an invoice - or the invoice linked should be cancelled and payment status should not be "Invoicing App Legacy". Steps to reproduce the issue: ---------------------------- 1. install Accounting, Sales and Timesheets app 2. Create a SO with a service product and confirm the SO 3. Create a timesheet for the SOL contained the service product 4. Create a invoice to partially invoice the service made for the SO. 5. Go to "Accounting app > Settings" 6. Enable the "Invoicing Switch Threshold" feature and make sure the date set on that feature is most recent than the one set on the invoice created in step 4. By doing that, the invoice created in step 4 should now be cancelled but with payment status set to "Invoicing App Legacy". 7. Create another timesheet for the same SOL 8. Go back to the SO created in step 2 and create another invoice to invoice the another timesheet. Current behavior: ---------------- The timesheet linked to the first invoice is now linked to the second one with the other timesheet. Expected behavior: ------------------ Since the first invoice is not really cancelled, the timesheet should still be linked to the invoice and so that timesheet should be considered as billed. opw-4556956 Forward-Port-Of: odoo/odoo#198669 Forward-Port-Of: odoo/odoo#198277
This commit moves the html_field migration system to the standard. See implementation in 0df669159aaa1a9631ab12a68758bf78954071f7. Removing the Excalidraw command means that the html migration system must be moved to `html_editor`. This commit thus removes the sytem from Knowledge and adapts the manifests to take into account the move done, and updates a test to account for the new html editor version (1.1). task-4489076 Forward-Port-Of: odoo/enterprise#77321
Original PR description
This commit moves the html_field migration system to the standard. See implementation in 0df669159aaa1a9631ab12a68758bf78954071f7. Removing the Excalidraw command means that the html migration system must be moved to `html_editor`. This commit thus removes the sytem from Knowledge and adapts the manifests to take into account the move done, and updates a test to account for the new html editor version (1.1). task-4489076 Forward-Port-Of: odoo/enterprise#77321