Followers of regular mail channels that have email sending turned off will no longer receive emails just because they follow the channel. This supports using channel follows for mobile push notifications without creating unwanted email, while direct mentions can still trigger email based on the user’s notification settings.

Do not send email to partner followers of non-mass-mailing channels.

When a partner follows a channel without "Send messages by email",
we expect the follower to not receive any email whatsoever.

This behaviour is required to implement mobile channel notifications
for some users without receiving them by email. Basically, users can
follow a channel to enable push notifications.

Note that a mention of the user in a non-mass-mailing channel still
sends an email to this user, in case the notification preferences are
set to "Handle by emails".

This update adjusts how the Mail app sends emails when no channel email address is involved. It helps make message delivery behavior more reliable and consistent for users relying on Odoo communications.

The Latin American invoicing flow now uses one consistent rule to determine which document types can be selected during invoice reversals. This reduces the chance of users choosing an invalid document type when Latin American documents are not in use.

Merges the computation of `l10n_latam_available_document_type_ids` and `l10n_latam_document_type_id` as they're really strongly related.

Note: not really sure about the conditions on the reversal: currently if there are no available types any type can be selected. Previously, *if* move_id had been modified *and* `l10n_latam_use_documents` was set (during the last modification of move_id) no type could be selected.

Task 2115472

Payment setup now applies tighter rules when choosing default payment tokens, ensuring tokens are only considered for suitable electronic payment methods. This helps prevent inappropriate payment options from being selected while preserving important settings such as capture mode and company filtering.

Task 2115472

New custom fields now use the expected copy behavior even when they are created outside the standard form, such as through Studio. This makes duplicated records more consistent and helps prevent unexpected missing values, while one-to-many fields keep their special non-copy behavior.

New fields created from `ir.model.fields` view form are copy=True by
default (copy=False in case of One2many) thanks to an onchange but
manually created fields were not (e.g. created from Studio)

Task: 2067885

Mobile shoppers can now see product categories on the shop page even when product filters are enabled. Product filters remain hidden by default to keep browsing easy, but customers can choose to show them when needed.

### [FIX] website_sale: show categories/hide filters in /shop mobile

Before this commit, when the settings "eCommerce Categories" and "Product
Attribute's Filters" are set, neither of them are visible in mobile.

The expected behaviour in mobile is to display categories and hide filters.
The choice to hide filters in mobile is deliberate, and this is to avoid to
scroll too much in order to see the list of products below.

The cause of the issue is that both settings share the same DOM element
`<div id="products_grid_before">`. When the filters are activated, it hides
the DIV for very small screens.

This commit solves the issue by having two sub-elements of
`<div id="products_grid_before">`, namely `products_grid_before_categories`
and `products_grid_before_attributes`. That way, we can independently set
the visibility rules of each of these settings in the side/navbar.

Fixes #23864

### [IMP] website_sale: toggle visibility of product filters in /shop mobile

Before this commit, product attributes filters are hidden on small screens.

The reason of hiding them is to avoid scrolling too much before consulting
the product list below.

This commit enables attributes filters on small screens. By default, they are
not visible, but the user can click on 'Show Filters' to make them visible.
video: https://youtu.be/GlX_ad9SvIE



--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

The survey invitation flow was updated to remove dynamic recipient filtering rules. This reduces complexity in the survey module and helps make the invite process more predictable for users.

Task 2115472

This change tidies the internal handling of recruitment application updates so calculated fields and on-screen changes behave more consistently. It is an internal cleanup aimed at improving maintainability without changing the recruiting workflow for users.

When computing the price of a product through a pricelist item, if the item was based on anotherp pricelist, the dates and uom weren't given to the subsequent method call. As the majority of the calls to those pricelist methods put all their arguments in the context, it wasn't noticed until now. Functional example: Pricelist A: Rule A1 : 10% discount on Pricelist B, from day 3 to day 6. Pricelist B: Rule B1: 5% discount on Sales price, from day 3 to day 6, Rule B2: 10% discoun

