Steps to reproduce: - Install Project and Timesheet modules - In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method. - Create a new project. Then, create a task within the project and assign a Timesheet entry to it for 1 Day. - Share the project and copy the link provided. - When opening the link, the task previously recorded as 1 Day in the Timesheet now appears as 1.0 Hour Spent in the customer's portal Current behavior before PR: We are n

Steps to reproduce:
	- Install Project and Timesheet modules
	- In Timesheets, navigate to Configurations and choose 'Days / Half-Days' as the Encoding Method.
	- Create a new project. Then, create a task within the project and assign a Timesheet entry to it for 1 Day.
	- Share the project and copy the link provided.
	- When opening the link, the task previously recorded as 1 Day in the Timesheet now appears as 1.0 Hour Spent in the customer's portal

Current behavior before PR:
We are not passing the 'is_uom_day' value in the project portal view. So in XML when it checks this variable it will get undefined. so, always will go with the else condition.

https://github.com/odoo/odoo/blob/16.0/addons/hr_timesheet/views/project_portal_templates.xml#L50:L53

Desired behavior after PR is merged:
We are now passing this value to check if the timesheet unit is days so it will be shown as 'Days spent' instead of 'Hours spent'

opw-3925368

Forward-Port-Of: odoo/odoo#166164
Forward-Port-Of: odoo/odoo#165737

## Issue: - when you open a calendar event popover, you can't see its time and duration ## Steps To Reproduce: - In mobile view, go to calendar and create an event. - Click on the event and notice you can't see it's time and duration. ## Solution: - We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDate

## Issue:
- when you open a calendar event popover, you can't see its time and duration

## Steps To Reproduce:
- In mobile view, go to calendar and create an event.
- Click on the event and notice you can't see it's time and duration.

## Solution:
- We want to display the time in the popover for all modes. Therefore, I removed the `scale === "month"` condition from `showTime`. The `showTime` variable is used to set the `isTimeHidden` attribute, which is then checked in the `computeDateTimeAndDuration` function of the calendar popover.

opw-3829004

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

Forward-Port-Of: odoo/odoo#165793
Forward-Port-Of: odoo/odoo#160907

Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported. There were instances in which the `amount_to_invoice` was `None` and not `0` (to be looked at in a separate fix). In such a case the `None` value is passed to the `float` function and causes a traceback. 2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values

Currently there are 2 issues with the function used to compute `credit_to_invoice` on model 'res.partner' (`_compute_credit_to_invoice`): 1) On 17.0 a traceback has been reported.
   There were instances in which the `amount_to_invoice` was `None` and not `0`
   (to be looked at in a separate fix).
   In such a case the `None` value is passed to the `float` function and causes a traceback.
2) From a performance perspective it is unnecessary to aggregate all the `amount_to_invoice` values
   into an array and then postprocess them in python.
   Effectively the only thing we do in the postprocess is sum all the values but ignore all non-postive values.
   Thus we can just ignore sales orders with `amount_to_invoice <= 0` and let the SQL / the database handle the summing.
   This way we avoid the overhead from passing around the array(s) (size proportional to the number of sales orders)
   and just pass around a single value.

This commit introduces the changes mentioned in (2). These changes also solve (1):
The additional condition in the domain leads to sales orders where `amount_to_invoice` is `None` being ignored. (SQL / the DB handles (1) for us now.)

related PR introducing the changed lines of code: https://github.com/odoo/odoo/pull/162770
a comment about the issue in 17.0: https://github.com/odoo/odoo/commit/b5d02cc72543b36c7e5e620a3a579f15c88baed6#r141990142

Forward-Port-Of: odoo/odoo#166175
Forward-Port-Of: odoo/odoo#166087

Steps to reproduce the bug: - In Website edit mode. - Drag and drop a "Badge" snippet into the footer. - Bug: it is not possible to edit the text of the badge or change its icon. The problem occurs because the handles of the snippet overlay cover the entire surface of the snippet, and the pointer event is intercepted by these handles. Note that the fix does not need to be made before version 17 because, prior to that, the handles have a smaller height and therefore do not cause this b

