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 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

For historical reason, project depended on product. Probably to use
UoM. Now, UoM is extracted in 'uom' module, and project does not
use UoM anymore (only with timesheet). Removing the 'product'
dependency requires to make hr_timesheet depending of uom, since
this one really use UoM mecanism.

Task #39079

This commit removes the inheritS between account.analytic.account and
project.project. This means :
- When a project is created, an analytic account is not necessarily
genareted
- project has now its own name, company_id and partner_id fields
- an analytic account can be linked to several project
- project module does not depend anymore of analytic, but hr_timesheet
does.

This change implied
- an analytic account is required on project to timesheet on
its tasks. So, when checking 'allow_timsheets', if an AA is not
provided at project creation, an AA will be generated.
- to timesheet on project, an active AA is required. We don't want
timesheeting on project linked to unused AA to avoid bad analytic
entries.

This prepare the fact a sale order can create multiple project, sharing
the same analytic account (the one from the SO).

Also rename product.uom.categ into uom.category to
 give it a decent name.

Moves UoM models, test and data to a new addon in
order to be able to use uom without product.
A simple example is be to be able to use UoM for
timesheets.

This commit only move code, and adapt xml ids
without chaging any feature or functionnal
behavior.
Note: 'product' module now depends on new
'uom' module.

Since project depends on portal, this module can be removed.

Purpose of timesheet module is to track user time. This commit applies
various improvements and tweaking to better reflect this purpose.

This commit provides some UI improvements

 * improve views : user_id field is not displayed on 'My Timesheet'
   action, since it will always be the same user;
 * simplify menus : 'My timesheet' only for current user's timesheets
   and 'All timesheet' for everyone's. The latter one allows creating
   timesheets for someone else, if you have the required access rights;
 * add calendar views for timesheets
 * some filters are added to ease time-based filtering of timesheets

This commit also reorganizes user groups. Groups are now

 * new 'timesheet user' group (different from base.group_employee). Users
   can record their own timesheet. New access rights were added to perform
   the same operations as before.
 * 'timesheet manager' (hr_timesheet.group_manager). Users can record
   timesheets for other users, access to settings and reporting tools.