Friday, January 24, 2025
35 changes · 18.0
Enhancements to existing features
This change reuses an already calculated maintenance deadline instead of calculating it a second time. It keeps the same behavior for users while making the maintenance scheduling code slightly simpler and more efficient.
Original PR description
Description of the issue/feature this PR addresses: In the bellow bloc code `fields.Datetime.from_string(request.schedule_date).date()` is computed twice, but was saved into a variable just above.…
Description of the issue/feature this PR addresses:
In the bellow bloc code `fields.Datetime.from_string(request.schedule_date).date()` is computed twice, but was saved into a variable just above.
```py
date_dl = fields.Datetime.from_string(request.schedule_date).date()
updated = request.activity_reschedule(
['maintenance.mail_act_maintenance_request'],
date_deadline=date_dl,
new_user_id=request.user_id.id or request.owner_user_id.id or self.env.uid)
if not updated:
note = request._get_activity_note()
request.activity_schedule(
'maintenance.mail_act_maintenance_request',
fields.Datetime.from_string(request.schedule_date).date(),
note=note, user_id=request.user_id.id or request.owner_user_id.id or self.env.uid)
```
Current behavior before PR:
The variable is computed twice
Desired behavior after PR is merged:
Using the cached variable instead
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe stock return wizard now places the "Return All" button near the end of the button list instead of between related return options. This makes the dialog easier to understand and reduces confusion when processing returns or exchanges.
Original PR description
We move the "Return All" button of the return wizard as the penultimate button since it is a bit Awkward to see it between "Return" and "Return for Exchange".
Resolved issues and error corrections
The messaging menu now correctly refreshes its notification count when a user dismisses the browser notification prompt. This prevents misleading unread counts and keeps the messaging indicator accurate for users.
Original PR description
**Current behavior before PR:** Since [1](https://github.com/odoo/odoo/pull/192336) when a user discarded the `Turn on notifications` option from the messaging menu, the systray notification counter was not updated. This issue occurred due to an incorrectly written condition. **Desired behavior after PR is merged:** The issue is resolved, and the systray notification counter is correctly updated when the user discards the native notification prompt. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
The test suffered from multiple problems: - Duration of leaves could sometimes be less or more depending on the day of the week (weekend don't count in duration) - Demo data could make the test pass while the leaves created during the test were not actually found Here we improved the date mechanism as well as forcing the domain to only search within our own leaves as well as comparing that those leaves are the one with fetched. Forward-Port-Of: odoo/odoo#194994
Original PR description
The test suffered from multiple problems: - Duration of leaves could sometimes be less or more depending on the day of the week (weekend don't count in duration) - Demo data could make the test pass while the leaves created during the test were not actually found Here we improved the date mechanism as well as forcing the domain to only search within our own leaves as well as comparing that those leaves are the one with fetched. Forward-Port-Of: odoo/odoo#194994
The live chat window will now automatically open only once per visitor when configured to do so. This prevents repeated popups on every page visit, reducing annoyance and improving the website visitor experience.
Original PR description
Livechats can be configured to automatically open a chat window when a visitor opens a page. This should only occur once per visitor not to bother visitors. Before this PR, this occured each time the visitor accessed the page. The information on whether the popup was donce once is stored in the local storage but is incorrectly checked. This PR fixes the issue. opw-4503667
This fixes a visual issue on the online shop page where product grid borders could overlap nearby products or appear behind product images after changing product sizes. The correction keeps the grid layout clean and avoids confusing storefront presentation for shoppers.
Original PR description
Issue: in the /shop page, using the grid style if we change the size of a product on another column than the first one, the border of the grid will appear on the product or behind its image. This is due to the width 100vw which extends behind the product's current width and overflowing on other products of the same row. task-4513299 opw-4447224 | | |--------| --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing lot valuation from a product variant now uses the correct product-level update process. This prevents inconsistent valuation checks and helps keep inventory valuation behavior reliable.
Original PR description
The write logic for lot_valuated is handled on the ProductTemplate. When you change the value of 'lot_valuated', '_svl_empty_stock()' is called before the new value is set, and the code expects ProductTemplate.lot_valuated and ProductProduct.lot_valuated to not yet be updated. However, if you change 'lot_valuated' from the ProductProduct model, ProductProduct.lot_valuated will be updated before ProductTemplate.write() is called. Hence, in '_svl_empty_stock()', ProductTemplate.lot_valuated != ProductProduct.lot_valuated This issue only happens in the 'write' context, so it should not cause too much issue. To fix this issue, when lot_valuated is updated from ProductProduct, we call the ProductTemplate write instead. --- https://github.com/user-attachments/assets/9d2f64a4-a7ad-4078-ad0b-0cc50270492b --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents an accounting currency query from being built incorrectly when no companies are configured with a domestic currency. It helps avoid errors in affected accounting workflows and improves reliability in less common company setups.
Original PR description
We are not gonna find a value for domestic_currency_companies everytime, sometime they simply don't exist. In that case, we should check that they exist before we call _get_table_builder_domestic_currency. otherwise syntax of this query: https://github.com/odoo/odoo/blob/18.0/addons/account/models/res_currency.py#L157 is gonna be wrong. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The live chat button now receives the information it needs when opened from the chatbot test page. This prevents a setup gap that could affect testing live chat behavior before publishing it.
Original PR description
The livechat button loader template adds `websocket_worker_version` to the Odoo session. However, when the loader is called through `chatbot_test_script_page`, it does not receive the `websocket_worker_version`. In the standard Odoo environment, this value is already available in the session This fix ensures the `websocket_worker_version` is properly handled in scenarios involving `chatbot_test_script_page`. Task-4462067 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A missing company partner identifier was added to the accounting onboarding form so partner autocomplete works correctly. This prevents errors when users apply partner autocomplete during company setup or onboarding.
Original PR description
`partner_gid` was missing from `res_company_form_view_onboarding` view which was creating a bug when applying the partner autocomplete. opw-4489441 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue in Point of Sale employee handling where opening or closing a session could fail for employees linked to more than one partner record. Businesses can now manage POS sessions more reliably without interruptions caused by this employee setup.
Original PR description
Before this commit, if an employee had multiple related partners, an expected singleton error occurred when attempting to set the opening or closing of the session. opw-4482497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale sessions now record their opening time when the cashier clicks "Open register". This prevents new sessions from incorrectly inheriting the previous session's closing time, improving the accuracy of store session records.
Original PR description
- Fix bug where session opening time was set to previous session closing time. - Now we want the pos session opening time to be set when we click "Open register". task-id: 4500391 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Manufacturing planning view now identifies late work orders using the exact current date and time instead of only the calendar day. This makes the late filter more reliable for teams prioritizing urgent production work.
Original PR description
Steps to reproduce: ---- - Go to manufacturing - Planning by production - Add late filter Issue: ---- The late filter "does not work", the filter is based on the day. But the late order should be based on a much more precise datetime. Fix: --- Changed the filter from current_date to datetime.now to have more precision in the time, and so it filters more accurately. opw-4493678 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix updates a sales project test so it works consistently when that module is tested on its own. It helps prevent false test failures caused by missing project accounting setup, improving confidence in future releases.
Original PR description
It was failing in single module builds /locally and the reason was due to the fact that project not having a analytic account. task-4500108
The website editor now creates a proper primary button when users choose the button command from the powerbox, instead of accidentally inserting a regular link. This makes content editing more predictable and helps users create the intended call-to-action elements without extra manual adjustments.
Original PR description
Before this commit: Using the button command in the powerbox resulted in the creation of a regular link instead of a button. After this commit: Executing the button command now correctly creates a primary button as intended. task-4380129 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change adds coverage to ensure overtime is calculated correctly when an employee clocks in and out multiple times in one day, such as for breaks. It helps prevent incorrect extra-hours balances by making sure adjustments are applied to the latest attendance entry.
Original PR description
This PR adds a test to ensure that negative overtime works properly and is recomputed as multiple attendance records are made on a single day. For employees who clock out to take breaks, this is necessary. This ensures that the "extra hours" propagate to the most recent attendance record, while zeroing out those before it. The PR that brought the notion of negative overtime to flexible working schedules is here: https://github.com/odoo/odoo/pull/193523#pullrequestreview-2569240672
Direct debit mandates with a future start date are no longer closed when the mandate update task runs. This prevents valid upcoming customer payment authorizations from being incorrectly deactivated before they can be used.
Original PR description
### Steps to reproduce: - Go in Accounting > Customers > Direct Debit Mandates - Create a new mandate with a start date in the future - In Scheduled Actions search for "Mandate state updater" - Run manually this action - Return to Accounting > Customers > Direct Debit Mandates - The mandate was closed ### Cause: The code checks if `mandate.start_date <= today <= expiry_date`, if not the mandate is closed. ### Solution: Only check if `today <= expiry_date` opw-4460087
This fix ensures Belgian salary package users can select private car or bike options when a mobility budget is part of the contract. It prevents an incorrect restriction in the salary configuration flow, making mobility-related compensation choices available as intended.
This fix updates automated checks for Knowledge articles so they match recent editor changes and run reliably again. It removes a source of inconsistent test failures caused by embedded video loading, helping keep future Knowledge updates safer and more stable.
Original PR description
1st issue: Since the introduction of the [media command] in the editor, replacing the previous `/file`, some tour steps of a disabled test became obsolete. This commit fixes these steps according to…
1st issue: Since the introduction of the [media command] in the editor, replacing the previous `/file`, some tour steps of a disabled test became obsolete. This commit fixes these steps according to changes introduced along the `/media` command, in order to re-enable this test. 2nd issue: Other steps were incorrectly modified by [this commit] and had to be adapted too, related to the composer signature. 3rd issue: An embedded video was present in an article body in the readonly tour, and the patch supposed to neutralize it (to avoid external http requests) was applied in a manner that resulted in an indeterministic result: Sometimes the article body was loaded with the video, resulting in errors, sometimes the patch was applied resulting in the tour performing normally. This commit fixes the issue by ensuring there is no embedded video after the end of the editable tour, so that there is no need to care about it in the readonly tour. [media command]: https://github.com/odoo/odoo/commit/96c8c398c0fbef519b56edf4941691d11372eac0 [this commit]: https://github.com/odoo/enterprise/commit/1a73e227a5ce9fb1194e5664c8c4f5fcfe51b572 runbot-task-111948
Fixes an issue with the xml file where the tax exchange rate node would be added before the payment terms node if both features are used, which render the xml wrong. Also add a sudo when getting the system param for the test url; as this shouldn't block a non administrator user from testing the feature. opw-4425472 opw-4505562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194971
Original PR description
Fixes an issue with the xml file where the tax exchange rate node would be added before the payment terms node if both features are used, which render the xml wrong. Also add a sudo when getting the system param for the test url; as this shouldn't block a non administrator user from testing the feature. opw-4425472 opw-4505562 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194971
Before: The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term. For example The old value has the mapping: 'Draft': 'Brouillon' The new value contains the term: '<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>' Since the old term and the new term share the same text content, 'Draft', after `write`, the new term reuses the old translation of 'Draft'.
Original PR description
Before: The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term. For example The old value…
Before:
The typofix feature treats terms in the old and new values with similar text content as the same term, migrating the translations of the old term to the new term.
For example
The old value has the mapping:
'Draft': 'Brouillon'
The new value contains the term:
'<span invisible="name or name_placeholder or quick_edit_mode">Draft</span>'
Since the old term and the new term share the same text content, 'Draft', after `write`, the new term reuses the old translation of 'Draft'. However, the translation 'Brouillon' is always visible, unlike its en_US counterpart.
This behavior is acceptable in non-upgrade mode because the user writes the en_US value and is responsible for verifying translations afterward. However, it is problematic during upgrades because users cannot easily identify which records have changed and need to be rechecked.
After:
The translation inheritance behavior can be described as below Translations can be inherited after `write` from old terms to new terms which share the very close text contents
1. when `write` in production mode, text contents for translation terms are more important than the HTML/XML structures of them, and the old term translations should be remained as much as possible. Because
* the writing user is responsible to recheck all translations after `write`.
* it is easier for the writing user to copy technical HTML/XML structures than translate text contents for a language they may not know.
* the feature can also be used as typofix when the only small diff is the text content
2. when `write` in upgrade time, the HTML/XML structure is more important than the text content, and the new term structure should be remained as much as possible. Because
* HTML/XML structures might be changed a lot after upgrade, which may contain behavior relevant diff (e.g. `invisible`), even if text contents are not changed.
* users have no idea which records' values are changed during upgrade and are hard to recheck their translations.
* new terms are highly likely to be correctly translated in the latest po files which will be imported during upgrade.
* the typofix feature can still be remained when the only small diff is the text content
Based on the above feature analysis, we use the below new strategy
1. translations can be inherited only if the old source term and the new source term share the same HTML/XML structure
2. translations can be inherited only if the old translation term and the new source term share the same HTML/XML structure
3. when translations are inherited, MODIFIER_ATTRS will be synchronized with the new source term, other attributes will be copied from the source term if available.
Forward-Port-Of: #194181
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#194816Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error. opw-4422730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192246
Original PR description
Before this commit, if a gift card was created in another company and the gift card program was not assigned to any company, using the gift card in another company resulted in an error. opw-4422730 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#192246
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmet
Original PR description
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002`…
The `amount_untaxed` field, which is tracked, encounters floating-point precision issues during recomputation. When a value like `261,462.02` is assigned, the field may become 261,`462.0200000002` due to floating-point imprecision. Although the value is stored correctly in the database (as `261,462.02`), the tracked change is logged in the chatter, causing unnecessary noise. I couldn’t identify a clear or universal solution to this issue due to the inherent nature of floating-point arithmetic and its limitations. So what I did is checking if the new value is different than the old one then update the field. Steps to reproduce: 1. Create a PO 2. Add a product with price 261,462.02 3. Save 4. Change the expected arrival date 5. Save See the chatter. take a loot at the chatter.  opw-4315116 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193368
Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194432 For
Original PR description
Steps to reproduce: 1. Create two companies: Company A and Company B 2. Create a service product 3. Configure the product to be purchased on Company A and not on Company B 4. Create a sales order on Company B, while logged in Company A 5. Confirm the order Expected result: The service PO is created on Company B, even though it was configured not to. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194432 Forward-Port-Of: odoo/odoo#177659
### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create an invoice for a Swiss partner - Send it - The QR code appears in the generated PDF ### Cause: The bank eligibility is not checked when printing the QR code. ### Solution: After a discussion with the PO (THB) the Qr codes should appear on all Swiss transaction. But if the fiscal country of the user's company is not Switzerland, it must still be printed if its bank account is eligible to receive payment
Original PR description
### Steps to reproduce: - Install "l10n_ch" and switch to a Swiss company - Create an invoice for a Swiss partner - Send it - The QR code appears in the generated PDF ### Cause: The bank eligibility is not checked when printing the QR code. ### Solution: After a discussion with the PO (THB) the Qr codes should appear on all Swiss transaction. But if the fiscal country of the user's company is not Switzerland, it must still be printed if its bank account is eligible to receive payments via QRcodes. So the solution is to add a check if the fiscal_country is not Switzerland, then we check the account validity. A valid account is an IBAN account of this type CHXX 3000 0XXX XXXX with the number in the middle being between 30000 and 31999. opw-4380520 Forward-Port-Of: odoo/odoo#194563 Forward-Port-Of: odoo/odoo#194421
**Steps to reproduce:** - Install Accounting - Create a first tax: * Tax Name: Tax1 * Tax Computation: Percentage of Price * Tax Type: Sales * Amount: 20% * Label on Invoices: Tax1 * Tax Group: Tax1 * Affect Base of Subsequent Taxes: [Checked] - Create a second tax: * Tax Name: Tax2 * Tax Computation: Percentage of Price * Tax Type: Sales * Amount: 20% * Label on Invoices: Tax2 * Tax Group: Tax2 * Base Affected by Previous Taxes: [Not checked] - Crea
Original PR description
**Steps to reproduce:** - Install Accounting - Create a first tax: * Tax Name: Tax1 * Tax Computation: Percentage of Price * Tax Type: Sales * Amount: 20% * Label on Invoices: Tax1 * Tax Group: Tax1 * Affect Base of Subsequent Taxes: [Checked] - Create a second tax: * Tax Name: Tax2 * Tax Computation: Percentage of Price * Tax Type: Sales * Amount: 20% * Label on Invoices: Tax2 * Tax Group: Tax2 * Base Affected by Previous Taxes: [Not checked] - Create an invoice - Add an invoice line - Add Tax1 - Add Tax2 **Issue:** Base amount of Tax2 is affected by Tax1 when it should not. opw-4450494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193451
Before this commit, it could happen that the autocomplete does not find the option to select. Now, we give the option to select so we're sure that the option exists when we select it. runbot errors: 5759, 102534, 111418 Forward-Port-Of: odoo/odoo#194672 Forward-Port-Of: odoo/odoo#124584
Original PR description
Before this commit, it could happen that the autocomplete does not find the option to select. Now, we give the option to select so we're sure that the option exists when we select it. runbot errors: 5759, 102534, 111418 Forward-Port-Of: odoo/odoo#194672 Forward-Port-Of: odoo/odoo#124584
In error_service, event.preventDefault() is required to prevent uncaught error message due to latest Chrome version (132) compatibility. 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#194789
Original PR description
In error_service, event.preventDefault() is required to prevent uncaught error message due to latest Chrome version (132) compatibility. 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#194789
Steps to reproduce: ----- - Create a FSM task - Add products - Mark as done - Create invoice - Duplicate the task Issue: ----- The newly created task is linked to the invoice of the duplicated task. This comportment is not intended. Fix: ---- Creation of the copy method so the sale_order_id and the sale_line_id get set to false when duplicating a record. opw-4393596 Forward-Port-Of: odoo/enterprise#77488 Forward-Port-Of: odoo/enterprise#76547
Original PR description
Steps to reproduce: ----- - Create a FSM task - Add products - Mark as done - Create invoice - Duplicate the task Issue: ----- The newly created task is linked to the invoice of the duplicated task. This comportment is not intended. Fix: ---- Creation of the copy method so the sale_order_id and the sale_line_id get set to false when duplicating a record. opw-4393596 Forward-Port-Of: odoo/enterprise#77488 Forward-Port-Of: odoo/enterprise#76547
### Steps to reproduce: - Install helpdesk_sale_timesheet module - Go to Timesheets and click on 'Add a line' - Set a task while the project is empty - Notice the project is not automatically filled with the task's project ### Cause: This is happening because while changing the task it trigger the computation of the helpdesk_ticket_id where it checks if something changed and if not we are removing the project_id from the computation tree. https://github.com/odoo/enterprise/blob/f5384
Original PR description
### Steps to reproduce: - Install helpdesk_sale_timesheet module - Go to Timesheets and click on 'Add a line' - Set a task while the project is empty - Notice the project is not automatically filled with the task's project ### Cause: This is happening because while changing the task it trigger the computation of the helpdesk_ticket_id where it checks if something changed and if not we are removing the project_id from the computation tree. https://github.com/odoo/enterprise/blob/f53841d756c532a95fccc15aca986143dfb53337/helpdesk_timesheet/models/analytic.py#L54-L60 ### Fix: Checking if the record is not created yet we won't remove the project_id from the computation tree to make sure it will get computed and auto-populate opw-4478579 opw-4457347 Forward-Port-Of: odoo/enterprise#77418
### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a European IBAN - Create a valid Direct Debit Mandate for your contact - Create an invoice for that contact and register a payment using SEPA - Now delete that Sepa payment from Accounting > Customers > Payments - Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mand
Original PR description
### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a…
### Steps to reproduce: - Select an EU company and provide a SEPA creditor identifier (for example BE55ZZZ0455530509) - Have a contact with a European IBAN - Have a company bank journal with a European IBAN - Create a valid Direct Debit Mandate for your contact - Create an invoice for that contact and register a payment using SEPA - Now delete that Sepa payment from Accounting > Customers > Payments - Open the customer's Direct Debit Mandate > It shows one invoice was paid using that mandate although the payment was deleted - Expected: link between invoice and mandate should not be kept if payment was deleted ### Cause: The field `sdd_mandate_id` of the invoice is not reset when the payment is reset to draft. ### Solution: Add an `api.ondelete` method on `account.partial.reconcile` which checks if any of the unreconciled moves is an invoice with `sdd_mandate_id`. In that case, and if the unreconciled payment is the only SEPA payment, set `sdd_mandate_id` to False. opw-4277982 Forward-Port-Of: odoo/enterprise#77497 Forward-Port-Of: odoo/enterprise#75273
Before this commit, `_compute_past_shift` method will compute the `is_past` but also set `request_to_switch` field to False when the shift is in the past and `request_to_switch` was truely. The problem is the `_compute_past_shift` could be only called to read `is_past` field and so the cursor is sometimes in readonly to only allow SQL queries to fetch data. This commit makes sure the `_compute_past_shift` method will only alter `is_past` field and alter `request_to_switch` inside the met
Original PR description
Before this commit, `_compute_past_shift` method will compute the `is_past` but also set `request_to_switch` field to False when the shift is in the past and `request_to_switch` was truely. The problem is the `_compute_past_shift` could be only called to read `is_past` field and so the cursor is sometimes in readonly to only allow SQL queries to fetch data. This commit makes sure the `_compute_past_shift` method will only alter `is_past` field and alter `request_to_switch` inside the method that could be called when `request_to_switch` is truly for the shift contains in self. A cron is not added to make sure the request_to_switch for the shifts in the past will be set to False because the actual code is sufficient since we usually check if the shift is in the past before allowing the action or displaying the button. runbot-66162 task-4276516 Forward-Port-Of: odoo/enterprise#77523 Forward-Port-Of: odoo/enterprise#68031
The goal of this commit is to remove the AR, AP and G prefix when exporting the journal report to a PDF. This was first introduced here: https://github.com/odoo/enterprise/commit/d023d914dce1b23bf321252fb844c780e831f003 We now want to revert back that idea task-4453514 Forward-Port-Of: odoo/enterprise#77476
Original PR description
The goal of this commit is to remove the AR, AP and G prefix when exporting the journal report to a PDF. This was first introduced here: https://github.com/odoo/enterprise/commit/d023d914dce1b23bf321252fb844c780e831f003 We now want to revert back that idea task-4453514 Forward-Port-Of: odoo/enterprise#77476
Steps to reproduce: 1) Configure SEPA provider 2) Input wrong IBAN 3) See UI blocked After this commit when a rpc error happens during payment processing UI is unblocked allowing user to see the error. opw-4411773 Forward-Port-Of: odoo/enterprise#77634
Original PR description
Steps to reproduce: 1) Configure SEPA provider 2) Input wrong IBAN 3) See UI blocked After this commit when a rpc error happens during payment processing UI is unblocked allowing user to see the error. opw-4411773 Forward-Port-Of: odoo/enterprise#77634
**[IMP] account_reports: hide "Amount Currency" in PL if single currency** Currently, the column "Amount Currency" is displayed in the partner ledger even in a single currency setup. With this commit, it will now be hidden. **[FIX] account_reports: fix isNextLineChild** Currently, `isNextLineChild` method will consider `~account.report~14|~res.partner~10|0~account.move.line~32` being a a child of `~account.report~14|~res.partner~10|0~account.move.line~3` as the first string star
Original PR description
**[IMP] account_reports: hide "Amount Currency" in PL if single currency** Currently, the column "Amount Currency" is displayed in the partner ledger even in a single currency setup. With this commit, it will now be hidden. **[FIX] account_reports: fix isNextLineChild** Currently, `isNextLineChild` method will consider `~account.report~14|~res.partner~10|0~account.move.line~32` being a a child of `~account.report~14|~res.partner~10|0~account.move.line~3` as the first string starts with the second one. This is wrong, they are siblings. The fix here is to add a pipe, as done in `isLineChildOf`. **task-4321032** Forward-Port-Of: odoo/enterprise#76953 Forward-Port-Of: odoo/enterprise#73843