Back2Basics of the timesheet module. Add helpers/dummy data to improve
the onboarding of the module.

Rename some roles/menus.

Add a QR Code client action when clicking on the timesheet app icons in
settings to allow users to directly download the app on their phone.

closes odoo/odoo#55565

Taskid: 2303955
Related: odoo/enterprise#12273
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Purpose
=======

The current kanban view is messy. It is difficult to identify which
apps are installed or not. The user can completely miss a module
that might have interested him. A search panel would make things way
more readable.

closes odoo/odoo#44401

Taskid: 2181557
Related: odoo/enterprise#8144
Related: odoo/upgrade#879
Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Following changes needing ir.model.access on transient models too.
Remove groups declaration on the action to move it to ir.model.access
when possible.
Rules are strict by default with no unlink access by default and high
priviledge asked. Adaptations may be needed later.
Write access is given as a wizard may need to be modified in case the
action triggers an error and the user has to correct a value

account*: use account.group_account_user for all transient by default
	  remove account.print.journal relic
stock*: use stock.group_stock_user by default
survey: survey user can send invitations
mail: allow any employee to execute wizards
      additional verifications are made to ensure they are executed
      only on the documents the user has access to you
      give portal access to mail.compose.message as portal still does
      some actions like posting messages on the forum
      add ir.rule to avoid reading somebody else messages
      increase the query count because of undeterminist count
crm: saleman for lead2opp, manager for massmailing
     partner manager for actions linked to partners
     avoid a write in test_lead_lost
sms: any employee can send sms
mrp: mrp user can execute wizards
     give unlink access as making write during do_produce operation
base_import: employees can import files
delivery: stock user can deliver
event_sale: sale user can configure the wizards
	    event user inherit from  sale rights
gamification: employee can give badge
google_service: resolve FIXME
hr: add specific rights
    manager can set a plan according to group on button
    anyone who can write on an employee can register a departure
hr_expense: set rights based on buttons
hr_holidays: an approver can make a summary report
hr_recruitment: recruiter can refuse a candidate
hr_timesheet: can use the wizard if can create a timesheet
l10n_eu_service: managers can create fiscal positions
mass_mailing: same group as on mass.mailing.list
membership: accountant can create invoice from membership
payment: accountant can create a link
	 as the source is an account.move
	 keep the payment.acquirer.onboarding.wizard to system user
	 only as it is called during company configuration
point_of_sale: PoS manager only can use wizards
	       never create closing_balance_confirm_wizard records
product_expiry: stock user has rights on stock.picking
product_margin: access from accounting menus
repair: same rules as for above models
sale: set ir.rule for self wizard only
      add rule from model introduced in payment to add salesman group
sale_crm: saleman can create a quotation from a lead
sale_coupon: any saleman can generate coupon
	     add self ir.rule
sale_product_configurator: salesman can select product variants
snailmail: employee can send letters
website: designers can write on website
website_crm_partner_assign: same rule as group on action
website_sale: sale ACL as for payment.acquirer.onboarding.wizard
website_slides: anyone can send invitation

base: base.language.*: allow employee (cf lang_install)
      change.password.user: can not read change password wizard of
      other users
      test.*: no access is needed

Courtesy of Damien Bouvy, William Andre and Antoine Prieëls for review
of acl

=======
Purpose
=======

Currently for a user to be allowed to see a private project they must follow the
project. This means that they will be added as a follower of all new tasks in the
project which causes them to receive 1000000 notifications, especially if there are a
lot of tasks in a project.

==============
Specifications
==============

1) Add an Employee m2m field on project next to 'Invited Employees'
    - only visible if the 'Invited Employees' option is selected
    - the project should only be visible to employees selected there (regardless if they
      are followers or not)
2) Add an Employee m2m field on tasks below the 'Email cc' one in debug mode
    - only visible if the 'Invited Employees' option is selected on the related project
    - should be pre-filled with what is set on the project
    - the task should be visible to employees selected there (regardless if they are
      followers or not)
