Thursday, March 27, 2025
49 changes · saas-18.1
Enhancements to existing features
Users can now open list data source details while viewing spreadsheets in read-only mode. This lets them understand what data they are looking at, including filters and sorting, without needing edit access.
Resolved issues and error corrections
When setting up a new point of sale payment method, choosing a payment terminal provider no longer causes the page refresh to discard information already entered. This prevents duplicate data entry and makes terminal installation smoother for users configuring POS payments.
Original PR description
In this commit, save the record when we install the payment terminal from the form widget. Steps: --- - Go to payment method config - Click on new - Journal = bank & Integration = terminal - Select a payment provider to download - the page refreshes and loses the data that is configured task - 4653445 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
Versions -------- - 18.0+ Steps ----- 1. Create a quotation; 2. add a product with taxes. Issue ----- Depending on the company tax setting, the only "Amount" viewable from the sale order line view is either `price_total` or `price_subtotal`. There's no way to easily add the other column to the view. Cause ----- The Pricepocalypse changed the view in commit 5bfd603d0cae5 to make only one "Amount" column available. Solution -------- Add the other amount as an optional fie
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a quotation; 2. add a product with taxes. Issue ----- Depending on the company tax setting, the only "Amount" viewable from the sale order line view is either `price_total` or `price_subtotal`. There's no way to easily add the other column to the view. Cause ----- The Pricepocalypse changed the view in commit 5bfd603d0cae5 to make only one "Amount" column available. Solution -------- Add the other amount as an optional field. opw-4574399 Forward-Port-Of: odoo/odoo#203215
Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart). This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items. opw-4378554 Enterprise PR: https://github.com/odoo/enterprise/pull/77741 Forward-Port-Of: odoo/
Original PR description
Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart). This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items. opw-4378554 Enterprise PR: https://github.com/odoo/enterprise/pull/77741 Forward-Port-Of: odoo/odoo#188860
When a quotation has been confirmed, the invoice generated and confirmed by an accountant, the salesman of that first quotation has access to the invoice and its button "Send & Print". However, when trying to generate the document and send it, he receives an access right error. The salesman should be able to Send & Print when the invoice has been confirmed by an accountant. task-4378899 Forward-Port-Of: odoo/odoo#200732 Forward-Port-Of: odoo/odoo#191823
Original PR description
When a quotation has been confirmed, the invoice generated and confirmed by an accountant, the salesman of that first quotation has access to the invoice and its button "Send & Print". However, when trying to generate the document and send it, he receives an access right error. The salesman should be able to Send & Print when the invoice has been confirmed by an accountant. task-4378899 Forward-Port-Of: odoo/odoo#200732 Forward-Port-Of: odoo/odoo#191823
### Steps to reproduce: - Create a flexible working schedule with not even hours per day (e.g. 9:15) - Assign this working schedule to one of the employees - Create a time off type its request unit is hours - Create a time off for the employee that has the flexible calendar for one day - Notice the duration of the leave is rounded up ### Cause: This is happening because when calculating the leave duration for a flexible resource we are using ceil() to round up the hours variable ht
Original PR description
### Steps to reproduce: - Create a flexible working schedule with not even hours per day (e.g. 9:15) - Assign this working schedule to one of the employees - Create a time off type its request unit is hours - Create a time off for the employee that has the flexible calendar for one day - Notice the duration of the leave is rounded up ### Cause: This is happening because when calculating the leave duration for a flexible resource we are using ceil() to round up the hours variable https://github.com/odoo/odoo/blob/ece2a795a303a1ce1b837a4b65e1cf99f1b717b5/addons/hr_holidays/models/hr_leave.py#L428-L429 ### Fix: Since we are not really benefiting from using ceil() as we are not using it anyways in case of half-days so it is better to avoid rounding the hours up. opw-4640130 Forward-Port-Of: odoo/odoo#202707
Before this PR, live chats were sometimes displayed under the wrong category. Steps to reproduce: - Ensure you have one live chat pinned in the sidebar. - Go to the inbox, fold the live chat category. - Reload the page. - Open the live chat category. - The chat is displayed under the wrong category. Since [1], the t-key used in the side bar template is the index of the category which is not reliable. Change it to the id field which is also unique but more reliable. [1]: https://git
Original PR description
Before this PR, live chats were sometimes displayed under the wrong category. Steps to reproduce: - Ensure you have one live chat pinned in the sidebar. - Go to the inbox, fold the live chat category. - Reload the page. - Open the live chat category. - The chat is displayed under the wrong category. Since [1], the t-key used in the side bar template is the index of the category which is not reliable. Change it to the id field which is also unique but more reliable. [1]: https://github.com/odoo/odoo/pull/203150  Forward-Port-Of: odoo/odoo#203463 Forward-Port-Of: odoo/odoo#203416
Creating a physical gift card in the PoS without an expiration date led to an Odoo error. Steps to reproduce: ------------------- * Open a PoS * Add a gift card * Click on Sell physical gift card? * Input a unique code and a value * Remove the default expiration date * Click on Add Balance > Observation: TypeError: value.toFormat is not a function at serializeDate Why the fix: ------------ the addBalance() method was trying to format the expiration date with serializeDate(t
Original PR description
Creating a physical gift card in the PoS without an expiration date led to an Odoo error.
Steps to reproduce:
-------------------
* Open a PoS
* Add a gift card
* Click on Sell physical gift card?
* Input a unique code and a value
* Remove the default expiration date
* Click on Add Balance
> Observation:
TypeError: value.toFormat is not a function
at serializeDate
Why the fix:
------------
the addBalance() method was trying to format the expiration date with serializeDate(this.state.expirationDate) without verrifing that it exists.
opw-4623141
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#201543See commit messages for details. Fixes runbot issue [105000](https://runbot.odoo.com/odoo/runbot.build.error/105000) Enterprise: https://github.com/odoo/enterprise/pull/82189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203472
Original PR description
See commit messages for details. Fixes runbot issue [105000](https://runbot.odoo.com/odoo/runbot.build.error/105000) Enterprise: https://github.com/odoo/enterprise/pull/82189 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203472
By default, you cannot choose which third parties to block, you can just add to the default list. After this commit, you can use the 'magic key' `#ignore_default` to define your own list. Forward-Port-Of: odoo/odoo#201706
Original PR description
By default, you cannot choose which third parties to block, you can just add to the default list. After this commit, you can use the 'magic key' `#ignore_default` to define your own list. Forward-Port-Of: odoo/odoo#201706
Steps: - create a stage from "To-Do" app - reload the page Actual result: - stage disappear Expected result: - stage is shown as personal stage opw-4637169 Forward-Port-Of: odoo/odoo#203057
Original PR description
Steps: - create a stage from "To-Do" app - reload the page Actual result: - stage disappear Expected result: - stage is shown as personal stage opw-4637169 Forward-Port-Of: odoo/odoo#203057
Users of SA localization needs to add a QR (resulting from the EDI validation) to their official invoices. This should occurs also for point of sales invoices but this is currently not working. Steps to reproduce: - With SA localization setup - Open POS session - Add a product - Invoice to a customer - Validate order - Check generated invoice Issue: QR is missing This occurs because we print the invoice before sending it to ZATCA. This way we generate an invoice without the nee
Original PR description
Users of SA localization needs to add a QR (resulting from the EDI validation) to their official invoices. This should occurs also for point of sales invoices but this is currently not working. Steps to reproduce: - With SA localization setup - Open POS session - Add a product - Invoice to a customer - Validate order - Check generated invoice Issue: QR is missing This occurs because we print the invoice before sending it to ZATCA. This way we generate an invoice without the needed fiscal information opw-4562837 Forward-Port-Of: odoo/odoo#199039
Description of the issue/feature this PR addresses: - Setup an eWallet for POS and website - Place an order of eWallet top up from POS - Place an order of eWallet top up from ecommerce - Make sure both has the same ID, or any POS order that has the same ID with sale.order ID - You will see the loyalty issued becomes the sum of the unrelated model Current behavior before PR: - The loyalty showed in Portal / Odoo will be wrong if it clashes with other model ID Desired behavior after PR
Original PR description
Description of the issue/feature this PR addresses: - Setup an eWallet for POS and website - Place an order of eWallet top up from POS - Place an order of eWallet top up from ecommerce - Make sure both has the same ID, or any POS order that has the same ID with sale.order ID - You will see the loyalty issued becomes the sum of the unrelated model Current behavior before PR: - The loyalty showed in Portal / Odoo will be wrong if it clashes with other model ID Desired behavior after PR is merged: - Only consider the order that comes from the sale order model --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202433
Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-
Original PR description
Steps to reproduce: - Access with the demo user - Open Timesheet dashboard - Switch to list view Issue: Access error will raise Since commit https://github.com/odoo/odoo/commit/0258a627addf678d2c9b66bd8ee6752905fbac8f Readonly account users have now read access to analytic account lines. However, when sale_timesheet is installed, in the lowest access right it is possible to see only the own timesheets, so the rule needed to be limited as it occurs with Billing users. Forward-Port-Of: odoo/odoo#203460
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#203368 Forward-Port-Of: odoo/odoo#203117
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203368 Forward-Port-Of: odoo/odoo#203117
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#202787 Forward-Port-Of: odoo/odoo#201780
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202787 Forward-Port-Of: odoo/odoo#201780
**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820 Forward-Port-Of: odoo/odoo#201212 Forward-Port-Of: odoo/odoo#196987
Original PR description
**issue:** When "Audit Trail" is activated and a user creates an incorrect payment, deleting the payment is not possible. The error message suggests archiving the payment; however, there is no option to archive it. A more flexible error message should be used instead. opw-4494820 Forward-Port-Of: odoo/odoo#201212 Forward-Port-Of: odoo/odoo#196987
Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut. This comes from the following causes: - portal composer has special margin/padding at the top to compensate with website header, so that scrolling on website keeps the composer at the top - portal composers should not autofocus on mount compared to backend views. The portal sharing page was mistakenly not conside
Original PR description
Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut. This comes from the…
Before this commit, when accessing public project sharing page with "edit" access rights, opening a task showed the chatter and "Follow" button above but it was partially cut. This comes from the following causes: - portal composer has special margin/padding at the top to compensate with website header, so that scrolling on website keeps the composer at the top - portal composers should not autofocus on mount compared to backend views. The portal sharing page was mistakenly not considered a portal composer at some point and was fixed by [1]. However had regression to include the margin/padding top compensation, thus it cut the 'Follow' button. The margin/padding top is not pretty but it works fine for website. Here for project we want to ignore them. This commit fixes the issue by ignoring project sharing for the padding/margin top compensation, using variable `env.projectSharingId`. opw-4509372 [1]: https://github.com/odoo/odoo/pull/189568 Before  After  Forward-Port-Of: odoo/odoo#203308
Versions -------- - 17.0+ Steps ----- 1. Open website in French; 2. select a pricelist using CHF as currency; 3. add a product to the wishlist; 4. open wishlist in mobile view. Issue ----- With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated. Cause ----- View was probably designed with only English & USD in mind. Solution -------- Same approach as commit ba2a0d7e33e8 took for the product configurator:
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Open website in French; 2. select a pricelist using CHF as currency; 3. add a product to the wishlist; 4. open wishlist in mobile view. Issue ----- With the increased amount of space the currency symbol needs, along with the translation of "Add", the view gets truncated. Cause ----- View was probably designed with only English & USD in mind. Solution -------- Same approach as commit ba2a0d7e33e8 took for the product configurator: - In full view, display `<fa-shopping-cart> Add` - On mobile, display `<fa-shopping-cart>` opw-4624112 Forward-Port-Of: odoo/odoo#202650
Steps: - Compute no_validated_overtime_hours for many records Actual result: - Singleton expected Expected result: - Compute is done for all records Forward-Port-Of: odoo/odoo#201544
Original PR description
Steps: - Compute no_validated_overtime_hours for many records Actual result: - Singleton expected Expected result: - Compute is done for all records Forward-Port-Of: odoo/odoo#201544
In this commit, we're removing the initial delay from macro.js. This parameter was introduced to try to optimize macro execution times. However, in practice, it doesn't change much. The debounceDelay is only used if there's a trigger in a step. 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#20
Original PR description
In this commit, we're removing the initial delay from macro.js. This parameter was introduced to try to optimize macro execution times. However, in practice, it doesn't change much. The debounceDelay is only used if there's a trigger in a step. 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#203505
After this commit, when a company is selected, the order is set to "to_invoice = true" by default. The user is still able to put it back to false if he wants. task-id: 4658640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202515
Original PR description
After this commit, when a company is selected, the order is set to "to_invoice = true" by default. The user is still able to put it back to false if he wants. task-id: 4658640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202515
Test introduced in 6a4c02e6 fails because the `attribute_line_ids` field is not visible by default in product forms. Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456) Forward-Port-Of: odoo/odoo#203225
Original PR description
Test introduced in 6a4c02e6 fails because the `attribute_line_ids` field is not visible by default in product forms. Fixes [runbot error 161456](https://runbot.odoo.com/odoo/runbot.build.error/161456) Forward-Port-Of: odoo/odoo#203225
Since [1], the data-snippet tag was added for each t-call which was not the desired behavior. This commit fix this to restrain the addition of the data-snippet tag only for t-snippet-call. [1]: https://github.com/odoo/odoo/commit/6d5c741820cb69f7619e2cf49bce1457b2cd1efd Forward-Port-Of: odoo/odoo#202025
Original PR description
Since [1], the data-snippet tag was added for each t-call which was not the desired behavior. This commit fix this to restrain the addition of the data-snippet tag only for t-snippet-call. [1]: https://github.com/odoo/odoo/commit/6d5c741820cb69f7619e2cf49bce1457b2cd1efd Forward-Port-Of: odoo/odoo#202025
Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203088 Forward-Port-Of: odoo/odoo#202875
Original PR description
Before this commit, when there is a module_loader error, the error was shown on the ui for everyone, even the public users. Now, the error will be shown on the ui only if we are in debug mode TASK-ID: 4600145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203088 Forward-Port-Of: odoo/odoo#202875
**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200546 Forward-Port-Of: odoo/odoo#184035
Original PR description
**Current behavior before PR:** When applying a text color to text that already has a gradient color, the gradient color would be removed from selected text, causing gradient color the style to be interrupted. **Desired behavior after PR is merged:** Text color can now be applied without removing or affecting the existing gradient color. task: 4196424 Forward-Port-Of: odoo/odoo#200546 Forward-Port-Of: odoo/odoo#184035
Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to reproduce ----- - Install Sales, Inventory, Purchase and German localization - Switch to a German company - Create a product - Create a Sale Order for the product & confirm it - Validate the linked Delivery - Go back to the SO & create a (draft) Invoice - Set a delivery date & confirm the
Original PR description
Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to…
Issue ----- For a German company, when confirming an invoice for an order the delivery date (of the invoice) gets set to the invoice date, even when one was manually provided beforehand. Steps to reproduce ----- - Install Sales, Inventory, Purchase and German localization - Switch to a German company - Create a product - Create a Sale Order for the product & confirm it - Validate the linked Delivery - Go back to the SO & create a (draft) Invoice - Set a delivery date & confirm the Invoice -> The delivery date changed to the invoice date Cause ----- When posting, we set the invoice date if no value was provided. This triggers compute_delivery_date because it is overridden in the German localization to depend on the invoice_date field. The override is present because delivery_date is a legal requirement for the German localization. However, forcing a value for invoice_date is also handled in the _post override of the localization. We can thus change the compute into an onchange method (to keep suggesting a value to the user). This creates a problem of there being no value for delivery_date if invoice_date is also False. This is because _post sets delivery_date = invoice_date before calling the logic that forces a value for invoice_date. We should thus provide a fallback value. ----- Ticket: opw-4599301 Forward-Port-Of: odoo/odoo#203373 Forward-Port-Of: odoo/odoo#201731
Remove empty core file. The file was introduced by mistake in another forwardport Forward-Port-Of: odoo/odoo#202520
Original PR description
Remove empty core file. The file was introduced by mistake in another forwardport Forward-Port-Of: odoo/odoo#202520
Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270
Original PR description
Before this change, if a jsonrpc handler was successful but returned the value `None` the dispatcher would return a response object containing just the `jsonrpc` and `id` keys. This is an invalid response according to [JSON-RPC 2.0 Specification section 5 "Response Object"][jsonrpc-response]: > Either the result member or error member MUST be included [...] [jsonrpc-response]: https://www.jsonrpc.org/specification#response_object Forward-Port-Of: odoo/odoo#203270
Query counter values are higher if only survey app is installed. Based on the SQL query, it looks like with only survey there is extra query to load the default language rb-111093 rb-111094 rb-111095 Forward-Port-Of: odoo/odoo#202526
Original PR description
Query counter values are higher if only survey app is installed. Based on the SQL query, it looks like with only survey there is extra query to load the default language rb-111093 rb-111094 rb-111095 Forward-Port-Of: odoo/odoo#202526
Version: 18.0 When the invoice is a refund, it should reduce the achievement's amount and not increase it. opw-4610960 Forward-Port-Of: odoo/enterprise#81671
Original PR description
Version: 18.0 When the invoice is a refund, it should reduce the achievement's amount and not increase it. opw-4610960 Forward-Port-Of: odoo/enterprise#81671
Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart). This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items. opw-4378554 Community PR: https://github.com/odoo/odoo/pull/188860 Forward-Port-Of: odoo/enterprise
Original PR description
Before this fix, it was possible to add more combo products than available to the cart. Indeed, the available quantity was only checked in the combo configurator, but not in other places where the quantity could be updated (such as the product page or the cart). This fix introduces a "max quantity" concept for combo products, which is based on the available quantity of their combo items. opw-4378554 Community PR: https://github.com/odoo/odoo/pull/188860 Forward-Port-Of: odoo/enterprise#77741
### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_va
Original PR description
### Steps to reproduce: - Accounting > Dashboard > Bank > Import Statement - Select a QIF file with a transaction having a total of 0 - Traceback ### Cause: The QIF file parser (`_parse_bank_statement_file`) does not return `unique_import_id` for transactions. In [`_create_bank_statements`](https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L261-L269) when the amount is 0, the code tries to read `line_vals['unique_import_id']` so an error is raised. ### Solution: The read is done to store the skipped lines in `ignored_statement_lines_import_ids`. This variable is then only used to get the number of skipped lines. https://github.com/odoo/enterprise/blob/316b7bdc7781d5d72d91430f74de35fdafb0bf84/account_bank_statement_import/models/account_journal.py#L291 The fix is to increment a counter instead of storing the lines. opw-4656142 Forward-Port-Of: odoo/enterprise#81944
During this commit: https://github.com/odoo/enterprise/commit/eae026d97399e0cf77c4d55fa1975968a27a3d2d We adapted the report to IMB. But by doing so there was some mistake in the report. opw-4625920 Forward-Port-Of: odoo/enterprise#81313
Original PR description
During this commit: https://github.com/odoo/enterprise/commit/eae026d97399e0cf77c4d55fa1975968a27a3d2d We adapted the report to IMB. But by doing so there was some mistake in the report. opw-4625920 Forward-Port-Of: odoo/enterprise#81313
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a problem, as the second "get_gantt_data" RPC could return *after* the helper responsible for selecting the range called a `runAllTimers` that would drastically increase the current time, and thus affect the RPC payload. The fix here is to include the desired range directly in the view arch,
Original PR description
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a…
This PR fixes non-deterministic issues with a unit test in the appointment module. The issue was coming from the gantt range being separately from the mounting of the view. This could sometimes be a problem, as the second "get_gantt_data" RPC could return *after* the helper responsible for selecting the range called a `runAllTimers` that would drastically increase the current time, and thus affect the RPC payload. The fix here is to include the desired range directly in the view arch, instead of selecting the range manually from the UI. Furthermore, when trying to reproduce the non-deterministic behavior of the test mentioned above by slowing down RPCs, other gantt tests showed constitently failing results due to a poor architecture relying on animation frames instead of waiting for network calls. These tests have been fixed preventively to avoid potential timing issues. Fixes runbot issues: - [159865](https://runbot.odoo.com/odoo/runbot.build.error/159865) - [161300](https://runbot.odoo.com/odoo/runbot.build.error/161300) - [161490](https://runbot.odoo.com/odoo/runbot.build.error/161490) Community: https://github.com/odoo/odoo/pull/203472 Forward-Port-Of: odoo/enterprise#82189
In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`). Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting. In the view, they will not be used (any of those 4 chars will simply be considered a whitespace). One could add `style="white-space: pre-line"` as an attribut
Original PR description
In the bank reconciliation widget, when the transaction_details of bank statement lines get formatted by calling json.loads(), an error will show if some strings contain control characters (`\n`, `\t`, `\r`, `\0`). Adding the parameter `strict=False` to the call to json.loads would allow such characters to be kept by the formatting. In the view, they will not be used (any of those 4 chars will simply be considered a whitespace). One could add `style="white-space: pre-line"` as an attribute to the span tag of those element, but this is not necessary. This PR simply aims to patch the already existing data in databases. opw-4480250 Forward-Port-Of: odoo/enterprise#78684
Forward-Port-Of: odoo/enterprise#81878 Forward-Port-Of: odoo/enterprise#81465
Original PR description
Forward-Port-Of: odoo/enterprise#81878 Forward-Port-Of: odoo/enterprise#81465
The test requires `stock_dropshipping` to be installed to have sense, but the condition set to avoid the test running without it was insufficient. Since it was only checking on a string in the database, it wouldn't raise a ValueError, but just not find any matching record, thus running the test even without the module installed. Forward-Port-Of: odoo/enterprise#81981
Original PR description
The test requires `stock_dropshipping` to be installed to have sense, but the condition set to avoid the test running without it was insufficient. Since it was only checking on a string in the database, it wouldn't raise a ValueError, but just not find any matching record, thus running the test even without the module installed. Forward-Port-Of: odoo/enterprise#81981
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is d
Original PR description
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at…
Issue ===== When validating an uncompleted return in Barcode, an error is raised. How to reproduce ================ - Open Barcode app > Operations > Receipts and create a new receipt; - Scan at least two times the same product's barcode; - Validate. - Re-open the same receipt and click on "Return Products"; - Scan one product then validate -> The return is correctly validated but an "Invalid Operation" error is raised. Cause of the issue ================== The return's move is done but `_split` is called and calling this method on a done move is forbidden. How to fix ========== In the `split_uncompleted_moves` move's method, done and cancel move are skipped. Also, the JS method who call `post_barcode_process` will now doesn't call it if operation is done or cancelled or if there is no moves (to avoid to do useless RPC.) [OPW-4535205](https://www.odoo.com/odoo/project/49/tasks/4535205) [OPW-4535257](https://www.odoo.com/odoo/project/49/tasks/4535257) Forward-Port-Of: odoo/enterprise#81829 Forward-Port-Of: odoo/enterprise#81312
How to reproduce the issue: - Create an analytic distribution model. - In the bank reconciliation, create a new transaction. In manual operations, remove the analytic. If you reload the reconciliation, the analytic distribution is not deleted. In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line. opw-446
Original PR description
How to reproduce the issue: - Create an analytic distribution model. - In the bank reconciliation, create a new transaction. In manual operations, remove the analytic. If you reload the reconciliation, the analytic distribution is not deleted. In the `bank_rec_widget` of account_accountant, the method `_line_value_changed_analytic_distribution` is triggered when the analytic field is modified. However it does not save the new value of the analytic on the account.move.line. opw-4460079 Forward-Port-Of: odoo/enterprise#81504 Forward-Port-Of: odoo/enterprise#78732
Reproducing the issue in the database currently requires a real digital DIAN certificate. However, it can be tested in Python: - Create a credit note for a CO company with a foreign currency. - Generate the XML report. The tags SourceCurrencyBaseRate and CalculationRate are being added with a negative sign, but the DIAN only accepts positive values. This commit replace the locally computed rate with the account_move invoice_currency_rate (which meant correcting a few already existing t
Original PR description
Reproducing the issue in the database currently requires a real digital DIAN certificate. However, it can be tested in Python: - Create a credit note for a CO company with a foreign currency. - Generate the XML report. The tags SourceCurrencyBaseRate and CalculationRate are being added with a negative sign, but the DIAN only accepts positive values. This commit replace the locally computed rate with the account_move invoice_currency_rate (which meant correcting a few already existing test because of decimal accuracy differences) opw-4608444 Forward-Port-Of: odoo/enterprise#80850
### Steps to reproduce: - Install "l10n_mx_edi" and switch to Mexican company - In Accounting > Configuration > Taxes create a new tax with "Factor Type" set to "Cuota" - Create an invoice with this tax - Click "Send", select "CFDI" and send - Traceback ### Cause: Apparently a typo: The code tries to read `grouping_key['importe']` but `importe` is in the dictionary `tax_value` not `grouping_key`. ### Solution: Change `grouping_key` to `tax_value`. opw-4594061 Forward-Port-Of: o
Original PR description
### Steps to reproduce: - Install "l10n_mx_edi" and switch to Mexican company - In Accounting > Configuration > Taxes create a new tax with "Factor Type" set to "Cuota" - Create an invoice with this tax - Click "Send", select "CFDI" and send - Traceback ### Cause: Apparently a typo: The code tries to read `grouping_key['importe']` but `importe` is in the dictionary `tax_value` not `grouping_key`. ### Solution: Change `grouping_key` to `tax_value`. opw-4594061 Forward-Port-Of: odoo/enterprise#81328
With the PR [1] added test case which is failing in no demo mode (see [2]). This commit will ensure the test case will completely run witth no demo mode. [1] https://github.com/odoo/enterprise/pull/77334 [2] https://runbot.odoo.com/runbot/build/76189941 Forward-Port-Of: odoo/enterprise#80969
Original PR description
With the PR [1] added test case which is failing in no demo mode (see [2]). This commit will ensure the test case will completely run witth no demo mode. [1] https://github.com/odoo/enterprise/pull/77334 [2] https://runbot.odoo.com/runbot/build/76189941 Forward-Port-Of: odoo/enterprise#80969
Steps to reproduce: === - Install point_of_sale. - pos_online_payment is auto-installed. - Uninstall pos_online_payment. - Install pos_urban_piper. - Installation fails with an XPath error. Issue: === - XPath targeting is_online_payment is not found when pos_online_payment is uninstalled. Fix: === - Replaced XPath from is_online_payment to split_transactions to ensure proper installation. task-4639074 Forward-Port-Of: odoo/enterprise#80944
Original PR description
Steps to reproduce: === - Install point_of_sale. - pos_online_payment is auto-installed. - Uninstall pos_online_payment. - Install pos_urban_piper. - Installation fails with an XPath error. Issue: === - XPath targeting is_online_payment is not found when pos_online_payment is uninstalled. Fix: === - Replaced XPath from is_online_payment to split_transactions to ensure proper installation. task-4639074 Forward-Port-Of: odoo/enterprise#80944
Following this commit : - Initially for image_1920 in the product form view `options` was passed as `convert_to_webp': True`. - Since whenever the image is been uploaded irrespective of any format (.jpeg, .png) it will be converted to .webp which is not supported by Urban Piper. - So for pos_urban_piper this option is been modified and made False. task-4658346 Forward-Port-Of: odoo/enterprise#82044
Original PR description
Following this commit : - Initially for image_1920 in the product form view `options` was passed as `convert_to_webp': True`. - Since whenever the image is been uploaded irrespective of any format (.jpeg, .png) it will be converted to .webp which is not supported by Urban Piper. - So for pos_urban_piper this option is been modified and made False. task-4658346 Forward-Port-Of: odoo/enterprise#82044
When a user changes the theme colors and applies a dark background the attribute filters will not be apparent Also the color applied to text is not applied to the attributes only if the accordion is active As a fix now the accordion headers will match the updated text color from the theme opw-4559710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202691
Original PR description
When a user changes the theme colors and applies a dark background the attribute filters will not be apparent Also the color applied to text is not applied to the attributes only if the accordion is active As a fix now the accordion headers will match the updated text color from the theme opw-4559710 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202691
Steps to reproduce: ------------------- - Switch to a Mexican company (or any company with cash basis option enabled). - Go to analytic plans and set at least one plan to mandatory. - Create a vendor bill, with a line having a vat (16% for example), and confirm the bill. - Click on credit note, try to confirm the credit note, it will show error. Cause ----- The cash basis entry created doesn't copy the display type of the original move lines, so the move lines of the taxes will get the
Original PR description
Steps to reproduce: ------------------- - Switch to a Mexican company (or any company with cash basis option enabled). - Go to analytic plans and set at least one plan to mandatory. - Create a vendor bill, with a line having a vat (16% for example), and confirm the bill. - Click on credit note, try to confirm the credit note, it will show error. Cause ----- The cash basis entry created doesn't copy the display type of the original move lines, so the move lines of the taxes will get the default display type (product). And this affects the function that applies the mandatory analytic plans, as it filters out lines that have display_type != product. Fix --- Add lines to copy the display_type for the move lines of the cash basis. opw-4579419 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#200389
**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD) 3. Create a purchase order for the product like: a. currency: USD b. price unit: 12.6 c. qty: 6 d. discount: 33.33% 4. Confirm the order 5. Receive the product 6. Create the bill 7. Open the journal items tree view The credit/debit amounts of the journal entrie
Original PR description
**Steps to reproduce:** 1. Create a company with IQD as its currency 1. Create a product with average costing and real_time accounting 2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD…
**Steps to reproduce:**
1. Create a company with IQD as its currency
1. Create a product with average costing and real_time accounting
2. Create an exchange rate from USD to IQD (e.g, 0.00075758 USD per IQD)
3. Create a purchase order for the product like:
a. currency: USD
b. price unit: 12.6
c. qty: 6
d. discount: 33.33%
4. Confirm the order
5. Receive the product
6. Create the bill
7. Open the journal items tree view
The credit/debit amounts of the journal entries for the reception and the invoice don't match. The `amount_currency` is the same, but there are additional exchange differences items.
The reception journal item balance is taken from the `stock.valuation.layer`.
In the example, `unit_cost` is in the company currency IQD:
https://github.com/odoo/odoo/blob/191d44c91a4578445d8cb59d3172042022cb5a9a/addons/stock_account/models/product.py#L177
The invoice's balance is computed with `amount_currency`, which is converted to USD with the exchange rate and rounded:
https://github.com/odoo/odoo/blob/4e724323d811dec76c186b5cfff6e4b0135b2128/addons/account/models/account_move_line.py#L1570
The difference between the roundings (depending on the conversion rate) may generate exchange differences that shouldn't be there.
**Fix:**
Try to prepare the AML balance while creating it from a purchase
line- we have the unrounded `price_unit_discounted` that may be
used to find an accurate balance.
Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4103167)
opw-4103167
Forward-Port-Of: odoo/odoo#203386
Forward-Port-Of: odoo/odoo#190043Before this commit: The deduceURLfromText function was executed at the normalization step. This caused restrictions when creating links, as the link's href would be overridden if the label was deducible to a URL. Example: If a user wanted to link a WhatsApp URL to a phone number, the href would automatically change to tel:1234, making it impossible to set a different URL. After this commit: The deduceURLfromText function is no longer part of the normalization process. Instead: 1.
Original PR description
Before this commit: The deduceURLfromText function was executed at the normalization step. This caused restrictions when creating links, as the link's href would be overridden if the label was…
Before this commit: The deduceURLfromText function was executed at the normalization step. This caused restrictions when creating links, as the link's href would be overridden if the label was deducible to a URL. Example: If a user wanted to link a WhatsApp URL to a phone number, the href would automatically change to tel:1234, making it impossible to set a different URL. After this commit: The deduceURLfromText function is no longer part of the normalization process. Instead: 1. It is executed only when the user change directly inside a link, not when editing through a link popover. User change can be input, paste or delete 2. If the user edits the link using the popover, the href will not be overridden by deduceURLfromText. 3. If the current href differs from the deduced URL, the href remains unchanged. 4. If the deduced URL matches the current href and the user changes the link's text by typing, pasting or deleting, the href will also be updated to reflect the text changes. These adjustments ensure better flexibility and prevent unwanted overrides when creating or editing links. Related link tests are also adapted. task-3787019 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#189623