Saturday, May 24, 2025
54 changes · saas-18.3
Resolved issues and error corrections
This update stabilizes automated tests for the HTML editor so they behave consistently in newer Chrome versions. It helps reduce false test failures during development and release validation without changing end-user functionality.
Original PR description
This is a follow-up to https://github.com/odoo/odoo/pull/210867/commits/c52e74066f9b43d24461e2840ea8a6ec64444727.
This update refines accounting demo data so sample bank reconciliation flows are easier to understand and less likely to show misleading tax or matching behavior. It renames a demo bank fees model, adjusts sample partner data, and improves bank statement examples for a smoother product demonstration experience.
Original PR description
This PR adjusts the new demo data that were brought by [this commit](https://github.com/odoo/odoo/commit/9e7db1e80050add6e9e555acc5da71d0d04e1f47) with three commits whiches summaries are: The first commit adjusts the name of a reconciliation model which can be slightly improved. The second commit relocates a partner to avoid domestic taxes to be automatically applied. The third commit applies a series of changes to iterate the demo data to a new version which better displays the features available to the user. --- task-none --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A sales product configurator test now explicitly enables pricelist behavior so it matches the expected business scenario. This helps keep automated checks reliable and reduces the risk of pricing-related regressions reaching users.
This fixes an issue where checkout could fail when customers used separate delivery and billing addresses and the delivery address had no VAT number. The change helps ensure orders with separate addresses can be completed smoothly for Italian electronic invoicing flows.
Original PR description
When user decides to have separate address for delivery and payment, delivery address does not have vat field, which gives an error. This commit fixes the issue. [runbot-223239](https://runbot.odoo.com/odoo/error/223239)
This fixes an issue that could prevent WinBooks accounting imports from creating records correctly after a platform change. The update keeps the import workflow compatible so businesses can continue importing accounting data without interruption.
Original PR description
Due to this commit: https://github.com/odoo/odoo/commit/420c64c9e9d4b3b0f3e51f1a41774587a04fbf2e (PR: https://github.com/odoo/odoo/pull/197868), create now only accepts list or tuples and this one raise because it was using dict_values. opw-4803277
When a calendar event is linked to an existing sales opportunity, the system now checks whether a meeting reminder already exists before creating a new one. This prevents duplicate activities, reducing clutter and helping sales teams keep opportunity follow-ups accurate.
Original PR description
Prevent scheduling a meeting activity if one already exists when linking a calendar event to an existing opportunity. Also ensures that activities are only created when necessary by checking for existing activities on the opportunity, avoiding redundant calls to `activity_schedule`. Task-4747036
Fixes crashes that happened when restaurant staff cleared product or category filters, or selected a time filter, in the preparation display. This makes the preparation screen more reliable during daily point-of-sale operations.
Original PR description
Steps to reproduce: - Select a category/product filter in the preparation display - Click on "clear all filters" => traceback - Select a time filter => traceback Fix: The first traceback is caused by a refactoring mistake where preparationDisplay was changed by prepDisplay. The second traceback is due to calling a method that doesn't exist, the method is now added in this commit.
This change ensures barcode inventory tests always enable lot and serial number tracking before running. It prevents occasional test failures caused by missing setup, improving confidence in the barcode workflow checks without changing user-facing behavior.
Original PR description
This test assumes the lot/serial setting was enable before the test but it was not guarantied. Meaning the tour steps was sometimes failing on the `lot_id` field being invisible. runbot: 182040
The AI feature now handles property tag and selection fields that have no configured options without causing an error. This prevents interruptions when users click the AI button on incomplete or empty property settings.
Original PR description
Bug === When clicking on the AI button of a property tags, without tags (or on a selection without option / m2x without model), a traceback is raised. Task-4712395
The Barcode app no longer performs an unnecessary readiness count when opening manufacturing operations. This reduces avoidable background work and helps the manufacturing barcode screen load more efficiently without changing user workflows.
Original PR description
Issue ===== In `StockBarcodeKanbanRenderer` `onWillStart`, the python method `get_model_records_count` is called to fetch the number of ready picking or batch picking. The issue is this method is useless for manufacturing order but is called anywway. With this commit, this method is called only when needed. How to reproduce ================ - Install Inventory, Manufacturing and Barcode; - Inventory > Configuration > Settings > check "Batch, Wave & Cluster Transfers"; - Go in Barcode > Operations > Manufacturing: If you inspect calls, you'll see `get_model_records_count` is called.
Miscellaneous changes
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958) Forward-Port-Of: odoo/odoo#211042 Forward-Port-Of: odoo/odoo#207743
Original PR description
Before this commit, mapping over `suggestedPartners['res.partner']` without checking caused runtime errors when the RPC returned no data. removed the mapping step and adding data to store as returned by server task-[4737958](https://www.odoo.com/odoo/project/1519/tasks/4737958) Forward-Port-Of: odoo/odoo#211042 Forward-Port-Of: odoo/odoo#207743
Currently, the default ffmpeg configuration used for screencast conversion fails when browser dimensions result in odd-numbered width or height, as H.264 requires even dimensions. This commit adds a padding filter to ensure dimensions are even numbers. runbot-160976 Forward-Port-Of: odoo/odoo#209100
Original PR description
Currently, the default ffmpeg configuration used for screencast conversion fails when browser dimensions result in odd-numbered width or height, as H.264 requires even dimensions. This commit adds a padding filter to ensure dimensions are even numbers. runbot-160976 Forward-Port-Of: odoo/odoo#209100
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields (partner) would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal or partner. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute
Original PR description
Before fix, when a user manually added a narration (e.g. terms and conditions) on an invoice, changing the journal or other dependent fields (partner) would trigger a recompute of the narration field, which cleared the user-provided content. Steps to reproduce: ---- 1. Create a customer invoice. 2. Add custom narration (terms and conditions). 3. Change the journal or partner. → The narration field is reset and the manually-entered content is lost. After this commit: ---- The compute method for the narration field checks if narration already exists and preserves it, preventing loss of user input. ---- opw-4757119 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211459 Forward-Port-Of: odoo/odoo#210852
Odoo part of the IAP PR. Add some more error codes that will be sent by the IAP server, in order to provide more useful errors for the users. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209410
Original PR description
Odoo part of the IAP PR. Add some more error codes that will be sent by the IAP server, in order to provide more useful errors for the users. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209410
Before this commit, when the user creates a SOL from scratch inside the form view of a task and would like to also create and edit the product linked to that new SOL, a traceback is occurred because a certain field cannot be computed correctly. The reason is because the form view loaded is the one of the `product.template` module instead of `product.product`. This commit adds a new product form view to hide the product type if the user creates a product inside the SOL form view displayed when
Original PR description
Before this commit, when the user creates a SOL from scratch inside the form view of a task and would like to also create and edit the product linked to that new SOL, a traceback is occurred because a certain field cannot be computed correctly. The reason is because the form view loaded is the one of the `product.template` module instead of `product.product`. This commit adds a new product form view to hide the product type if the user creates a product inside the SOL form view displayed when he creates a SOL in sale_line_id field of `project.task` model. This commit also changes the form view to load for `product.product` model to use the one added inside that commit. task-4781817 Forward-Port-Of: odoo/odoo#209572
When viewing the valuation in the past, the default measures 'Remaining Qty' and 'Remaining Value' are irrelevant. Instead, display the 'Quantity' and 'Total Value' measures by default. opw-4517548 Forward-Port-Of: odoo/odoo#202685
Original PR description
When viewing the valuation in the past, the default measures 'Remaining Qty' and 'Remaining Value' are irrelevant. Instead, display the 'Quantity' and 'Total Value' measures by default. opw-4517548 Forward-Port-Of: odoo/odoo#202685
Since [1], domain name matching in get_current_website did not account for IDNA (punycode) encoding, making it impossible to use non-ASCII domain names (e.g., düsseldorf.localhost). This commit fixes the issue by normalizing the incoming domain to Unicode, then encoding it to punycode for comparison with stored website domains, ensuring correct resolution of websites with internationalized domain names. [1]: https://github.com/odoo/odoo/commit/4a202440b8d9bbe8e93e1ae47b68159330c8836d
Original PR description
Since [1], domain name matching in get_current_website did not account for IDNA (punycode) encoding, making it impossible to use non-ASCII domain names (e.g., düsseldorf.localhost). This commit fixes the issue by normalizing the incoming domain to Unicode, then encoding it to punycode for comparison with stored website domains, ensuring correct resolution of websites with internationalized domain names. [1]: https://github.com/odoo/odoo/commit/4a202440b8d9bbe8e93e1ae47b68159330c8836d task-4756915 Forward-Port-Of: odoo/odoo#207884
Account 461411, set by default on the sales taxes in LU localization does not need to be reconcilable as only payables and receivables defined in tax groups have to be opw-4749885 Forward-Port-Of: odoo/odoo#211244 Forward-Port-Of: odoo/odoo#210613
Original PR description
Account 461411, set by default on the sales taxes in LU localization does not need to be reconcilable as only payables and receivables defined in tax groups have to be opw-4749885 Forward-Port-Of: odoo/odoo#211244 Forward-Port-Of: odoo/odoo#210613
This PR removes the `onchange` logic previously used to auto-set the l10n_in_gst_treatment field based on company_type and country_id. The GST Treatment is now set dynamically by the PartnerAutoComplete service. If a user manually creates a partner (without using autocomplete), they will need to select the GST Treatment manually. Related IAP-https://github.com/odoo/iap-apps/pull/1051 Forward-Port-Of: odoo/odoo#211103 Forward-Port-Of: odoo/odoo#205714
Original PR description
This PR removes the `onchange` logic previously used to auto-set the l10n_in_gst_treatment field based on company_type and country_id. The GST Treatment is now set dynamically by the PartnerAutoComplete service. If a user manually creates a partner (without using autocomplete), they will need to select the GST Treatment manually. Related IAP-https://github.com/odoo/iap-apps/pull/1051 Forward-Port-Of: odoo/odoo#211103 Forward-Port-Of: odoo/odoo#205714
### Steps to reproduce: - Have 2 companies: COMP1 and COMP2 - Create a storable product P with a kit bom for attached to COMP1. - With COMP2 create a delivery for 1 unit of P. > If you click on check availability the move should not be assigned. - As COMP1 and with COMP2 active, click on check availability once more #### > The move is assigned. ### Cause of the issue: Checking the availability will launch a call of the `action_assign` of the stock picking. During this call, the mov
Original PR description
### Steps to reproduce: - Have 2 companies: COMP1 and COMP2 - Create a storable product P with a kit bom for attached to COMP1. - With COMP2 create a delivery for 1 unit of P. > If you click on check…
### Steps to reproduce: - Have 2 companies: COMP1 and COMP2 - Create a storable product P with a kit bom for attached to COMP1. - With COMP2 create a delivery for 1 unit of P. > If you click on check availability the move should not be assigned. - As COMP1 and with COMP2 active, click on check availability once more #### > The move is assigned. ### Cause of the issue: Checking the availability will launch a call of the `action_assign` of the stock picking. During this call, the moves that shoudl by pass the reservation process will automatically be reserved: https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/stock/models/stock_move.py#L1852-L1853 However, kit products are flagged to bypass the reservation process by these lines: https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/mrp/models/stock_move.py#L521-L522 The issue with this line being that the product is a kit form COMP1 and not for COMP2 (the context is used to determine this in the compute method): https://github.com/odoo/odoo/blob/9b0c1c416eaa0df64fbe28c5672f2590a218f315/addons/mrp/models/product.py#L38-L40 ### Note: The issue can not be reproduced prior to 18.0, since the override of the `_should_bypass_reservation` was introduced by commit 4e1d46869e6c2d1ff473317179393007522a10a3 opw-4660233 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209900
Peppol send & print was performing lots of SMP calls for everything at every step, which didn't have that much value and to avoid overloading some SMPs, we prefer to limit the number of SMP calls the wizard does. no-task Forward-Port-Of: odoo/odoo#210873
Original PR description
Peppol send & print was performing lots of SMP calls for everything at every step, which didn't have that much value and to avoid overloading some SMPs, we prefer to limit the number of SMP calls the wizard does. no-task Forward-Port-Of: odoo/odoo#210873
In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...). This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values. However, before this commit, the logic
Original PR description
In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction…
In list views, we have a custom logic for column widths which aims at optimizing as much as possible the available space, and freezing the table such that it doesn't flicker upon user interaction (like editing, adding records, browsing through pages...). This logic defines, for some field types, the exact width that values need to be properly displayed, especially for dates and datetimes for which we know upfront the format, i.e. the length of values. However, before this commit, the logic was incorrect. It didn't take into the account the fact that date and time formats are language dependant. It assumed that the required space for the english formats (+ a bit of security margin) was enough. Moreover, the fonts may obviously has an impact as well (some fonts requiring more space to display the same text, than others). As a consequence, on macos and, for instance, in deutch, date and datetime values were trimmed, which is something we never want: dates and datetimes should always be fully displayed. This is even worse in some languages, like arabic, basque or chinese, in which the month and/or the day of week is displayed in letters. This commit comes with a more elaborated solution to deal with those variable date and time formats + fonts. We no longer hardcode the ideal widths of dates and datetimes, but instead compute it (lazily) once, by rendering values in the DOM. This commit also improves the datetime and daterange cases with option "show_time" set to false: in that case, we know those fields only require the width of date values, not datetime, so we can shrink their columns. X-original-commit: c7421ddb2bfea433d56faa928c36b5ef7d5aef4c 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#210839 Forward-Port-Of: odoo/odoo#210739
When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder. Steps to reproduce: ------------------- * Create 2 products, one with a cost of 20 and one with a cost of 0 * Create a PoS order with 2 lines, one for each product * Validate the order using the shiplater option * Close the session and go to the picking created * Validate the delivery only for the product with a cost of 20 and make a backorder for t
Original PR description
When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder. Steps to reproduce: ------------------- * Create 2…
When using shiplater in PoS and creating a backorder from the original picking, the COGS would be duplicated when validating the backorder. Steps to reproduce: ------------------- * Create 2 products, one with a cost of 20 and one with a cost of 0 * Create a PoS order with 2 lines, one for each product * Validate the order using the shiplater option * Close the session and go to the picking created * Validate the delivery only for the product with a cost of 20 and make a backorder for the product with a cost of 0 * Go to the session accounting entries and check the COGS entries, you should see one entry for the product we just processed * Validate the backorder > Observation: A second COGS entry is created for the product with a cost of 20 Why the fix: ------------ Instead of creating the COGS entries based on the PoS order lines, we now create them based on the stock move lines. This way, we only create the COGS entries for the stock move lines that are actually processed. We also avoid creating COGS entries for the stock move lines that have no cost. opw-4597430 Forward-Port-Of: odoo/odoo#210704 Forward-Port-Of: odoo/odoo#207075
EDIT: new description, cf commit
Original PR description
EDIT: new description, cf commit
The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary. Steps to reproduce: --- - Install `Gamification` and `hr_appraisal` modules - Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `A
Original PR description
The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not…
The system raised a `psycopg2.errors.UndefinedFunction` error when attempting to compute a `SUM` on a `timestamp field (create_date)` in gamification goals. This is because PostgreSQL does not support `SUM(timestamp)` — `SUM` can only be used with numeric types such as integer, float, or monetary.
Steps to reproduce:
---
- Install `Gamification` and `hr_appraisal` modules
- Create a Gamification Challenge, and also create a Goal Definition and set `Computation Mode` -> `Sum`, `Model` -> `Appraisal Goal`, `Field to Sum` -> `Created on (Appraisal Goal)`, `Filter Domain` -> `[]`
- `Start Challenge` in Gamification Challenge
Traceback:
---
```
UndefinedFunction
function sum(timestamp without time zone) does not exist LINE 1: SELECT SUM("hr_appraisal_goal"."create_date") FROM "hr_appra...
^
HINT: No function matches the given name and argument types. You might need to add explicit type casts.
```
To fix this, we now check the field type before applying aggregation. If the computation mode is set to `sum` but the field is not numeric, we gracefully fallback to using `count` instead. This prevents SQL errors and ensures that goal computations remain reliable even with misconfigured definitions.
sentry-6575130734
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#208077Follow up of https://github.com/odoo/odoo/pull/193597 Starting from 18.1, the unavailable operators (due to being in call in particular) are excluded from available_operator_ids, rather than filtered afterwards. This means the gc will not be called if all operators are in call, even though the goal was to remove potentially obsolete calls. Forward-Port-Of: odoo/odoo#211255
Original PR description
Follow up of https://github.com/odoo/odoo/pull/193597 Starting from 18.1, the unavailable operators (due to being in call in particular) are excluded from available_operator_ids, rather than filtered afterwards. This means the gc will not be called if all operators are in call, even though the goal was to remove potentially obsolete calls. Forward-Port-Of: odoo/odoo#211255
Steps to reproduce ================== Run the test `/test_mail.test_message_process_references_multi_parent_notflat` a bunch of times. It will eventually fail. Or simply change the random range from `randint(0, 99998)` to `randint(0, 98)` Cause of the issue ================== ```py "<%.7f-%05d-test@iron.sky>" % (time.time(), randint(0, 99998)) ``` If randint returns a low enough value, the msg_id might look like `'<1747742185.1234567- 42-test@iron.sky>'` Solution ======
Original PR description
Steps to reproduce ================== Run the test `/test_mail.test_message_process_references_multi_parent_notflat` a bunch of times. It will eventually fail. Or simply change the random range from `randint(0, 99998)` to `randint(0, 98)` Cause of the issue ================== ```py "<%.7f-%05d-test@iron.sky>" % (time.time(), randint(0, 99998)) ``` If randint returns a low enough value, the msg_id might look like `'<1747742185.1234567- 42-test@iron.sky>'` Solution ======== We can pad the random int with zeros. runbot-110801 Forward-Port-Of: odoo/odoo#210833
- On a slow connection; - In a list view (or a form view), click on a button (a view button); - Make some changes and click on the Discard button; - Make some changes in the main view. Because the connection is slow, the main view reloads after the user has made some changes. This causes some issues, for example : the changes may be lost, editable list views may become uneditable, forcing the user to click again. This happens because on the action service, the callback function (`onClos
Original PR description
- On a slow connection; - In a list view (or a form view), click on a button (a view button); - Make some changes and click on the Discard button; - Make some changes in the main view. Because the…
- On a slow connection; - In a list view (or a form view), click on a button (a view button); - Make some changes and click on the Discard button; - Make some changes in the main view. Because the connection is slow, the main view reloads after the user has made some changes. This causes some issues, for example : the changes may be lost, editable list views may become uneditable, forcing the user to click again. This happens because on the action service, the callback function (`onClose`) is called after the dialog is closed. In the case of a view button, the callback function will reload the main view. This commit, is related to [1], in which an almost identical issue was resolved. The difference is that in previous commit the user clicked on the `Save` button in the dialog; whereas in this commit, it is the `Discard` button that is causing the issues. This commit changes that order, we will wait for the execution of the callback to complete before closing the dialog. [1] : https://github.com/odoo/odoo/commit/31c00161fd3a77c9fbd260754cb8c142fcb0d652 Forward-Port-Of: odoo/odoo#210521
The failing step is creating a new website, which could take a long time. Increasing the timeout for the next step should prevent the error. runbot-error-104332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210935 Forward-Port-Of: odoo/odoo#210121
Original PR description
The failing step is creating a new website, which could take a long time. Increasing the timeout for the next step should prevent the error. runbot-error-104332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210935 Forward-Port-Of: odoo/odoo#210121
Following [1], the blog page reverted to using the first blog post as the cover. However, the title of the page ("Our Latest Posts") was made non-editable and, consequently, non-translatable, which is not ideal. This commit addresses the issue by making the title editable, ensuring it can also be translated. [1]: https://github.com/odoo/odoo/commit/05ef95d3f13ac42713bb8d8a3002f149345cc08b opw-4289735 Forward-Port-Of: odoo/odoo#187680
Original PR description
Following [1], the blog page reverted to using the first blog post as the cover. However, the title of the page ("Our Latest Posts") was made non-editable and, consequently, non-translatable, which is not ideal.
This commit addresses the issue by making the title editable, ensuring it can also be translated.
[1]: https://github.com/odoo/odoo/commit/05ef95d3f13ac42713bb8d8a3002f149345cc08b
opw-4289735
Forward-Port-Of: odoo/odoo#187680Purpose of this commit: To remove the restriction of the partner being mentioned on a public channel. Forward-Port-Of: odoo/odoo#211232
Original PR description
Purpose of this commit: To remove the restriction of the partner being mentioned on a public channel. Forward-Port-Of: odoo/odoo#211232
Currently, an error occurs when users attempt to group by records by **Activity State** in the CRM pipeline kanban view. **Steps to reproduce:** - Install the `crm` module. - Open the CRM pipeline kanban view. - Group records by Activity State. - Observe the error. **Error:** `AssertionError` The issue occurs when attempting to add a LEFT JOIN on an SQL query without verifying whether it has already been included. - [1] The method `_read_group_groupby` is called twice because th
Original PR description
Currently, an error occurs when users attempt to group by records by **Activity State** in the CRM pipeline kanban view. **Steps to reproduce:** - Install the `crm` module. - Open the CRM pipeline…
Currently, an error occurs when users attempt to group by records by **Activity State** in the CRM pipeline kanban view. **Steps to reproduce:** - Install the `crm` module. - Open the CRM pipeline kanban view. - Group records by Activity State. - Observe the error. **Error:** `AssertionError` The issue occurs when attempting to add a LEFT JOIN on an SQL query without verifying whether it has already been included. - [1] The method `_read_group_groupby` is called twice because the `activity_state` field is used both as a progress bar field at [2] and as a manual group by option in the Kanban view by the user. [1] - https://github.com/odoo/odoo/blob/6edf0ba80818fc23b8daf46d694d201e0efee133/addons/mail/models/mail_activity_mixin.py#L284 [2] - https://github.com/odoo/odoo/blob/5c4e0826528ec88ea7a180a3598e7f225346bc49/addons/crm/views/crm_lead_views.xml#L505-L507 This commit adds a check to ensure that the join is only added once, preventing redundant joins. Sentry - 6545651193 Forward-Port-Of: odoo/odoo#206942
…ew PCSID When a journal is re-onboarding on ZATCA and a new PCSID is generated, the Invoice Counter Value (ICV) should be reset > Currently, the system does not reset the ICV when a journal is re-onboarded. The fix resets the sequence back to 1 on re-onboarding task-4652483 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/
Original PR description
…ew PCSID When a journal is re-onboarding on ZATCA and a new PCSID is generated, the Invoice Counter Value (ICV) should be reset > Currently, the system does not reset the ICV when a journal is re-onboarded. The fix resets the sequence back to 1 on re-onboarding task-4652483 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#210078
JoFotara portal expects credit notes lines ids (in the XML) to match those of the original invoice. This expectation was not satisfied before, causing partial credit notes submission to fail. This commit solves this issue. task-4752035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211280 Forward-Port-Of: odoo/odoo#209882
Original PR description
JoFotara portal expects credit notes lines ids (in the XML) to match those of the original invoice. This expectation was not satisfied before, causing partial credit notes submission to fail. This commit solves this issue. task-4752035 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211280 Forward-Port-Of: odoo/odoo#209882
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was invited to more than one event. - At least one of them was going to be notified in the future. - Google cancelled the first of those. <details> ``` 2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`. 2024-12-1
Original PR description
Description of the issue/feature this PR addresses: allow portal attendees to be synced by google calendar Current behavior before PR: There was an `AccessError` happening when: - One portal user was…
Description of the issue/feature this PR addresses:
allow portal attendees to be synced by google calendar
Current behavior before PR:
There was an `AccessError` happening when:
- One portal user was invited to more than one event.
- At least one of them was going to be notified in the future.
- Google cancelled the first of those.
<details>
```
2024-12-11 10:19:02,144 31 INFO odoo odoo.addons.base.models.ir_cron: Manually starting job `Google Calendar: sincronización`.
2024-12-11 10:19:02,151 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(29,)
2024-12-11 10:19:02,539 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(15,)
2024-12-11 10:19:03,029 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(50,)
2024-12-11 10:19:03,414 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(40,)
2024-12-11 10:19:03,823 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(52,)
2024-12-11 10:19:04,219 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(10,)
2024-12-11 10:19:04,580 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(28,)
2024-12-11 10:19:04,936 31 INFO odoo odoo.addons.google_calendar.models.res_users: Calendar Synchro - Starting synchronization for res.users(2,)
2024-12-11 10:19:05,501 31 INFO odoo odoo.models.unlink: User #2 deleted mail.message records with IDs: [1055490, 1055487, 1055480, 1055478, 1055403]
2024-12-11 10:19:05,518 31 INFO odoo odoo.models.unlink: User #2 deleted calendar.event records with IDs: [2920874, 2920875, 2920880]
2024-12-11 10:19:05,520 31 INFO odoo odoo.models.unlink: User #2 deleted mail.followers records with IDs: [6232226, 6232227, 6232228, 6232229, 6232230, 6232231, 6232232, 6232233, 6232234, 6232235, 6232236, 6232237, 6232238, 6232239, 6232240, 6232241, 6232242, 6232243, 6232270, 6232271, 6232272, 6232283]
2024-12-11 10:19:05,544 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 INFO odoo odoo.addons.base.models.ir_model: Access Denied by ACLs for operation: read, uid: 65, model: calendar.alarm
2024-12-11 10:19:05,545 31 ERROR odoo odoo.addons.google_calendar.models.res_users: [res.users(2,)] Calendar Synchro - Exception : No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario. !
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 997, in get
cache_value = field_cache[record._ids[0]]
KeyError: 8
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1161, in __get__
value = env.cache.get(record, self)
File "/opt/odoo/custom/src/odoo/odoo/api.py", line 1004, in get
raise CacheMiss(record, field)
odoo.exceptions.CacheMiss: 'calendar.alarm(8,).alarm_type'
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1187, in __get__
recs._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
During handling of the above exception, another exception occurred:
Traceback (most recent call last):
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 100, in _sync_all_google_calendar
user.with_user(user).sudo()._sync_google_calendar(google)
File "/opt/odoo/auto/addons/google_calendar/models/res_users.py", line 79, in _sync_google_calendar
synced_events = self.env['calendar.event'].with_context(write_dates=events_write_dates)._sync_google2odoo(events - recurrences, default_reminders=default_reminders)
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 185, in _sync_google2odoo
cancelled_odoo._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/calendar.py", line 326, in _cancel
super(Meeting, my_cancelled_records)._cancel()
File "/opt/odoo/auto/addons/google_calendar/models/google_sync.py", line 152, in _cancel
self.unlink()
File "/opt/odoo/auto/addons/calendar/models/calendar_event.py", line 721, in unlink
self.env['calendar.alarm_manager']._notify_next_alarm(partner_ids)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 242, in _notify_next_alarm
notif = self.with_user(user).with_context(allowed_company_ids=user.company_ids.ids).get_next_notif()
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 210, in get_next_notif
last_found = self.do_check_alarm_for_one_date(in_date_format, meeting, max_delta, time_limit, 'notification', after=partner.calendar_last_notif_ack)
File "/opt/odoo/auto/addons/calendar/models/calendar_alarm_manager.py", line 130, in do_check_alarm_for_one_date
if alarm.alarm_type != alarm_type:
File "/opt/odoo/custom/src/odoo/odoo/fields.py", line 1189, in __get__
record._fetch_field(self)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3210, in _fetch_field
self._read(fnames)
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3220, in _read
self.check_access_rights('read')
File "/opt/odoo/custom/src/odoo/odoo/models.py", line 3480, in check_access_rights
return self.env['ir.model.access'].check(self._name, operation, raise_exception)
File "/opt/odoo/custom/src/odoo/odoo/addons/base/models/ir_model.py", line 1924, in check
raise AccessError(msg)
odoo.exceptions.AccessError: No puede ingresar a los registros 'Event Alarm' (calendar.alarm)
Se permite esta operación para los grupos siguientes:
- User types/Internal User
Póngase en contacto con su administrador para solicitar acceso si es necesario.
2024-12-11 10:19:05,547 31 INFO odoo odoo.addons.base.models.ir_cron: Job `Google Calendar: sincronización` done.
```
</details>
Desired behavior after PR is merged:
Google Sync works.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
@moduon MT-8345
cc @arj-odoo
Forward-Port-Of: odoo/odoo#209351
Forward-Port-Of: odoo/odoo#190356Problem: When pasting a YouTube link and embedding it as an `iframe`, saving removes the `iframe` element. This happens because `iframe` is listed as a `kill_tag` in `SANITIZE_TAGS`, leading to its removal. As a result, the wrapper `div` becomes empty and is converted to a self-closing element, which produces invalid HTML. Solution: Disable video embedding on `body_html` of email templates to avoid inserting `iframe` elements that will later be stripped. Steps to reproduce: 1. Paste
Original PR description
Problem: When pasting a YouTube link and embedding it as an `iframe`, saving removes the `iframe` element. This happens because `iframe` is listed as a `kill_tag` in `SANITIZE_TAGS`, leading to its removal. As a result, the wrapper `div` becomes empty and is converted to a self-closing element, which produces invalid HTML. Solution: Disable video embedding on `body_html` of email templates to avoid inserting `iframe` elements that will later be stripped. Steps to reproduce: 1. Paste a YouTube link in an email template. 2. Choose "Embed YouTube Video" from the popup. 3. Save the template. → The content is broken due to missing `iframe`. opw-4746178 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#209549
Suppose an invoice line of 11.0 with 21% tax. The total of the invoice is 13.31. With a cash rounding of 0.05 UP, the total of the invoice becomes 13.35. If we apply an early payment discount of 2% on payments, we expect a discount of 0.25 because 13.35 * 0.98 = 13.08 but 13.10 with the cash rounding. 13.35 - 13.10 = 0.25 However, the cash rounding of the payment register wizard is computed from the total invoice instead of taking the amount stored on the accounting item. Then, he was computi
Original PR description
Suppose an invoice line of 11.0 with 21% tax. The total of the invoice is 13.31. With a cash rounding of 0.05 UP, the total of the invoice becomes 13.35. If we apply an early payment discount of 2% on payments, we expect a discount of 0.25 because 13.35 * 0.98 = 13.08 but 13.10 with the cash rounding. 13.35 - 13.10 = 0.25 However, the cash rounding of the payment register wizard is computed from the total invoice instead of taking the amount stored on the accounting item. Then, he was computing an early payment of 13.35 * 0.02 = 0.27 instead. At the end, the invoice was still open with a residual amount of 0.02. opw-4730764 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207562 Forward-Port-Of: odoo/odoo#207049
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024 Forwa
Original PR description
Description of the issue/feature this PR addresses: The audit trail error is displayed eventhough the audit_trail is disabled for the company. Current behavior before PR: Attachments cannot be deleted with deactivated audit trail feature. Desired behavior after PR is merged: Only prevent deleting audit trail attachments, when audit trail setting is active. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr https://github.com/odoo/odoo/pull/207024 Forward-Port-Of: odoo/odoo#209024
Problem: Adding a document when creating a new email template using `/media` results in duplicated content on save. Cause: During HTML processing on save, `flattenBackgroundImages` wraps elements with inline background images (`style*=background-image`) in MSO-specific comments: `<!--[if mso]><![endif]-->`. However, if multiple such elements are nested, they are each wrapped, resulting in invalid nested comments and broken layout. Solution: Since the two conditions are opposites,
Original PR description
Problem: Adding a document when creating a new email template using `/media` results in duplicated content on save. Cause: During HTML processing on save, `flattenBackgroundImages` wraps elements…
Problem: Adding a document when creating a new email template using `/media` results in duplicated content on save. Cause: During HTML processing on save, `flattenBackgroundImages` wraps elements with inline background images (`style*=background-image`) in MSO-specific comments: `<!--[if mso]><![endif]-->`. However, if multiple such elements are nested, they are each wrapped, resulting in invalid nested comments and broken layout. Solution: Since the two conditions are opposites, we remove completely the content of the nested comment if it has oppisite condition otherwise we just remove the comment tags since they will be replaced with the upper comment Fixed in `web_editor` in https://github.com/odoo/odoo/commit/fcedeb63f5b5da6758e75d02f0c1d4f3b965adc1 Steps to reproduce: 1. Create a new email template. 2. Add a document using `/media`. 3. Save. → The content is duplicated or layout is broken. opw-4775908 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208788
- Create a sub company from the main company. - On only the sub-company create a new followup level. - While being in both the main company and the sub-company at the same time, try to access the newly created followup level in the followup report view. The following traceback appears: File "/home/odoo/src/odoo/addons/web/models/models.py", line 128, in web_read vals = many2one_data[values[field_name]] KeyError: 9 This commit hide the statusbar for the child company if there is followu
Original PR description
- Create a sub company from the main company. - On only the sub-company create a new followup level. - While being in both the main company and the sub-company at the same time, try to access the newly created followup level in the followup report view. The following traceback appears: File "/home/odoo/src/odoo/addons/web/models/models.py", line 128, in web_read vals = many2one_data[values[field_name]] KeyError: 9 This commit hide the statusbar for the child company if there is followup level in the parent as per the specification of https://github.com/odoo/enterprise/commit/bbcd54519706539d7e2e313118c956200ea70c91 and the implementation of https://github.com/odoo/enterprise/commit/f82ef250560957046be0590f8c2a08039bcc34ca#diff-c502b098cfa2c57bc70c144ae4f0e1fbe1c0116f392ed1a63743f12a51b82084 opw-4669397 Forward-Port-Of: odoo/enterprise#85977 Forward-Port-Of: odoo/enterprise#82324
Repro steps: 1.Install l10n_lu_reports module 2. Go to Reporting > Tax Return > Annual VAT Declaration 3. Click on `Appendix to Operational Expidenture` 4. You will get a traceback error Cause: As of this PR in 18.1: https://github.com/odoo/enterprise/pull/70280 The function `registerCustomComponent` changed in 2 ways: 1. It now expects a module name 2. It registers the component by its name These changes were not applied in l10n_lu_reports module hence causing the error of the comp
Original PR description
Repro steps: 1.Install l10n_lu_reports module 2. Go to Reporting > Tax Return > Annual VAT Declaration 3. Click on `Appendix to Operational Expidenture` 4. You will get a traceback error Cause: As of this PR in 18.1: https://github.com/odoo/enterprise/pull/70280 The function `registerCustomComponent` changed in 2 ways: 1. It now expects a module name 2. It registers the component by its name These changes were not applied in l10n_lu_reports module hence causing the error of the component not being found in the registery This commit solves this issue by applying those changes in l10n_lu_reports module task-4816146 Forward-Port-Of: odoo/enterprise#86284
missing group attribute for ytd_balance_ids (private field) build_error-162969 Forward-Port-Of: odoo/enterprise#83688
Original PR description
missing group attribute for ytd_balance_ids (private field) build_error-162969 Forward-Port-Of: odoo/enterprise#83688
Currently a traceback is occurring when the user tries to generate a payslip report. To reproduce this issue: 1) Install `l10n_in_hr_payroll` and shift to Indian company 2) Create an employee and a bank account in the private information of employee 3) Remove the `Bank Identifier Code` from the `Bank` while creating a bank record 4) Create a new `payslip` record with a `running contract` 5) Confirm the payslip and click the `Create Payment Report` Error:- ``` TypeError: expect
Original PR description
Currently a traceback is occurring when the user tries to generate a payslip report. To reproduce this issue: 1) Install `l10n_in_hr_payroll` and shift to Indian company 2) Create an employee and a bank account in the private information of employee 3) Remove the `Bank Identifier Code` from the `Bank` while creating a bank record 4) Create a new `payslip` record with a `running contract` 5) Confirm the payslip and click the `Create Payment Report` Error:- ``` TypeError: expected string or bytes-like object, got 'bool' ``` As the `bank_bic` is not a required field, user can removes it. if there is no `bank_bic`, it leads to the above traceback from the below line. https://github.com/odoo/enterprise/blob/e2a9442ac33579c9833f65f59cf8341b3c6eafc8/l10n_in_hr_payroll/models/hr_employee.py#L24 sentry-6199042870 Forward-Port-Of: odoo/enterprise#81682
…o switzerland Forward-Port-Of: odoo/enterprise#86183
Original PR description
…o switzerland Forward-Port-Of: odoo/enterprise#86183
Before this commit, if a user attempted to open a spreadsheet they lacked access to or that did not exist, they would get a traceback due to improper error handling. This commit resolves the issue by handling server errors when fetching the spreadsheet and redirecting the user to the documents app. Steps to reproduce: - Create a spreadsheet with Mitchell Admin. - Copy a hyperlink. - In another browser, log in as Marc Demo and paste the hyperlink. - You get a traceback and you don't unders
Original PR description
Before this commit, if a user attempted to open a spreadsheet they lacked access to or that did not exist, they would get a traceback due to improper error handling. This commit resolves the issue by handling server errors when fetching the spreadsheet and redirecting the user to the documents app. Steps to reproduce: - Create a spreadsheet with Mitchell Admin. - Copy a hyperlink. - In another browser, log in as Marc Demo and paste the hyperlink. - You get a traceback and you don't understand what's going on. task-4551255 Forward-Port-Of: odoo/enterprise#81276
### **Version:** saas-18.1 --- ### **Steps to reproduce:** 1. Open a sign template. 2. Make **no changes** to the template. 3. Try to send or reuse the template which has sign_request. 4. A warning appears. --- ### **Issue:** The warning dialog is incorrectly triggered even when the template hasn't been modified. This leads to unnecessary interruption and confusion, especially when the user only intends to reuse or send the existing template without editing it. ---
Original PR description
### **Version:** saas-18.1 --- ### **Steps to reproduce:** 1. Open a sign template. 2. Make **no changes** to the template. 3. Try to send or reuse the template which has sign_request. 4. A warning appears. --- ### **Issue:** The warning dialog is incorrectly triggered even when the template hasn't been modified. This leads to unnecessary interruption and confusion, especially when the user only intends to reuse or send the existing template without editing it. --- ### **Cause:** The `saveTemplate()` method did not verify whether the template had any actual changes. --- ### **Solution:** Added a check to ensure the warning is shown when the user made actual changes to the template. task-4778666 Forward-Port-Of: odoo/enterprise#85335
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: --------
Original PR description
Currently you are able to select the button to settle customer account/ deposit money even though the config does not have access to a paylater payment method. This will never settle the customer account. Steps to reproduce: ------------------- * Remove the customer account payment method from the config * Open the pos session * Find a customer that has an amount due * Select "Settle due accounts" * Process > Observation: The customer account is never settled. Why the fix: ------------ If there is no payment method of type "pay_later" we should not show the button whose purpose is to use such payment method. opw-4488571 Forward-Port-Of: odoo/enterprise#86133 Forward-Port-Of: odoo/enterprise#83995
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.
Original PR description
This commit fixes an issue with the Facebook app and the management of pages. For Facebook to identify the user as able to manage a page, we need to provide another permission to the scope. The permission `business_management` is needed for the API to understand that the user is able to manage its pages. Thus we are adding it to the scope but as an optional permission. Some users may not have this permission set up for their own applications, thus we are adding the system parameter `social.facebook_no_business_management`. This parameter blocks the addition of the permission to the scope if set to any value, if not set it adds the permission to the scope. task-4719790 Forward-Port-Of: odoo/enterprise#86137 Forward-Port-Of: odoo/enterprise#84032
Single app require an additional query. Let us fix runbot, and investigate when we have time (aka: haha). Forward-Port-Of: odoo/enterprise#86116
Original PR description
Single app require an additional query. Let us fix runbot, and investigate when we have time (aka: haha). Forward-Port-Of: odoo/enterprise#86116
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-462
Original PR description
Currently, entering only spaces in the Full Name field when signing in auto mode enables the sign button, allowing users to proceed without a valid name. Steps to reproduce: 1. Sign > Create a request 2. Attempt to sign in auto mode with only spaces in the Full Name field 3. Observe that the sign button becomes enabled Cause: The system does not checks for whitespace-only name Solution: Add a validation to disable the sign button if the trimmed name is empty in auto mode. opw-4628577 Forward-Port-Of: odoo/enterprise#85996 Forward-Port-Of: odoo/enterprise#84613
Currently if you make a mistake in the name of your employee and create a payslip, it's name will never be corrected since there is no direct dependency on the field. Forward-Port-Of: odoo/enterprise#86201
Original PR description
Currently if you make a mistake in the name of your employee and create a payslip, it's name will never be corrected since there is no direct dependency on the field. Forward-Port-Of: odoo/enterprise#86201
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred reven
Original PR description
Summary ----- When you generate an entry via the deferred revenue report, if the original journal item has an analytic distribution at x%, then the lines of the deferred entries have an analytic distribution at -x%. Steps to reproduce ----- 1. In Accounting > Settings, enable the analytic accounting and set the "Generate Revenue Entries" as "Manually & Grouped". 2. Create an invoice with an analytic distribution, a start date and an end date. 3. Generate an entry with the deferred revenue report by selecting a period including the created invoice. 4. Observe the negative analytic distribution in the generated entries. opw-4502556 Forward-Port-Of: odoo/enterprise#85039 Forward-Port-Of: odoo/enterprise#82594
When an expense is manually created, the document is sent to the OCR, and the ocr modifies the values of the document. The issue is that the user cannot see that values have been modified and submit the expense with the wrong values (the ones returned by OCR which are not displayed on the form during submission). So to avoid such behaviour, we've made different fixes: - We display the banner that it has been sent to the OCR immediatly (not after a refresh) - We make work the refres
Original PR description
When an expense is manually created, the document is sent to the OCR, and the ocr modifies the values of the document. The issue is that the user cannot see that values have been modified and submit…
When an expense is manually created, the document is sent to the OCR, and the ocr modifies the values of the document. The issue is that the user cannot see that values have been modified and submit the expense with the wrong values (the ones returned by OCR which are not displayed on the form during submission). So to avoid such behaviour, we've made different fixes: - We display the banner that it has been sent to the OCR immediatly (not after a refresh) - We make work the refresh button diplayed in the banner - We don't change the name and/or product of the expense if the name of the expense has been entered manually (to know that we check if the name is the generated one when we create from attachment or not) - We don't modify the status of the expense to draft (if it has been submited before the response of the OCR we don't want modifications) The test have been modified the use case, because to correctly work if the expense is sent to the OCR, it means that there is an attachment linked to this PR. Also when we want to check the completion of the OCR, the attachment name is set as expense name (expense name is required) The issue comes from an internal feedback Forward-Port-Of: odoo/enterprise#84897
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016 Forward-Port-Of: odoo/enterprise#86094
Original PR description
pain.001.001.09 is a newer version of the ISO20022 format. Before this commit, we only supported it for SEPA Credit Transfer, using the same selection field as the one allowing to choose national variants of SEPA. This fix only intends to solve the issue for existing customers by using a system parameter that needs to be switched from "False" to "True". A cleaner solution will come in the future, after a refactoring of the payment methods. task-4647016 Forward-Port-Of: odoo/enterprise#86094 Forward-Port-Of: odoo/enterprise#85597