Previously, when users selected the month or quarter filter and saved it, the filter would only return data from the current year. This issue has been fixed in this commit.

Merge the month and quarter data filters into a single month/quarter filter. This will allow users to select a year which behave as year filter. If a user only selects a month or quarter, the filter will work accordingly.

The year filter will be removed, as the month/quarter filter can now be used to filter data by year.

In addition, a checkbox will be added to the relation filter that will allow users to automatically select the current user. This checkbox will only be displayed if the model is res.users.

Task ID: 3370627

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
rresponding to that user.

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

### [[FIX] account_reports: pass deferred type in options](https://github.com/odoo/enterprise/pull/48022/commits/24d4789fa1228c724d10daa3fb11c43f74ed0929)

It seems the deferred type (revenue of expense) was not correctly passed in the options to the JS view, which caused the action to view existing deferral entries to always show these of the revenues (the default option).

### [[IMP] account_*: separate modes for deferred expenses and revenues](https://github.com/odoo/enterprise/pull/48022/commits/67ca6d4930631b4f92575c93e576fc2b25ecbaff)
*account_accountant,account_reports

Currently one deferral mode can be selected for both deferred expenses and deferred revenues. Either the deferrals are created on validation, when the invoice/bill is posted (perfect when you don't have a lot of deferrals per month), or a grouped deferral entry is created manually by the user periodically (interesting when you have a lot of deferrals per month).

Realistically the situation of a company is not the same concerning customer invoices and vendor bills. They might generate lots of customer invoices with deferrals, wanting a manual grouped entry. But on the other hand they might not have a lot of vendor bills with deferrals, so don't want to create a manual entry for this every month.

In order to facilitate this, we now allow to select a different mode for both deferred revenues and deferred expenses.

### [[IMP] account_accountant: prevent account change of deferred line](https://github.com/odoo/enterprise/pull/48022/commits/aabde63ba57c5998d16a3c63c5778e89b95e4971)

When opening the list view of journal items, a user can use multi-select to change the account of one or more lines. In the case where we have lines that are already deferred, changing the account would break the balance deferred by the already existing deferral moves.

In order to prevent this, we don't allow changing the account of a line that is already deferred.

### [[IMP] account_*: show grouped journal items for deferrals](https://github.com/odoo/enterprise/pull/48022/commits/1e4ba5f5ad570c13f734ad758fc1cea16c891fc9)

*account_accountant,account_reports

Smart buttons allow navigating between invoices/bills and their deferral moves. When clicking a smart button, a list of moves is shown. In order to audit deferrals and their original invoices, you have to open every move separately, which makes it very inconvenient.

In order to easy auditability and get an instant overview of what happens with the deferrals, we now show a list of journal items grouped by move.

Related to https://github.com/odoo/upgrade/pull/5200

task-3516660

This commit introduces the following changes :

- Introduced a new Trash folder(fake folder) within the documents views.
  This folder is designed to contain any file that has been archived
  from any other folder.

- The archived filter has been removed. We now encourage users to
  utilize the Trash folder for this purpose instead.

- Documents that are archived will now be automatically deleted after a
  span of 30 days.

- When a user opts to delete a folder, the system will no longer offer
  the option to move its files to the parent folder. Instead, all the
  content from the deleted folder will be moved directly to the trash.

- In the event a folder is deleted, it will be archived and will no
  longer be displayed in the search panel. The documents from this
  folder will be relocated to the trash, and any child folders will be
  archived in the same manner.

- If a folder is archived and doesn't have any documents (be it active
  or inactive) linked to it, nor any child folder (that respect the same
  rules), the folder will be automatically deleted.

- When a document is restored from the Trash, and its original folder
  has been archived, the system will restore the folder as well. If this
  folder had a parent, it will be restored as its child. If not, it will
  be placed as a root folder.

- It's no longer possible to manually delete archived folders from the
  folder list view. This change was implemented since these archived
  folders might still have connections with archived documents in the
  Trash. As a result, the delete action has been made invisible for
  these folders.

- A new filter for archived folders has been added to the folder list
  views for better user navigation.

- It is possible to restore workspaces from the workspace list/form
  view. When restoring a workspace, all the documents and children
  folders linked to that workspace are restored as well.

Remark:
The Trash folder, labeled as a 'fake' folder, has been assigned an id="Trash".
It isn't linked to any specific model but is designed to allow the
search model to fetch inactive files. The decision to assign it an id="Trash"
was influenced by the searchPanel's requirement for unique rootIds.

TaskId-3046516

Co-authored-by: William Braeckman ( <wbr@odoo.com> )

Description of the issue/feature this commit addresses:

The computation of the queries used for the data that will be shown by a report currently takes into account the record rules and uses them to adapt the query. This means that it could be possible that two users see different totals in a report since their record rules would not allow them to see all the data that is included in the complete report.
It is debatable but record rules should not impair the data shown in a report. If the user has 
access to the report, he should be able to read it entirely (for example: regardless to the invoices he can read).

---

Desired behavior after the commit is merged :

This commit removes the inclusion of the record rules in the calculation of the query that a report will need to display its data. This means two thing:
* The first is that ALL users that have access to a specific report will see the exact same data inside it.
* The second is that users with record rules that would make it impossible for them to read specific data wan now see their impact on a report. If they try to open said data, they will have a message telling them they are not allowed to retrieve it but they will still be taken into account in the report they are consulting.

Adding this improvement, record rules are no longer taken into account for report queries calculation.


---

Post modification testing notes : 

This PR removes a line of the _query_get() method which purpose was to apply the record rules to the query before using it, a line using the _apply_ir_rules() method on the query. A comment was attached to that line explaining that it was applying ir rules to the query to avoid bypassing company access rights. 
After the modification, multiple tests were made in order to see if company access rights were bypassed in certain scenarios and data of "Company One" would be found in the reports of "Company Two".
No specific set of user, groups, companies and record rules was able to produce such a behavior and debugging the _query_get() method would reveal that the exclusion of company restricted data would be applied to the query by the _where_calc(domain) method.
With all the information gathered taken into account, it is believe most probable that no company restricted data would become available inside other companies' reports and the removal of this line can be done with no negative impact on the queries' quality.



task-3347860