A bug in the Mail app could cause public Discuss conversations to crash when a new message arrived before the user's identity was fully loaded. This fix makes message handling more reliable and prevents interruptions for users joining or viewing public discussions.

This may happen when receiving a new message without setting the self persona yet.

Fix runbot issue 19975

Spreadsheet pivots and lists now automatically show clear black borders around header areas and total rows. This makes inserted tables easier to read when header backgrounds are close in color to grid lines.

### Description of the issue/feature this PR addresses:

The problem is that when users insert pivots/lists, because the background color of headers is close to the grid line color, the border of cells becomes almost invisible. 

### Current behavior before PR:

See above. 

### Desired behavior after PR is merged:

When inserting pivots/lists, the cells in header zone will automatically have borders. 

task [3103403](https://www.odoo.com/web#id=3103403&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

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

This fix ensures the Belgian localization demo setup does not block or replace demo accounts created by other modules. It helps demo environments work correctly when Belgian accounting is used together with modules such as payroll accounting.

Other modules (i.e. `hr_payroll_account`) might also be creating demo accounts, do not prevent that.

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

Mail notifications no longer assume every visitor is signed in as an internal user. This prevents errors for guest users, helping shared discussions and portal-style interactions continue smoothly.

Some code in handle notification wrongly assumes `store.user` is set, as it reads `user.id`. This is correct when the user is authenticated as an internal user, but for guests this is incorrect.

This commit adapt code of handling notifications so that `store.user` can be undefined for guests.

Fix runbot issue 19978

The mail app no longer logs an unnecessary warning when emoji data is not loaded before a short automated flow ends. Users still see the existing failure message if emojis cannot load, while internal test systems avoid false failure alerts.

This happens intentionally on tours that finishes successfully before the emojis are fully loaded. Notably short tours like public discuss page show this case.

The console.warn still trigger unhappy runbot. Functionally the emoji picker shows "Failed to load emoji", so this warning becomes useless.

Fix runbot issue 20081

This update fixes incorrect data lookups in the public live chat interface that could trigger errors while visitors use chat. It helps keep the live chat window stable and reliable for website users and support teams.

- non-field read "__parentedMixin" on record(PublicLivechatView_1)
- non-field read "model" on record(PublicLivechat_1)
- non-field read "isFolded" on record(PublicLivechatWindow_1)

The live chat startup flow was adjusted to avoid an unnecessary failure during page loading. This should make the website chat button and chatbot experience more reliable for visitors, with no expected change to normal business workflows.

*: website_livechat

This fix ensures frontend services are only deployed and started once, even when several services register at nearly the same time. It reduces the risk of duplicate initialization that could cause inconsistent behavior in areas such as live chat, mail, surveys, and website interactions.

Before this commit, it was possible to deploy services more
than once. This happened in case the root widget was about to
deploy and start the services, and more than one service was
registering itself during a next tick.

Services must be deployed and started only once. This commit
ensures that if many services are added in this scenario, the
services are deployed and started only once.

Task-2878911

Selecting an emoji in the mail composer now keeps the cursor where the user was typing instead of moving it to the end of the message. This makes composing messages smoother and avoids extra editing when adding emojis mid-sentence.

This commit fixes the caret location after selecting an emoji
Previously that location was reset to the end of the input every time
an emoji was inserted

The demo Partner Spreadsheet now shows borders around pivot and list headers. This small visual fix makes the sample spreadsheet easier to read and better presented for users exploring Documents Spreadsheet.

This PR adds borders for headers of pivot and list in the demo spreadsheet (Partner Spreadsheet Test).

task [3103403](https://www.odoo.com/web#id=3103403&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

See the changes in community: https://github.com/odoo/odoo/pull/117493

The Kanban board’s quick-create process has been reorganized to use a simpler, more focused approach within the Kanban view. This reduces internal complexity and should make future maintenance more reliable without changing the overall user workflow.

This commit uses an extension of the form view controller as the
kanban's record quick create. This is done to simplify the relational
model and the kanban record quick create.

part-of task-id 3179751

This update changes much of Odoo's web code to use modern browser module loading instead of an older internal format. It is mainly an internal cleanup that should make the web client easier to maintain and prepare for simpler startup code, with little direct impact on day-to-day users.

This commit converts almost all odoo module by native module. The goal is to deprecate odoo.define in favor of native module and then simplify boot.js by removing the regexp that finds module dependencies.

task id: 3162300

This update reorganizes internal parts of Odoo's Mail module that manage message-related data updates. It should make the code easier to maintain and reduce risk in future mail and messaging changes, without introducing direct user-facing changes.

Task-3037277

This update cleans up how Odoo's internal email and SMS tests are organized by removing unnecessary duplicate test helper classes. It makes the test structure easier to maintain and supports future separation of test add-ons without affecting end users.

Remove 'TestMailCommon' and 'TestSMSCommont' test classes. Use MailCommon
or SMSCommon when possible to ease move of test addons and inheritance.

'TestMailCommon' was useless and is replaced by the 'MailCommon' class defined
directly in Mail addon, easing inheritance and imports.

'TestSMSCommon' was useless and is replaced by the 'SMSCommon' class defined
directly in SMS addon, easing inheritance and imports. See community PR for
more details.

Task-3263512

The pull request streamlines internal SMS-related test setup by using the shared SMS testing base directly. This reduces maintenance overhead for developers without changing how business users experience the product.

This update modernizes the internal code behind Mexico-specific Point of Sale invoicing popups. It helps keep the feature aligned with the newer Odoo interface framework, reducing future maintenance risk without changing day-to-day user workflows.

Part of https://github.com/odoo/odoo/pull/116307.

The test tour `time_off_request_calendar_view` would fail once the first Thursday of the year was not visible to the user (e.g. on the 1st April) as the MouseEvents would not be fired. Forward-Port-Of: odoo/odoo#117440

The test tour `time_off_request_calendar_view` would fail once the first Thursday of the year was not visible to the user (e.g. on the 1st April) as the MouseEvents would not be fired.

Forward-Port-Of: odoo/odoo#117440

- Create an account of type current asset - Add him a Sales Tax and a Purchase Tax - Create invoice - Add a line - Remove the taxes from this line - Change the account to the one you created => A purchase tax is applied to the line. It should not happen, so we prevent it. 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/sub

- Create an account of type current asset
- Add him a Sales Tax and a Purchase Tax
- Create invoice
- Add a line
- Remove the taxes from this line
- Change the account to the one you created

=> A purchase tax is applied to the line.
It should not happen, so we prevent it.

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#117481
Forward-Port-Of: odoo/odoo#115196

before this commit, in the website profile, ie in the forum, if we filter the users using This week or This month filters, always the + is displayed along with the gained karma. so if the user's gained karma during the selected period is negative values, lets say -500, currently it displays as follows --> +-500 , instead of -500 after this commit, if the gained karma during the period is it will show as -500 instead of +-500 with reference to: https://github.com/odoo/odoo/pull/111634

before this commit, in the website profile, ie in the forum, if we filter the users using This week or This month filters, always the + is displayed along with the gained karma.

so if the user's gained karma during the selected period is negative values, lets say -500, currently it displays as follows --> +-500 , instead of -500

after this commit, if the gained karma during the period is it will show as -500 instead of +-500


with reference to: https://github.com/odoo/odoo/pull/111634

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

Forward-Port-Of: odoo/odoo#117018
Forward-Port-Of: odoo/odoo#114506

…ounts exist The first problem when multiple analytics accounts exist is the sql query, it is generated with less placeholders than the actual arguments, so putting the ids in an array groups them in a single argument. The second problem is the getter from the collected data dict in the project models, it is assuming there is only a single account for all projects. see also https://github.com/odoo/enterprise/pull/36855 ``` Traceback (most recent call last): [...] data = model.

…ounts exist

The first problem when multiple analytics accounts exist is the sql query, it is generated with less placeholders than the actual arguments, so putting the ids in an array groups them in a single argument.

The second problem is the getter from the collected data dict in the project models, it is assuming there is only a single account for all projects.

see also https://github.com/odoo/enterprise/pull/36855

```
Traceback (most recent call last):
[...]
    data = model.search_read(domain=domain, fields=fields_list, limit=80)
   File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4947, in search_read
    result = records.read(fields, **read_kwargs)
   File "/home/odoo/src/odoo/16.0/odoo/models.py", line 2966, in read
    return self._read_format(fnames=fields, load=load)
   File "/home/odoo/src/odoo/16.0/odoo/models.py", line 3115, in _read_format
    vals[name] = convert(record[name], record, use_name_get)
   File "/home/odoo/src/odoo/16.0/odoo/models.py", line 5830, in __getitem__
    return self._fields[key].__get__(self, type(self))
   File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1188, in __get__
    self.compute_value(recs)
   File "/home/odoo/src/odoo/16.0/odoo/fields.py", line 1347, in compute_value
    records._compute_field_value(self)
   File "/home/odoo/src/odoo/16.0/addons/mail/models/mail_thread.py", line 403, in _compute_field_value
    return super()._compute_field_value(field)
   File "/home/odoo/src/odoo/16.0/odoo/models.py", line 4175, in _compute_field_value
    getattr(self, field.compute)()
   File "/home/odoo/src/odoo/16.0/addons/project_purchase/models/project.py", line 30, in _compute_purchase_orders_count
    self._cr.execute(query_string, query_param)
   File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 515, in execute
    return self._cursor.execute(*args, **kwargs)
   File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 310, in execute
    _logger.debug("query: %s", self._format(query, params))
   File "/home/odoo/src/odoo/16.0/odoo/sql_db.py", line 302, in _format
    return self._obj.mogrify(query, params).decode(encoding, 'replace')
 TypeError: not all arguments converted during string formatting
```

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

Forward-Port-Of: odoo/odoo#112271

Problem: The email created by _send_availability_email is not translated correctly. The body is always sent in English and the subject will always use the current language of the database. Example: Partner A's language = Spanish Current database language = "French" The body of the email sent to Partner A will be in English and the subject of the email sent will be in French. Solution: Pass in the partner's language into the context. If the partner does not have any language, defau

Problem:
The email created by _send_availability_email is not translated correctly. The body is always sent in English
and the subject will always use the current language of the database.

Example:
Partner A's language = Spanish
Current database language = "French"

The body of the email sent to Partner A will be in English and the subject of the email sent will be in French.

Solution:
Pass in the partner's language into the context.
If the partner does not have any language, default to English. This fix will translate the entire email uniformly according to the context's language.

opw-3207979

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

Forward-Port-Of: odoo/odoo#114885

This commit improves ux/ui by adding the slide description on top of quiz and offering links to additional resources if user gets questions wrong. task-3246366 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117047 Forward-Port-Of: odoo/odoo#116576

This commit improves ux/ui by adding the slide
description on top of quiz and offering links to additional resources if user gets questions wrong.

task-3246366



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

Forward-Port-Of: odoo/odoo#117047
Forward-Port-Of: odoo/odoo#116576

**Issue:** Trying to print an image from attachment_viewer (the component on chatter that previews the attachment on chatter) the page opened is completely empty because this.imageUrl is undefined . **Fix:** The correct attr that should be used is imageUrl from attachmentViewerViewable --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#114547

**Issue:**

Trying to print an image from attachment_viewer (the component on chatter that previews the attachment on chatter) the page opened  is completely empty because  this.imageUrl is undefined . 


**Fix:**
The correct attr that should be used is imageUrl from attachmentViewerViewable






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

Forward-Port-Of: odoo/odoo#114547

**[FIX] project: display project in read-only when portal user is not a collaborator** Before this commit: - A portal user cannot access the project if he's not a follower but a public user can do that and It doesn't make sense for portal users to have less access than public users. - Technically the problem was that we call _check_project_sharing_access with a project with the portal user instead of sudo, so when trying to access self.collaborator_ids, an exception is raised saying that t

**[FIX] project: display project in read-only when portal user is not a collaborator**

Before this commit:
- A portal user cannot access the project if he's not a follower but a public user can do that and  It doesn't make sense for portal users to have less access than public users.
- Technically the problem was that we call _check_project_sharing_access with a project with the portal user instead of sudo, so when trying to access self.collaborator_ids, an exception is raised saying that the portal user cannot have access to project fields.

After this commit:
- Portal users can both access the project in read-only when they are not part of followers.
- Technically, we preferred searching over just adding self.sudo() to get the result directly in one query for a better performance.

task-3205644

Forward-Port-Of: odoo/odoo#117401
Forward-Port-Of: odoo/odoo#113657

I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117515

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

Forward-Port-Of: odoo/odoo#117515

Steps to reproduce ================== - Go to eLearning - On the "Trees, Wood and Gardens" card, click on "view course" - Click on Main Trees Categories The slide name is outside the view Also, the XP badge is cropped Before ======  After ==== ![Screen Shot 2023-03-28 at 10 16 21](https://user-images.githubusercontent.com/48759451/228

Steps to reproduce
==================

- Go to eLearning
- On the "Trees, Wood and Gardens" card, click on "view course"
- Click on Main Trees Categories

The slide name is outside the view
Also, the XP badge is cropped

Before
======

![Screen Shot 2023-03-28 at 10 18 14](https://user-images.githubusercontent.com/48759451/228173909-8a05ef7d-6285-423c-8be3-ccde602229ff.png)

After
====

![Screen Shot 2023-03-28 at 10 16 21](https://user-images.githubusercontent.com/48759451/228173284-09960a33-a578-47c3-aca9-f3dbf6fd6349.png)

opw-3225999

Forward-Port-Of: odoo/odoo#116781

Before this revision, a date/datetime field was displayed in UTC instead of in the user timezone. This revision fixes this issue. opw 3127742 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#117514 Forward-Port-Of: odoo/odoo#114529

Before this revision, a date/datetime field was displayed in UTC instead of in the user timezone.
This revision fixes this issue.

opw 3127742

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#117514
Forward-Port-Of: odoo/odoo#114529

when customer upgrading their database to the 16.0 from older versions then it, they are facing an issue in discuss app during opening the chat ``` UncaughtClientError > TypeError Uncaught Javascript Error > Cannot read properties of undefined (reading 'channel') TypeError: Cannot read properties of undefined (reading 'channel') at model.compute (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:11716:504) at Listener.onChange (https://69.test.u

when customer upgrading their database to the 16.0 from older versions then it, they are facing an issue in discuss app during opening the chat

```
UncaughtClientError > TypeError
Uncaught Javascript Error > Cannot read properties of undefined (reading 'channel')
TypeError: Cannot read properties of undefined (reading 'channel')
    at model.compute (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:11716:504)
    at Listener.onChange (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:10422:252)
    at ModelManager._notifyListenersInUpdateCycle (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:10446:226)
    at ModelManager._flushUpdateCycle (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:10433:64)
    at ModelManager.update (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:10357:62)
    at model.update (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:10504:137)
    at model._handleGlobalWindowFocus (https://69.test.upgrade.odoo.com/web/assets/157609-0cec86b/web.assets_backend.min.js:11803:184)
    at owl.EventBus.trigger (https://69.test.upgrade.odoo.com/web/assets/157608-48bb818/web.assets_common.min.js:1535:63)
    at onFocusChange (https://69.test.upgrade.odoo.com/web/assets/157608-48bb818/web.assets_common.min.js:6255:165)
    at https://69.test.upgrade.odoo.com/web/assets/157608-48bb818/web.assets_common.min.js:6258:84
```

for more clear: https://www.awesomescreenshot.com/video/16178967?key=69054b02935378a1708a3cdc726614fa

issue-3183156,3232109,3229195,3248633

Forward-Port-Of: odoo/odoo#117570
Forward-Port-Of: odoo/odoo#117468

- Japan chart of account template updates - Translation updates - Use better code names for tax report task-3127047 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#112278

- Japan chart of account template updates
- Translation updates
- Use better code names for tax report

task-3127047

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

Forward-Port-Of: odoo/odoo#112278

Steps to reproduce the error: 1. Open a Pos 2. Without any orderline, click on `+-` button 3. You will see an error issue https://github.com/odoo/odoo/issues/115642 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117063 Forward-Port-Of: odoo/odoo#116478

Steps to reproduce the error:
 1. Open a Pos
 2. Without any orderline, click on `+-` button
 3. You will see an error

issue https://github.com/odoo/odoo/issues/115642

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

Forward-Port-Of: odoo/odoo#117063
Forward-Port-Of: odoo/odoo#116478

Before revision 5bf1207c8cb7575fba4501aff4932c2cc952bf9f a new environment was created for each call at `xml_import` or `convert_file`, with `odoo.api.Environment(cr, SUPERUSER_ID, {})` meaning the context was empty, meaning the lang was never set Now that we pass from end to end the environment, the caller of `xml_import` or `convert_file` passes his own environment, therefore propagating his `context` variables, therefore potentially passing a lang in the context. Therefore, since

Before revision 5bf1207c8cb7575fba4501aff4932c2cc952bf9f a new environment was created for each call
at `xml_import` or `convert_file`,
with `odoo.api.Environment(cr, SUPERUSER_ID, {})`
meaning the context was empty, meaning the lang was never set

Now that we pass from end to end the environment,
the caller of `xml_import` or `convert_file`
passes his own environment, therefore propagating
his `context` variables, therefore potentially passing a lang in the context.

Therefore, since this change, the lang of the user is taken into account when calling `xml_import`/`convert_file`, and it updates the translation term rather than the source term for translated fields.

This could be an actual/intended valid behavior,
this needs to be discussed,
but currently the places where `xml_import`/`convert_file` is called expects to update the source term,
not the translated term.
See for reference
https://github.com/odoo/odoo/pull/116780#issuecomment-1486506663

Therefore, as this is an unexpected/unintended change of behavior of the refactor 5bf1207c8cb7575fba4501aff4932c2cc952bf9f, and as code blocks calling `xml_import`/`convert_file` have not been adapted, we prefer to play it safe
and revert the behavior to what is was.

This is very possible other context keys will need to be dropped, but one of the desired change of the refactor was to be able to pass keys in the context, currently we prefer to not wipe the environment context and just blacklist the one we do not want to propagate, such as the lang.
If other related issues arise, we will then re-consider.

Forward-Port-Of: odoo/odoo#117383

Since saas 16.1, we added a more visible error information box when the module system cannot find some dependencies, or if there is an error in the JS code. This error box is very useful to understand a lot of typical devlopment issues. However, it was occasionally displayed in production code. However, we sometimes observe that the error information box was displayed, because the request to load an assets failed with a 404. It is unclear in which circumstance this can happen, but it

Since saas 16.1, we added a more visible error information box when the
module system cannot find some dependencies, or if there is an error in
the JS code. This error box is very useful to understand a lot of
typical devlopment issues.  However, it was occasionally displayed in
production code.

However, we sometimes observe that the error information box was
displayed, because the request to load an assets failed with a 404.

It is unclear in which circumstance this can happen, but it seems that
the following elements are involved:

- the user has an open tab with odoo, kept open for a while
- some js code is changed on the server, which causes the previous
assets to be deleted
- the user reload its open tabs, so the browser will load the /web page
from disk, which points to the old assets files
- then it will try to load all assets, with a 404 on one of the script
- the error information box is displayed

This commit intercepts the loading error and stop displaying the error
information box, which is basically the same behaviour as 16.0 and
before. We could force a reload in that case, but it seems dangerous,
since in case of errors, it could easily lead to an infinite loop.



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

Forward-Port-Of: odoo/odoo#117541
Forward-Port-Of: odoo/odoo#117453

Before this commit: the `product.display_name` field could contain line breaks, which prevented it from being matched correctly by regular expressions. This commit fixes the issue by modifying the `_product_search_string()` function to remove line breaks. opw-3239830 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117368 Forward-Port-Of: odoo/odoo#116692

Before this commit: the `product.display_name` field could contain line breaks, which prevented it from being matched correctly by regular expressions. This commit fixes the issue by modifying the `_product_search_string()` function to remove line breaks.

opw-3239830

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

Forward-Port-Of: odoo/odoo#117368
Forward-Port-Of: odoo/odoo#116692

With `generic_coa` now installed by default, the default pos.config are automatically assigned a sale and an invoice journal, and trying to install afterward a country specific chart template result in the following error: 2023-04-03 16:29:27,642 9344 ERROR _testdb-162820-testdb-162820-point-of-sale odoo.sql_db: bad query: DELETE FROM "account_journal" WHERE id IN (1, 2, 3, 8, 4, 6, 9, 7, 5, 10) ERROR: update or delete on table "account_journal" violates foreign key constraint "pos_config_jo

With `generic_coa` now installed by default, the default pos.config are automatically assigned a sale and an invoice journal, and trying to install afterward a country specific chart template result in the following error:

2023-04-03 16:29:27,642 9344 ERROR _testdb-162820-testdb-162820-point-of-sale odoo.sql_db: bad query: DELETE FROM "account_journal" WHERE id IN (1, 2, 3, 8, 4, 6, 9, 7, 5, 10)
ERROR: update or delete on table "account_journal" violates foreign key constraint "pos_config_journal_id_fkey" on table "pos_config"
DETAIL:  Key (id)=(10) is still referenced from table "pos_config".

Traceback (most recent call last):
  ...
  File "/home/odoo/src/odoo/saas-16.2/odoo/modules/loading.py", line 481, in load_modules
    processed_modules += load_marked_modules(env, graph,
  File "/home/odoo/src/odoo/saas-16.2/odoo/modules/loading.py", line 365, in load_marked_modules
    loaded, processed = load_module_graph(
  File "/home/odoo/src/odoo/saas-16.2/odoo/modules/loading.py", line 297, in load_module_graph
    module.write({'state': 'installed', 'latest_version': ver})
  File "/home/odoo/src/odoo/saas-16.2/addons/account/models/ir_module.py", line 67, in write
    self.env['account.chart.template'].try_loading(
  File "/home/odoo/src/odoo/saas-16.2/addons/account/models/chart_template.py", line 141, in try_loading
    return self._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/saas-16.2/addons/point_of_sale/models/chart_template.py", line 16, in _load
    result = super()._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/saas-16.2/addons/account/models/chart_template.py", line 176, in _load
    self.env[model].search([('company_id', '=', company.id)]).with_context({MODULE_UNINSTALL_FLAG: True}).unlink()
  File "/home/odoo/src/odoo/saas-16.2/addons/account/models/account_journal.py", line 524, in unlink
    ret = super(AccountJournal, self).unlink()
  File "/home/odoo/src/odoo/saas-16.2/addons/mail/models/mail_thread.py", line 326, in unlink
    res = super(MailThread, self).unlink()
  File "/home/odoo/src/odoo/saas-16.2/addons/mail/models/mail_activity_mixin.py", line 246, in unlink
    result = super(MailActivityMixin, self).unlink()
  File "/home/odoo/src/odoo/saas-16.2/odoo/models.py", line 3635, in unlink
    cr.execute(query, (sub_ids,))
  File "/home/odoo/src/odoo/saas-16.2/odoo/sql_db.py", line 311, in execute
    res = self._obj.execute(query, params)
psycopg2.errors.ForeignKeyViolation: update or delete on table "account_journal" violates foreign key constraint "pos_config_journal_id_fkey" on table "pos_config" DETAIL:  Key (id)=(10) is still referenced from table "pos_config".

This commit also reset the journals on the existing pos.config so that `post_install_pos_localisation()` assign the right ones once the new chart template is loaded.
    
We also only reset payment methods and journals in case we load a new chart of accounts (this fix the "reload" of the CoA when PoS is installed)

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

Forward-Port-Of: odoo/odoo#117522

In some themes, RGBA colors were used to define the colors of shapes. However, adding this color in the parameters of the background image URL of a "shape" element was not valid. This caused several bugs, such as the colorpicker not finding the colors of the shape used, as well as the colors of the shape being lost after the application of a "flip". Steps to reproduce the bug: - In website edit mode, open the homepage page of the Nano theme. - Drag and drop a Banner snippet onto the page.

In some themes, RGBA colors were used to define the colors of shapes. However, adding this color in the parameters of the background image URL of a "shape" element was not valid. This caused several bugs, such as the colorpicker not finding the colors of the shape used, as well as the colors of the shape being lost after the application of a "flip".

Steps to reproduce the bug:

- In website edit mode, open the homepage page of the Nano theme.
- Drag and drop a Banner snippet onto the page.
- Bug: The colorpicker does not recognize the four colors used by the shape.
- Click on one of the two "Flip" buttons.
- Bug: The colors of the shape are lost.

Also, this commit combines the two "onBuilt" methods of the "BackgroundShape" options. This should have been done during the forward-port of this commit [1], but we missed it.

[1]: https://github.com/odoo/odoo/commit/256ff539afe331544ccb58848f1ecd0eecbe4daa

task-2824607

Forward-Port-Of: odoo/odoo#117394
Forward-Port-Of: odoo/odoo#116052

On a calendar event, the 'free' option does not hide the element. So that the user doesn't expect this behavior, you have to modify its description. opw-3047999 Forward-Port-Of: odoo/odoo#116654

On a calendar event, the 'free' option does not hide the element.
So that the user doesn't expect this behavior,
you have to modify its description.

opw-3047999

Forward-Port-Of: odoo/odoo#116654

Incorporate Rolando Duarte (rolandojduartem) as Vauxoo's contributor. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#117558 Forward-Port-Of: odoo/odoo#117545

Incorporate Rolando Duarte (rolandojduartem) as Vauxoo's contributor.

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

Forward-Port-Of: odoo/odoo#117558
Forward-Port-Of: odoo/odoo#117545

It takes a too long to load project task kanban view. And ~85% of this time is spent in `ProjectTask._get_all_subtasks`, which is a recursive method returning the children of the children, while any, of the task, for each task, just to display their count. We replaced this recursive method with a SQL request, which is way faster. Also, it can be called in batch. It will return a dict {id: subtask_ids}. task-3246085 --- I confirm I have signed the CLA and read the PR guidelines at w

It takes a too long to load project task kanban view. And ~85% of this time is spent in `ProjectTask._get_all_subtasks`, which is a recursive method returning the children of the children, while any, of the task, for each task, just to display their count.

We replaced this recursive method with a SQL request, which is way faster. Also, it can be called in batch. It will return a dict {id: subtask_ids}.

task-3246085



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

Forward-Port-Of: odoo/odoo#117532
Forward-Port-Of: odoo/odoo#116570

There is a very nice and clear system that helps the user to figure what are the available area to drop content inside, and what will they do: are they shared between products, or product specific etc. The issue is that once you have dropped a snippet inside, that helper message is not shown anymore, but it's still not obvious which area is used for what, actually you have no clue which one is which, especially if you come back on the page later: at best remember there were 2 separate zones b

There is a very nice and clear system that helps the user to figure what are the available area to drop content inside, and what will they do: are they shared between products, or product specific etc.

The issue is that once you have dropped a snippet inside, that helper message is not shown anymore, but it's still not obvious which area is used for what, actually you have no clue which one is which, especially if you come back on the page later: at best remember there were 2 separate zones but you don't especially remember which one is which.

Keeping the message helps in that regard without any negative impact.

Note that making the message appear when there are already a snippet will work out of the box in the sense that the message will be duplicated and shown twice: one at the very bottom of the area and one at the very top.

task-3160416

For tracking purpose, here is how it looks like in actual 16.0:
| color | before | after |
| -- | -- | -- |
| white | ![image](https://user-images.githubusercontent.com/30048408/224693692-ea6111d1-429b-4fac-a9c3-b4295656d066.png) |![image](https://user-images.githubusercontent.com/30048408/224694899-f70ed5b1-675f-4e15-ade9-2d8513b58492.png) |
|odoo purple | ![image](https://user-images.githubusercontent.com/30048408/224693807-5540993e-a14f-42f9-8c74-fae4c34cff0b.png) |![image](https://user-images.githubusercontent.com/30048408/224694810-3e8b56dd-ac06-42e4-8848-fcada8de1896.png) |
| odoo green | ![image](https://user-images.githubusercontent.com/30048408/224693905-d5c8d0ff-6ae7-48a1-b56d-e572a02ffba4.png) | ![image](https://user-images.githubusercontent.com/30048408/224694863-2c3e19f1-5c77-4d58-86dc-da57069f824c.png)|
| gray | ![image](https://user-images.githubusercontent.com/30048408/224694004-f480899e-9ae3-441d-b006-1745ea1354d8.png) | ![image](https://user-images.githubusercontent.com/30048408/224694664-a0462485-e7e5-4457-afaa-0236075298ef.png) |
| black | ![image](https://user-images.githubusercontent.com/30048408/224694324-a1f0db75-693b-4124-bab1-c2c2b77466f7.png) | ![image](https://user-images.githubusercontent.com/30048408/224694737-046e1a4c-1d87-4d59-8039-401057cfe30f.png)|

Forward-Port-Of: odoo/odoo#111515

When a new tax is created and click on Reload button of fiscal Localization it will generate traceback. Steps to Produce:- - Create a new Tax. - Then open the setting of invoicing and Click on reload Button which is located inside fiscal Localization. - IndexError will be generated. Cause:- - When a user creates a tax from UI `get_external_id` return an empty string and we try to `spilt` an empty string and get 1 index value and because of that it gives traceback. Fix:- - Che

When a new tax is created and click on Reload button of fiscal Localization it
will generate traceback.

Steps to Produce:-
- Create a new Tax.
- Then open the setting of invoicing and Click on reload Button which is located
  inside fiscal Localization.
- IndexError will be generated.

Cause:-
- When a user creates a tax from UI `get_external_id` return an empty string and
we try to `spilt` an empty string and get 1 index value and because of that
it gives traceback.

Fix:-
- Check xml_id is not null before trying to spilt and get the value from xml_id.


![image](https://user-images.githubusercontent.com/91726130/229419930-383cf813-e6cb-4fb4-8ded-d8b710d45e7e.png)

Sentry-4042986115

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

Forward-Port-Of: odoo/odoo#117436

**Steps to reproduce the bug:** - Create two warehouses in the same company - Create a storable product “P1”: - Add 10 units in each warehouse - Click on the forecasted widget **Problem:** The quantity on hand is 20 instead of 10 while the current warehouse set in the filter is "WH1", because the warehouse has not been added in the context, so we calculate all the quantities available in all the locations of the current company: https://github.com/odoo/odoo/blob/c05815ae6b8bd7afceb7

**Steps to reproduce the bug:**
- Create two warehouses in the same company
- Create a storable product “P1”:
    - Add 10 units in each warehouse
- Click on the forecasted widget

**Problem:**
The quantity on hand is 20 instead of 10 while the current warehouse set in the filter is "WH1", because the warehouse has not been added in the context, so we calculate all the quantities available in all the locations of the current company:
https://github.com/odoo/odoo/blob/c05815ae6b8bd7afceb760395af09c707c89c485/addons/stock/report/stock_forecasted.py#L164 https://github.com/odoo/odoo/blob/3ee5d7a0fbccae5f742e1aba8d3d24f8bab3cbdd/addons/stock/models/product.py#L275

for the filter, the default one is added in the context here: https://github.com/odoo/odoo/blob/16.0/addons/stock/static/src/stock_forecasted/forecasted_warehouse_filter.js#L19

opw-3194872

Forward-Port-Of: odoo/odoo#114308

**Current behavior before PR:** help command returns false instead of DM group members name **Desired behavior after PR is merged:** it returns DM group members name Task-2917720 -- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#115770 Forward-Port-Of: odoo/odoo#96491

**Current behavior before PR:**

help command returns false instead of DM group members name

**Desired behavior after PR is merged:**

it returns DM group members name

Task-2917720

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

Forward-Port-Of: odoo/odoo#115770
Forward-Port-Of: odoo/odoo#96491

…oduct with currency - Description of the issue/feature this PR addresses: Calling [price_compute()](https://github.com/odoo/odoo/blob/135c7e1884b3587fcd6e4034a8d2f42d07702106/addons/product/models/product.py#L641) on product.product cause AssertationError **IF you also provide currency parameter.** This happens because when currency_id conversion is performed, the product.company_id is False in variants, so maybe it should be investigated why is it false, but this is a very quick fix

…oduct with currency

- Description of the issue/feature this PR addresses:

Calling [price_compute()](https://github.com/odoo/odoo/blob/135c7e1884b3587fcd6e4034a8d2f42d07702106/addons/product/models/product.py#L641) on product.product cause AssertationError **IF you also provide currency parameter.** 

This happens because when currency_id conversion is performed, the product.company_id is False in variants, so maybe it should be investigated why is it false, but this is a very quick fix withoud any drawback.

- Steps to reproduce:

This is very easy to reproduce, but you need a simple snippet because there is no call to price_compute() in product.product while using currency conversion in original source code. Easiest way to reproduce this is to make a button that calls method on a product.product record, you will get AssertationError:

    def btn_test_price_compute(self):

        product = self.env['product.product'].browse(10)  # fetch any product from variant model
        currency = product.currency_id or self.env.company.currency_id  # fetch currency

        price = product.price_compute(
            "list_price",
            uom=product.uom_id,
            currency=currency,
            company=product.company_id
        )[product.id]


        # try to compute price: works fine in product template and also
        # in product product as long as you don't use 'company' argument.
        # As soon as you provide currency a conversion will be performed,
        # but it will fail because there is no product.company_id:
        #
        # >>AssertionError: convert amount from unknown company


- Desired behavior after PR is merged:

We can call price_compute() on product variants using currency conversion parameter without issues.

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

Forward-Port-Of: odoo/odoo#117644
Forward-Port-Of: odoo/odoo#117435

1. Install [Manufacturing] on Apps 2. On [Settings]>[Manufacturing] - toggle on [Work Orders], [Quality] & [Quality Worksheet] 3. Go to Manufacturing - Work Centers (a.k.a WC) Overview should be visible - if no W.C. by default, add from [Configuration]>[Work Centers] 4. click on the 3 dots at the top right corner of each WC card affected branch: saas-16.1 up to master Forward-Port-Of: odoo/odoo#117525

1. Install [Manufacturing] on Apps
2. On [Settings]>[Manufacturing]
- toggle on [Work Orders], [Quality] & [Quality Worksheet]
3. Go to Manufacturing
- Work Centers (a.k.a WC) Overview should be visible
- if no W.C. by default, add from [Configuration]>[Work Centers]
4. click on the 3 dots at the top right corner of each WC card

affected branch: saas-16.1 up to master

Forward-Port-Of: odoo/odoo#117525

Before this commit period of label actually spelled in dutch language 'Periode' not in english 'Period'. This commit fix typo by writting correct spelling in english. task-3186590 Forward-Port-Of: odoo/enterprise#39270 Forward-Port-Of: odoo/enterprise#37397

Before this commit period of label actually spelled in dutch language 'Periode' not in english 'Period'.

This commit fix typo by writting correct spelling
in english.

task-3186590

Forward-Port-Of: odoo/enterprise#39270
Forward-Port-Of: odoo/enterprise#37397

Some adaptations to community fix. Related: https://github.com/odoo/odoo/pull/116570 task-3246085 Forward-Port-Of: odoo/enterprise#39243 Forward-Port-Of: odoo/enterprise#38723

Some adaptations to community fix.

Related: https://github.com/odoo/odoo/pull/116570
task-3246085

Forward-Port-Of: odoo/enterprise#39243
Forward-Port-Of: odoo/enterprise#38723

Issue --> Consider a `data_merge.group` record with two `data_merge.record` records that point to two `crm.lead` records. Case 1: 1) Both the original `crm.lead` records have been deleted 2) The `res_id` field for the `data_merge.record` records point to an empty object Running the cron "Data Merge: Cleanup Records" leads to a traceback because the dictionary `original_records` inside the method `_cleanup()` is empty and the code `original_record = original_records[rec.res_id]` retur

Issue -->

Consider a `data_merge.group` record with two `data_merge.record` records that point to two `crm.lead` records.

Case 1:
1) Both the original `crm.lead` records have been deleted 
2) The `res_id` field for the `data_merge.record` records point to an empty object

Running the cron "Data Merge: Cleanup Records" leads to a traceback because the dictionary `original_records` inside the method `_cleanup()` is empty and the code `original_record = original_records[rec.res_id]` returns an error

Case 2:
1) One of the two original `crm.lead` records have been deleted

In this case, running to the cron leads to a KeyError traceback on the `original_records` dictionary as `original_record = original_records[rec.res_id]` tries to access a key that does not exist in it.

Both of these errors are caused by the `data_merge.record` records still existing even after the original records have been deleted.

Solution -->

This PR adds an if-else block and a dict.get() method call to handle the two cases mentioned above, respectively by utilizing the existing variables to unlink the `data_merge.group` and `data_merge.record` with non-existent `res_id` records.

opw-3193111

Forward-Port-Of: odoo/enterprise#37648

Forward-Port-Of: odoo/enterprise#39265

Forward-Port-Of: odoo/enterprise#39265

Steps to reproduce: - install 'hr_contract_salary' (to show template contract configuration); - go to 'Employees/Configuration/Contracts/Templates'; - create a new template; - create a new "Contract Document Template" via the form view; - upload a file; - click on 'SAVE & CLOSE' button; Issue: A User Error is triggered. Cause: In the code: `attachments = self.env['ir.attachment'].browse([vals.get('attachment_id') for vals in vals_list])` returns `attachments = [False]`. Therefore

Steps to reproduce:
- install 'hr_contract_salary' (to show template contract configuration);
- go to 'Employees/Configuration/Contracts/Templates';
- create a new template;
- create a new "Contract Document Template" via the form view;
- upload a file;
- click on 'SAVE & CLOSE' button;

Issue:
A User Error is triggered.

Cause:
In the code:
`attachments = self.env['ir.attachment'].browse([vals.get('attachment_id') for vals in vals_list])` returns `attachments = [False]`.
Therefore,
`self._check_pdf_data_validity(attachment.datas)` to check if the data `b''` is valid. As this is not the case, a user error is triggered.

Solution:
You have to make sure that an attachment is created when we do not pass in the `create_with_attachment_data` function before the `create` function.

Forward-Port-Of: odoo/enterprise#38195

Use the duration in the link to compute the end date as the custom appointment type can have multiple durations. Before, it was leading to having a 404 error because the duration was not enough to get the slot. Even if the duration has been tempered in the link, we check later if the duration has the correct value based on the type of slot. task-3259580 Forward-Port-Of: odoo/enterprise#39239 Forward-Port-Of: odoo/enterprise#39222

Use the duration in the link to compute the end date as the custom appointment type can have multiple durations. Before, it was leading to having a 404 error because the duration was not enough to get the slot. Even if the duration has been tempered in the link, we check later if the duration has the correct value based on the type of slot.

task-3259580

Forward-Port-Of: odoo/enterprise#39239
Forward-Port-Of: odoo/enterprise#39222

Bug === The link preview show the link tracker URL, now we show the title of the page. Task-3239261 Forward-Port-Of: odoo/enterprise#39228 Forward-Port-Of: odoo/enterprise#38473

Bug
===
The link preview show the link tracker URL,
now we show the title of the page.

Task-3239261

Forward-Port-Of: odoo/enterprise#39228
Forward-Port-Of: odoo/enterprise#38473

Steps to reproduce: - Install the Appointment and Website. - Create a new Online Appointment with certain hours available. - Now when we go to the frontend to book an appointment. - Now, taking into account that our default timezone is 'Europe/Brussels', we can see that the available hours are from 10:00 to 12:00. - Now we change the timezone any timezone we want to use, for example 'America/New_York', now we can see that the available hours are now from 5:00 am to 7:00am. - Then we sele

Steps to reproduce:

- Install the Appointment and Website.
- Create a new Online Appointment with certain hours available.
- Now when we go to the frontend to book an appointment.
- Now, taking into account that our default timezone is 'Europe/Brussels', we can see that the available hours are from 10:00 to 12:00.
- Now we change the timezone any timezone we want to use, for example 'America/New_York', now we can see that the available hours are now from 5:00 am to 7:00am.
- Then we select 5:00am, and we go to the next step, here we can see at the right side the hour that we have selected and the timezone.
- Now we change our mind and we want to change the hour that we have selected, so we go back to the previous step but using the browser button to go back (or the usual mouse button).
- In the first step again, we can see that we have the timezone reseted to 'Europe/Brussels' again, with it rights hours.
- Let's say we forgot to change the timezone again, and we just select one of the hours available for the current displayed timezone.
- We go to the next step and we look carfully at the right side, we can see what happened with the hour that we have selected, and the timezone.

Issue:

With the flow of going back using the browser, we don't keep the proper timezone in the session, so when we go back to the first step, the frontend is updated for the default timezone, but we never really change the previous timezone, which make us in this case for example, to be able to book an appointment for 10:00am for 'America/New_York' timezone, which is not an hour that we have available in our appointment.

Solution:

The issue is caused by the browser "storing" the page and not calling the controller again when we go back which leads to not updating the `request.session.timezone` key. So what we do here is to prevent the browser from storing the page, so when we go back, the controller is called again and the `request.session.timezone` is updated.

opw-3116509

Forward-Port-Of: odoo/enterprise#38826
Forward-Port-Of: odoo/enterprise#37920

steps to produce: - go to the helpdesk teams - select assignment method 'Random' or 'Balanced' - add same user(mitchell admin) as team member in both teams - then change assignment method to 'Manual' in one of team. - while applying 'my teams' filter on helpdesk team both of team will visible issue: manual assignment method and previously added team member on helpdesk team for that case my team filter not working properly. fix: adding domain for 'my teams' in helpdesk team task-305

steps to produce:
- go to the helpdesk teams
- select assignment method 'Random' or 'Balanced'
- add same user(mitchell admin) as team member in both teams
- then change assignment method to 'Manual' in one of team.
- while applying 'my teams' filter on helpdesk team both of team will visible

issue: manual assignment method and previously added team member on helpdesk team for that case my team filter not working properly.

fix: adding domain for 'my teams' in helpdesk team

task-3052920

Forward-Port-Of: odoo/enterprise#36603

### The Bug: We are getting a traceback when printing an invoice, for all invoices where the CDR was retrieved from IAP/Digiflow/SUNAT after the sending of the EDI document failed because the invoice already existed on SUNAT's side. The traceback happens because the EDI document that is saved in the ZIP attachment lacks the signature that is needed to generate the QR code. This is because we saved the unsigned version of the EDI document instead of the signed version. ### The Fix: In

### The Bug:
We are getting a traceback when printing an invoice, for all invoices where the CDR was retrieved from IAP/Digiflow/SUNAT after the sending of the EDI document failed because the invoice already existed on SUNAT's side.

The traceback happens because the EDI document that is saved in the ZIP attachment lacks the signature that is needed to generate the QR code.

This is because we saved the unsigned version of the EDI document instead of the signed version.

### The Fix:
In `_l10n_pe_edi_sign_invoices_{iap,digiflow,sunat}`, we always return the signed version of the EDI document, even if the IAP/Digiflow/SUNAT service returned an error, so that if we are able to recover from the error (in the case where the invoice already existed on SUNAT and we are able to download its CDR), the signed version gets saved.

opw-3243335

Forward-Port-Of: odoo/enterprise#39151
Forward-Port-Of: odoo/enterprise#39046

…ounts When multiple analytics account exist on projects, the sql query will have less placeholders than the account ids arguments. And the getter from the dict will use a key that has all ids. see also https://github.com/odoo/odoo/pull/112271 Forward-Port-Of: odoo/enterprise#36855

…ounts

When multiple analytics account exist on projects, the sql query will have less placeholders than the account ids arguments. And the getter from the dict will use a key that has all ids.

see also https://github.com/odoo/odoo/pull/112271

Forward-Port-Of: odoo/enterprise#36855

In the Documents app, create a new spreadsheet from a template. Reload the page => you see the raw template data Since 8377cd6 Test backported (and adapted) from bfe094b Forward-Port-Of: odoo/enterprise#39215 Forward-Port-Of: odoo/enterprise#39190

In the Documents app, create a new spreadsheet from a template. Reload the page
=> you see the raw template data

Since 8377cd6

Test backported (and adapted) from bfe094b

Forward-Port-Of: odoo/enterprise#39215
Forward-Port-Of: odoo/enterprise#39190

Description of the issue/feature this PR addresses: When trying to display any pill in the project.task gantt view (when the timesheet module is installed) a traceback is raised. Basically the time formater was deprecated, now using a simple reference, not 100% sure it's good in every case. Task-3249673 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#39013

Description of the issue/feature this PR addresses:

When trying to display any pill in the project.task gantt view (when the timesheet module is installed) a traceback is raised.
Basically the time formater was deprecated, now using a simple reference, not 100% sure it's good in every case.

Task-3249673

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

Forward-Port-Of: odoo/enterprise#39013

Steps to reproduce: - Go to Apps, and install the module `l10n_se_reports`. - Go to Accounting > Reporting > Fiscal Year EC Sales Report. - Select This Financial Year and click on "PDF". Issue: We aren't able to generate the pdf report for the fiscal year in ec sales report. Solution: We need to fix the limitation inside `_get_se_period` which wasn't ableing to get the period for a financial year. FW - port: saas-15.3 opw-3088073 Forward-Port-Of: odoo/enterprise#38846 Fo

Steps to reproduce:

- Go to Apps, and install the module `l10n_se_reports`.
- Go to Accounting > Reporting > Fiscal Year EC Sales Report.
- Select  This Financial Year and click on "PDF".

Issue:

We aren't able to generate the pdf report for the fiscal year in ec sales report.

Solution:

We need to fix the limitation inside `_get_se_period` which wasn't ableing to get the period for a financial year.

FW - port: saas-15.3

opw-3088073

Forward-Port-Of: odoo/enterprise#38846
Forward-Port-Of: odoo/enterprise#34976

before this commit, text was getting out of the kanban card After this commit, text was given width in the kanban card task-3147011 Forward-Port-Of: odoo/enterprise#39159 Forward-Port-Of: odoo/enterprise#36534

before this commit, text was getting out of the kanban card

After this commit, text was given width in the kanban card

task-3147011

Forward-Port-Of: odoo/enterprise#39159
Forward-Port-Of: odoo/enterprise#36534