Issue ----- - install helpdesk_sale_timesheet - activate loyalty feature - create a SO for a customer A for a service product, apply for example a coupon code on this SO - in a helpdesk project with Time Billing enabled, create a task for customer A - ** the discount SO line is available to select as a SOL item ** This commit improves the SOL domain in continuation of https://github.com/odoo/odoo/commit/d840a3b62627392e72ab4667922bc1cfca45815d opw-4212956 Forward-Port-Of: odoo/enter

Issue
-----
- install helpdesk_sale_timesheet
- activate loyalty feature
- create a SO for a customer A for a service product, apply for example a coupon code on this SO
- in a helpdesk project with Time Billing enabled, create a task for customer A
- ** the discount SO line is available to select as a SOL item **

This commit improves the SOL domain in continuation of https://github.com/odoo/odoo/commit/d840a3b62627392e72ab4667922bc1cfca45815d

opw-4212956

Forward-Port-Of: odoo/enterprise#71995
Forward-Port-Of: odoo/enterprise#71640

Set up Avatax on a company Create Branch and switch to it Create an invoice with fiscal position Avatax Compute taxes > Taxes will be created in branch company Switch to main company Create an invoice with fiscal position Avatax again. Compute taxes > Error Error will block the action ``` Validation Error Tax names must be unique! - CA STATE TAX [06] (6.0000 %) in test ``` This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the ma

Set up Avatax on a company
Create Branch and switch to it
Create an invoice with fiscal position Avatax
Compute taxes > Taxes will be created in branch company Switch to main company
Create an invoice with fiscal position Avatax again. Compute taxes > Error

Error will block the action
```
Validation Error

Tax names must be unique!
- CA STATE TAX [06] (6.0000 %) in test 
```
This occurs because we first created the taxes in the branch company. Then when retrieving taxes from the main company those taxes are not found and will be created again but we have a constraint that tax name must be unique

opw-3962212

Forward-Port-Of: odoo/enterprise#72130

Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`. This commit makes sure the label of that field will always be `Documents` in all cases. task-4250848 Forward-Port-Of: odoo/enterprise#71741

Before this commit, when documents_project module is installed on a fresh DB the label of `Use Documents` and when documents_fsm module is installed the label is updated to be `Documents`.

This commit makes sure the label of that field will always be `Documents` in all cases.

task-4250848

Forward-Port-Of: odoo/enterprise#71741

Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class Forward-Port-Of: odoo/enterprise#69552

Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times.

Fixing it by extracting setup to an utility class

Forward-Port-Of: odoo/enterprise#69552

Before this commit it was very difficult to change the logic of the CODA file parsing, if not copy-pasting `_parse_bank_statement_file` method in `account.journal`. Forward-Port-Of: odoo/enterprise#72169

Before this commit it was very difficult to change the logic of the CODA file parsing, if not copy-pasting `_parse_bank_statement_file` method in `account.journal`.

Forward-Port-Of: odoo/enterprise#72169

Issue ----- The activities from the calendar, which should be today's meetings, are in some circumstances displaying meetings from the next day. Steps ----- - Set the user timezone to "Asia/Manila". - In Calendar, create a meeting early (before 18:00) the next day. - Check the activities (clock in the navbar), tomorrow's meeting appears. Cause ----- `datetime.datetime` objects are not timezone aware, and using the `replace` function on them will simply lead to a naive convers

Issue
-----
The activities from the calendar, which should be today's
meetings, are in some circumstances displaying meetings
from the next day.

Steps
-----
- Set the user timezone to "Asia/Manila".
- In Calendar, create a meeting early (before 18:00) the
next day.
- Check the activities (clock in the navbar), tomorrow's
meeting appears.

Cause
-----
`datetime.datetime` objects are not timezone aware, and using
the `replace` function on them will simply lead to a naive
conversion which causes potential issues.

Example:
```
import pytz
import datetime

