IoT boxes will now regularly send device status information to the server every five minutes, helping businesses monitor connected hardware more reliably. Printer detection and installation are also improved, reducing setup delays and making point-of-sale hardware easier to manage.

With this commit dict of devices will be send every 300 seconds to server

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

The mail composer was streamlined by removing unnecessary message-related behavior and keeping only the fields it actually uses. This reduces complexity and avoids unsupported forum channel notifications that did not work, making email and message composition more reliable.

Purpose
 * unnecessary inherit of composer on mail.message: lot of unused fields and
   message specific behavior (notify, check access) not relevant for
   composer;
 * simply duplicate fields to use and remove inheritance;

This update refreshes internal counter values used by developers when checking mail-related test performance. It helps ensure community and enterprise test counters stay accurate, reducing confusion during development checks.

Some counters are not up to date notably taking in to account community-only
and test-mail with enterprise only counters. Those are used notably when
developing to ease quick check of counters.

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

Payments are now categorized as customer or supplier payments based on the partner type, not whether money is being received or sent. Point of Sale payments are consistently treated as customer payments, reducing confusion in payment menus and reimbursement workflows.

Task 1934667

1. That's the partner type (and not the payment type) that should define if a payment is a customer or a supplier payment :
a. When the partner type on the payment is "customer", the payment should be considered as a customer payment
(and thus be visible from the menu customer payments)
b. When the partner type on the payment is "supplier", the payment should be considered as a supplier payment
(and thus be visible from the menu supplier payments)

2. The PoS should only create customer payments (you never pay suppliers through the PoS)
The payment created should be with a partner type "Customer"
But the partner field can stay empty if the customer wasn't set on the PoS Order

3. When I change the payment type while creating a payment from scratch, it shouldn't change the partner type
Example : I'm creating a payment for a reimbursement, I'll create it from the customer payments menu (as I'm paying a customer), I'll tick the payment type "Send money"
I don't expect the partner type to change to vendor.


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

New stock operation types now enable detailed operations automatically when the company setup makes them useful, such as multi-location inventory or lot and serial number tracking. The separate “Show Reserved” option has also been removed to simplify operation type settings and reduce configuration choices.

In case it's appropriate (using multilocation or lots/serial numbers) the 'show detailed operations' option is active by default when a new operations type is created.

Task #1944853