When computing the price of a product through a pricelist item, if the 
item was based on anotherp pricelist, the dates and uom weren't given to 
the subsequent method call.

As the majority of the calls to those pricelist methods put all their 
arguments in the context, it wasn't noticed until now.

Functional example:
Pricelist A:
Rule A1 : 10% discount on Pricelist B, from day 3 to day 6.

Pricelist B:
Rule B1: 5% discount on Sales price, from day 3 to day 6,
Rule B2: 10% discount, from day 7 to day 9.

If today was day 8, the call to pricelist(A)._compute_price_rule(day=5) 
would use rules A1 and B2, but should have used rules A1 and B1.

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#41254
Forward-Port-Of: odoo/odoo#39124

Description of the issue/feature this PR addresses: Current behavior before PR: Traceback in master nightly because of not having been adapted to the last model changes to the tax report line (with the new tax report model) Desired behavior after PR is merged: No traceback in nightly -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41193

Description of the issue/feature this PR addresses:

Current behavior before PR:
Traceback in master nightly because of not having been adapted to the last model changes to the tax report line (with the new tax report model)


Desired behavior after PR is merged:
No traceback in nightly




--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#41193

Co-authored-by: beledouxdenis Description of the issue/feature this PR addresses: During an upgrade, an issue may occur if a (materialized) view is used instead of a table. Current behavior before PR: Migration stop at the point of the ORM tries to add the log_access_columns NOTE: LOG_ACCESS_COLUMNS = ['create_uid', 'create_date', 'write_uid', 'write_date'] Desired behavior after PR is merged: This case is now properly handled and columns will not be added for views or

Co-authored-by: beledouxdenis

Description of the issue/feature this PR addresses:
    During an upgrade, an issue may occur if a (materialized) view is used instead of a table.

Current behavior before PR:
   Migration stop at the point of the ORM tries to add the log_access_columns
   NOTE: LOG_ACCESS_COLUMNS = ['create_uid', 'create_date', 'write_uid', 'write_date']

Desired behavior after PR is merged:
   This case is now properly handled and columns will not be added for views or materialized views
   NOTE: information_schema.table doesn't contain values for materialized views while pg_class does.

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#40930

Set a default company since it is mandatory and hidden in mono-company mode. opw-2129187 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#41214

Set a default company since it is mandatory and hidden in mono-company
mode.

opw-2129187

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#41214