Steps to reproduce the bug:

- In Website edit mode.
- Drag and drop a "Badge" snippet into the footer.
- Bug: it is not possible to edit the text of the badge or change its icon.

The problem occurs because the handles of the snippet overlay cover the entire surface of the snippet, and the pointer event is intercepted by these handles.

Note that the fix does not need to be made before version 17 because, prior to that, the handles have a smaller height and therefore do not cause this bug.

Their height was changed with this commit [1].

[1]: https://github.com/odoo/odoo/commit/70f723a9f78c406746f5409f6a89cbe93ad21580

task-3927962

Forward-Port-Of: odoo/odoo#165657

In the express checkout flow delivery methods with failed rate shipment stay still available as a choice for the users. With this commit only carriers with successful rate will be shown. opw-3861519 Forward-Port-Of: odoo/odoo#165260 Forward-Port-Of: odoo/odoo#161524

In the express checkout flow delivery methods with failed rate shipment stay still available as a choice for the users. With this commit only carriers with successful rate will be shown.

opw-3861519

Forward-Port-Of: odoo/odoo#165260
Forward-Port-Of: odoo/odoo#161524

Motivation: MemoryError exceptions when a large number of records on the same model have dirty fields. Such often happens during upgrades. In the current implementation, the cached data is re-arranged in multiple steps using local data structures. The most problematic is `id_vals[record.id][field.name]`, because it creates a dictionary with a potentially long field name (think studio fields) as key for each dirty record. For thousands of records, this quickly accumulates to 10s or even 100s o

Motivation: MemoryError exceptions when a large number of records on the same model have dirty fields. Such often happens during upgrades.

In the current implementation, the cached data is re-arranged in multiple steps using local data structures. The most problematic is `id_vals[record.id][field.name]`, because it creates a dictionary with a potentially long field name (think studio fields) as key for each dirty record. For thousands of records, this quickly accumulates to 10s or even 100s of MiB in RAM.

The idea of this patch is:
1. collect all dirty ids for all dirty fields on the model. This does not cost additional memory, since the ist of ids per field will be pop()'ed from the cache.
2. Walk over fields and ids collecting all fields and values of each id in the same loop, carefully consuming objects, while directly building the `updates` dictionary, without creating the intermediate data structures.

This way, the _flush method only consumes a marginal amount of memory compared to the memory already consumed by the cache.

Careful profiling (using `memray` for memory profiling, the odoo profiler for runtime profiling) of a testcase that flushes 80k records in 8 writes has shown this new version to consume roughly 95% less memory while running slightly faster.

Forward-Port-Of: odoo/odoo#165393

When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to `_is_combination_possible_by_config`. More specifically, calling `attribute_lines.product_template_value_ids` and `self._get_own_attribute_exclusions` for each combination is pretty slow. To speed that up, this commit introduces a new method, `_filter_combinations_impossible_by_config`. This method accepts a sequen

When there are a relatively high number of exclusions + a lot of combinations for a given product_template, `create_variant_ids` can become slow. The main bottlneck is the call to `_is_combination_possible_by_config`. More specifically, calling `attribute_lines.product_template_value_ids` and
`self._get_own_attribute_exclusions` for each combination is pretty slow.

To speed that up, this commit introduces a new method, `_filter_combinations_impossible_by_config`. This method accepts a sequence of combinations and yield those that are valid w.r.t. the exclusions. Because values that only depends on self are computed once before looping through the combinations, this lead to a significant speedup. This method is a generator to avoid MemoryErrors, be able to raise a UserError after "creating" 1000 variants and be consistent with choices made in `_create_variant_ids`. https://github.com/odoo/odoo/blob/0042b9d3eece219d4e89fe9c6ecb9971a1f3bf12/addons/product/models/product_template.py#L710

#### speedup

