Appointment access link handling has been moved out of the appointment app and centralized in the calendar app. This reduces duplicate logic behind the scenes, making the feature easier to maintain and less prone to inconsistencies.

Before this commit, access_token was defined in both appointment and calendar. All access_token logic is now moved to calendar.

task-3017252

The Planning app’s automated tour tests were updated to match the newer schedule scale dropdown and avoid timing-related failures. This helps keep quality checks stable without changing day-to-day user functionality.

The recruitment signing workflow tests were updated after navigation labels were simplified. This keeps automated checks aligned with the product and helps ensure applicant signing flows remain reliable.

The commit a092c5e removes the title attribute on navbar items. The title was only repeating the content so it was useless. This commit fixes an outdated selector in tour.

task: 3097276

Logout now removes leftover user preference cookies, so the next person using the same browser starts with the expected default settings. This prevents preferences such as dark mode from carrying over between different users on shared devices.

Some cookies were left around even when the user logged out.

The next user would not use the default light mode in case the last user was in dark mode.

task-3077421

https://github.com/odoo/odoo/pull/108998

The Helpdesk kanban board header now keeps the correct width when it stays fixed at the top. This prevents the header from visually overlapping or misaligning with helpdesk records, making the board easier to read and use.

The commit [1] makes the kanban group header sticky.
Since then the header can overlap the records but the header
has the wrong width.
This commit fixes the header's width.

[1] 6b21c31b03351d1d1b2630919bd70503055dd765

Bill prediction is now included directly in the Accounting Accountant module instead of a separate module, simplifying setup and maintenance. Product prediction has its own setting, while the unused account prediction setting and old standalone module are removed.

The prediction is now merged into the account_accountant module. The account prediction boolean setting (which was used nowhere) is now replaced by a boolean for product prediction.

Project and field service screens, portal views, and reports were reorganized for greater consistency with the broader project app changes. Customers using field service portals will see clearer time labels and better handling of field service project context.

*=industry_fsm,industry_fsm_{report,sale},project_holidays,sale_timesheet_enterprise

The main changes of this PR are explained in the community PR. Other changes include:

- Added the `fsm_mode` context key in the portal for fsm projects.
- Changed the label of `portal_effective_hours` and `portal_subtask_effective_hours` in the portal to be consistent with their non-portal counterpart.

---

Community: https://github.com/odoo/odoo/pull/106015

Task-2746370

The salary contract wizard was reorganized so the information needed to generate simulation links is handled in one clearer flow. This reduces internal duplication and makes future maintenance easier, with little expected impact on day-to-day users.

The various information in generate.simulation.link is currently calculated and determined in multiple unrelated places. This commit streamlines the flow of this wizard and removes redundant fields to make the code more readable.

task-3050988

Previously, if a serialization error occurred, it would prevent the following documents from being uploaded to the extraction server. Now, the serialization error will be ignored and it will attempt to send the next documents anyways. Ticket #3125117 Forward-Port-Of: odoo/enterprise#35737

Previously, if a serialization error occurred, it would prevent the following documents from being uploaded to the extraction server.

Now, the serialization error will be ignored and it will attempt to send the next documents anyways.

Ticket #3125117

Forward-Port-Of: odoo/enterprise#35737

Forward-Port-Of: odoo/enterprise#35722

Forward-Port-Of: odoo/enterprise#35722

Steps to reproduce the bug: - Install Susbscriptions app and go to it. - Go to configuration > Close reasons. - Remove all default reasons and add a new one (e.g. "Custom reason"). - Go to Susbscriptions, and now try to close a subscription giving the new custom close reason. Issue: We got a traceback missing the proper id for the closing reason. Solution: Changed the way we get the closing reason id, to get it directly from `self.close_reason_id`. Fw-bot up to master opw

Steps to reproduce the bug:

- Install Susbscriptions app and go to it.
- Go to configuration > Close reasons.
- Remove all default reasons and add a new one (e.g. "Custom reason").
- Go to Susbscriptions, and now try to close a subscription giving the new custom close reason.

Issue:

We got a traceback missing the proper id for the closing reason.

Solution:

Changed the way we get the closing reason id, to get it directly from `self.close_reason_id`.

Fw-bot up to master

opw-3114177

Forward-Port-Of: odoo/enterprise#35373