3) Add a Portal users m2m field on project next to 'Portal users and all employees'
    - only visible if the 'Portal users and all employees' option is selected
    - the project should only be visible to portal users selected there (regardless if
      they are followers or not)
    - rename the option into 'Invited portal users and all employees'
4) Add a Portal users m2m field on tasks below the 'Email cc' one in debug mode
    - only visible if the 'Portal users and all employees' option is selected
    - should be pre-filled with what is set on the project
    - the task should be visible to portal users selected there (regardless if they are
      followers or not)
5) Following a project/task should not grant the user/employee the ability to see the
   project/task

Task 2031527

closes odoo/odoo#40505

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

TaskID: 2088586

Timer in the list and kanban views :
----------------------------------
In kanban and list views, It's possible to update the 'unit_amount'
field with a timer. The user can easily launch the timer in these views
for one of his timesheets.
One timesheet can be launched at the same time, when the user start a
timer for a timesheet and start another timer for another timesheet, the
first timer stop and the new timer start.

The timer is usable only if the encoding unit is 'Hours' and the
timesheet is not validated. To do this : a new computed field 'display_timer'
is created in account.analytic.line, this field is set to True is the
encoding unit is 'Hours'. With this field, we can easily hide and display
the timer in different views.

The user can only use the timer for his timesheets. Because the user
with the access rights to see all timesheets might launch and/or stop a timer of a
timesheet of other user. That is the timer must be accessed only in 'My Timesheets' menu.

Add pivot view for 'All timesheets' menu.

Creation a timer_mixin :
----------------------
With this timer mixin, we can have a generic timer to use in other
models that they need to use a timer like account.analytic.line and
project.task models
The timer in account.analytic.line model has changed to use the timer
mixin.

Specific behaviour of the timer :
-------------------------------
When the user use the timer and the minutes spent with the timer is less
than 1 minute, we don't add in unit_amount of timesheet. If the
unit_amount is equals to 0 and minutes spent of timer is less than 0.
Then the timesheet created by the timer is deleted because it is useless to
have a timesheet with unit_amount set on 0.

Misc :
----
Add some styles for the timer button and for the 'unit_amount' field when the
timer is running.

remove duplicated fields in tree view (record
id='timesheet_view_tree_user')

TaskID: 2088586

The low level access right is now "See my timesheets".
This access disallow to a user to view and manage the timesheets of others users.

When the visibility of a project is set on "Invited employees",
the users with the access rules : 'See my timesheet' and
'See all timesheets' can show the timesheets, if these users
follow the project.

Purpose of the commit is to clean the current portal right of
timesheet(analytic account line) and analytic account(no more ir.rule).

the idea is to remove ir.rule since the domain will be difficult with ir.rule
extension mecanism. Moreover, as this is "technical" data, we will use 'sudo' controller.
as we don't want to customize what is shown in portal.
End user is free to create its own ir.rule to connect odoo in xmlrpc
he will be the only responsible for that.

task-1932488

When we remove the inheritS between project and analytic account, we move the
analytic_accound_id field in timesheet because it was the only use case for
a project to be linked to an analytic account.
This commit prepares new cost origin for a project (other that timesheet).
Register costs on project will required an analytic account to keep analytic
costs tracking. The analytic account management is now moved to project, like
it was in 10.0, but without the inheritS.

Task-1911581

Purpose
=======

Access group terminology is missleading. Yous have to be manager to administrate
an application. This task consists to rename groups to be understandable for everyone.

Groups should be reorganised on the users form to be more explicit.

Specification
=============

1/ Rename 'Manager' to 'Administrator' in users groups.
2/ Define a hierarchy on access groups by using the category_id in the manifests
   A category 'Operations/Project' will create a category Project with a parent
   category 'Operations', and something smart is already developed (in modules/db.py)
   to avoid duplicating categories.
3/ Add a group in expenses to be able to approve expenses reports for my team.
4/ Add a group in timesheets to be able to approve timesheets for my team.
5/ Remove partially the useless crap in ir_module_category_data.xml
6/ Sort access rights groups on users form according to its parent category

closes odoo/odoo#29362

Signed-off-by: "Yannick Tivisse (yti)" <yti@odoo.com>