Payroll teams can now control the appearance of salary rule lines on printed payslips, including color, bold, italic, and underline styles. This makes payslip formatting easier to adjust directly from salary rules instead of relying on fixed hard-coded presentation.

In this commit, add styling effect on rule to render on printed payslip. Now you are able to change the rule color, bold, underline, italic styling effect dynamically on the rule. Previously, these styling effects had been hard coded.

task-3810365

Subscription lists now include clearer filters that separate automatic payments, manual payments, and automatic invoicing without payment. This helps users quickly understand how each subscription will be billed, while demo data now supports automatic invoice generation by scheduled jobs.

In this PR, added filters to categorize subscription based on payment_token and online_payment values.
- Filter for automatic payments when there is payment token.
- Filter for manual payment when there is no payment token and online payment is require.
- Filter for automatic invoicing without payment when no payment token and online payment is not require.
- rename "Failed Payments" filter to "In Error" for better user understanding
- make online payment false in demo data of subscription so automatic invoice will be generated by cron.

task-4295759

Payroll now prevents salary attachments from being deleted when they are already linked to a payslip. This helps avoid payroll record inconsistencies and gives users a clear error message explaining why the deletion cannot proceed.

This PR improves the deletion process for salary attachments linked to payslips. An error message is now displayed when attempting to delete a salary attachment associated with any payslip.

task-4007473

Point of Sale orders now automatically include related sub-record information when serialized across several localization and POS add-ons. This improves consistency and reduces manual handling for processes such as fiscal reporting, preparation displays, and rental stock flows.

*: l10n_cl_edi_pos, l10n_de_pos_res_cert, l10n_mx_edi_pos, pos_preparation_display, pos_sale_stock_renting

Automatically mapping sub records of pos_order to be serialized in the pos_order model.

This update cleans up the mail features after recent changes and fixes a small typo affecting mobile mail notification handling. It also adds groundwork to let some email notifications be delayed or handled in batches, which can improve reliability and efficiency for larger mail operations.

The helpdesk portal grouping option now uses the label "Sales Order Item" instead of "Sales Order". This makes the interface more accurate and avoids confusion, since the grouping already worked at the sales order item level and no behavior has changed.

Renamed the group by field from 'Sales Order' to 'Sales Order Item'. The behavior was not changed as it was already grouping by Sales Order Item.

task-4260389

This update streamlines the website signup form in Studio by removing actions that are not needed in that context. This should make the form editing experience clearer and reduce the chance of users selecting unsuitable options.

WIP

India payroll salary rules were simplified by removing duplicate entries for salary assignment and attachment. This reduces confusion in payroll configuration while keeping the net salary calculation unchanged.

Currently, the 'Assignment of Salary' and 'Attachment of Salary' rules are duplicated in the salary rules, and the NET formula is the same. I have removed these duplicate rules from the India payroll.

task-4383807

First-time Documents users now get guided onboarding to help them understand and start using the app more easily. This improves the initial experience by showing relevant guidance only when there is content to work with, reducing confusion during setup.

This commit adds on-boarding support for a user using documents for the first time.