Before this fix, a QUnit test was wrong (didn't parse) After this fix, the test actually works and tests something. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41231

Before this fix, a QUnit test was wrong (didn't parse)
After this fix, the test actually works and tests something.





--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#41231

Steps to reproduce the bug: - Let's consider a fiscal position FP with automatic detection for customer in your country - Let's consider two taxes T1 and T2 where T1 is mapped by T2 in FP - Let's consider a product P with T1 as customer taxe - Let's consider a customer C in your country with no fiscal position - Create a repair order for C - Add P as an add line Bug: T1 was set as customer taxe for P instead of T2. When manually creating an invoice for C with P, FP is automatically

Steps to reproduce the bug:
- Let's consider a fiscal position FP with automatic detection for customer in your country
- Let's consider two taxes T1 and T2 where T1 is mapped by T2 in FP
- Let's consider a product P with T1 as customer taxe
- Let's consider a customer C in your country with no fiscal position
- Create a repair order for C
- Add P as an add line

Bug:

T1 was set as customer taxe for P instead of T2.
When manually creating an invoice for C with P, FP is automatically
detected and T2 is set.

With this fix, the automatic detection of FP is applied on repair order.

opw:2120595

Forward-Port-Of: odoo/odoo#40511
Forward-Port-Of: odoo/odoo#40256

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#41103 Forward-Port-Of: odoo/odoo#40718

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#41103
Forward-Port-Of: odoo/odoo#40718

### Issue - Swiss company - Install Accounting & Studio - Journals > Customers Invoice - Communication standard: Switzerland - Journals > Bank - Swizz account with CHF ISR subscription number - Studio > Reports > ISR Traceback ### Cause If the statement of the `l10n_ch_isr_optical_line` compute method is False, the value will be `None`. In the view, we do a foreach on the value which is `None` and it crashes. ### S

### Issue

    - Swiss company
    - Install Accounting & Studio
    - Journals > Customers Invoice
        - Communication standard: Switzerland
    - Journals > Bank
        - Swizz account with CHF ISR subscription number
    - Studio > Reports > ISR

    Traceback

### Cause

    If the statement of the `l10n_ch_isr_optical_line` compute
    method is False, the value will be `None`.

    In the view, we do a foreach on the value which is `None` and
    it crashes.

### Solution

    Set an empty string as default value for the
    `l10n_ch_isr_optical_line` field

**OPW-2129122**

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#41213

With the reload from attachment ticked (attachment_use) when dealing with a single pdf, the attachment's content must be returned without calling _merge_pdfs in order to preserve the embedded files. Since PyPDF2 doesn't support completely the embedded files, there are simply dropped with creating a new pdf in _merge_pdfs even with a single attachement. -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#41184

With the reload from attachment ticked (attachment_use) when dealing with
a single pdf, the attachment's content must be returned without calling _merge_pdfs
in order to preserve the embedded files. Since PyPDF2 doesn't support completely
the embedded files, there are simply dropped with creating a new pdf in _merge_pdfs even
with a single attachement.

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#41184

`custom_layout` should be set as a context key, otherwise it crashes at creation because of non-existing field. opw-2146695 opw-2149726 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#41211

`custom_layout` should be set as a context key, otherwise it crashes at
creation because of non-existing field.

opw-2146695
opw-2149726

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#41211

Do not remove the country set on the company when the state is removed. 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#41113

Do not remove the country set on the company when the state is removed.

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#41113

…production steps to reproduce: -install the manufacturing app -install studio -go to manufacturing > click on the studio icon (top right of the window) > click views > activate the gantt view you should see a traceback with the following error "Invalid field 'progress' on model 'mrp.production'" mrp_production does not have a progress field => removal of the property "progress" in the view fixes the issue opw-2144823 Forward-Port-Of: odoo/odoo#41182

…production

steps to reproduce:
-install the manufacturing app
-install studio
-go to manufacturing > click on the studio icon (top right of the window) >
 click views > activate the gantt view

you should see a traceback with the following error
"Invalid field 'progress' on model 'mrp.production'"

mrp_production does not have a progress field => removal of the
property "progress" in the view fixes the issue

opw-2144823

Forward-Port-Of: odoo/odoo#41182

If a visitor logs in (and has a visitor_id in his cookie), the partner will be linked to the visitor. If, after 1 week, the visitor tries to connect again with a different session (or another visitor_id in cookies), the authenticate will crash because: * _cron_archive_visitors applies on visitor inactive since at least a week * there can be only one visitor per partner (sql constraint) * The visitor linked to the partner is not retrieved (because archived) and we try to link the partner

If a visitor logs in (and has a visitor_id in his cookie), the partner will be
linked to the visitor. If, after 1 week, the visitor tries to connect again
with a different session (or another visitor_id in cookies), the authenticate
will crash because:
* _cron_archive_visitors applies on visitor inactive since at least a week
* there can be only one visitor per partner (sql constraint)
* The visitor linked to the partner is not retrieved (because archived) and
  we try to link the partner to a new visitor.

Further than that, if the visitor is archived and the linked partner wants to
login again with a new visitor_id, we should : 
* reactivate the previous visitor,
* copy history from newest to previous one
* delete the newest one

(last two points were already done before this commit).

This PR also fixes and simplifies the time_statistics computation.
As time_connection_datetime is always set and in the depends, no need to read
values before looping, the data is already fetched in memory. We can than
use directly the value for each visitor in self.

Task ID: 2120464

Forward-Port-Of: odoo/odoo#40199

The `session_info` dictionnary is used to bootstrap some JS code client side (usually in the backend). It includes relevant information, such as some parameters key for the OdooBot onboarding, the Enterprise subscription expiration alert, etc. to avoid triggering a lot of RPC calls upon webclient start. `session_info` is also called by the remote authentication mechanism located at `/web/session/authenticate`, which can be used by external mechanism to obtain a valid session remotely.

The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.

`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.

Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).

While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.

This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.

@tivisse @JKE-be 
Could you confirm that the multi-company information is only needed for internal users? Or could it mess things up in the website?
JKE: could you confirm that this is not used in website at all? It seems that `get_frontend_session_info` is used there (notably for translation cache key), but I'd like to have your confirmation

Forward-Port-Of: odoo/odoo#40213

For better usability. opw-2146601 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#41199

For better usability.

opw-2146601

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#41199

## [FIX] web: fix RTL pivot view dropdown ### Reproduce the issue - Load Arabic language - Install Sales - Report > Sales - Switch to arabic - Click on the pivot view to display the dropdown The dropdown position is incorrect ### Cause The calculations are based on a `left` value who is weird. This commit use the mouse X position to compute the `left` value. ---------------------- ## [FIX] web, account: fix RTL popover on invoice ### Repro

## [FIX] web: fix RTL pivot view dropdown

### Reproduce the issue

    - Load Arabic language
    - Install Sales
    - Report > Sales
    - Switch to arabic
    - Click on the pivot view to display the dropdown

    The dropdown position is incorrect

### Cause

    The calculations are based on a `left` value who is weird.

This commit use the mouse X position to compute the `left` value.

----------------------
## [FIX] web, account: fix RTL popover on invoice

### Reproduce the issue

    - Load Arabic language
    - Install Accounting
    - Create an invoice & add credit note
    - Switch to arabic
    - Click on the "(i)" icon near the total price

    The popover is displayed at the other side of the screen

### Cause

    - RTLcss was reversing the "left: 0" css property to "right: 0"
    - The popover configuration was not adapted for RTL

This commit ignore RTL for the popover css "left" property and
configure correctly the JS side

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#41158

The `session_info` dictionnary is used to bootstrap some JS code client side (usually in the backend). It includes relevant information, such as some parameters key for the OdooBot onboarding, the Enterprise subscription expiration alert, etc. to avoid triggering a lot of RPC calls upon webclient start. `session_info` is also called by the remote authentication mechanism located at `/web/session/authenticate`, which can be used by external mechanism to obtain a valid session remotely.

The `session_info` dictionnary is used to bootstrap some JS code client
side (usually in the backend). It includes relevant information, such
as some parameters key for the OdooBot onboarding, the Enterprise
subscription expiration alert, etc. to avoid triggering a lot of RPC
calls upon webclient start.

`session_info` is also called by the remote authentication mechanism
located at `/web/session/authenticate`, which can be used by external
mechanism to obtain a valid session remotely.

Revision odoo/odoo@8a28cc2 introduced the concept of cache keys for
some oft-requested data (such as menus, translations and dynamic qweb
templates) to avoid requesting them on each webclient start, since they
tend not to change often. Unfortunately, it introduced a read on the
ir.ui.menu model that raised an `AccessError` if the authenticating user
was not a member of the `base.group_user` group ('Internal' user type).

While fixing that issue, it became apparent that `session_info`
returns a whole lot of information through this remote connection route
which is entirely unnecessary if not used in the context of a webclient
start, such a currencies, the state of the enterprise subscription, etc.

This commit fixes the access right issue by removing this non-relevant
information from the returned dict (including cache keys) if the user
is not an internal one.

@adr-odoo 
Could you confirm that ocn token is only needed for internal users?

Forward-Port-Of: odoo/enterprise#6688