Objective
---------
Libro Diario is just a big name for "Journal" in Spanish, but it's also a precise report that is expected to reflect a chronological report of all Accounting Entries in a Database. It's expected to be published and available to show all the transactions recorded by a Company.

It's basically an export of the General Ledger with all the accounting entries, not grouped by Account but by Accounting Entries, sorted by date, and to show a full sequence.

The Libro Diario should posess the following columns and each row should contain an account move line:
- "Entry": ascending numbering for each move, starting at 1.
- "Line": numbering of the move line inside the move, starting at 1. 
- "Date": accounting date of the move; as mentionned, moves should be sorted by dates
- "Account code"
- "Account name"
- "Description": label of the move line
- "Document": account move name
- "Debit"
- "Credit"

Solution
---------
1. Add a custom General Ledge Handler that adds the option to export the Libro Diarios
2. Since `_get_line` returns the AMLs grouped by accounts, it is easier to fetch the query that gets all the AMLs data (`_get_query_amls`) and then postprocess the amls data to generate the matrix of data passed to the XLSX builder. Doing so forces us to manually initialize the currency table.

task-4294391

## Description
Most read `ir.rule` on documents are based around the searchable field `user_permission`. Both `documents.document` and `documents.access` rely on it, and its' implementation creates a recursive application of the ir.rule, as `documents.document` calls `_search_user_permission`, which reads on `documents.access`, whos `ir.rule` rely on `document_id.user_permission`, re-applying the same domain from `_search_user_permission`.
This recursive-like behaviour creates excessively large queries with a lot of subquery, exploding the costs of it above the `jit_above_cost` threshold (500k by default), leading to slow execution, due to the JIT optimizer, which normally should be reserved for long analytical queries.

## Patch
Adding `auto_join=True` on `documents.access.document_id` will transform some of the subqueries in joins, and is done in `sudo` context, avoiding re-application of the `ir.rule` while resolving itself. The simplification of the query leads to lower query cost that is bellow the `jit_above_cost` threshold, removing the slow optimisation step, leading to faster execution, as it was the main bottleneck.

## Benchmark
On a db with a moderately sized `documents_document` table:

| Timings                       | Before | After | Speed up |
|-------------------------------|--------|-------|----------|
| `action_update_access_rights` | 7s     | 550ms | 12.7x    |

## Reference
task-4381572

The filter to replenish use the `qty_to_order` field. However when adding a filter multiple function are called. `web_search_read`, `search_panel_select_range, `search_panel_select_multi_range`

However they all use the search domain and in the default search there is the `to replenish` filter with [('qty_to_order', '>', 0)] And each time they trigger while it's not needed to recompute them.

We think about storing the qty_to_order_computed but it's not optimal to store a value that needs to be updated everyday, just to cache it.

Instead we will remove the default filter. It's a good trade off since it's only needed when people create their orderpoints automatic themself. In general, it's not needed since the automatic rr are deleted and created on missing quantity. For people that create the automatic rr they can still use the filter and move it default but it could continue the performance issue

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

Currently a traceback occurs when the user opens an invoices from the tasks in the portal.

To reproduce this issue:

1) Install sale, timesheet
2) Open a sale order having a project or create a confirmed SO with product type as service 
3) Create multiple invoices for that SO
4) Now open the related tasks of that SO having invoices from the portal 
5) Click on `invoices` from side panel

Error:- 
```
AttributeError: 'list' object has no attribute 'ids'
```

This error is occurring from the below line
https://github.com/odoo/odoo/blob/88c0f9d953d077510961243080dcab2cc1920c27/addons/sale_timesheet/controllers/portal.py#L43-L50

Clearly, we get invoices as a list of dict in values from the below line.
 https://github.com/odoo/odoo/blob/88c0f9d953d077510961243080dcab2cc1920c27/addons/account/controllers/portal.py#L126-L133

Initially, we get the recordsets of invoices in `values['invoices']`. But because of the recent changes from the below commit, we get a list of recordset values, from which we can access the value of invoice ID.

https://github.com/odoo/odoo/pull/174812/files#diff-3b907221102acd53c211a3a6b50b00543dcbbc865d50ef4451bea465f7300cbaR107-R112

We can resolve this issue by looping in invoices and access the invoice id. similarly like this
https://github.com/odoo/odoo/blob/48629b94dac45dad0766fbaeef0f71934a5adcc4/addons/account/controllers/portal.py#L90

sentry-6117277208

Emails sent by some job platforms (e.g. Indeed) result in applicants with a display name like:

[Action required] New application for Developer, San Francisco, CA

This makes it hard for recruiters to efficiently use the recruitment app. These emails don't use `hr.job.platform`, because the platform (e.g. Indeed) sends out the email under an application-specific `From: `, e.g.

`"Joren Van Onder" <jov2ueneo87n_g88@indeedemail.com>`

So the `hr.job.platform` mechanism isn't needed.

Before this commit, when an application like this was received, the name on the hr.applicant (computed field based on candidate_id) would become the email subject name. This is the default behavior of `mail.thread`: it fills `_rec_name` with the subject if not set [1]. To fix it, always force partner_name in `hr.applicant`s `message_new()` (this already was being done if an `hr.job.platform` matched).

[1] https://github.com/odoo/odoo/blob/f4990442904a23a387f21822b91d096f5eb987fc/addons/mail/models/mail_thread.py#L1412-L1422

opw-4383191

Currently, the timesheet header is not working correctly in the list view. There are a bunch of issue that this commit aims to fix:

An empty header is displayed when the start button is pressed, and trying to either stop it or discard it will triggers an error

The grouped by function triggers a similar issue as the one above when trying to start & stop the timer

When there are no timesheetable project inside the database, an error is triggered too when starting the timer.

Source of the issues :
- when trying to start a timer in the list view, the function 'cleartimesheetname' is triggered. The problem is that function triggers an update on the listview. This update then triggers a second execution of the 'onWillUpdateProps' of the timesheet_timer_hook class. This second execution is not expected in the flow and set the value of the timesheet of the header to 'false'.

- when the view is grouped, the record are not loaded inside the the folded section. This means that when we search for the record inside the 'popRecord' function of the timesheet_timer_hook class, we find nothing. In this use case though, the record is supposed to be found and set.

- when there are no timesheetable project, the method 'popRecord' will set the timesheet of the header back to 'undefined'.

Solution :

- Removed the 'cleartimesheetname' method, as it is no longer usefull. A check up in the write/create of the model will prevent the required field 'description' from being null. The 'enterEditMode' has also been restricted to the kanban view, since doing this in the list view was also triggering an extra call to 'onWillupdateprops'

- Checked the view to get a dynamicRecordList we can use to correctly set the data. More information inside the comment in the code.

- added a condition inside the 'popRecord' method so that in no longer set the timesheet to undefined when we dont need it to

task - 4268687
affected version 18.0-master