Customer saas-16.4 database with 378 templates, 3832 products, 44 product.attributes, 186 product.attribute.values, 79 product.template.attribute.lines, 484 product.template.attribute.values, 374 product.template.attribute.exclusions. No dynamic attributes.

Timing to write on product.template, adding a new attribute value on a ProductTemplate Form increasing the number of combinations.

| Combinations | Before PR        | After PR |
|:------------:|:----------------:|:--------:|
|        4     |       219ms      |   218ms  |
|       55     |       785ms      |   440ms  |
|      216     |       1.36s      |   592ms  |
|    1 944     |       28s        |   809ms  |
|   33 048     |     5min30s      |   3.78s  |
|  231 336     | +15min (timeout) |   12s    |

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

Forward-Port-Of: odoo/odoo#164191
Forward-Port-Of: odoo/odoo#162239

Create a [TEST] Product with: - Invoicing Policy: Prepaid/Fixed Price product - Create on Order: Project & Task - Unit of Measure: Days Create a Sales Order with [TEST] prod Add a timesheet line on the recorded hours Go in Timesheet > Reporting > By Project Add the measure Timesheet Revenues Issue: Revenues are much greater than the sale order line amount. This occurs because we don't keep into account the UoM in the computation opw-3864227 Forward-Port-Of: odoo/odoo#164181

Create a [TEST] Product with:
- Invoicing Policy: Prepaid/Fixed Price product
- Create on Order: Project & Task
- Unit of Measure: Days
Create a Sales Order with [TEST] prod
Add a timesheet line on the recorded hours
Go in Timesheet > Reporting > By Project
Add the measure Timesheet Revenues

Issue: Revenues are much greater than the sale order line amount.
This occurs because we don't keep into account the UoM in the
computation

opw-3864227

Forward-Port-Of: odoo/odoo#164181

Forward-port of the test from https://github.com/odoo/odoo/commit/5d5752e87a09602d9cb05d5f7ded324499fdce63 Add a test in case we try to generate a link preview and we don't get a 'Content-Type' in the headers of the response. This potential issue was addressed by https://github.com/odoo/odoo/commit/bc202e0a0294e5a0c90118a8fa43ba54838e66b3, we now also add a test. Forward-Port-Of: odoo/odoo#165723 Forward-Port-Of: odoo/odoo#162398

Forward-port of the test from https://github.com/odoo/odoo/commit/5d5752e87a09602d9cb05d5f7ded324499fdce63

Add a test in case we try to generate a link preview
and we don't get a 'Content-Type' in the headers of the
response.

This potential issue was addressed by https://github.com/odoo/odoo/commit/bc202e0a0294e5a0c90118a8fa43ba54838e66b3,
we now also add a test.

Forward-Port-Of: odoo/odoo#165723
Forward-Port-Of: odoo/odoo#162398

If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`. Fixes #165537 Forward-Port-Of: odoo/odoo#165945

If you try to retrieve the `amout_available_for_refund` of a recordset of `account.payment`, it raises a traceback because the search domain includes `self.id` where it should be on the record `payment`.

Fixes #165537

Forward-Port-Of: odoo/odoo#165945

Steps to reproduce: ------------------- - create a project; - create a new planning slot for the project with a resource (user); - go to the project and create a task; - record timesheet in the planning slot time range in the task; - go to the planning slot view (via list view) Issue: ------ The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`. Cause: ------ The `effective_hours` field will be recomp

Steps to reproduce:
-------------------
- create a project;
- create a new planning slot for the project with a resource (user);
- go to the project and create a task;
- record timesheet in the planning slot time range in the task;
- go to the planning slot view (via list view)

Issue:
------
The times recorded are not updated (in the smart button). Despite the fact that `_compute_effective_hours` depends on `timesheet_ids`.

Cause:
------
The `effective_hours` field will be recomputed if one of its dependencies changes (in this case, `timesheet_ids`). For `timesheet_ids` to be marked for compute,
one of its dependencies must change.

`project_id.analytic_account_id.line_ids`
is different from `project_id.timesheet_ids`.

As a result, the method which computes `effective_hours` is not triggered.