Before this commit, the test_vendor_bill_description_multi_line_format test could fail in some conditions. This test for the invoice name to avoid date sequence check or use of freeze_time. Unfortunately, in some conditions, like running the test on the first of january with account_accountant, the invoice name could be recomputed after post and the test would fail: ``` AssertionError: 'Commission on INV/2023/00001, Customer, 2,000.00\xa0€\nS001[61 chars](s))' != 'Commission on INV/12345/

Before this commit, the test_vendor_bill_description_multi_line_format test could fail in some conditions. This test for the invoice name to avoid date sequence check or use of freeze_time.

Unfortunately, in some conditions, like running the test on the first of january with account_accountant, the invoice name could be recomputed after post and the test would fail:

```
AssertionError: 'Commission on INV/2023/00001, Customer, 2,000.00\xa0€\nS001[61 chars](s))' != 'Commission on INV/12345/0001, Customer, 2,000.00\xa0€\nS001[61 chars](s))'
- Commission on INV/2023/00001, Customer, 2,000.00 €
?                   ^^   -
+ Commission on INV/12345/0001, Customer, 2,000.00 €
?                   ^  ++
```

This commit makes sure to update the invoice name after the invoice confirmation.

Runbot issue: https://runbot.odoo.com/web/#id=22347937&cids=1&model=runbot.build&view_type=form

Forward-Port-Of: odoo/enterprise#35576

currently the module is named as LT, where as it has to be Lithuania according to odoo localization module standards Forward-Port-Of: odoo/enterprise#35447 Forward-Port-Of: odoo/enterprise#35032

currently the module is named as LT, where as it has to be Lithuania according to odoo localization module standards

Forward-Port-Of: odoo/enterprise#35447
Forward-Port-Of: odoo/enterprise#35032

No default value for the partner_name in `message_new` forbids tickets created from a mail alias to enter the custom "partner flow creation" defined in the create method of helpdesk.ticket. **Issue 1, steps to reproduce:** 1. Set an email alias an helpdesk team 2. Send an email to this alias (for example, from "Client A <client_a@someprovider.com>") _Before this commit:_ a partner is created, with name "client_a@someprovider.com" and email "client_a@someprovider.com" _After this com

No default value for the partner_name in `message_new` forbids tickets created from a mail alias to enter the custom "partner flow creation" defined in the create method of helpdesk.ticket.

**Issue 1, steps to reproduce:**
1. Set an email alias an helpdesk team
2. Send an email to this alias (for example, from "Client A <client_a@someprovider.com>")

_Before this commit:_ 
a partner is created, with name "client_a@someprovider.com" and email "client_a@someprovider.com"

_After this commit:_
a partner is created, with name "Client A" and email "client_a@someprovider.com"

**Issue 2, steps to reproduce:**
1. Set an email alias an helpdesk team
2. On the default stage of this team, remove the Email Template
3. Send an email to this alias (for example, from "Client A <client_a@someprovider.com>")

_Before this commit:_
no partner is created

_After this commit:_
a partner is created, with name "Client A" and email "client_a@someprovider.com"

opw-2982426

Forward-Port-Of: odoo/enterprise#35577
Forward-Port-Of: odoo/enterprise#32047

This revision is a follow-up of odoo/enterprise#33526 odoo/enterprise#34372 When disabling the employee multi-company record rule, the fix done in odoo/enterprise#33526 triggers the below bad SQL query: ``` bad query: SELECT aal.employee_id as employee_id, COALESCE(SUM(aal.unit_amount), 0) as worked_hours FROM account_analytic_line aal WHERE aal.employee_id IN () AND date >= '2021-04-01' AND date <= '2021-04-30' GROUP BY aal.employee_id

This revision is a follow-up of
odoo/enterprise#33526
odoo/enterprise#34372

When disabling the employee multi-company record rule, the fix done in odoo/enterprise#33526 triggers the below bad SQL query:
```
bad query:
            SELECT aal.employee_id as employee_id, COALESCE(SUM(aal.unit_amount), 0) as worked_hours
            FROM account_analytic_line aal
            WHERE aal.employee_id IN () AND date >= '2021-04-01' AND date <= '2021-04-30'
            GROUP BY aal.employee_id

ERROR: syntax error at or near ")"
LINE 4:             WHERE aal.employee_id IN () AND date >= '2021-04...
```

Because
```py
self.env.cr.execute(query, (tuple(employees.ids), date_start, date_stop))
```

receives an empty list of ids `employees.ids`
because `employees` are forced within the code to belong to the user companies, despite the record rule being disabled.
```py
employees = self.env['hr.employee'].with_context(active_test=False).search([
    ('id', 'in', [data['id'] for data in employees_grid_data]),
    ('company_id', 'in', self.env.companies.ids),
])
```

Letting users disabling multi-company rule is tolerated, and so, the code should be resilient to that fact. Hence, this piece of code shouldn't hard-code to filter out employees which do not belong to the current user companies.

odoo/enterprise#33526 solves an access right issue when the grid view is trying to display a timesheet in the current user company but assigned to an employee from another company. It did so by not displaying at all the timesheets in the grid view assigned to employees not part of the user companies, even if the timesheet itself was in the user companies.

