Steps to reproduce: - Create an account journal. - Rename the created journal (let's say from A to B). - Create a new account journal named A. Changing the name of a journal doesn't change the name of the alias, An error caused by duplicate mail alias names will occur. Additionally the error can happen if the user has manually added aliases with the same name before upgrading to 17.0. Adding the code and company id of the journal to the alias to ensure uniqueness when an alias with the

Steps to reproduce:
- Create an account journal.
- Rename the created journal (let's say from A to B).
- Create a new account journal named A.

Changing the name of a journal doesn't change the name of the alias, An error caused by duplicate mail alias names will occur. Additionally the error can happen if the user has manually added aliases with the same name before upgrading to 17.0.

Adding the code and company id of the journal to the alias to ensure uniqueness when an alias with the same name is already in the DB (as the combo `company_id`,`code` is unique).

Other possible fixes: (I'm not sure what's better here)

- Automatically rename an alias when its journal is renamed (only when they are identical after being sanitized)
- Add numbers as suffix to alias names

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

Description of the issue/feature this PR addresses: In the journal entry you can group by partner/date/journal/company, but in vendor bill or customer invoice you cannot. @qdp-odoo @oco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169584 Forward-Port-Of: odoo/odoo#161369

Description of the issue/feature this PR addresses:
In the journal entry you can group by partner/date/journal/company, but in vendor bill or customer invoice you cannot.

@qdp-odoo @oco-odoo 



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

Forward-Port-Of: odoo/odoo#169584
Forward-Port-Of: odoo/odoo#161369

Versions -------- - 15.0+ Steps ----- 1. Go to Sale / Configuration / Units of Measure Categories; 2. go to Working Time; 3. set rounding precision of Hours to 1.0; 4. create a SO, selling 10 hours of timesheeted service; 5. click confirm; 6. add 9.1 hours to a timesheet for the SO. Issue ----- The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded. Cause ----- The smart button displays the value of the `timesheet_total_duration` fie

Versions
--------
- 15.0+

Steps
-----
1. Go to Sale / Configuration / Units of Measure Categories;
2. go to Working Time;
3. set rounding precision of Hours to 1.0;
4. create a SO, selling 10 hours of timesheeted service;
5. click confirm;
6. add 9.1 hours to a timesheet for the SO.

Issue
-----
The sale order line displays 9 hours delivered, while a smart button displays 10 hours recorded.

Cause
-----
The smart button displays the value of the `timesheet_total_duration` field, this field gets computed with `_compute_quantity` method of `uom.uom`, which defaults to the `UP` rounding method:
https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/uom/models/uom_uom.py#L216

In contrast, the SOL displays the result of `_get_delivered_quantity_by_analytic`, which uses the same `uom.uom` method, but with the `HALF-UP` rounding method: https://github.com/odoo/odoo/blob/b724fbcf6f348ed7a9109a325d366be69c052d1c/addons/sale/models/sale_order_line.py#L387

Solution
--------
Modify the `_compute_timesheet_total_duration` methods of `account.move` and `sale.order` to use the same rounding method as the `_get_delivered_quantity_by_analytic` method.

opw-3949986

Forward-Port-Of: odoo/odoo#169900
Forward-Port-Of: odoo/odoo#167607

Use case: - LOT A 20 units in stock - LOT B 20 units in stock - Do an outgoing picking for 10 units - Reserve - Remove the `stock.move.line` - Add a new line of B Current behavior: Line is prefilled for 20 units Expected: Line only takes the 10 units missing It's due to commit [1] enforcing the computation on the origin move and not the current situation [1] commit 383d4eb98ba4bfbcb384b3d1ee27393da00226e7 Description of the issue/feature this PR addresses: Current beha

Use case:
- LOT A 20 units in stock
- LOT B 20 units in stock
- Do an outgoing picking for 10 units
- Reserve
- Remove the `stock.move.line`
- Add a new line of B

Current behavior:
Line is prefilled for 20 units

Expected:
Line only takes the 10 units missing

It's due to commit [1] enforcing the computation
on the origin move and not the current situation

[1] commit 383d4eb98ba4bfbcb384b3d1ee27393da00226e7

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

Credit notes shoudn't make the down payment reference disappear from the matching down payment SO line. opw-3904918 See #168418 for further details Forward-Port-Of: odoo/odoo#169859 Forward-Port-Of: odoo/odoo#169779

Credit notes shoudn't make the down payment reference disappear from the matching down payment SO line.

opw-3904918

See #168418 for further details

Forward-Port-Of: odoo/odoo#169859
Forward-Port-Of: odoo/odoo#169779

This commit import payment_token file in __init__ which was missed by [1] PR to properly execute it's code and do not return any token for express checkout. [1]: https://github.com/odoo/odoo/pull/107788 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#169942

This commit import payment_token file in __init__
which was missed by [1] PR to properly execute
it's code and do not return any token for express
checkout.

[1]: https://github.com/odoo/odoo/pull/107788

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

The tour is not actually ran in this version, and is blocked before in other versions. We should fix it in an other PR. This typo causes a check on available steps to fail in master. runbot-68355 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169973 Forward-Port-Of: odoo/odoo#169646

The tour is not actually ran in this version, and is blocked before in other versions.
We should fix it in an other PR.
This typo causes a check on available steps to fail in master.

runbot-68355




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

Forward-Port-Of: odoo/odoo#169973
Forward-Port-Of: odoo/odoo#169646

The issue: When creating an invoice from multiple sale orders, each invoice line is going to be linked to the appropriate sale order line from each sale order, which will cause a singleton traceback when trying to access the is_downpayment field Expected behavior: to confirm the invoice Current Behavior: Singleton traceback opw-3878327 Forward-Port-Of: odoo/odoo#167064 Forward-Port-Of: odoo/odoo#163766

The issue:
When creating an invoice from multiple sale orders, each invoice line is going to be linked to the appropriate sale order line from each sale order, which will cause a singleton traceback when trying to access the is_downpayment field

Expected behavior:
to confirm the invoice

Current Behavior:
Singleton traceback

opw-3878327

Forward-Port-Of: odoo/odoo#167064
Forward-Port-Of: odoo/odoo#163766

The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain. This commit changes the format to be the same as in module l10n_es_edi_tbai . task-3990176 Forward-Port-Of: odoo/odoo#169609

The certificate issuer name in the Factura-e XML needs to be formatted in a very specific way. Else it fails the validators of the Basque Region in Spain.

This commit changes the format to be the same as in module l10n_es_edi_tbai .

task-3990176

Forward-Port-Of: odoo/odoo#169609

Problem --------- When the OCR was deactivated, the attachments from the mail would get deleted. Solution --------- By default, when requesting a decoder, return a function that returns False. That way, we always have a 'decoder' and attachments create an invoice. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#169861

Problem
---------
When the OCR was deactivated, the attachments from the mail would get deleted.

Solution
---------
By default, when requesting a decoder, return a function that returns False. That way, we always have a 'decoder' and attachments create an invoice.

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

Forward-Port-Of: odoo/odoo#169861

During a fw-port, an error was made and the "or" became an "and". This fixes it, to hide the tab if the move is not from a polish company. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#168502

During a fw-port, an error was made and the "or" became an "and". 
This fixes it, to hide the tab if the move is not from a polish company.




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

Forward-Port-Of: odoo/odoo#168502

Before commit: When creating an expense through an email alias, it can sometimes have no product_id set. This usually causes a clean error message to pop up, but here there was a traceback due to the use of product_uom_id.rounding before we get to show the error message After commit: The traceback is solved and the correct error message is shown opw-3921278 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#165552

Before commit:
When creating an expense through an email alias, it can sometimes have no product_id set.  This usually causes a clean error message to pop up, but here there was a traceback due to the use of product_uom_id.rounding before we get to show the error message

After commit:
The traceback is solved and the correct error message is shown

opw-3921278

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

Forward-Port-Of: odoo/odoo#165552

… module Steps to reproduces: - install module `test_spreadsheet_edition` - run js tests => some tests fail. The reason is we are trying to click or hover some cells in those tests. But the spreadsheet (its viewport) size is 0. The cells are not visible. This commit moves some scss from module `documents_spreadsheet` to `spreadsheet_edition`. This css ensures the spreadsheet takes all the available space and be sized properly. runbot errors 65775, 65774, 65773, 65772 Forward-P

… module

Steps to reproduces:
- install module `test_spreadsheet_edition`
- run js tests => some tests fail.

The reason is we are trying to click or hover some cells in those tests. But the spreadsheet (its viewport) size is 0.
The cells are not visible.

This commit moves some scss from module `documents_spreadsheet` to `spreadsheet_edition`.

This css ensures the spreadsheet takes all the available space and be sized properly.

runbot errors 65775, 65774, 65773, 65772

Forward-Port-Of: odoo/enterprise#65015

Previous implementation checked if a folder was empty before removing it. However, it didn't take into account cases where one folder is empty but there are non-empty subfolders inside. Removing the parent folder triggered an error. The new implementation recursively checks the subfolders to ensure their emptiness before trying to remove the parent folder. Forward-Port-Of: odoo/enterprise#62184 Forward-Port-Of: odoo/enterprise#61649

Previous implementation checked if a folder was empty before removing it. However, it didn't take into account cases where one folder is empty but there are non-empty subfolders inside. Removing the parent folder triggered an error.

The new implementation recursively checks the subfolders to ensure their emptiness before trying to remove the parent folder.

Forward-Port-Of: odoo/enterprise#62184
Forward-Port-Of: odoo/enterprise#61649

In applicants kanban view, when there is no applications, the text was unreadable, so it is white now. Task: 3786280 Forward-Port-Of: odoo/enterprise#64967

In applicants kanban view, when there is no applications, the text was unreadable, so it is white now.

Task: 3786280

Forward-Port-Of: odoo/enterprise#64967

Since the introduction of the new model/record, the `record` props of fields can be updated to another `resId` without triggering `onWillUpdateProps`. Instead a new hook called `useRecordObserver` was introduced. This PR introduces multiple technical corrections related to the new model/record. * `openArticle` can use the `Record.save` with `nextId` this will avoid re-loading the current record's data just before switching to another record. * Behaviors in an article body can be destroyed

Since the introduction of the new model/record, the `record` props of fields can be updated to another `resId` without triggering `onWillUpdateProps`. Instead a new hook called `useRecordObserver` was introduced.

This PR introduces multiple technical corrections related to the new model/record.

* `openArticle` can use the `Record.save` with `nextId` this will avoid re-loading the current record's data just before switching to another record.
* Behaviors in an article body can be destroyed sooner using `useRecordObserver`.
* Topbar, Sidebar, Comments and Cover are adjusted to properly interact with the `Record` they handle
* Ensure that a title is extracted from the body at the right timings if applicable (`beforeLeave` and `openArticle`)
* Reduce flickering when switching article

task-3875521

Forward-Port-Of: odoo/enterprise#64896
Forward-Port-Of: odoo/enterprise#60960

A new field of type 'sale.subscription.pricing' was added to the 'product.template' model. This breaks product creation form for users who don't have sales permissions (e.g. stock managers). This commit fixes the issue by adding `groups` to the field. Forward-Port-Of: odoo/enterprise#64504 Forward-Port-Of: odoo/enterprise#60912

A new field of type 'sale.subscription.pricing' was added to the 'product.template' model. This breaks product creation form for users who don't have sales permissions (e.g. stock managers). This commit fixes the issue by adding `groups` to the field.

Forward-Port-Of: odoo/enterprise#64504
Forward-Port-Of: odoo/enterprise#60912

…efined Steps to reproduce: - Have a company A - Have a company B - Have a Product A defined only for Company A - Activate intercompany and automatic invoice/bills in both Company A and Company B - In Company A, create an invoice with Product A and Company B as the customer - Confirm Issue: An access error is raised Cause: Because of the new access rules introduced by branches, `account.move.line` have `_check_company_auto = True` https://github.com/odoo/odoo/blob/14db39961c445

…efined

Steps to reproduce:
- Have a company A
- Have a company B
- Have a Product A defined only for Company A
- Activate intercompany and automatic invoice/bills in both Company A and Company B
- In Company A, create an invoice with Product A and Company B as the customer
- Confirm

Issue:
An access error is raised

Cause:
Because of the new access rules introduced by branches, `account.move.line` have `_check_company_auto = True`
https://github.com/odoo/odoo/blob/14db39961c445a8243c2cc7af44132320a655594/addons/account/models/account_move_line.py#L23

Triggering the check at
https://github.com/odoo/odoo/blob/e30853b9fbde28cd4b1dc9948e12fe2be0b03abc/odoo/models.py#L4324-L4325

Creating inconsistencies at
https://github.com/odoo/odoo/blob/e30853b9fbde28cd4b1dc9948e12fe2be0b03abc/odoo/models.py#L3745-L3750

Solution:
Set the product on the bill only it has no company_id set on it

opw-3875354

Forward-Port-Of: odoo/enterprise#63086

Before this commit only admin can add pivot in dashbord. <img width="680" alt="image" src="https://github.com/odoo/enterprise/assets/16716992/a301451f-1bf1-42f7-81fa-d93ab9223d05"> Forward-Port-Of: odoo/enterprise#65048

Before this commit only admin can add pivot in dashbord.

<img width="680" alt="image" src="https://github.com/odoo/enterprise/assets/16716992/a301451f-1bf1-42f7-81fa-d93ab9223d05">

Forward-Port-Of: odoo/enterprise#65048

Task-3610647 Forward-Port-Of: odoo/enterprise#64909 Forward-Port-Of: odoo/enterprise#64267

Task-3610647

Forward-Port-Of: odoo/enterprise#64909
Forward-Port-Of: odoo/enterprise#64267

When timezone of user is empty and the user clicks on Add a Leave button, a traceback will appear. Steps to reproduce the error: - Open Profile > Preferences > Select empty in timezone > Save - Install 'Appointments' - Go to Appointments > Schedule > Resource Bookings > Add a Leave Traceback: ``` AttributeError: 'bool' object has no attribute 'upper' File "odoo/http.py", line 2254, in __call__ response = request._serve_db() File "odoo/http.py", line 1829, in _serve_db

When timezone of user is empty and the user clicks on Add a Leave button,
a traceback will appear.

Steps to reproduce the error:
- Open Profile > Preferences > Select empty in timezone > Save
- Install 'Appointments'
- Go to Appointments > Schedule > Resource Bookings > Add a Leave

Traceback:
```
AttributeError: 'bool' object has no attribute 'upper'
  File "odoo/http.py", line 2254, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1829, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1849, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1827, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1834, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2059, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 220, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 38, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 34, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 871, in onchange
    defaults = self.default_get(missing_names)
  File "odoo/models.py", line 1524, in default_get
    defaults[name] = field.default(self)
  File "home/odoo/src/enterprise/saas-17.2/appointment/wizard/appointment_manage_leaves.py", line 20, in <lambda>
    leave_start_dt = fields.Datetime('Start Date', required=True, default=lambda self: self._default_time(0, 0))
  File "home/odoo/src/enterprise/saas-17.2/appointment/wizard/appointment_manage_leaves.py", line 14, in _default_time
    user_timezone = pytz.timezone(self.env.user.tz or self.env.context.get('tz', 'utc'))
  File "odoo/tools/_monkeypatches_pytz.py", line 129, in timezone
    return original_pytz_timezone(name)
  File "__init__.py", line 183, in timezone
    if zone.upper() == 'UTC':
```

https://github.com/odoo/enterprise/blob/7640860f415028d2d516a2df5e4bc26d9d6dd3b4/appointment/wizard/appointment_manage_leaves.py#L14 When the user selects an empty timezone, tz will be False.
So, It will lead to the above traceback.

sentry-5443573507

Forward-Port-Of: odoo/enterprise#63858

Current behavior: --- When looking at an appointment availability, slots are missing (ie: 11pm-12am) Steps to reproduce: --- 1. Install website_appointment 2. Go to Appointment 3. Select/Create a resource appointment 4. Make sure resources use the default calendar 5. In schedule, change 'To' to midnight (00:00) 6. Click on 'Go to Website' 7. Select the next day 8. Should be available until midnight 9. => slots missing Cause of the issue: --- When computing unavailabilities wi

Current behavior:
---
When looking at an appointment availability, slots are missing (ie: 11pm-12am)

Steps to reproduce:
---
1. Install website_appointment
2. Go to Appointment
3. Select/Create a resource appointment
4. Make sure resources use the default calendar
5. In schedule, change 'To' to midnight (00:00)
6. Click on 'Go to Website'
7. Select the next day
8. Should be available until midnight
9. => slots missing

Cause of the issue:
---
When computing unavailabilities with _unavailable_intervals_batch, 
it takes all available slots: 12am-11:59am, 12pm-11:59pm 
then finds intervals between slots: 11:59am-12pm 11:59pm-12am 
These 1-minute intervals invalidate their respective slot 
=> the slots 11am-12pm and 11pm-12am will show as unavailable

Fix:
---
Don't consider intervals that are one minute or less as unavailable

Community PR: https://github.com/odoo/odoo/pull/163213

opw-3861561

Forward-Port-Of: odoo/enterprise#64949
Forward-Port-Of: odoo/enterprise#61403