Solution:
---------
Add `project_id.timesheet_ids` in dependencies.

opw-3891624

Forward-Port-Of: odoo/enterprise#61668

The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user. Forward-Port-Of: odoo/enterprise#62876

The compute function _compute_sending_conditions needs date_from and date_to fields as its dependencies to compute whether or not to show the "Send" button on the ICP report SBR wizard. Without them, the field does not get properly recomptued, and the button isn't shown, unless the "Is Test" checkbox gets ticked by the user.

Forward-Port-Of: odoo/enterprise#62876

…ec widget Steps to reproduce: - Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD - Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD - Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created. At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate). The point is both account.partial.reconcile are linke

…ec widget

Steps to reproduce:
- Create an invoice with a foreign currency of rate 1:3: 120 EUR = 40 USD
- Create a statement line with a foreign currency of rate 1:2: 120 EUR = 60 USD
- Reconcile them both using the bank reco widget: An exchange diff of 20 USD will be created.

At this point, the invoice and the statement line are reconciled all together. The exchange difference is reconciled with the statement line (lowest rate).

The point is both account.partial.reconcile are linked to the exchange diff. That's what will cause the problem describe below.

When the invoice is reset to draft:
'button_draft' removes the reconciliation so the partial linking the invoice with the statement line is deleted. Since an exchange diff is attached to the account.partial.reconcile through the exchange_move_id field, we create a reversal for the exchange diff to neutralize its accounting items. During the creation of the reversal, we remove the reconciliation so the partial linking the exchange difference with the statement line is deleted.
Since the exchange diff is wrongly attached to this partial too, again, the code tries to reverse the exchange difference.
At the end, a double reversal of the exchange diff has been created.

opw: 3869770

Forward-Port-Of: odoo/enterprise#62773
Forward-Port-Of: odoo/enterprise#62717