dt = datetime.datetime(2024,1,1,0,0)
dt = dt.replace(tzinfo=pytz.timezone("Asia/Manila")).astimezone(pytz.UTC)
print(dt)
>>> 2024-01-01 15:56:00+00:00 # 1 day offset to expected result
```

Instead, it is better to use the pytz `localize` function.

opw-4142911

Forward-Port-Of: odoo/odoo#181795

Steps to reproduce : ------------------------- - Install the pos_restaurant module. - Create a restaurant with no floors. - Open Restaurant and click on edit plan button. - Try to do anything from editing options. Issue : -------- As there are no floor exists neither of the options works and some will give tracebacks. Cause : --------- Without any floor we were trying to change properties of the floor. Fix : ---- We will check if any floor exists for that config then only the

Steps to reproduce :
-------------------------
- Install the pos_restaurant module.
- Create a restaurant with no floors.
- Open Restaurant and click on edit plan button.
- Try to do anything from editing options.

Issue :
--------
As there are no floor exists neither of the options works and some will give tracebacks.

Cause :
---------
Without any floor we were trying to change properties of the floor.

Fix :
----
We will check if any floor exists for that config then only the edit plan button will be visible.

Forward-Port-Of: odoo/odoo#182702

Steps: - Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products. - Go to /shop -> product and click the Add to Cart button. - OR make SO and add the same product to order line. - In the Product Configurator, there is no strikethrough price. Issue: When the comparison price is activated the strikethrough price is not visible in the product configurator Cause: There was no `compare_price_list` in the template, hence the co

Steps:
- Turn on Comparison Price from settings and set a comparison price for a product with variants or/and optional products.
- Go to /shop -> product and click the Add to Cart button.
- OR make SO and add the same product to order line.
- In the Product Configurator, there is no strikethrough price.

Issue:
When the comparison price is activated the strikethrough price is not visible in the product configurator

Cause:
There was no `compare_price_list` in the template, hence the comparison price was never visible.

Fix:
- Added the `compare_price_list` to the template using XPath because `compare_price_list` is added to the `combination_info` dictionary in the website_sale module and made it conditionally hidden using `t-if` (not with `d-none` as we do for other cases) because the same product configurator template is being used in the backend (like while making a Sale or Rental order) where the `compare_list_price` is not present in `combination_info` which gives a key not found error.

opw-3992683

Forward-Port-Of: odoo/odoo#184100
Forward-Port-Of: odoo/odoo#171354

When User Clicks on Send payment status to SInvoice action, a traceback will appear. Steps to reproduce the error: - Install ``l10n_vn_edi_viettel`` module - Switch to VN Company - Go to Invoicing > Customers > Invoices > Select any invoice > Actions > Send payment status to SInvoice Traceback: ``` SyntaxError: syntax error at or near ")" LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO... ^ File "odoo/tool

When User Clicks on Send payment status to SInvoice action,
a traceback will appear.

Steps to reproduce the error:
- Install ``l10n_vn_edi_viettel`` module
- Switch to VN Company
- Go to Invoicing > Customers > Invoices > Select any invoice > Actions >
  Send payment status to SInvoice

Traceback:
```
SyntaxError: syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
                                                ^

  File "odoo/tools/safe_eval.py", line 391, in safe_eval
    return unsafe_eval(c, globals_dict, locals_dict)
  File "ir.actions.server(2134,)", line 3, in <module>
  File "addons/l10n_vn_edi_viettel/models/account_move.py", line 299, in action_l10n_vn_edi_update_payment_status
    self.env['res.company']._with_locked_records(self)
  File "addons/account/models/company.py", line 785, in _with_locked_records
    self._cr.execute(f'SELECT * FROM {records._table} WHERE id IN %s FOR UPDATE SKIP LOCKED', [tuple(records.ids)])
  File "odoo/sql_db.py", line 347, in execute
    res = self._obj.execute(query, params)
ValueError: <class 'psycopg2.errors.SyntaxError'>: "syntax error at or near ")"
LINE 1: SELECT * FROM account_move WHERE id IN () FOR UPDATE SKIP LO...
                                                ^
```

https://github.com/odoo/odoo/blob/072da22e72e66e6332d073502b987682f1b6e88b/addons/account/models/company.py#L745
Here, when there are no records for sending their payment status to SInvoice,
records.ids will be empty,
It will lead to the above traceback.

This commit will fix the above issue by preventing the execution of the query
when ``records.ids`` is empty.

sentry-5954926261

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

Forward-Port-Of: odoo/odoo#182621

This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master) Purpose: Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV. For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used

This commit implements the changes needed after receiving the first feedback of the new `l10n_ro_efactura` module. (Send CIUSRO-XML to the SPV). It's also commonly known as "Romanian EDI" (`l10n_ro_edi` in master)

Purpose:

Index key (received and saved as `key_download`) is an important number that should be displayed so that the customer can easily reference the invoice in the SPV.

For some customer, the state flow of E-Factura in Odoo is confusing as it doesn't match what they're used to in the SPV. This might be caused by the state name.

Changes:

