Daily updates from Odoo
Thursday, December 11, 2025
31 changes · 19.0
Enhancements to existing features
This update allows users to accurately display the account holder's name alongside bank details, even when it differs from the partner's name. Previously, the account holder name was automatically set to the partner's name, which is now corrected to ensure accurate reporting and reconciliation. This change enhances data clarity and reduces potential errors.
Original PR description
Allow changing of the account holder name in case it is different from the partner name which was the computed default. Task-5222712 [Related PR](https://github.com/odoo/enterprise/pull/98572)
This update enhances the efficiency of AI embedding generation by processing large text files in optimized batches. This reduces the number of API calls, preventing errors related to token limits and improving overall performance. It's a key improvement for faster and more reliable AI-powered features.
Original PR description
## Summary This PR adds support for batching embedding requests based on each provider’s input constraints. The goal is to maximize efficiency while avoiding token or payload limit errors. By processing large text files in properly sized chunks, we minimize the number of API calls and improve overall throughput. task-id-5223195
Resolved issues and error corrections
This update resolves a bug in the Odoo Studio interface that caused incorrect field choices when switching between different field types. The fix ensures that field selections always reflect the currently chosen field, preventing errors and improving the user experience. This improves the reliability of the Studio tool.
Original PR description
Before this commit when selecting fields in studio caused `getFieldChoices` to read from this.props which could still reference the previously selected field’s relation. when switching from a non-relational field to a relational one, the stale props sometimes provided an incorrect `relation` value This resulted in incorrect choice and errors such as `Invalid model name: undefined` during loadField. After this commit getFieldChoices now uses the updated props and safely guards relation lookups. this ensures that the available choices always correspond to the currently selected field and prevents loading choices from the previous field’s relation and avoids the traceback. task-5241639
This update resolves a technical issue that caused a traceback when reloading the WorkEntries page in Studio. The fix ensures Studio correctly loads the page action, preventing errors and improving stability. This change primarily impacts the Studio user experience.
Original PR description
**Verison:** - saas-18.2 **Steps to reproduce:** - Go to an employee form view. - Click on the WorkEntries smart button. - Open Studio. - Reload page. **Issue:** - A traceback appears after reloading the page in Studio. **Cause:** - The smart button URL uses the model name hr.work.entry, but Studio’s service_action expects a path without dots. Because the action cannot be loaded correctly, the view breaks and triggers the traceback. **Solution:** - Return the proper path instead of the model name so that the action loads correctly. This prevents the error when reloading the page. task-5236317 Forward-Port-Of: odoo/odoo#239335 Forward-Port-Of: odoo/odoo#235662
This update resolves an issue where multiple daily attendance entries were incorrectly merging, resulting in inaccurate duration calculations. The fix ensures that each attendance entry is accurately recorded, preventing overlaps and providing correct work time data. This improves the reliability of employee time tracking.
Original PR description
In this commit, we fixed the merge of multiple attendance work entries on the same day. Currently, when you create multiple attendances on the same day, the work entry duration is considering the last one's duration. Reason: converting a work entry into intervals will be in a full day interval which is wrong, it will consider previous work entries as included ones within the new one. Fix: we need to regenerate the old ones too. Related task: 5405642
This update fixes a technical error preventing the Nilvera E-Invoice module from correctly generating invoices when using bank accounts. The issue stemmed from a mismatch in how the system identifies address fields, specifically when dealing with bank records. This fix ensures invoices can now be successfully sent.
Original PR description
**Steps to reproduce:** * Install the **Türkiye - Nilvera E-Invoice (l10n_tr_nilvera_einvoice)** modules * Configure test mode following the [setup…
**Steps to reproduce:**
* Install the **Türkiye - Nilvera E-Invoice (l10n_tr_nilvera_einvoice)** modules
* Configure test mode following the [setup guide](https://docs.google.com/document/d/1EUzvTBnSm9-VwIfBsX299MHGXIVys-uijnsJ1fpz7vI/edit?tab=t.0).
* Create a bank account for the main company and fill the **Bank** selector (bank identifier dropdown).
* Create and attempt to send a customer invoice via Nilvera.
**Observed behavior:**
* A server error occurs: `KeyError: 'country_id'` in `l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py` at line 172 while generating `<cac:PayeeFinancialAccount>`.
* The invoice cannot be sent.
**Cause:**
* `_get_address_node()` determines field names using `vals.get('model', 'res.partner')`.
* When the parent class calls `_get_address_node({**vals, 'partner': bank})` with a `res.bank` record, it does **not** pass a `model` parameter.
* The method falls back to `'res.partner'` and attempts to read `country_id` from a `res.bank` record, which instead uses the field `country`.
* This mismatch triggers a `KeyError`.
**Fix:**
* Detect the appropriate field set by checking `partner._name` rather than relying on `vals.get('model')`.
* Use `country` / `state` when the record is `res.bank`.
* Use `country_id` / `state_id` when the record is `res.partner`.
opw-5380246This update corrects a potential issue in the Chilean VAT (l10n_cl_edi) module where an incorrect sequence number could be generated for VAT documents. Previously, if a specific journal setting wasn't configured, the system might produce sequences starting with 'False'. This fix ensures accurate and reliable sequence generation, preventing reporting errors.
Original PR description
Before this commit, if the journal is not set to using the document (l10n_latam_use_documents), the method _get_last_sequence could return a sequence that starts with False. opw-5404813 Forward-Port-Of: odoo/enterprise#101824
This PR addresses several issues across various Odoo modules, including website editing, account management, MRP, and mail functionality. It fixes visual inconsistencies, corrects calculation errors, and improves performance, ultimately enhancing the user experience and data accuracy.
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
This update corrects a display issue in the SA EDI version of vendor bills. When a bill's currency doesn't match the company's local currency, the amounts shown in the currency conversion section were incorrectly appearing as negative. The fix ensures accurate currency calculations and proper bill formatting.
Original PR description
**Steps to reproduce:** - Create a vendor bill with currency not matching the currency of an SA company - Print the bill in the SA EDI specific format (is not shown on preview) or export as PDF **Issue:** Amounts displayed in the currency conversion section of the bill incorrectly show negative values for subtotal and total. **Solution:** The view affecting the bill in question referred to `o.amount_untaxed_signed` and `o.amount_total_signed` where either unsigned `o.amount_untaxed` and `o.amount_total` or `abs(o.amount_[...]_signed)` should be used instead, as in other localizations. opw-5253213 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236654
This update resolves an issue where a previously revoked portal user could inadvertently become the default public user for a new website. This prevented potential confidentiality risks and ensured data integrity by retaining the user's original status. The fix maintains the portal group on the revoked user, allowing for future reactivation without causing default user conflicts.
Original PR description
**Steps to reproduce:** - Go to a Contact - Go to the actions dropdown menu of the record - Grant Portal Access - Revoke that Access - Create a new Website in the same Company that Portal Access was…
**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions
**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)
if public_users_for_company:
return public_users_for_company[0]
```
This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).
**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).
For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.
Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.
related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b
opw-4760550
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757This update resolves an issue where top-up events would fail when a company's archived account was used. The team has simplified the reconciliation process, now skipping it as it's considered a 'nice to have'. This ensures top-ups function correctly even with archived accounts.
Original PR description
Before this commit: Webhook 'topup.succeeded' events would fail if the company `transfer_account_id` field is set to an archived account at the reconciliation step After this commit: As the reconciliation is a "nice to have", we skip the reconciliation step Steps to reproduce: - Install `hr_expense_stripe_demo` - Fill the KYC of doom - Archive the account set on the company `transfer_account_id` field - Create a top-up - Nothing happens, error 550 logged on IAP test
This update fixes a technical issue that prevented product catalog search options from being properly translated into different languages. By wrapping labels with the '_t' function, the system now supports localization, ensuring consistent and accurate translations across all Odoo languages. This improves the user experience for international customers.
Original PR description
When adding the search options in the catalog view[^1], the labels were not made translatable. This commit wraps the labels with the _t function to ensure they can be translated into different languages. [^1]: https://github.com/odoo/odoo/commit/96dc626f8d489817c944420178c22dba5c916799
This update resolves an issue where a user's live chat agent name was unintentionally revealed in messages. The change ensures that when mentioning internal users in live chat, the system now uses their live chat username instead, enhancing privacy and security. This update impacts the mail module.
Original PR description
Before this commit, when mentioning an internal user in live chat it would show their name in the message body. This leads to the agent's name being leaked when a live chat username is set. This commit fixes the issue by using the user's live chat username (when available and in the context of live chats) in the generated mention element. This commit also changes `mail_message@_to_store_defaults` to send, when available, the `user_livechat_username` of the recipients of a message. task-5384305
This update fixes a technical issue related to how audit status information is calculated in financial reports. The previous calculation used incorrect settings, leading to inaccurate reporting. This change ensures that audit status data is correctly processed across various localized versions of Odoo Enterprise.
Original PR description
When computing allow_account_audit_status_on_lines, we used the wrong field_name and default_value. Removed all the localized value as this fix should have been the one done in the first place. task-5106852
This update resolves an issue where the Gantt chart would crash when event start or end dates were cleared. The fix ensures the Gantt calculation only runs when a valid date range exists, preventing errors caused by comparing dates with empty values. This improves stability and usability of event scheduling.
Original PR description
When removing the start or end date on an Event, the system raises a traceback during Gantt information computation. **Steps to Reproduce:** 1. Install `website_event_track_gantt` module. 2. Create a new Event. 3. Add at least one **Track** with a track **Date** and **Duration**. 4. In the Event form, clear the Start or End Date field. **Error:** `TypeError: '<' not supported between instances of 'datetime.datetime' and 'bool'` **Cause:** When the event start or end date is removed, those fields become False. During computation, the system attempts to compare these False values with the track dates (which are real datetimes), resulting in an invalid datetime-boolean comparison, causing the error. **Fix:** This commit ensures the Gantt calculation only executes when the event has a valid date range, avoiding comparisons that include missing values. no id Forward-Port-Of: odoo/enterprise#101541
This update adds a field to the salary configuration to allow users to specify the correct account holder name. This is crucial for payment security in Belgium, as incorrect account holder details can lead to manual payment confirmations. The change also includes fixes for testing and addresses issues found in the automated testing environment.
Original PR description
Law is now more secure and you need to have the correct name on the bank account holder otherwise payment need to be manually confirmed everytime. Therefore a field is added to the salary config to allow the user to set his account holder name separately from his actual name in case it is different. Task-5222712 [Related PR](https://github.com/odoo/odoo/pull/233965)
This update adds an index to the `sale.order.project_id` field, significantly speeding up the loading time of the project settings page. Previously, the system was performing a slow scan of the database, but this change allows for faster data retrieval and improved responsiveness.
Original PR description
Description ----------- Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant…
Description ----------- Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`. This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened. Benchmark --------- On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took: | | Before | After | |--------------|--------|-------| | Timing (hot) | 9.1s | 5ms | Reference --------- opw-5280364 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#239338 Forward-Port-Of: odoo/odoo#238995
This update resolves an issue where the color picker test was failing intermittently due to timing problems. The fix ensures the test waits for all steps to complete, preventing unpredictable results and improving the reliability of the website customization process. This enhances the overall quality and stability of the website builder.
Original PR description
__Behavior before commit:__ Since `edit` writes one character after the other, using it on a color picker to write an RGBA color calls `make_scss_customization` when the input value reaches the RGB color. Then, another call is made when the entire color is written (because they are both valid colors). However usually the test finished before the steps for the second call were reached because the `Deferred` was only waiting for the first call. __Fix:__ Wait for all steps to avoid nondeterministic behavior. Runbot error: https://runbot.odoo.com/odoo/runbot.build.error/234621 Forward-Port-Of: odoo/odoo#239441
This update resolves an issue preventing the local overlay feature in the HTML editor from functioning correctly. The fix ensures that the overlay is displayed as intended, improving the user experience when editing HTML content within Odoo. This enhancement ensures consistent and reliable functionality for users.
Original PR description
task-5380409
This update removes the display of guest amounts from the payment screen in the Odoo Restaurant Point of Sale module. Previously, this information was shown for all orders, which was causing confusion and unnecessary data. This change simplifies the payment process for users.
Original PR description
Before this commit, for all of the orders there was the amount per guest displayed in the payment screen. opw-5394429 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a minor usability issue where clicking the question mark (?) on the website would unexpectedly focus a field. This was causing a frustrating user experience, particularly on mobile devices. The fix ensures the question mark only displays the tooltip, as intended.
Original PR description
On desktop: - Hovering the "?" opens the tooltip; - Clicking on the "?" focuses the field => bug On Mobile: - Clicking on the "?" focuses the field => bug Clicking on the "?" should not focus the field (annoying because it could open a "Search more" on M2O, a bottom sheet, etc.) task-5359752 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update enhances the IoT app by providing clear notification feedback when users enable remote debug. Previously, there was no indication of success or failure when entering the debug token. Now, users will receive a confirmation message, improving the user experience and troubleshooting.
Original PR description
When activating the remote debug from iot app backend there is no feedback when entering the token. We now display a notification to inform whether the remote debug is enabled or not. Task: 5388242
This update resolves an issue where reconciling expenses linked to multiple legacy accounts would cause the system to crash. Now, when multiple expenses share a common account, the system correctly identifies it and allows reconciliation. This ensures accountants can accurately manage historical expense data.
Original PR description
The aim of this commit is to allow accountants to be able to reconcile legacy <account.move> linked to several expenses. Context: With the refactoring of the expense module, we made the assumption that an expense paid by the company will generate one <account.move>. This is True within the new system but is wrong regarding legacy data and those weren't adapted through an upgrade script. Before this commit: Trying to reconcile an <account.move.line> that is already linked to another one from which it's <account.move> is linked to several expenses will crash while we try to get the relevant account to compute the needed_terms on the <account.move>, even if all the expenses will result in giving back the same account. After this commit: We check if all the expense retrieve the same account. If they do, we just retrieve it. If not, we throw a UserError instead of a weird singleton error. task-5113799
This update resolves an issue where the OCR process incorrectly assigned foreign currencies (like Convertible Marks) to expense reports, particularly when linked to products with standard prices. Now, users can correct the total amount after the OCR, ensuring accurate currency conversions and timely reimbursements.
Original PR description
Fixes a bug where the OCR would sometimes put a foreign currency on an expense with a product having a cost. Making it impossible to switch back to the company currency (because the currency cannot be changed). This also allows the user to change the total amount after the OCR pass, so it can be corrected if needed task-4873236 Forward-Port-Of: odoo/enterprise#101822 Forward-Port-Of: odoo/enterprise#89093
This update resolves a confusing issue with audio/video device selection in Odoo's Discuss calls, specifically on Chromium browsers. The system now correctly requests necessary permissions and displays a clear 'Permission Needed' message when permissions aren't granted, leading to a smoother user experience.
Original PR description
Backport of https://github.com/odoo/odoo/pull/236499 This commit removes the 'Browser Default' placeholder for audio/video device selection on Chromium-based browsers, as they already return their own default device and the placeholder causes confusion. The device-selection dropdown will now display 'Permission Needed' when permissions are not granted. Clicking the dropdown will trigger the permission dialog if the necessary permissions are not granted. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a potential issue in the payroll calculation process. Specifically, it adds a new 'validated days' conflict state within the work entry module, ensuring accurate tracking of validated time entries and preventing incorrect payroll calculations. This improves the reliability of payroll processing.
This update fixes issues with sending follow-up reports via snailmail, specifically addressing address validation, cover page functionality, and PDF formatting. The changes ensure the report is correctly formatted for the Pingen service and provides feedback to the user if the address is invalid, preventing silent failures.
Original PR description
#### [FIX] snailmail_account_followup: fix address, cover page and layout Currently there is the following potential problem when sending the followup report via snailmail. 1. The address generation…
#### [FIX] snailmail_account_followup: fix address, cover page and layout
Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
lead to problems with the service we use to send the actual letter.
They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
So we can not work around problems with the address generation
by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
with our current snailmail provider (Pingen). But there is no error
message about it. (Although we do have something in the usual
snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
so the user does not receive any feedback.
This could be an issue in case multiple follow-up reports are sent
at the same time.
This commit fixes these issues. (See below for details.)
(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.
(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
not rejected by Pingen because of this
But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.
(4)
We try to print / send the letter even if the address is invalid
Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
(Settings -> Accounting -> section "Customer Invoices")
- enabled to test for the cover page
- disabled to test that the address generation is adjusted
4. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
(or just search for "snailmail" in the main screen)
And select the letter
6. Download the PDF document
#### [FIX] snailmail_account_followup: forbid regenerating failed letters
The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.
Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).
After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.
Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)
1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
- On 17.0: Accounting -> menu: "Customers" / "Follow-up Reports"
-> click on a line / partner -> button "Follow up"
- On 18.0+: partner form view -> tab "Accounting"
-> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)
#### references
opw-5160121
opw-5209504
opw-5226366
Forward-Port-Of: odoo/enterprise#101737
Forward-Port-Of: odoo/enterprise#99491This update fixes a discrepancy in the demo data where the maximum paid time off was incorrectly displayed as 21 days. The change ensures the demo data accurately reflects the legal maximum of 24 days for employees working 6 days a week, aligning with current regulations. This update improves the accuracy of the demo environment for testing and training.
Original PR description
In the demo data, the number of paid time off was displayed as 21, when it should be 20. The issue was tracked to the statement used for assigning the working schedule to each employee. Also the maximum time off possible is now 24 days as stated by the law (for people working 6 days a week). task-5172492
This update fixes a bug in the Mexican EDI localization that occurred when refunding orders with global discounts. Previously, refunds could exceed the original order total, causing invoice generation errors. The fix limits refunds to prevent this issue, ensuring accurate invoice creation for Mexican customers.
Original PR description
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to…
When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization. Steps to reproduce: ------------------- * Activate the global discount option in any PoS * Open PoS and make a sale with a global discount * Refund the sale without including the discount * Go to the backend * Go to the order list and select the 2 orders you made * Now try to create a global invoice > Observation: The global invoice is in error because the negative lines cannot be distributed correctly. Why the fix: ------------ To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense. opw-4899501 Forward-Port-Of: odoo/enterprise#101622 Forward-Port-Of: odoo/enterprise#93101
This update resolves a technical issue where the POS appointment booking tab displayed incorrectly for users with Arabic language settings. The fix corrects how dates are formatted, preventing a traceback error caused by an incorrect date translation. This ensures a smooth and accurate booking experience for all users, regardless of their language.
Original PR description
Currently, when the user language is arabic and we try to select the booking tab inside pos, a traceback appears. Steps to reproduce: ------------------- * Make sure shop has activate the booking feature * Set appointment type to "Table" * Set user language to arabic * Open pos session * Open the booking tab > Traceback: ... invalid isoformat string Why the fix: ------------ `.toFormat` was responsible for the "translation" of the date to arabic. opw-5380768
This update resolves an issue where the accounting section in Odoo Enterprise V19 was limited to SEPA countries. Now, features like the HSBC Autopay option and Batch account move lines are available for all localization settings, including the Hong Kong localization. This ensures consistent functionality across all supported countries.
Original PR description
Before this commit, the accounting section in V19 was exclusive to SEPA countries, causing some fields located in this section for other localizations to disappear. This was the case for the HK localization, which had the Payroll HSBC Autopay option inside this section, causing it not to appear, and also prevented the Batch account move lines option from being available for non-SEPA countries. With this commit, the accounting section and the Batch account move lines option are available for all localizations. This was already fixed in the master here is the PR in question odoo/enterprise#96283 task - 5268780