**Steps to reproduce:** - Install Accounting and l10n_mx_edi - Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE) - Activate another currency (e.g. USD) - In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico) - Add a different currency rate for USD for yesterday - Create an invoice: * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA) * Currency: [USD] * Invoice Date: [yesterday] * Invoice Lines: - Product: [any product with UNS

**Steps to reproduce:**
- Install Accounting and l10n_mx_edi
- Switch to a Mexican company (e.g. ESCUALA KEMPER URGATE)
- Activate another currency (e.g. USD)
- In Accounting settings, run the "Automatic Currency Rates" feature ([MX] Bank of Mexico)
- Add a different currency rate for USD for yesterday
- Create an invoice:
  * Customer: [a Mexican customer] (e.g. INMOBILIARIA CVA)
  * Currency: [USD]
  * Invoice Date: [yesterday]
  * Invoice Lines:
    - Product: [any product with UNSPSC Category set]
    - Price: [any] - Taxes: [any]
- Confirm the invoice
- Generate CFDI via "Send & Print" button
- Request Cancel:
  * Reason: 01- Invoice issued with errors (with related document)
- Create Replacement Invoice

**Issue:**
A UserError is raised while checking the balance of the replacement invoice because the total of debits and the total of credits are different.

**Cause:**
The lines for the replacement invoice are just copied, keeping the values of the original invoice lines for many fields (such as "balance", "discount_balance" and "tax_base_amount").
Product-type lines do not have "balance" set in the copied data. In this case, "balance" is computed by using the current currency rate when the replacement invoice is created, which is correct.
The other lines are populated with the copied "balances" that correspond to the previous currency rate, which is not correct.
This leads to a mix of balances linked to different currency rates.

These fields are in the invoice currency and should be computed with the current currency rate as the replacement invoice is created with the present day as invoice date.

**Solution:**
Remove non product-type lines from the copied data to force them to recompute with the current currency rate.

opw-3863010
opw-3902683

Forward-Port-Of: odoo/enterprise#62373

Steps to reproduce: 1. In the contact page for a Mexican-based contact, add a default usage 2. Start a new session in point of sale 3. Select the client with a default usage, add go to payment 4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined. The same behaviour hap

Steps to reproduce:
1. In the contact page for a Mexican-based contact, add a default usage
2. Start a new session in point of sale
3. Select the client with a default usage, add go to payment
4. Select invoice. The usage field shows 'Acquisition of merchandise', despit the default usage selected before

Currently, the popup only takes into account the l10n_mx_edi_usage selected in the POS session or the code 'Acquisition of merchandise' if the field is undefined.

The same behaviour happens if an invoice is created for a previous order.

This commit adds l10n_mx_edi_usage to the partner fields to be loaded when loading the pos data. Then, the field in the popup can be filled with the default CDFI usage of the partner if it exists. Else, it behaves as before, displaying either the usage code selected in the POS session or code 'Acquisition of merchandise' if the field is undefined.

task-3865331

Forward-Port-Of: odoo/enterprise#62261

This issue arises after having visited the "General Ledger" at least once. When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred. Steps to reproduce original issue: - Install `account_reports` - Go to: Accounting > Reporting > Audit Reports > General Le

This issue arises after having visited the "General Ledger" at least once.

When clicking on the "General Ledger" part of the "The current balance in the General Ledger didn't match the balance of your last bank statement, leading to an unexplained difference of [...]" message in "Bank Reconciliation", options such as the currency unit weren't properly transferred.

Steps to reproduce original issue:

- Install `account_reports`
- Go to: Accounting > Reporting > Audit Reports > General Ledger
- Go back
- Create, confirm & reconcile an invoice
- Reset invoice to draft
- In "Accounting", go to "Dashboard"
- Click on the 3 vertical dots to the right of the "Bank" card
- Click on "Reconciliation Report"
- In "Options: Posted Entries Only", select "Include Draft Entries"
- Click on "General Ledger" in the first yellow warning
- Draft entries won't be included

task-3928454

Forward-Port-Of: odoo/enterprise#62655

**Steps to reproduce:** 1) Open any view of any module. 2) Click on insert a link in the article from Favorites. 3) Now publish the article from the share panel. 4) Copy that link and open it from the public user. 5) Click on the embedded link. **Issue:** Nothing will happen on click of that embedded link. **Solution:** Redirect the public user to the login page and after logging in redirect the user to that view if they have access to that view. **Task**-3082042 Forward-Port-O

**Steps to reproduce:**
1) Open any view of any module.
2) Click on insert a link in the article from Favorites.
3) Now publish the article from the share panel.
4) Copy that link and open it from the public user.
5) Click on the embedded link.

**Issue:**
Nothing will happen on click of that embedded link.

**Solution:**
Redirect the public user to the login page and after logging in redirect the user to that view
if they have access to that view.

**Task**-3082042

Forward-Port-Of: odoo/enterprise#62674
Forward-Port-Of: odoo/enterprise#57346

Steps to reproduce: - Configure Starshipit - Create a stock picking - Choose Starshipit as carrier - Validate the picking - Try multiple times to reproduce the error Current behaviour: - KeyError exception raised Expected behaviour: - Should not have any KeyError Explanation: Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as wel

Steps to reproduce:

- Configure Starshipit
- Create a stock picking
- Choose Starshipit as carrier
- Validate the picking
- Try multiple times to reproduce the error

Current behaviour:

- KeyError exception raised

Expected behaviour:

- Should not have any KeyError

Explanation:

Starshipit API sometimes will not return the total_shipping_price, therefore the carrier price become 0 and cannot proceed. To handle this case, we put the order detail fetching in background as welljust in case the API didn't return the total_shipping_price again.

task-3887386

Forward-Port-Of: odoo/enterprise#61286

payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases. Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers t

payment_method_code was in the view for the batch payment creation view. However, when you create batch payment the check printing module has a compute that was being triggered on all payments with the same payment method because the payment method's code was being written by the payment_method_code on this view. This would cause performance issues on some databases.

Setting this to readonly causes the create to no longer use this payment_method_code value and subsquently no longer triggers the recompute.