Task-[3729929](https://www.odoo.com/web?debug=assets#id=3729929&cids=2&menu_id=6478&action=4043&model=project.task&view_type=form)

Users can now group tasks by project in the Gantt view without encountering an error. This restores expected project planning behavior and prevents interruptions when reviewing tasks across projects.

Step to reproduce:
- Go to the Project module.
- Open all tasks
- Switch to Gantt view.
- Group tasks by Project.
- Observe the traceback error.

Cause:
- The error occurred after merging this [commit](https://github.com/odoo/odoo/pull/194673/commits/5c2e8c58290571a9d8e59e2602db6493b381945e), This change caused the `filter_domain_leaf()` function to return a `DomainBool` object, leading to the TypeError when attempting to use len() on it in the `_group_expand_project_ids` method.

Solution:
- To fix this, the `filter_domain_leaf()` output was wrapped with `list()`, ensuring that filtered_domain is always a list and allowing the safe use of `len()`.

task-4521684

This error occurs when clicking ``Send to eTIMS``, as the system cannot retrieve tax details for the invoice lines. The issue is caused by the newly created tax lacking proper details, leaving the tax information empty. Steps to reproduce: --- - Install ``l10n_ke_edi_oscu`` module - Switch to ``KE Company`` - Invoicing > Configuration > Accounting > Taxes - Create a NEW Tax -> (Tax Computation= Group of Taxes, Tax Type = Purchase, KRA Tax Code = Select any one) - Create a NEW Vendors Bi

This error occurs when clicking ``Send to eTIMS``, as the system cannot retrieve tax details for the invoice lines. The issue is caused by the newly created tax lacking proper details, leaving the tax information empty.

Steps to reproduce:
---
- Install ``l10n_ke_edi_oscu`` module
- Switch to ``KE Company``
- Invoicing > Configuration > Accounting > Taxes
- Create a NEW Tax -> (Tax Computation= Group of Taxes, Tax Type = Purchase, KRA Tax Code = Select any one)
- Create a NEW Vendors Bill > Add a Product and set a new tax for it
- Click ``Send to eTIMS``

Traceback: 
---
```
StopIteration: null
  File "odoo/http.py", line 2406, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1934, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1997, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 137, in retrying
    result = func()
  File "odoo/http.py", line 1964, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2214, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 334, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 733, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 36, in call_button
    action = call_kw(request.env[model], method, args, kwargs)
  File "odoo/service/model.py", line 62, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "home/odoo/src/enterprise/saas-18.1/l10n_ke_edi_oscu/models/account_move.py", line 497, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "home/odoo/src/enterprise/saas-18.1/l10n_ke_edi_oscu/models/account_move.py", line 192, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "home/odoo/src/enterprise/saas-18.1/l10n_ke_edi_oscu/models/account_move.py", line 243, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
```

At [1], we are encountering ``tax_details['tax_details_per_record'][line] ['tax_details'] = {}`` because there are no tax details available for the newly created tax.

This commit now ensures that both tax lines and tax repartition lines are present in the tax.

[1] - https://github.com/odoo/enterprise/blob/d7d816efdff81c9c6eab1f11b04445f08c73e519/l10n_ke_edi_oscu/models/account_move.py#L243-L247

sentry-6236536577

Forward-Port-Of: odoo/enterprise#77624

runbot-error-108304 Forward-Port-Of: odoo/enterprise#78094

runbot-error-108304

Forward-Port-Of: odoo/enterprise#78094

Same rules as for approval.request Forward-Port-Of: odoo/enterprise#78028 Forward-Port-Of: odoo/enterprise#77892

Same rules as for approval.request

Forward-Port-Of: odoo/enterprise#78028
Forward-Port-Of: odoo/enterprise#77892

Switch to XE's API for currency rates: - Replaced web scraping of XE's website with integration to their paid API. - Updated codebase to handle API authentication and responses. - Updated documentation to reflect the use of XE's API instead of web scraping. IAP: https://github.com/odoo/iap-apps/pull/970 task-4461343 Forward-Port-Of: odoo/enterprise#78226 Forward-Port-Of: odoo/enterprise#77517

Switch to XE's API for currency rates:

- Replaced web scraping of XE's website with integration to their paid API.
- Updated codebase to handle API authentication and responses.
- Updated documentation to reflect the use of XE's API instead of web scraping.

IAP: https://github.com/odoo/iap-apps/pull/970

task-4461343

Forward-Port-Of: odoo/enterprise#78226
Forward-Port-Of: odoo/enterprise#77517

StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period. To reproduce, you can: - Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01" * Recurring plan: Monthly * Start Date: "2024-10-01" - Trigger the cron to invoice & deliver the FIRST period ("2

StockMove.date does not represent the Scheduled date when the move is Done, but the date it was validated. Hence, if the move was validated outside the period it was made for, it will be accounted for in the future period.

To reproduce, you can:
- Create a subscription with a start_date in the past, so that today's date is in the SECOND period: Ex: Today = "2024-11-01"
    * Recurring plan: Monthly
    * Start Date: "2024-10-01"
- Trigger the cron to invoice & deliver the FIRST period ("2024-10-01" -> "2024-10-31").
- Validate the first period picking => "Scheduled Date" becomes the done date: "2024-11-01"
- Trigger the cron to invoice & deliver the SECOND period ("2024-11-01" -> "2024-11-30"). => Second period picking is NOT generated, because the first period picking was interpreted as belonging to the second period.

---

Test result before fix:
```
2024-11-07 13:44:54,695 34298 ERROR oes_17_test_sss odoo.addons.sale_subscription_stock.tests.test_sale_subscription_stock_order: FAIL: TestSubscriptionStockOnOrder.test_picking_done_in_another_period
Traceback (most recent call last):
  File "/home/odoo/projects/odoo-src/multiverse/src/17.0/enterprise/sale_subscription_stock/tests/test_sale_subscription_stock_order.py", line 543, in test_picking_done_in_another_period
    self.assertTrue(bool(second_picking))
AssertionError: False is not true
```

OPW-4280155

Forward-Port-Of: odoo/enterprise#73825
Forward-Port-Of: odoo/enterprise#73484

This commit fix 2 tests who nightly fails on runbot: Test 1, `test_01_orders_no_invoiced` (https://runbot.odoo.com/odoo/runbot.build.error/111519): This test failed because of a `flush_all()`, who raised an error because of an `api.depends_context` on a computed field in `product_template` Solution: remove the `api.depends_context` as he's useless (the compute still trigger as it should) Test 2, `test_read_purchase_order` (https://runbot.odoo.com/odoo/runbot.build.error/111518): This te

This commit fix 2 tests who nightly fails on runbot:

Test 1, `test_01_orders_no_invoiced` (https://runbot.odoo.com/odoo/runbot.build.error/111519):
This test failed because of a `flush_all()`, who raised an error because of an `api.depends_context` on a computed field in `product_template`
Solution: remove the `api.depends_context` as he's useless (the compute still trigger as it should)

Test 2, `test_read_purchase_order` (https://runbot.odoo.com/odoo/runbot.build.error/111518):
This test failed because of access right error
Solution: add a compute_sudo on `l10n_ke_validation_message` field and add a `groups="point_of_sale.group_pos_user"` on account_move view.

no-task

Forward-Port-Of: odoo/enterprise#77636

The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account. no task id Forward-Port-Of: odoo/enterprise#78260

The aim of this commit is making sure that we don't display the bank selection in the dashboard if the journal is already connected to a bank account.

no task id

Forward-Port-Of: odoo/enterprise#78260