The above behavior, while it does solve the reported issue for that revision, is not perfect as it no longer displays in the grid view timesheets you are entitled to see, as they are in your current companies. But, because they are assigned to employees of other companies, it removes them from the grid view.
For instance, you can see these timesheets assigned to employees of other companies in the tree view.
Why couldn't you see in the grid view timesheets you can see in the tree view ?
Another case is an employee changing of company:
Let's say an employee is employed Odoo Belgium,
log some timesheets while working in Odoo Belgium, than move to Odoo US.
Suddenly, his manager in Odoo Belgium will no longer see in the grid view his timesheets, which is incorrect.

Instead of not allowing the user to see those kind of timesheets in the grid view, just read the data the user lacks the access right to as sudo (`employees.resource_id`).
That way, the user still sees the timesheets in the grid view, even for employees of other companies.

This revision adds unit test for the 3 cases:
- The case odoo/enterprise#33526 solves,
- The case odoo/enterprise#34372 solves,
- This new case of the disabling the multi-company rule.

The issue has been reported by a user of Odoo.com while upgrading to Odoo 16.0:
> [ASE] All timesheet, search on an employee trigram (MAB) in this case & try to load monthly grid view & get traceback: https://pastebin.com/yM9SAzgi

Forward-Port-Of: odoo/enterprise#35664

GST return filing using IAP ===================== In this commit, we introduce a new module for filing GST returns. GSTR-1: Send and view a summary report GSTR-2B: matching GSTR-3B: view report Forward-Port-Of: odoo/enterprise#34481

GST return filing using IAP
=====================
In this commit, we introduce a new module for filing GST returns.

GSTR-1: Send and view a summary report
GSTR-2B: matching
GSTR-3B: view report

Forward-Port-Of: odoo/enterprise#34481

Before this commit, the test would fail with the following error: ``` FAIL: TestSubscriptionController.test_automatic_invoice_token Traceback (most recent call last): File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 169, in test_automatic_invoice_token subscription = self._portal_payment_controller_flow() File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 248, in _portal_payment_controller_flow

Before this commit, the test would fail with the following error:
```
FAIL: TestSubscriptionController.test_automatic_invoice_token
Traceback (most recent call last):
  File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 169, in test_automatic_invoice_token
    subscription = self._portal_payment_controller_flow()
  File "/data/build/enterprise/sale_subscription/tests/test_subscription_controller.py", line 248, in _portal_payment_controller_flow
    self.assertEqual(subscription.invoice_ids.payment_state, 'in_payment')
AssertionError: 'paid' != 'in_payment'
- paid
+ in_payment

```

Runbot task: 14926

Forward-Port-Of: odoo/enterprise#35728

The general ledger uses the generic tax report to generate some lines for sales and purchases journals. The problem was that if your company was in a country that had a variant of the tax report, it will try to use that report instead. That would create an inconsistency between report ids that would raise an error. This commit forces the use of the generic tax report for this case, keeping the report ids consistent. opw-3114298 Forward-Port-Of: odoo/enterprise#35700

The general ledger uses the generic tax report to generate some lines for sales and purchases journals.

The problem was that if your company was in a country that had a variant of the tax report, it will try to use that report instead. That would create an inconsistency between report ids that would raise an error.

This commit forces the use of the generic tax report for this case, keeping the report ids consistent.

opw-3114298

Forward-Port-Of: odoo/enterprise#35700

Currency rates are updated based on the day that it is requested. However the ECB only updates rates at 16:00, therefore we could be retrieving the exchange rates for the wrong day. With this fix, we use the date provided in the XML Task-3131497 Forward-Port-Of: odoo/enterprise#35735

Currency rates are updated based on the day that it is requested. However the ECB only updates rates at 16:00, therefore we could be retrieving the exchange rates for the wrong day. With this fix, we use the date provided in the XML

Task-3131497

Forward-Port-Of: odoo/enterprise#35735

The bank reconciliation widget tries to restore the last statement line that was active when returning to the kanban. It's possible that the statement line is not available in the list of records, causing a stacktrace. To replicate: Accounting > Dashboard > Reconcile 8 Items Switch to list view Search for a transaction that returns 0 records for eg. yabadabadoo Switch to kanban With this fix, no record is selected and the no_content_helper screen is displayed instead Forward-Port-Of: o

The bank reconciliation widget tries to restore the last statement line that was active when returning to the kanban. It's possible that the statement line is not available in the list of records, causing a stacktrace.

To replicate:
Accounting > Dashboard > Reconcile 8 Items
Switch to list view
Search for a transaction that returns 0 records for eg. yabadabadoo Switch to kanban

With this fix, no record is selected and the no_content_helper screen is displayed instead

Forward-Port-Of: odoo/enterprise#35724