opw-3848817

Forward-Port-Of: odoo/enterprise#62431
Forward-Port-Of: odoo/enterprise#61908

When receiving a webhook to update for template quality it may crash with the following error: ``` ValueError: Wrong value for whatsapp.template.quality: 'unknown' ``` As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value. [^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/ Forward-Po

When receiving a webhook to update for template quality it may crash with the following error:

```
ValueError: Wrong value for whatsapp.template.quality: 'unknown'
```

As indicated in the reference documentation [^1], whatsapp use the value `UNKOWN` whereas we're using `none` for `whatsapp.template` quality, so this commit convert it to the appropriate value.

[^1]: https://developers.secure.facebook.com/docs/graph-api/reference/whats-app-business-account/message_templates/

Forward-Port-Of: odoo/enterprise#62756

Versions -------- - 17.0+ Steps ----- 1. Go to timesheet grid view; 2. start a new timer for a project; 3. wait at least one minute; 4. leave view and come back; 5. press stop & start timer in quick succession; 6. if timer starts like normal, go back to step 1. Issue ----- Timer may display a negative value after first tick. Cause ----- 1. `onWillStart` begins; 2. it suspends for a RPC to get the server time; 3. render is canceled on resetting the timer; 4. `onWillDestro

Versions
--------
- 17.0+

Steps
-----
1. Go to timesheet grid view;
2. start a new timer for a project;
3. wait at least one minute;
4. leave view and come back;
5. press stop & start timer in quick succession;
6. if timer starts like normal, go back to step 1.

Issue
-----
Timer may display a negative value after first tick.

Cause
-----
1. `onWillStart` begins;
2. it suspends for a RPC to get the server time;
3. render is canceled on resetting the timer;
4. `onWillDestroy` is called;
5. timer isn't canceled because it hasn't started yet;
6. `onWillStart` continues;
7. a timer is added for a destroyed component.

Solution
--------
Use Owl's `status` function to ensure the component hasn't been destroyed before adding a timer.

opw-3815398

Forward-Port-Of: odoo/enterprise#62110

**Steps** - Install Field Service and Helpdesk - Create a ticket for a customer. Add a field service task. A link will be sent to the customer via mail (visible in chatter). ** 403 for the customer if not logged in when clicking the link ** **Issue** Access rights issue here https://github.com/odoo/enterprise/blob/4f44fcf5761ca5499ede148e2e49363e3c8f80bc/helpdesk_fsm/controllers/portal.py#L34 **Fix** Don't show the "Tasks" link if the user doesn't have access rights to them. opw-39

**Steps**
- Install Field Service and Helpdesk
- Create a ticket for a customer. Add a field service task. A link will be sent to the customer via mail (visible in chatter). ** 403 for the customer if not logged in when clicking the link **

**Issue**
Access rights issue here
https://github.com/odoo/enterprise/blob/4f44fcf5761ca5499ede148e2e49363e3c8f80bc/helpdesk_fsm/controllers/portal.py#L34

**Fix**
Don't show the "Tasks" link if the user doesn't have access rights to them.

opw-3911444

Forward-Port-Of: odoo/enterprise#62087

To reproduce: - Log-in Administrator - Go to Timesheet app - Switch to list view - Add 2 group by: * Date > Week * Date > Day - Switch to grid view After odoo/enterprise@28337b5ae971 that result in a crash (error dialog) saying that `day` is not valid aggregation methods. This commit ensure we remove all groupby on the column field (no only the first one). opw-3908383 Forward-Port-Of: odoo/enterprise#62381

To reproduce:

- Log-in Administrator
- Go to Timesheet app
- Switch to list view
- Add 2 group by:
  * Date > Week
  * Date > Day
- Switch to grid view

After odoo/enterprise@28337b5ae971 that result in a crash (error dialog) saying that `day` is not valid aggregation methods.

This commit ensure we remove all groupby on the column field (no only the first one).

opw-3908383

Forward-Port-Of: odoo/enterprise#62381