Monday, June 1, 2026
35 changes · saas-19.2
Enhancements to existing features
This update clarifies how half-day work periods are displayed on payslips. Previously, half-days were shown as separate entries, which was confusing. Now, the system consolidates these entries for a clearer and more straightforward view of employee work time and pay.
Original PR description
In order to clearly distinguish work days that extended full day or half day, the worked days under the payslips will not display both entries as separate types with the half days flagged Task: 5975762 Forward-Port-Of: odoo/enterprise#112328
This update enhances the design of Odoo's documentation links by adding styling options through 'class' props. Previously, these links were fixed in appearance, limiting their use in different contexts. Now, developers can easily customize the links to fit various design needs, increasing their versatility.
Original PR description
Before this commit, the style of that component is fixed, thus it is not possible to customize it to render that component as a secondary button neither display it as dropdown item. This commit adds the `class` props in that component to be able easily change the style to use that component anywhere. task-6095833 Forward-Port-Of: odoo/odoo#267114
Resolved issues and error corrections
This update resolves a technical issue preventing correct reporting of US Chart of Accounts settings. The previous implementation caused a conflict between files, leading to incorrect formatting. This change consolidates the US CoA definitions for improved reporting accuracy.
Original PR description
In 19.1, when `account_reports_negative_format` was introduced, the PR created a new `template_us` file for `l10n_us_reports` to set the new field, not realizing that `account_chart_template` already existed. Since both files were to the same template and had the exact same method name, one shadowed the other which means all this time the `negative_format` was not properly set for US CoA. Since most other countries keep their CoA in a `template_TEMPLATE_NAME.py` file, move the deferred accounts to `template_us` and remove the `account_chart_template` file. task-none Forward-Port-Of: odoo/enterprise#118712
This update resolves an issue where deleting an action linked to an inactive filter would sometimes cause an error. The change ensures that inactive filters are also removed when an action is deleted, preventing data inconsistencies and improving the user experience. This improves data integrity and stability.
Original PR description
How to reproduce: - Delete an action linked to an inactive user-defined filter. - Go to the User-Defined menu, - Show inactive filters (with "Archived filter") - Got a MissingError. Explanation: odoo/odoo#156622 fixes an inconsistency when deleting an action, but the reviewer was "amorti" so he (I) forgot to account for inactive "ir.filters". Add active_test=False to ensure inactive "ir.filters" are also removed. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266761 Forward-Port-Of: odoo/odoo#262195
This update resolves an issue where a test in the account payment module was unreliable due to dependencies on a module not always present. The test has been updated to use a more direct method, ensuring consistent and stable results. This improves the overall quality and reliability of our payment processing tests.
Original PR description
The set_line_bank_statement_line method is defined in account_accountant, meaning we can't use it in account_payment as it will automatically break if enterprise is not installed. Replace it with direct call to _get_partial_amounts, which is the purpose of this test anyway. runbot-939260 Forward-Port-Of: odoo/odoo#267139
This pull request addresses minor issues identified during the recent update of the French payroll module (l10n_fr_pdp). It backports necessary fixes to ensure proper functionality and data accuracy within this module. This update improves the reliability of financial reporting for French businesses using Odoo.
Original PR description
Backports some fixes discovered during FW-porting task-None Forward-Port-Of: odoo/odoo#267375 Forward-Port-Of: odoo/odoo#267330
This update fixes an issue where commission plans were incorrectly shown in a salesperson's list even when their assignment periods didn't overlap. The system now accurately checks for overlapping assignment dates, ensuring that only relevant plans are displayed, improving reporting accuracy and plan management.
Original PR description
Version - 18.0 Steps to reproduce: 1. Create a commission plan A with effective period 2025–2026 2. Assign salesperson to plan A from 01/01/2025 to 31/12/2025 3. Create another commission plan B with effective period 2026 4. Assign the same salesperson to plan B from 01/01/2026 to 31/12/2026 5. Open plan B and check the 'Other Plans' section in the salespeople tab Issue: Plans are shown in 'Other Plans' even when salesperson assignment periods do not overlap. System incorrectly relies on plan effective dates instead of salesperson-specific assignment dates Fix: A plan is now considered overlapping only if the salesperson assignment periods intersect. Non-overlapping plans are properly excluded from 'Other Plans'. Taskid-6055253 Forward-Port-Of: odoo/enterprise#118769 Forward-Port-Of: odoo/enterprise#112694
A recent update caused an error when users attempted to cancel draft POS orders. This fix removes a problematic code change that was causing the error, allowing users to successfully cancel draft orders. This ensures smooth order management within the POS system.
Original PR description
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select…
Currently an error is generated when the user tries to cancel a draft POS order as follows: - Install the `pos_enterprise` module with demo data - Open the register of `Furniture store` and select any product - Click on the `Upload` icon to save the draft order and go to the backend. - Navigate Orders > Orders > open Draft order - Click the `cog` icon and click `Cancel Order` >>> Error occurs This issue is caused by the recent refactor introduced in [1]. The `action_pos_order_cancel` action now returns the `order` (`pos.order` recordset) instead of default returning `None`. As a result, the `action` variable contains a `pos.order` recordset, and an error is raised at line [2] when `setdefault` is called on it, since `setdefault` expects a dictionary-like object. This commit fixes the above issue by removing the code that returns the `pos.order` object from the action. As a result, the action now behaves as expected and returns the default value (`None`). [1]: https://github.com/odoo/enterprise/commit/27f57036a1d0468efe6e68d7aceafe0f01b21f93 [2]: https://github.com/odoo/odoo/blob/48f93ca056633bd5cba36b66ee1008fb57ca666c/addons/web/controllers/utils.py#L24 Sentry-7354160052 Forward-Port-Of: odoo/enterprise#118035
This update resolves an issue where users without specific accounting permissions were encountering errors when loading templates within the knowledge article feature. The fix delays access to sensitive audit reporting data, ensuring the feature works correctly for a wider range of user roles. This improves usability and prevents disruptions for users accessing this functionality.
Original PR description
Steps to reproduce: 1. Install `accountant_knowledge` with `demo data` 2. Remove demo user from bookkeeper access right and give some lesser right 3. Open knowledge and create a new artical with demo user 4. Click on Load template for example `Meeting Minutes` Issue: It gives a access error: `This operation is allowed for the following groups: - Accounting/Bookkeeper` Cause: - accountant_knowledge was doing accounting-only work during generic template loading. Immediately calling `target_article._get_inherited_audit_report()` that returns `inherited_audit_report_id`, which is a computed relation to audit report. `audit.report` is only readable by `account.group_account_user` Solution: - delay that access until it is actually needed, - only if the template contains data-embedded="accountReport" opw-6067390 Forward-Port-Of: odoo/enterprise#117292 Forward-Port-Of: odoo/enterprise#112946
This update fixes an issue where manually creating a bill from the purchase dashboard would always use the default purchase journal. Now, the system correctly selects the journal the user was previously viewing, ensuring bills are created in the appropriate accounting context. This improves the accuracy and reliability of purchase transactions.
Original PR description
This commit fixes the default journal used when pressing "Create a bill manually" on a purchase journal in the journals dashboard. Previously, when creating a bill manually, it would be created on the default purchase journal. Now, the correct purchase journal is chosen depending on which journal I pressed the "creating a bill manually" link from. task-6167135 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261586
This update corrects an issue where placeholder text within blog posts was incorrectly displayed as HTML spans when translations were applied. The fix ensures that placeholder text always shows as plain text, improving the user experience and consistency across languages. This resolves a visual inconsistency that could confuse users.
Original PR description
Since placeholder attribute is translated, for non-form elements placeholder attributes that contain a translation <span/> need to be unwrapped to restore the plain text value. Steps to reproduce the issue: - Have website and website_blog installed - Add a second language - Open a blog post in your second lanuage - Start translating - Remove the blog title => Shown placeholder text is <span ...> task-5190459 Forward-Port-Of: odoo/odoo#267327 Forward-Port-Of: odoo/odoo#263320
This update ensures that customers only see product categories accessible from their current website view. Previously, some categories were incorrectly displayed on Website 1, leading to a 'Not Found' error. The fix filters categories based on website access, improving the user experience and preventing broken links.
Original PR description
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. -…
Steps to produce: --- - Install `website_sale` with demo data. - Go to `website > ecommerce > products > ecommerce categories`. - Open `Desks/Components` category > Set website to `My website 2`. - Open the shop page on website > Click on Desks category. Issue: --- - The Components subcategory is still displayed on Website 1. - Clicking on it leads to a Not Found page since the category is not assigned to that website. Root cause: --- - At [1], In the category filmstrip template, subcategories are fetched without filtering based on website access. - As a result, categories restricted to another website are still shown. Solution: --- - Filter categories using the `can_access_from_current_website` method to ensure only categories accessible from the current website are displayed. [1]https://github.com/odoo/odoo/blob/900fc043064216c5943ea07392d8120be7b50b63/addons/website_sale/views/templates.xml#L758-L769 opw-6159549 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266637 Forward-Port-Of: odoo/odoo#262410
This update resolves an issue preventing correct calculation of the 13th month salary in the Belgian localization. The fix ensures the forced variable salary is properly applied during payslip computation, addressing a previous type error.
Original PR description
Steps to reproduce: * Create a new payslip in belgian localization * Set pay structure type to 13th month * Set the input value for the forced variable salary * Compute the payslip sheet Issue: * Despite the change of benefits to properties, the avg_variable_revenues was still being set as one of the benefit lines instead of ref_property value which was causing an type_error traceback Solution: A simple approach is to be followed to retrieve the value fo the forced variable salary from the actual property being set by the user at the payslip form view and will be accounted for in the payslip computation. Task: 6241608 Forward-Port-Of: odoo/enterprise#118644
This update resolves an issue where the employee org chart would crash when displaying records with a missing 'write_date' field. This occurred due to a type error when attempting to use the timestamp of a NULL value. The fix mirrors a similar pattern used elsewhere in Odoo to gracefully handle missing dates, ensuring the chart loads correctly for all employee records, including those with legacy data.
Original PR description
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python #…
### Description of the issue / feature this PR addresses The Odoo 19.0 \`hr_org_chart\` controller passes \`employee.write_date\` to JS as a cache-busting key: \`\`\`python # addons/hr_org_chart/controllers/hr_org_chart.py:35 write_date=int(employee.write_date.timestamp()) * 1000, # to have it in milliseconds for js \`\`\` When \`hr_employee.write_date\` is NULL the ORM returns \`False\` for the field, so the unconditional \`.timestamp()\` call raises: \`\`\` AttributeError: 'bool' object has no attribute 'timestamp' \`\`\` This crashes the employee form view on click for any record with NULL \`write_date\`. NULL audit columns can occur in legacy databases — records inserted via direct SQL by data-loaders, rows carried forward from very old Odoo versions that did not always populate \`_log_access\` columns, or data restored from anonymised backups. The ORM's \`vals.setdefault\` defaults in \`_log_access\` do not override an explicit falsy value passed by callers. This is a regression vs 18.0 — the 18.0 \`_prepare_employee_data\` did not include \`write_date\` at all. ### Behaviour before this PR Opening the form view of an employee with NULL \`write_date\` (any affected employee record) raises \`AttributeError\` and the org chart fails to load. ### Behaviour after this PR The controller falls back to \`0\` when \`write_date\` is missing — the same defensive pattern already used in \`odoo/addons/base/models/avatar_mixin.py:67\`: \`\`\`python bgcolor = get_hsl_from_seed(self[self._avatar_name_field] + str(self.create_date.timestamp() if self.create_date else "")) \`\`\` The org chart loads; the JS cache key for that one record is \`0\` until the record is next written (which will set \`write_date\` via the normal ORM path). No user-visible regression on healthy rows. Forward-Port-Of: odoo/odoo#264591
This update makes carousels on the website more user-friendly by pausing automatic sliding when a user prefers reduced motion. It also increases the time between carousel image changes from 1 second to 5 seconds, preventing a jarring and fast-paced experience. This improves accessibility and overall website performance.
Original PR description
Auto-sliding carousels should be paused if the user chose prefers reduced motion. This commit also increases the fallback interval when none is set from 1s to 5s. Cycling through images every second is much too fast. task-5470023 Forward-Port-Of: odoo/odoo#266997 Forward-Port-Of: odoo/odoo#250169
This update resolves a warning message that appeared during AI development in Odoo 19.2. The change ensures the warning remains visible, as it was previously suppressed due to limitations in earlier versions. This maintains visibility into potential issues during AI integration.
Original PR description
This reverts commit e1c71a90b3e7163733cba3da401eaf473f190fef. The warning is fine. https://github.com/odoo/odoo/pull/259007#issuecomment-4299650605 > il fallait justement stop le forward-port en 18.2, on veut le warning, mais on n'avait pas la possibilité d'en avoir un avant 18.1 Forward-Port-Of: odoo/odoo#266967 Forward-Port-Of: odoo/odoo#262841
This update resolves an issue where Odoo couldn't properly serialize Date, Datetime, or Binary values stored in sparse fields when exporting data to JSON. The fix utilizes existing Odoo tools to handle these types natively, preventing errors and ensuring data is consistently serialized. This improves the reliability of data exports and integrations.
Original PR description
Storing a sparse field of type Date, Datetime or Binary raises a TypeError because json.dumps() cannot natively serialize the Python objects returned by convert_to_read (date/datetime instances and bytes). Fix Serialized.convert_to_cache to pass json_default (from odoo.tools.json) as the default serializer to json.dumps(). This handles Date, Datetime and Binary values without any extra conversion step in _inverse_sparse, and reuses the existing Odoo infrastructure instead of introducing a custom helper. Steps to reproduce: 1. Create a model with a sparse field of type Date, Datetime or Binary 2. Set a value on it 3. → TypeError: Object of type date is not JSON serializable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266779
This update corrects a minor inaccuracy in how remaining days are displayed. Specifically, when deadlines are very close to the current date, the display was sometimes misleading (e.g., showing 'Next month' for a deadline of May 1st when today is April 30th). This change ensures a more precise and user-friendly representation of time remaining.
Original PR description
Luxon is not very accurate when the field is close to today: If today is Apr 30, so a deadline set to May 1 will be displayed as "Next month". In practice, it is not wrong, but it is not very accurate. task-6175442 Forward-Port-Of: odoo/odoo#267102
This update optimizes the HTML editor's performance, specifically when handling large tables like the Accounting > Balances Sheets. By changing a selector, the system now recalculates styles more quickly, reducing delays during actions like hovering or sorting, leading to a smoother user experience.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267165
This update automatically sets the deductibility prorata rate to 100% by default in the Iranian (l10n_ma) tax reports. Previously, users had to manually configure this rate, which often led to inaccurate tax reports. This change ensures more reliable tax reporting for businesses using the Iranian localization.
Original PR description
Users often forget to complete the deductibility prorata rate, which makes the tax report seems buggy. Set the rate to 100% by default. task-6092580 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263486
This update fixes an issue where replenishment quantities weren't being rounded correctly when the product and replenishment UoM were the same. Previously, orders were calculated with decimals, leading to inaccurate replenishment amounts. This change ensures that replenishment quantities are rounded to the nearest whole unit, aligning with expected inventory behavior.
Original PR description
**Issue** Replenishment quantity is not rounded when the replenishment UoM is the same as the product UoM. **Steps to reproduce**: - Enable "Units of Measure & Packagings" setting - Create a tracked…
**Issue** Replenishment quantity is not rounded when the replenishment UoM is the same as the product UoM. **Steps to reproduce**: - Enable "Units of Measure & Packagings" setting - Create a tracked product and add a vendor using the same uom (ex: Unit) - Create a replenishment order rule: - min = 0 - max = 10 - multiple: Unit - Create a sale order for that product with 1.11 units -> It tries to replenish 11.11 units instead of 12 **Cause**: While computing `qty_to_order`, it rounds using the given multiple via `_get_multiple_rounded_qty`: https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L471-L475 However, `_get_multiple_rounded_qty` skips rounding when the replenishment UoM matches the product UoM: https://github.com/odoo/odoo/blob/995629db3231de944710751c3184bf1b8b1355c7/addons/stock/models/stock_orderpoint.py#L802-L809 opw-[6015189](https://www.odoo.com/web#id=6015189&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#262105 Forward-Port-Of: odoo/odoo#256006
This update resolves a rare test failure related to timing issues in the website's interaction testing. The fix eliminates a potential delay caused by waiting for animation frames, ensuring more reliable test results. This improves the overall stability of the website development process.
Original PR description
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise…
This commit fixes the test "waitForTimeout does not trigger update if interaction is not ready yet", which could very rarely fail on runbot. **Origin of the problem** The test relies on precise timings, but the helper `advanceTime` could introduce a non-deterministic lag because, when called with default options, it awaits for an animation frame. If the lag happens to be too long, the second `verifySteps` is called too late and the test fails. **Fix** The helper `advanceTime` is now called with the option `animationFrame` set to false to avoid awaiting for an animation frame. For additional safety, the waiting time is also reduced. Two changes not directly related to this problem have been applied to improve the test: 1. an unnecessary `await` in `willStart` has been removed; 2. the `animationFrame` has been set to false also on the second `advanceTime` (a non-deterministic lag here can't fail the test, but still there is no reason to await for the animation frame). runbot-243515 Forward-Port-Of: odoo/odoo#266432
This update fixes an issue where the sidebar menu wouldn't scroll properly when it contained a large number of items, preventing users from accessing the bottom menu options. The fix adds scrolling functionality to the sidebar menu, ensuring a smoother user experience, particularly with extensive menus. This resolves a long-standing issue that has persisted across multiple Odoo versions.
Original PR description
Scenario: - set menu bar as sidebar - adds lot of menu item (or decrease page height) - try to scroll to bottom menu item that are not shown Result: you can't see the bottom of the menu Cause: there is no overflow auto on sidebar elements so the default visible is used without possible scroll. This issue doesn't happen for hamburger menu (hamburger template or on mobile) because it wraps the menu in an .offcanvas-body element that has in bootstrap overflow-y: auto Fix: add vertical overflow to o_header_sidebar menu. opw-5486934 --- __pr note__: I'm not sure if there is a reason this was not done yet or if this has just not been reported. The behavior happen from 16.0 to now. Since the query is from 19.0 to lower risk (and since it's not really broken, just not working with a big number of menu) I've targeted 19.0 but I could go lower if wanted. Forward-Port-Of: odoo/odoo#252047
This update clarifies the meaning of a document access right within the Documents app. Previously, 'No' indicated no access, which was misleading. It's now 'Basic,' accurately reflecting that users retain access to their own and shared documents.
Original PR description
In the Documents app, the lowest tier access right was called "No", which implies the user has no access. However, this is not the case. The user still has access to the app, their own documents, and shared documents. To resolve this confusion, "No" is changed to "Basic" and the relevant descriptions are updated. task-6099135 Forward-Port-Of: odoo/enterprise#113660
This update ensures that changes to pricelist item dates made after a Point of Sale session is opened are correctly reflected within that session. Previously, reloading the POS wouldn't update the items. This improves the accuracy of pricing displayed to customers during transactions.
Original PR description
Before this commit, if the date validity of a pricelist item was changed after opening a POS session, reloading the POS won't update the items. opw-6223217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#265211
This update resolves a test failure related to how binary data is handled during the import of Italian electronic invoices. The fix ensures test data is correctly formatted for Python 3.14's stricter base64 validation, preventing an error and ensuring the test runs successfully.
Original PR description
This commit fixes an error when running the `test_edi_import` test on Python 3.14, which is stricter about base64 validation. Ultimately, the root issue was that raw test content was being passed to the `datas` field of an attachment when a base64 representation was actually expected (which is obviously invalid base64). Passing it via the `raw` field instead correctly handles the raw binary data. runbot-939133 Forward-Port-Of: odoo/odoo#266731
This update resolves a minor issue in the POS system's testing process. A recent change introduced a new property within the data generated for preparation, and this fix ensures the tests accurately reflect this updated data. This ensures the POS functionality continues to operate correctly.
Original PR description
The community PR added a new property (`order_name`) to `extra_data` returned by `generatePreparationData`. We adapt the assertion in this test to account for that new field. opw-6208965
This update fixes an issue where the Timesheet Assistant incorrectly suggested declined calendar events. The change now includes events where the user is an attendee, regardless of their RSVP status, providing more relevant suggestions. This ensures the Timesheet Assistant offers a more complete and accurate view of available calendar events.
Original PR description
### Before this commit: The Timesheet Assistant would incorrectly suggest calendar events that the user had explicitly declined. Furthermore, the domain only retrieved events where the user was the organizer (`user_id`), completely missing events where the user was only an attendee. ### After this commit: The `get_calendar_events` getter in `_get_assistant_events_getters` is updated to: 1. Include events where the current user is an attendee by adding a condition on `partner_ids`. 2. Explicitly exclude events where the user's `calendar.attendee` status is 'declined'. Task-6222659 Forward-Port-Of: odoo/enterprise#117613
This update resolves a bug where the time parser incorrectly handled German time entries with capital letters (e.g., '2h30m'). The fix ensures the parser correctly interprets time formats, including those with minutes, regardless of the user's language setting.
Original PR description
Issue: ---------------------------------------- In German, using a time field with minutes breaks the parser and only the hours are taken into account. Steps to reproduce:…
Issue:
----------------------------------------
In German, using a time field with minutes breaks the parser and only the hours are taken into account.
Steps to reproduce:
----------------------------------------
- Install Timesheet and Project
- Change language to German
- Open a task, page "Timesheets"
- Create a new record
- Write "2:30" to set the time, it will work
- It won't work if you add an UoM, i.e. "2h30m", "2h 30 Min."
Cause:
----------------------------------------
In German all common nouns begin with a capital letter so their UoMs too.
In the parser we call `durationUnitsRegex` which uses a library to get the UoMs in the local language.
https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/core/l10n/time.js#L289-L298
For Germany, the abbreviations will have capital letters ("Min.", "Sek.", etc.). So there will be upper case letters in the regex.
But the string on which we call the regex is only lower case:
https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/views/fields/parsers.js#L185-L189
https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/core/l10n/time.js#L271-L277
So the regex returns no match.
Solution:
----------------------------------------
When building the regex, we call `RegExp()` constructor with "i" to ignore cases.
opw-6236787This update corrects a bug in the website builder where an unnecessary `<p>` tag was added when inserting icons. This prevented icons from being displayed correctly and caused formatting issues. The fix ensures icons are wrapped in `<p>` tags only when appropriate, maintaining proper website styling.
Original PR description
When the "icon" snippet is dropped, after the icon is selected and inserted, a call to `wrapInlinesInBlocks` ensures the icon is wrapped in a `<p>` element. The added `p` is only desired when the icon snippet is dropped between blocks, and it is problematic when the icon snippet is dropped "inline". This commit only wraps the icon if needed (aka, the parent `allowsParagraphRelatedElements`) Steps to reproduce: - Open website builder - Select a span of text and turn it bold - Type `/button` inside the bold text and add a button - Drag and drop the "Icon" snippet (an inner content snippet) - Select any icon - Bug: a `<p>` element is added in the `strong` element (which is invalid html), and this adds line breaks (and the style is affected if the line breaks are manually deleted) task-6251585 Forward-Port-Of: odoo/odoo#266735
This update removes a confusing placeholder in the accounting module that encouraged users to create specific ledger types. The change streamlines the process by removing the suggestion and acknowledging the existing 'Local GAAP' option, improving clarity and reducing potential errors for users.
Original PR description
The placeholder 'e.g. GAAP, IFRS, ...' is confusing for the users as it encourages them to create a GAAP ledger, or there is already an implicit ledger for that called 'Local GAAP'. task-6260588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a reporting issue where the 'Local GAAP' implicit ledger would sometimes appear empty when all company journals were assigned to a single ledger. Removing this empty ledger from report selections ensures accurate and consistent financial reporting for users. This improves the reliability of key financial reports.
Original PR description
When all journals of the company are in a ledger, the implicit ledger 'Local GAAP' is empty, so we remove it from the ledger selection in the reports. task-6260588
This update resolves an issue where date formatting in the spreadsheet module was inconsistent across different Chrome versions. A change in underlying dependencies caused variations in how dates were displayed, leading to test failures. This revision ensures a consistent and reliable date format is used within the spreadsheet functionality.
Original PR description
Some dependencies in the chrome build changed between chrome 145 and 148 which changes the output value of luxon.Interval.toLocaleString, more specifically, some space characters were changed and the tests can pass or not depending on the chrome version they run with. This revision forces a standardized output. task-6233171 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#267254 Forward-Port-Of: odoo/odoo#265565
This update adds a direct link within the Timesheets Assistant interface to the relevant documentation. This makes it easier for users to quickly find information and support related to the Timesheets Assistant feature. It's a small change intended to improve user experience and knowledge access.
Original PR description
This commit adds documentation link in Timesheets Assistant to redirect the user to the documentation of Timesheets Assistant. task-6095833 Forward-Port-Of: odoo/enterprise#118754
This update optimizes the performance of the MRP work order display, specifically during tasks like resizing windows or scrolling. By changing a technical selector, the system now recalculates styles more efficiently, leading to a smoother user experience. This is a minor improvement focused on responsiveness.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior, this reduces work during the "Recalculate Style" phase. It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. Forward-Port-Of: odoo/enterprise#118618