Wednesday, July 24, 2024
28 changes · saas-17.1
Resolved issues and error corrections
This update brings the spreadsheet component to its latest version and fixes an issue where cell A1 appeared hovered by default. Users should see more accurate visual feedback when working in spreadsheets.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/0edff474d [REL] 17.1.25 Task: 0 https://github.com/odoo/o-spreadsheet/commit/aa5f544f1 [FIX] grid_overlay: A1 is hovered by default Task: 4042621 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>
Miscellaneous changes
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit
Original PR description
Before this PR, when selecting a new date in a date(time)_field, the value would first be reset before performing the "onchange" call, resulting in a flicker (selected value -> null -> new value after onchange). Now, the value is not reset and is simply left as selected when performing the onchange call, as to not trigger any flicker. Part of task [3471424](https://www.odoo.com/odoo/333/tasks/3471424) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174326
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Original PR description
Some fields related to Italian invoicing are included in XML but missing from the invoice PDF. Added these fields to report_invoice for users to have more visibility for what's included in the XML submitted to Sdl. Task [link](https://www.odoo.com/odoo/project.task/3794551) task-3794551 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168447
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. Current behavior before PR:  Desired behavior after PR is merged:  --- I confirm I have signed the CLA and read the PR guidelines at ww
Original PR description
Description of the issue/feature this PR addresses: This PR fixes the incorrect styling applied by the css when reporting the client_order_ref field. 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#172741 Forward-Port-Of: odoo/odoo#172366
Current behavior before PR: I. Inserting text into an empty paragraph tag with a `br` does not remove the `br`. II. When pasting single or multiple block elements the start and end block would unwrap causing inconsistency while pasting. III. Unwrapping the firstChild and the lastChild when pasting empty blocks resulted in the addition of br's to the block. Desired behavior after PR is merged: I. Inserting text into an empty node with a `br` should result in the removal of that `br`
Original PR description
Current behavior before PR: I. Inserting text into an empty paragraph tag with a `br` does not remove the `br`. II. When pasting single or multiple block elements the start and end block would unwrap causing inconsistency while pasting. III. Unwrapping the firstChild and the lastChild when pasting empty blocks resulted in the addition of br's to the block. Desired behavior after PR is merged: I. Inserting text into an empty node with a `br` should result in the removal of that `br`. II. Make sure if the node to start or end with is the same node we want to paste into; unwrap it, otherwise split the node. III. Empty blocks are no longer unwrapped when pasting. IV. This PR also addresses issues with testcases that includes `p` tag without a `br`. task-3630662 Forward-Port-Of: odoo/odoo#173890 Forward-Port-Of: odoo/odoo#160345
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817 Forward-Port-Of: odoo/odoo#174259
Original PR description
[REV] project: set default value of analytic plan in the project config setting This reverts commit https://github.com/odoo/odoo/commit/a2c51c6ad9ae80e6d4edc5de96811edd56df7a7c because the `analytic.project_plan` should not be altered since that field is used to find the column auto-generated in `account.analytic.line` model by `analytic.plan`. opw-4051817 Forward-Port-Of: odoo/odoo#174259
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed
Original PR description
To replicate the issue: - Go to the partner page of the current company (Invoicing > Customers > Customers > Look for the company) - Change type from Company to Individual - Create and post an invoice - Click on Send & Print. Download the Facturae - NAME should appear in line 30, before AddressInSpain, but it doesn't Cause of the issue: The template values do not include a value for self_party_name, only for other_party_name. In the template, when partner_name is set, no value is passed for self_party. Fix: Instead of only extracting the partner name for partner (other_party), the code is used in a new function, which can be called for both partner and company (self_party). Then, self_party_name can be used as a value in the template. opw-4053023 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173608
If for some reason you want to apply taxes on the gift card reward, they were not correctly applied. Steps to reproduce: ------------------- * Create a gift card program * Find the gift card reward product in the program * Add some taxes to it * Open a PoS session, add some product and use a gift card > Observation: The tax on the gift card product is not taken into account Why the fix: ------------ When generating the gift card we force all taxes to be included in price this wa
Original PR description
If for some reason you want to apply taxes on the gift card reward, they were not correctly applied. Steps to reproduce: ------------------- * Create a gift card program * Find the gift card reward product in the program * Add some taxes to it * Open a PoS session, add some product and use a gift card > Observation: The tax on the gift card product is not taken into account Why the fix: ------------ When generating the gift card we force all taxes to be included in price this way the value of the gift card is not modified, but the taxes are applied opw-3916989 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173412 Forward-Port-Of: odoo/odoo#170590
Before this commit, search results for chats and channels on mobile show up in uppercase. This happens because of the class `text-uppercase` on a parent element. This commit fixes the issue by removing said class on the parent element. Before:  After:  Forward-Port-Of: odoo/odoo#174224
Original PR description
Before this commit, search results for chats and channels on mobile show up in uppercase. This happens because of the class `text-uppercase` on a parent element. This commit fixes the issue by removing said class on the parent element. Before:  After:  Forward-Port-Of: odoo/odoo#174224
Versions: --------- - 16.0 Steps to reproduce: ------------------- - go to the planning calendar. - hover over a record in the sidebar of the calendar, and then - click on "Shifts" in the calendar entries. Issue: ------ 1. the size of the popover enlarges when the content of the field is large, and the child element does not inherit the width of its parent elements. 2. The size of the popover becomes larger when hovering over the calendar filter tooltip. Cause: ------ Th
Original PR description
Versions: --------- - 16.0 Steps to reproduce: ------------------- - go to the planning calendar. - hover over a record in the sidebar of the calendar, and then - click on "Shifts" in the calendar entries. Issue: ------ 1. the size of the popover enlarges when the content of the field is large, and the child element does not inherit the width of its parent elements. 2. The size of the popover becomes larger when hovering over the calendar filter tooltip. Cause: ------ The popover title is taking up the full 100% width. Additionally, the popover title and body expand in response to the content of the fields, causing the popover size to become larger. Solution: --------- Setting a maximum width and enabling text truncation will make it appear more visually appealing. Additionally, set a maximum width of 25% and enable text truncation." **task-3446307** Forward-Port-Of: odoo/odoo#173203 Forward-Port-Of: odoo/odoo#138336
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by creating these single records are displayed which is confusing. Steps to Reproduce ----- 1. In Accounting > Configuration > Accounting > Chart of Accounts, create an account with the type "Off-Balanced Sheet" 2. On the same page, import a Chart of Account (import journal items
Original PR description
Summary ----- In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately. Only the errors caught by…
Summary
-----
In the method load in models.py, when there is an error when we try to create a recordset with at least 2 records, we try to create each record separately.
Only the errors caught by creating these single records are displayed which is confusing.
Steps to Reproduce
-----
1. In Accounting > Configuration > Accounting > Chart of
Accounts, create an account with the type "Off-Balanced Sheet"
2. On the same page, import a Chart of Account (import journal
items) by uploading a file which contains the following lines
(example available on the ticket):
[
['move_id','account_id','balance' 'journal_id','date'],
[<move_name>,<account_code_1>,1,<journal_name>,2021-01-01],
[<move_name>,<account_code_2>,-1,<journal_name>,2021-01-01]
]
such that:
- move_name cannot exist
account_code_1 is the code of the created account at
first step
account_code_2 is not the code of an account with the
type "Off-Balanced Sheet"
- journal_name is the name of an existing journal
3. Test or import the uploaded file and see the error which does
not mention the "Off-Balanced Sheet" account.
Cause
-----
If a journal entry contains a line with an "Off
Balanced Sheet" account, then all the other lines must have an account with the same type.
So when we try to load the lines of the uploaded file, it raises a UserError which is caught (which is not added to the list 'messages'). Then we try to create the lines one by one which and that raises an error too because the balance is not null.
Only these errors are added to the list 'messages' which contains the displayed error messages.
Fix
-----
Add the first error to 'message', and ensure that the next errors are not already in 'messages'.
opw-3945687
Forward-Port-Of: odoo/odoo#169083**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle sim
Original PR description
**Current behavior before PR:** When initiating searches quickly in discuss channels or chatter, overlapping requests can occur before previous searches finish. This race condition leads to errors and causes issues with destructuring properties like count, loadMore, and messages.( see: [Discuss](https://www.awesomescreenshot.com/video/29801496?key=44057f8e37a2f394f20e8fc790f80537)) **Desired behavior after PR is merged:** This commit updates the `useMessageSearch` hook to handle simultaneous requests more robustly by checking that search results are defined before processing them. This prevents errors and improves stability during rapid searches. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174174
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Original PR description
- Changed pos_display background to follow odoo 17's default one, updated all colors/logo to fit, - Moved error message to console as it's almost never relevant to users, - Added hostname on top of the page. Task: 3947355 Forward-Port-Of: odoo/odoo#174169
Pre-authorized debit payments in Canada are using Automated Clearing Settlement System (ACSS), which our current integration does not support. opw-4012861 Forward-Port-Of: odoo/odoo#173587
Original PR description
Pre-authorized debit payments in Canada are using Automated Clearing Settlement System (ACSS), which our current integration does not support. opw-4012861 Forward-Port-Of: odoo/odoo#173587
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
Original PR description
Allow customization to retrieve the user used to authenticate by adding the user attribute. opw-4059147 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174208
**Steps:** - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. **Cause:** - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. **Fix:** - Raise user
Original PR description
**Steps:** - Create a new Discount and loyalty program. - Keep the program type as Buy X Get Y / any other program - In the rewards pop-up, leave the 'description on the product' empty and click on 'save & close'. - Try to save the loyalty program. Validation error appears. **Cause:** - This occurs because the description is used to set the name of the discount product, but if it's empty, the write method will not get the proper values hence resulting in error. **Fix:** - Raise user error if the description field is set to empty. **Affected Version:** 16.0 - saas~17.4 **opw**-4032798 Forward-Port-Of: odoo/odoo#173789
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and en
Original PR description
In the POS Restaurant module, there was an issue where an order could be missed in the backend if a draft order, opened by a cashier on one device, was paid for on another device. Subsequently, if the cashier added more products to the order and completed the payment, the receipt would be printed, but the backend would fail to record the updated order. This fix ensures that an updated order with the same reference is captured in the backend if its content has changed, preventing data loss and ensuring consistency across devices. opw-4067875 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#174200
In its override of res_partner, the module introduces 2 new stored compute fields, which trigger a slow recompute at install time. Since those computations need to happen at some point to ensure that the module is working properly, changing the compute method was not an option. The changes proposed in this commit bypass the compute during the installation, leading to more reasonable install times (from an estimated 59 days down to about 1 min in our encountered case). A notable caveat i
Original PR description
In its override of res_partner, the module introduces 2 new stored compute fields, which trigger a slow recompute at install time. Since those computations need to happen at some point to ensure that the module is working properly, changing the compute method was not an option. The changes proposed in this commit bypass the compute during the installation, leading to more reasonable install times (from an estimated 59 days down to about 1 min in our encountered case). A notable caveat is that the users will have to trigger this computation manually record by record or in small batches. For smaller DBs, this shouldn't be an issue. For larger DBs, since the alternative is to not use the module at all or start from scratch with a new DB, the proposed solution seems acceptable. opw-4027267 Forward-Port-Of: odoo/odoo#172914
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "Save Template" button 4. Give a name for the new template => The modal title changes from "Compose Email" to "Odoo" TO
Original PR description
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the…
In the mail composer, the title of the modal changes to "Odoo" when the user clicks on the "Save Template" button. This commit will ensure that the modal will keep the title "Compose email" after the user clicks on the button. Steps to reproduce the issue: 1. Open a lead from the CRM module 2. Open the mail composer from the chatter 3. In the composer, click on the "Save Template" button 4. Give a name for the new template => The modal title changes from "Compose Email" to "Odoo" TO BE: The modal title should display "Compose Email" after creating the template. After creating the template, the system re-opens the composer by executing a dynamic action. This action does not specify any title. As a result, the modal fallbacks to the default title "Odoo" after executing the action. To fix the issue, we will simply set a name to the dynamic action. task-3748652 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#173135 Forward-Port-Of: odoo/odoo#172765
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly
Original PR description
This commit adds the missing neutralization necessary for the l10n_ro_efactura module introduced in [1] The purpose of the standard neutralization framework is to allow us to create database copies that will not interact with external systems in ways that could impact the production database (or if it is not possible to prevent the interactions, make sure that they are benign or won't result in actual changes), or impact the customers of the operator of the production database. This is mainly useful to allow safe support investigation on database duplicates. [1] https://github.com/odoo/odoo/pull/144061 Forward-Port-Of: odoo/odoo#174013
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterpr
Original PR description
[IMP] l10n_cz: Fill accounting date with 'taxable_supply_date' In CZ, they need to use the taxable supply date as accounting date and rely on it when we are calculating the currency rate 1- Set default value for 'taxable_supply_date' as the invoice date and allow the user to modify it. Also, fill the accounting date but using the taxable supply date as reference in place of invoice date. 2- Use taxable_supply_date/accounting date to compute the currency rate task-id#3983749 enterprise-pr: https://github.com/odoo/enterprise/pull/67149 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168933
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount
Original PR description
Steps: - Create group tax (20%) and add two tax in it (10% each) with Tax included true. - Create product with 100 price and and set that 20% tax on it. - Create coupon program with 90 amount on order and generate coupon. - Create SO and add SOL with that product now apply coupon on that SO. Issue: - Amount computation is wrong for coupon value which is greater then that product's tax_excluded(80) and it is only applying 80 instead of 90 because we were not properly computing amount of child taxed. Cause: - Discountable was not properly computed in commit [1]. it was not taking child tax values into account. Fix: - Add condition to properly check discountable values and take child tax amount into consideration. [1] https://github.com/odoo/odoo/commit/443097b4db29a4909bb0d0c44040140f08d1e433 opw-4033803 Forward-Port-Of: odoo/odoo#174196 Forward-Port-Of: odoo/odoo#173659
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the an
Original PR description
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example…
Step to reproduce: - Activate analytic accounting in the Accounting settings - Create an analytic account - Create an invoice with this new analytic account - Create a horizontal group, for example on the product_id field. - Enable the Profit and Loss report on the horizontal group - Open the P&L report and activate both the analytical and the horizontal groupby filters. => no result is displayed in the column of the analytical filter. Cause of the issue: When activating the analytic groupby, it creates a shadowing of the move lines based on the analytic lines. This shadowing loses most of the data of the move lines, which can therefore no longer be of use to create more advanced filters. Proposed solution: When doing the shadowing, if the account.analytic.line does not have the column present in the account.move.line, then takes the value of the related move line, instead of setting the value to NULL as it was done before. opw-4048157 Forward-Port-Of: odoo/enterprise#67197 Forward-Port-Of: odoo/enterprise#66980
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bound
Original PR description
Before this commit, after we drag a sign item out of bounds, it would disappear until we refresh the page. This was happening because we were hiding the item at drag start, then it would only get re-rendered after dropping it inside the page. Thus, if we dragged the item out of bounds instead of inside the page, the item would never get re-rendered. After this commit, the sign item can be dragged anywhere, even out-of-bounds. It works properly because now when the item is dragged out-of-bounds, we make the item visible again even though the the invalid operation is discarded. task-4037888 Forward-Port-Of: odoo/enterprise#66155
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as
Original PR description
Before this commit: For multi-label shipment tracking references are stored in field carrier_tracking_ref as "1Zxxxxxxxxxxxxxxxx+1Zxxxxxxxxxxxxxxxx+..." When cancelling the shipment, the ShipmentIdentificationNumber is the tracking reference of first package. carrier_tracking_ref is being sent as ShipmentIdentificationNumber with all the tracking references. resulting in error 'Shipment not found'. After this commit: Only the tracking reference for the first package is sent as ShipmentIdentificationNumber in cancel request. Reference ups documentation: https://developer.ups.com/api/reference?loc=en_US#operation/Shipment Methods > Shipment Methods > Void Shipment opw-3974794 Forward-Port-Of: odoo/enterprise#67158
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and
Original PR description
- 17.0 We reverted the commit https://github.com/odoo/enterprise/commit/a789702766df289f4abe993374583a69027ef572 because it was causing the issue of hiding days when the row name was too long in the timesheet grid view. ### Steps to reproduce: - Install the project and timesheet app. - Open the project app, create a project, and add a task to it. - Add a timesheet a week before the current date for the created task. - Now open the timesheet app in grid view. - The created project and task are in italic font. - The last letter of the project and task name is slightly cut. ### Issue: The last letter of the string is slightly cut in the timesheet grid view. ### Cause: The dedicated space allowed for normal text is not sufficient for the italic. So, the last letter was slightly cut. ### Solution: Provide an extra space to the italic string. task-3888277 Forward-Port-Of: odoo/enterprise#63786
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL f
Original PR description
Step to reproduce: 1. Install Accounting and l10n_dk 2. View the balance sheet in comparison to last year and check the current profit & loss 3. create a bill reversal for 2023 and confirm it 4. View the balance sheet and observe how the 2024 adds the 2023 total into its total Expected behavior: The PnL from the previous year should not be added to the total of that report line. Solution: Add the missing `date_scope` field on the formula to make sure it only considers the PnL from the start of the fiscal year, therefore getting the current year's PnL opw-3957488 Forward-Port-Of: odoo/enterprise#66883
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149
Original PR description
[IMP] l10n_cz_reports: Adapt cz test on taxable date CZ is going to rely on taxable_supply_date and not the invoice date So, We need to adapt the tests on the new behavior task-id#3983749 odoo-pr: https://github.com/odoo/odoo/pull/168933 Forward-Port-Of: odoo/enterprise#67149