- After receiving the `key_download`, log it in the invoice's chatter.
- Save the `key_download` data and pass it in-between documents, to make sure that relevant documents displays the index. (and the idx doesn't get lost when "sending" document is deleted)
- Change the display name of the statuses of the document.
- Add a tooltip on the E-Factura status fields (move & document).

The create document function helpers are changed to have one dictionary as the param signature so that we can pass on the new `key_loading` data (and any other important data in the future, for easier stable fix), and also to make it general (the same for all ro-documents)

task-id: 4059522

Forward-Port-Of: odoo/odoo#179278

Reproduce --- - -i event_crm_sale,website_event_questions - Create new "Lead Generation Rule" (Events/Configuration/Lead Generation) - "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]` - add some tag - Add new attendee to an EVENT - Add new question to the EVENT - BUG: `KeyError: 'registration_answer_ids'` opw-4125944 Forward-Port-Of: odoo/odoo#179734

Reproduce
---
- -i event_crm_sale,website_event_questions
- Create new "Lead Generation Rule" (Events/Configuration/Lead Generation)
	- "If the Attendees meet these Conditions": `[("lead_ids", "=", False)]`
	- add some tag
- Add new attendee to an EVENT
- Add new question to the EVENT
- BUG: `KeyError: 'registration_answer_ids'`

opw-4125944

Forward-Port-Of: odoo/odoo#179734

**Rational:** for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user. **Note:** We apply exactly the same logic as for the model sale.order and sale.order.line. See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15 F

**Rational:** 

for the time being pos.order model has a classic ir.rule ([('company_id', 'in', company_ids)]). However pos.order.line doesn't have such rule. So if we create a new menu and action to display pos.order.line model, it will display all the order lines, regardless the current companies of the user.

**Note:** 
We apply exactly the same logic as for the model sale.order and sale.order.line.
See : https://github.com/odoo/odoo/blob/16.0/addons/sale/security/ir_rules.xml#L5-L15

Forward-Port-Of: odoo/odoo#183045

Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1] Now, the empty option will not be rendered if the selection is required. [^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css Forward-Port-Of: odoo/odoo#183687 Forward-Port-Of: odoo/odoo#183614

Before this commit, styling is used to hide the empty option when the selection is required. Option elements don't support CSS styling properties in Chrome and Safari[^1]

Now, the empty option will not be rendered if the selection is required.

[^1]: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/option#styling_with_css

Forward-Port-Of: odoo/odoo#183687
Forward-Port-Of: odoo/odoo#183614

Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times. Fixing it by extracting setup to an utility class --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179344

Currently since TestFrontend has test methods and is imported/inherited, the same test is executed three times.

Fixing it by extracting setup to an utility class




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

Forward-Port-Of: odoo/odoo#179344

### Steps to reproduce: - Enable "Multi-steps Routes" in the settings - Inventory > COnfiguration > Warehouse Management > Warehouses - Change your warehouse settings to Deliver in 2 steps - Create a Storable product P with 10 units in stock - Create and confirm an SO for 1 unit of P > A pick and a ship deliveries were created. - Unreserve the PICK deliveries - Go to the forecast of your product avaialbility #### > the SO is unreconcilled and the product is treated as unavailable #

### Steps to reproduce:

- Enable "Multi-steps Routes" in the settings
- Inventory > COnfiguration > Warehouse Management > Warehouses
- Change your warehouse settings to Deliver in 2 steps
- Create a Storable product P with 10 units in stock
- Create and confirm an SO for 1 unit of P
> A pick and a ship deliveries were created.
- Unreserve the PICK deliveries
- Go to the forecast of your product avaialbility
#### > the SO is unreconcilled and the product is treated as unavailable

### Cause of the issue:

Since you unreserved the PICK delivery, the demand of the outgoing move is not null in the forecast lines computations:
https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L278 In addition, since you deliver in 2 steps the outgoing moves are part of a move chain. To generate this chain, the moves were created with an `make_to_order` `procure_method` and as such, the quantity considered to reconcile this move from stock is set to be at 0 here: https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L283-L287 Furthermore, since there is no incoming moves made to reconcile this outgoing move (whcih happen for real "MTO" moves and not these flagged as MTO because they were part of a chain) the line will be created here and flagged as not repleinshed nor available:
https://github.com/odoo/odoo/blob/91316ec8d55dbc5e1cd712568f614c62539bd807/addons/stock/report/stock_forecasted.py#L295-L299 The forecast error

### Note:

The issue is not reproducible in 16.0 since the forecast datas computed by the `_get_report_lines` was drastically prior to the 17.0 version.

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

Forward-Port-Of: odoo/odoo#183526
Forward-Port-Of: odoo/odoo#183211

Adhoc-task: 40503 Description of the issue/feature this PR addresses: 1- We removed the following taxes to avoid duplication: "ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2) "ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06

Adhoc-task: 40503

Description of the issue/feature this PR addresses:
1- We removed the following taxes to avoid duplication:

"ex_tax_retencion_suss_sufrida", "WTH SUSS I", which is already located here(https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R2)

"ex_tax_retencion_ganancias_sufrida", "WTH Earnings I", which is already located here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R7) and here (https://github.com/odoo/odoo/pull/168945/files#diff-4bca1b8ca406e3c79fa6697dcb06168a41e3a1a031fcfc467322ae0d78483523R12)

2- We moved the taxes from files to match the same structure as l10n_ar

Current behavior before PR:
After downloading l10n_ar_withholding and checking the taxes, we realized there were some duplicates.
[[FIX]l10n_ar_withholding: repeated taxes in chart of accounts.webm](https://github.com/odoo/odoo/assets/109111493/56776d61-86f1-4632-98a4-c9e192cc5f3a)


Desired behavior after PR is merged:
The taxes are no longer duplicated.



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

Forward-Port-Of: odoo/odoo#168945

Before this commit you could revoke all devices but attempting to revoke a single one will have resulted in an error that this.orm was undefined. Forward-Port-Of: odoo/odoo#184113

Before this commit you could revoke all devices but attempting to revoke a single one will have resulted in an error that this.orm was undefined.

Forward-Port-Of: odoo/odoo#184113

The issue: We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available. The fix: Create the analytic plan runbot-60608 Forward-Port-Of: odoo/odoo#181399

The issue:
We run the test under the assumption that an analytic plan with ID=2 exists. However, if the demo data hasn’t been loaded, this analytic plan won’t be available.

The fix:
Create the analytic plan

runbot-60608

Forward-Port-Of: odoo/odoo#181399

Steps to reproduce: - install new db with only industry_fsm or timesheet_grid - Run the test Cause: https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set. Solution: Instead of probably breaking the stable by changing the analytic_security.xml by adding a defau

Steps to reproduce:
- install new db with only industry_fsm or timesheet_grid
- Run the test

Cause:
https://github.com/odoo/odoo/blob/8029b467dacaf9e34b21db52b148a2963efb29e4/addons/hr_timesheet/security/hr_timesheet_security.xml#L33-L44 `hr.timesheet` overrides the acess rights for analytic line and adds an extra mandatory field; the analytic line should now have a project_id set.

Solution:
Instead of probably breaking the stable by changing the analytic_security.xml by adding a default rule, we skip the test if account is not present but hr.timesheet is.

runbot-100530

Forward-Port-Of: odoo/odoo#184067

**Current behavior before PR:** When link-preview is done on public channel invitation links it posts a guest joined the channel​ message in the public channel. **Desired behavior after PR is merged:** now we are ignoring public channel invitations links for link-preview, so it does not post guest joined the channel backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview. task-4083161 --- I confirm I have signed the CLA and read the PR guid

**Current behavior before PR:**

When link-preview is done on public channel invitation links it posts a guest
joined the channel​ message in the public channel.

**Desired behavior after PR is merged:**

now we are ignoring public channel invitations links for link-preview, so it
does not post guest joined the channel

backported PR: https://github.com/odoo/odoo/pull/178932 which handle's ignore link-preview.

task-4083161

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

Forward-Port-Of: odoo/odoo#180187

This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set. Steps to reproduce: - Create a list view with monetary field and different currencies - Don't set an aggregation method - An aggregation row is wrongly added and contains the error message Original PR: https://github.com/odoo/odoo/pull/132272 Forward-Port-Of: odoo/odoo#183772 Forward-Port-O

This commit fixes an issue with the display of list monetary aggregates where the error message saying that different currencies cannot be aggregated would show even when no aggregate method is set.

Steps to reproduce:
- Create a list view with monetary field and different currencies
- Don't set an aggregation method
- An aggregation row is wrongly added and contains the error message

Original PR: https://github.com/odoo/odoo/pull/132272

Forward-Port-Of: odoo/odoo#183772
Forward-Port-Of: odoo/odoo#183730

- Create a Sales Order, add a product and confirm - Open POS session - Click Quotations/Order button - Select the created SO - Apply a downpayment - Validate the downpayment order - Go back to the Sales Order - Deliver the product if necessary - Click 'Create Invoice' Issue: The downpayment amount paid via POS is not taken into account in computation of 'Already invoiced' and 'Amount to invoice' A solution is to add a component to keep track of the downpayments made via POS op

- Create a Sales Order, add a product and confirm
- Open POS session
- Click Quotations/Order button
- Select the created SO
- Apply a downpayment
- Validate the downpayment order
- Go back to the Sales Order
- Deliver the product if necessary
- Click 'Create Invoice'

Issue: The downpayment amount paid via POS is not taken into account in
computation of 'Already invoiced' and 'Amount to invoice'

A solution is to add a component to keep track of the downpayments made
via POS

opw-4131695

Forward-Port-Of: odoo/odoo#178844

Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards. This commit changes order of specific company values on report_template & report_invoice. Order before commit: vat (IČ DPH) company_registry (IČO) income_tax_id (DIČ) Order after commit: company_registry (IČO) income_tax_id (DIČ) vat (IČ DPH) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-

Order of company values on reports is different in most of local software in Slovakia. Fix is only cosmetic to follow standards.

This commit changes order of specific company values on report_template & report_invoice.

Order before commit:
vat (IČ DPH)
company_registry (IČO)
income_tax_id (DIČ)

Order after commit:
company_registry (IČO)
income_tax_id (DIČ)
vat (IČ DPH)




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

Forward-Port-Of: odoo/odoo#182156

Steps to reproduce: - install project app - create project without any task - change the language Issue: The helper string is not being translated. Reason: This issue occurs because the existing context is lost, particularly the `lang` variable, which impacts the translation functionality. Solution: In this commit, we have updated the method from with_context({'active_id': self.id}) to with_context(active_id=self.id). This fix ensures that the previous context is ret

Steps to reproduce: 
- install project app
- create project without any task
- change the language

Issue: The helper string is not being translated.
    
Reason: 
This issue occurs because the existing context is lost, particularly 
the `lang` variable, which impacts the translation functionality.
    
Solution:
In this commit, we have updated the method from 
with_context({'active_id': self.id}) to with_context(active_id=self.id).
This fix ensures that the previous context is retained.

task-3940540

Forward-Port-Of: odoo/odoo#184149
Forward-Port-Of: odoo/odoo#170720

We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded). opw-4231366 Forward-Port-Of: odoo/odoo#183359

We faced multiple times error because this update doing a try_loading is called in `post-` scripts (after the module is loaded) and not in `end-` scripts (when all modules are loaded).

opw-4231366

Forward-Port-Of: odoo/odoo#183359

There are two paths for a successful login via web_totp 1. The user has a cookie saved which saves them from having to enter the TOTP 2. The user is a new device / browser, enter the TOTP and a form is submitted Both call self._login_redirect but only the latter updates the env and context. This is a snippet to reproduce the bug: ```python @http.route() def web_totp(): response = super().web_totp(*args, **kw) if not request.env.user or request.env.user.is_public:

There are two paths for a successful login via web_totp
 1. The user has a cookie saved which saves them from having to enter the TOTP
 2. The user is a new device / browser, enter the TOTP and a form is submitted

Both call self._login_redirect but only the latter updates the env and context.

This is a snippet to reproduce the bug:
```python
@http.route()
def web_totp():
    response = super().web_totp(*args, **kw)
    if not request.env.user or request.env.user.is_public:
        return response
    do_something()
    ...
```
This would call `do_something` only when a user successfully logs in by putting the TOTP explicitly but not when they log in thanks to a cookie  being set.

Description of the issue/feature this PR addresses:
Makes web_totp consistent for the 2 flows (submit totp or use cookie)

Current behavior before PR:
A code logic that works for web_login does not work for web_totp, or rather, it works only for one flow but not the other

Desired behavior after PR is merged:
A code logic that works for web_login also works for web_totp

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

Forward-Port-Of: odoo/odoo#183838

Current behavior before PR: -Nested list numbering appeared differently in the preview compared to printed PDFs, causing inconsistencies in document appearance. Desired behavior after PR is merged: -Nested list numbering appears consistent between the preview and printed PDFs. task-4008883 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#172626

Current behavior before PR:

-Nested list numbering appeared differently in the preview compared to printed
 PDFs, causing inconsistencies in document appearance.

Desired behavior after PR is merged:

-Nested list numbering appears consistent between the preview and printed PDFs.

task-4008883



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

Forward-Port-Of: odoo/odoo#172626