Friday, March 20, 2026
35 changes · saas-19.1
Enhancements to existing features
This update adapts the French financial reporting process to changes in how data is exported from Odoo. Instead of downloading entire files, data is now streamed to the user, improving efficiency and reducing download times. This ensures accurate and timely reporting for French customers.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#107017 Forward-Port-Of: odoo/enterprise#102783
This update adds a mechanism to allow other Odoo modules to adjust timesheet values directly within the timesheet wizard. Previously, timesheet adjustments were limited. This enhancement provides greater flexibility for managing timesheets across different workflows and integrations.
Original PR description
Add a hook in helpdesk_timesheet timer wizard for other modules to modify timesheet values. Forward-Port-Of: odoo/enterprise#107441 Forward-Port-Of: odoo/enterprise#107301
Resolved issues and error corrections
This update corrects a bug that was causing incorrect decimal values to be generated in French Intrastat XML reports. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate reporting for French businesses using the Intrastat functionality.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
Miscellaneous changes
Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error. The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemp
Original PR description
Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via…
Write some bytes in a `field.Binary(attachment=False)` field. The ORM doesn't encode the bytes in b64, and the value is stored as a binary blob in postgres. Attempt to download the content via /web/content (actually any route that uses `http.Stream` is affected). It sometimes download something, sometimes fail with an "Incorrect padding" error. The `http.Stream` class wrongly assumes that reading a binary/image field is always going to return the value base64-encoded, thus it always attemps to decode it. The `b64decode` function silently discard non-b64 characters and only complain if the final thing lacks the b64 `=` padding (to make the length a multiple of 4). So when it downloaded something, it downloaded crap. The thing actually is: * Binary fields, accept raw bytes, store raw bytes in db. * Image fields, reject raw bytes, want base64, store base64 in db. When reading Image fields it is easy: always decode the base64. For Binary fields it is complicated, because some crazy people encode their binary fields in base64, and expect automatic base64 decoding when read. Crazy! So *attempt* to decode the b64 and if the decoding fail just assume it was raw bytes from the beginning. **Binary-field with non-b64 value** (original fix) Forward-Port-Of: odoo/odoo#214412 Forward-Port-Of: odoo/odoo#213997 **binary can store raw bytes** (fix of *Binary-field with non-b64 value*) Forward-Port-Of: odoo/odoo#214915 Forward-Port-Of: odoo/odoo#214758 This PR contains the squashed code of the above two PRs. Forward-Port-Of: odoo/odoo#253382 Forward-Port-Of: odoo/odoo#249544
This update resolves a technical issue preventing the tour from functioning correctly within the Brazilian localization (l10n_br) module. The fix was necessary due to recent changes in the website's user interface, specifically related to the select menu, which caused a conflict and race conditions within the tour.
Original PR description
Because of the community PR that changes the DOM of the select menu, the tour in this commit crashed. This commit adapts the tour and fixes it as races conditions were still present part-of-task-5935511
This update resolves an issue where GS1 barcode filtering would fail due to an incorrect date interpretation. The fix prevents errors from blocking product filtering, ensuring accurate internal transfer operations. This improves the reliability of our inventory management system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update resolves a technical issue that caused a traceback when using the pivot table autofill feature. The fix corrects a misidentification of the function being called, ensuring consistent behavior with vertical autofills. While the core autofill functionality remains unchanged, this resolves a potential error.
Original PR description
When autofilling a positional pivot row header horizontally, we would get a traceback because we were calling `_autofillPivotColHeader` instead of `_autofillPivotRowHeader`. Note that this fix only fixes the traceback, the result is not correct, but is consistent with autofilling a positional col header vertically. Task: [5909266](https://www.odoo.com/odoo/2328/tasks/5909266) Forward-Port-Of: odoo/enterprise#110994 Forward-Port-Of: odoo/enterprise#109620
This update optimizes the database by removing unnecessary default values from company and partner records. This change reduces data storage and improves performance, particularly for businesses managing multiple companies with different fiscal settings. The fix also resolves a previous issue causing cron jobs to fail.
Original PR description
On multi-company databases, having the defaults value on res.partner fields can unnecessary bloat the database for other companies with different fiscal package (localization). This commit remove the `l10n_ke_branch_code` field default on `res.partner` - the related field on `res.company` has been converted to a stored-compute + inverse so that partner related to a company automatically get the default value `00` whithout needing to touch other partner records. The `l10n_ke_oscu_last_fetch_purchase_date` default on `res.company` has also been removed, cron already fallback to the same default value when none are provided and will update it anyway after it ran. opw-5220129 Forward-Port-Of: odoo/enterprise#105917
This update resolves a visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to ensure the map always displays correctly, regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
This update ensures that the tax returns journal is automatically translated into all supported languages, rather than just the user's language. This improves the accuracy and usability of the tax reporting feature for international users.
Original PR description
Currently, the tax returns journal is created in the code and not via the standard `@template` function that makes sure it is always translated in the installed languages. So for now it was only translated in language of the current user. We refactored the code so the journal gets created via the standard `@template` function and thus automatically gets translated into all the installed languages. task-5921458 Forward-Port-Of: odoo/enterprise#111126 Forward-Port-Of: odoo/enterprise#107465
This update corrects a bug in the demo data for our Odoo Enterprise system. Specifically, it ensures that leave allocations are correctly created when using 'faketime,' which simulates future dates. This prevents errors related to time off calculations and ensures accurate reporting for all users.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690
This update resolves a potential issue where the system couldn't correctly evaluate data within project tasks. The fix ensures that all data used in evaluation processes are treated as strings, preventing errors and improving data integrity. This ensures reliable operation of the industry_fsm module.
Original PR description
literal_eval needs string values to evaluate,
action.get('domain', []) returns non-string value.
Forward-Port-Of: odoo/enterprise#111202This update corrects a problem in the GSTR report testing process. Previously, tests were deleting tax lines, which caused inaccurate reporting. Now, the system correctly removes taxes from the account move line, ensuring accurate GSTR report calculations and compliance.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#111198 Forward-Port-Of: odoo/enterprise#105174
This update corrects an issue with the numbering of report lines within the Vietnamese balance sheet report. Specifically, the order of items under 'I. Short-term liabilities' was adjusted for improved clarity and accuracy. This ensures the report aligns with Vietnamese accounting standards.
Original PR description
- Fixed the numbering of report lines under the section "I. Short-term liabilities" in the balance sheet report 6035762 Forward-Port-Of: odoo/enterprise#111234
This update corrects a technical issue where Helpdesk ticket buttons weren't being properly recognized by the system's editor. The change ensures buttons within email templates function correctly, preventing links from appearing as buttons. This improves the user experience when interacting with tickets.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#110797 Forward-Port-Of: odoo/enterprise#107888
This update corrects a visual discrepancy in the AI Live Chat snippet's appearance, ensuring it matches how it's displayed in real-time. The issue stemmed from mismatched code structures, and this fix ensures a consistent user experience across different devices and configurations. It also resolves a related problem with the fallback button visibility.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change) Forward-Port-Of: odoo/enterprise#109569
This update corrects a technical issue where archived partner data was incorrectly being matched during bank statement retrieval. Now, the system only considers active partners when finding bank statements, ensuring accurate partner assignments and data integrity. This improves the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: Partner auto-detection on statement lines could match archived partners via SQL causing unexpected partner_id assignment. Desired behavior after this commit is merged: Partner retrieval from bank account, partner name, and previous statement lines only considers active partners, preventing archived matches. runbot-238918 Forward-Port-Of: odoo/enterprise#111029 Forward-Port-Of: odoo/enterprise#110446
This update corrects a problem where the company logo was appearing too large on various Odoo reports. The fix targeted a generic CSS selector that was unintentionally affecting multiple reports. This ensures a consistent and professional appearance for all generated reports.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432 Forward-Port-Of: odoo/enterprise#110858
This update fixes a bug where right-clicking on the keypad caused unintended long-press actions. Previously, the system incorrectly interpreted right-clicks as long presses due to how the context menu was handled. This change ensures that only left-button actions are recognized, improving the user experience and preventing unexpected behavior.
Original PR description
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were…
Since [1], some keypad buttons have a long-press value/action and, at worst, they enter the normal key value after the long-press duration. It was later improved by [2] (19.2) and other actions were added such as long-pressing backspace at [3] (19.2) and more recently [4] (19.3) which allows calling the voicemail with long-pressing "1". In all those versions and features, there is the same bug: right-clicking the key triggers the long-press action as the context menu opens over the cursor, then our implementation ends up believing a long-press was performed. Solution: we should never have considered anything else than left-button actions anyways. [1]: https://github.com/odoo/enterprise/commit/82b4c4327fc722f55a0c14b14a916a5cddafa0eb [2]: https://github.com/odoo/enterprise/commit/b9dd0d6fc1fee479e9c8cd4c89dc0a9147891185 [3]: https://github.com/odoo/enterprise/commit/2723ef65622bb206d64e08482f3acd6594c03d28 [4]: https://github.com/odoo/enterprise/commit/dea0baa0dfd76962865717173807e4c945414cd3 task-6055182
This update resolves a potential issue where forum requests could get stuck indefinitely, causing performance problems. A timeout has been added to the /forum/get_url_title endpoint to ensure faster response times and a smoother user experience. This improves the overall stability and responsiveness of the forum.
Original PR description
Add a timeout to the requests done by /forum/get_url_title to avoid blocking indefinitely Forward-Port-Of: odoo/odoo#254607
This update resolves an issue where users with limited access to accounting couldn't successfully import vendor bills in XML format. The fix involved a change to how user permissions are handled during the import process, ensuring that restricted users receive a traceback when attempting to import. This prevents unauthorized access and data manipulation.
Original PR description
[FIX] account_edi_ubl_cii: restricted access user cannot import bill To reproduce: - create a user that has readonly access in Accounting - try to import a XML in vendor bills -> should traceback This commit modifies the `res_field` assignation by setting both `res_model` and `res_id` at the same time Forward-Port-Of: odoo/odoo#254698
This update fixes visual glitches and performance issues within the SelectMenu component, particularly when searching for options. It also improves the styling of the SelectMenu, ensuring a smoother and more reliable user experience across Odoo's SaaS platform.
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 resolves a technical issue where tracking signature fields within Odoo caused system crashes. The change prevents the system from attempting to track signature updates, which aren't supported, ensuring stability. This improves the overall reliability of the mail functionality.
Original PR description
With https://github.com/odoo/odoo/pull/232814, the signature type was introduced as a valid property in properties field type. When a property field of type signature is marked as tracked and its parent field changes, the system attempts to track the signature update. Since tracking image or binary content is not supported and is not implemented, this leads to a NotImplementedError. To prevent this crash, signature property fields are now excluded from tracking. task-5966544
This update resolves a bug where the 'is typing' indicator incorrectly appeared when users were editing messages in Odoo. The fix prevents this indicator from being triggered during edits, aligning with the intended use of the indicator – to signal new message arrivals, not temporary editing actions. Users will now see the message changes immediately without the distracting 'is typing' notification.
Original PR description
Before this commit, when editing a message, this was triggering the "is typing" on this member. This "is typing" was only stopped after the long timeout of 1 min. Typing indicator is meant to expect other others to receive a new message, so this is misleading to show the "is typing" when editing the message. Usually editing message is to fix small typo in a very short time, so it's quite expected for other people to see the new changes without requiring UI indicator other than the "(edited)" label on message textual content. This commit fixes the issue by not notifying is typing on composer of message edition. Task-6045905 Forward-Port-Of: odoo/odoo#254453
This update ensures that when importing tasks from Excel, the recurrence settings specified in the imported data are correctly applied, rather than defaulting to standard recurrence values. Previously, importing tasks without a recurrence ID would overwrite these settings, leading to inconsistencies. This fix guarantees that imported task recurrence aligns with the user's intended schedule.
Original PR description
### Steps to reproduce: - Create a xlsx sheet with some fsm_tasks values with recurrence values - Import the sheet to Field Service > Tasks - Navigate to the created tasks - Notice the recurrence values is the default ones not the ones in the imported sheet ### Cause: If we are importing records without recurrence_id value we will set the recurrence fields' values to the default values while we might already have values for those fields ### Fix: Check if we have values for recurrence fields we don't set the defaults and let the create method create the project.task.recurrence record and set the recurrence_id opw-5925546 Forward-Port-Of: odoo/odoo#249104
This update fixes a bug in the demo data for the HR holidays module. When simulating future time off periods (using faketime), the system incorrectly generated errors due to a mismatch in date calculations. The fix ensures the demo data accurately reflects the start of Anita Oliver's contract, preventing these errors and ensuring the system functions correctly for all time off scenarios.
Original PR description
Issue: The Anita Oliver contract starts on %Y-01-01, so her leave allocation begins from that date. When running with faketime set to 2027-01-01, the system attempts to create leave for the previous month, which results in an error stating that there is no allocation for that time off. Fix: Update the demo data to create the leave and payslip for the first month of the year. This prevents failures when using faketime and ensures it works correctly for real usage of `time off to defer`. task-6026690
This update corrects a minor issue with how product images are displayed on the website. A small typo in a styling code was preventing the images from showing correctly for some users. This fix ensures all users see the product images as intended.
Original PR description
task-6047633 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254817
This update resolves an issue preventing users with standard inventory access rights from printing inventory count sheets. The system was incorrectly restricting access to system parameters, which is now corrected. This ensures all inventory users can generate the necessary reports.
Original PR description
### Steps to reproduce: - Impersonate a user with only Inventory user access rights - Inventory > Operations > Adjustments> Physical Inventory - Select any quant in the list > Print > Count Sheet…
### Steps to reproduce: - Impersonate a user with only Inventory user access rights - Inventory > Operations > Adjustments> Physical Inventory - Select any quant in the list > Print > Count Sheet #### > Access Error: You are not allowed to access 'System Parameter' (ir.config_parameter) records. ### Cause of the issue: The template of the count sheet relies on the `get_param` methods of the `ir.config_parameter` model which requires read access rights on the model: https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/addons/stock/report/report_stockinventory.xml#L36-L39 https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/models/ir_config_parameter.py#L59-L69 This access right is limited to the the `base.group_system` (admin) user group: https://github.com/odoo/odoo/blob/69ec92cd6fd1b5f19c3db8763c12f003c9acf0dd/odoo/addons/base/security/ir.model.access.csv#L118 opw-5959200 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253251
This update fixes a potential issue where errors in outdated HTML snippets would cause the entire builder process to fail. Now, users receive a warning notification if a snippet is outdated, guiding them to update it and resolve the error. This improves the user experience and prevents disruptions.
Original PR description
Since [1], the warning to inform the user that a snippet is outdated has been removed. After this commit, if a builder action fail on outdated snippets (mismatched vcss/vxml/vjs versions), we show a warning notification instead of propagating the error. The notification informs the user that an error occurred on an outdated snippet, and prompts them to drag a new version of the snippet. This is achieved by wrapping try-catch blocks around all builder action lifecycle methods (apply, clean, load, getValue, isApplied) and implementing an error handling method that detects if the snippet is outdated. task-4297808 [1]: https://github.com/odoo/odoo/pull/224382 Forward-Port-Of: odoo/odoo#230816
This update corrects a bug where the messaging menu counter was incorrectly displaying an inflated number of conversations when the Discuss app wasn't in use. The fix ensures the counter accurately reflects active conversations, even after archiving channels, improving the user experience. It also addresses a related issue with muted channels, ensuring accurate counts across all channels.
Original PR description
Before this commit, when page loading in the webclient while not using Discuss (Discuss app closed, no chat window and bubble), the messaging menu counter could be wrong. Steps to reproduce: - Open…
Before this commit, when page loading in the webclient while not using Discuss (Discuss app closed, no chat window and bubble), the messaging menu counter could be wrong. Steps to reproduce: - Open Discuss app - Make a new channel - Post a message in this channel - Mark conversation as unread - Open Advanced settings of this channel - Archive this channel - Go back to home menu - (make sure no chat windows and chat bubbles are open) - Reload the page => The counter of messaging menu should be over-estimated by 1. For example if all conversations are read, counter is 1 instead of 0. Opening the messaging menu refreshes the counter to correct value 0. This happens because when using Discuss, the counter is deduced from all channels that have been fetched and for which current user is a member of these channels. Implicitly, archived channels are filtered out. However when not using discuss, the channels as member have not been fetched, and instead an estimation of the counter is fetched from server. This counter was computed on channel members that have unread messages. When a channel is archived, that doesn't mean the members are archived too. In the steps listed above, the self member is still active. As a result, the self member of this archived channel had contribution to the counter estimation, hence the value of 1 instead of 0. This commit fixes the issue by keeping computation on channel members but it checks also that the channel is active, as the resulting counter is based on active channels. This commit also fixed a similar issue where the counter was wrongly taking muted channels into account on the global counter when not using Discuss. This lead to a similar problem on non-archived but muted channels were they contribute in the estimated counter but not in the actual in-use counter. Task-6014754
This update ensures that presence status notifications are sent only after a user is removed from a record, preventing inaccurate status updates. Previously, notifications were sent using outdated data, leading to incorrect 'offline' statuses. This fix guarantees accurate and reliable presence status information for users.
Original PR description
Before this commit, presence channel notifications for unlinked records were sent before the records were actually removed from the database. This caused `im_status` to be calculated using stale data, occasionally resulting in statuses other than "offline" being broadcast. This commit ensures notifications are sent only after the presences have been unlinked, guaranteeing an accurate status. Forward-Port-Of: odoo/odoo#254186 Forward-Port-Of: odoo/odoo#249314
This update ensures invoices submitted to the Italian Public Administration receive correctly formatted XML responses. Previously, a misinterpretation of the response data caused errors. This fix converts the XML to base64, resolving the issue and ensuring smooth invoice submission.
Original PR description
When submitting invoices to the Italian Public Administration, we receive an updated XML response from IAP with the document including a signature. The response is a raw XML string, not base64. Previously, we tried to encode it incorrectly, causing errors because `l10n_it_edi_attachment_file` direct assignment expects a base64 string. This fix converts the raw XML received from IAP to base64 before assigning it to the `l10n_it_edi_attachment_file` field. It also updates the test to use a correct mock IAP response. Forward-Port-Of: odoo/odoo#254800
This update fixes an issue where the report bubble was too cramped, preventing sufficient address lines from displaying. The layout was adjusted to accommodate more address information by using a smaller logo version. This ensures reports accurately display all necessary address details.
Original PR description
The bubble layout was changed in commit[1] but the logo size is too big to accomodate a sufficient amount of address lines. task-5951770 [1]: odoo/odoo@8eb61a245cd3b650e309fdb55d24654c34d785cd Enterprise PR: https://github.com/odoo/enterprise/pull/110858 | Before | After | |--------|--------| | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/bb2671c3-62c8-45df-8039-4a9455d21982" /> | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/d36ca5fe-24b3-4a74-8323-2c587d11495e" />| | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/2b1c7ce9-2d14-47ab-9fc0-b4bca33e412f" /> | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/df189280-b274-4dea-9ec1-9482c47b00e5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249432
This update clarifies the tooltip for the 'l10n_ca_pst' field in the Quebec sales tax module. Previously, it incorrectly suggested this field was only for PST numbers. The change ensures users correctly input both PST and QST registration numbers, improving data accuracy and compliance.
Original PR description
Currently, the `l10n_ca_pst` field label and help message implies that it is only for the PST number; however, in Quebec the proper name for such a value is the Quebec Sales Tax or (QST) registration number. As such, by updating the help message we clarify to the users that both PST and QST should be placed here. task-5866356 Forward-Port-Of: odoo/odoo#254943
This update resolves a minor technical issue where debugging console logs were accidentally included in the spreadsheet test files. Removing these logs ensures the tests run smoothly and reliably, maintaining the quality and stability of the Odoo spreadsheet functionality. This change does not impact users.
Original PR description
some debugging lines were left in the final PR. Task-0 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