This commit:
   - make handle_visibility a private function (even if not
     exploitable in rpc easily since it uses request.website)
   - encrypt the password in db (even if not critic, since this
     password could be shared on twitter, ... it doesn't cost anything
     to secure it a bit more)
   - remove useless sudo, since handle_visibility does a sudo itself.

In the future, this notion of visibility should be handled on controller layer,
and no more on the View layer (during rendering)

closes odoo/odoo#48145

X-original-commit: 06e0e48217f25f17dff23331111f5dcb98e8cecd
Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>
Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

ir.rule are default values but can be customized based on the
company's policy and needs.
This is typically a record that is in noupdate as should be
customization-friendly.

Now, you can define a Visibility mode between:
    Public (All poeple)
    Connected (Portal or Employee)
    Restricted Group (Has this group or is Employee)
    With Password (Know password or is Employee)
    Internal Users (Is Employee)

It is a 'fair' feature, but without really warranty that the content is
really unreadable via others methods, ...

It is more for frontend display, that real secret. Dont use this like
a keychain ;)

We only catch the visibility on the main view and not the t-call inside.

Even if it should work on controller too, it is only display now on the
page property menu. (Or on the view directly in backend)

task-2091365

Courtesy of @Yenthe666

This commit closes odoo#32580

closes odoo/odoo#34039

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

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>

User 1 simply becomes a technical user (inactive, no password).

1. Create a new user with all the permissions as manager (or at least
   Accounting) except Inventory
2. Login and then go to Invoicing --> Settings
3. Do a minor change, save

An access error occurs.

Since the settings of all modules are smartly loaded in v11, it now
implies that a user must have extra manager access rights to be allowed
to save them. We could have kept separate actions for each setting page,
but we would have missed the fun of access errors.

Anyway, security-wise this is not an issue to force the manager groups
since a user with 'Settings' access rights can change his own rights.
It's just very annoying. Or fun.

Complement of aa65a46fc50701f

Fixes #21766
opw-801210

website.page = old ir.ui.view with page=True
website.redirect is a new mechanism to replace in the futur the ir.attachment
mechanism of redirect.

From now, we don't have a specific /page controller to serve 'page'.

We use a new model website.page which is rendered if none route matches the url
 and that the field 'url' on website.page matches the request.httprequest.path.

The order to serve a path is:
    - Routes defines in controllers (/shop, /blog, ...)
    - ir.attachment with name matching the path
    - website.page with url matching the path
    - website.redirect with url_from matching the path
    - 404

To improve:
    - allow regexp in website.redirect model
    - allow to edit the view_arch from the page.management via redirect backend
      (needed when traceback in the page, or when modifying a js/css/less/...)

* event, website_event, website_forum,
* website_hr_recruitment, website_sale

Website access rights were buggy. The editor assets and website editor
assets have to be loaded together to work so the previous behavior
which only loaded one with the restricted access right was not right.
Also, people which had the "Manager" access right for model like event
or job only got access to creation and edition of those objects if they
had the full access to website access rights.

Now the website module creates the two same groups :
* group_website_publisher: load all editor assets, give access to
page creation for model the user has access (event, job, ...) and
edition of those pages
* group_website_designer: implies the first one and give access in
creation and edition of all pages + access of all website menus

The manager access rights for event, product, jobs, etc now implies
the group_website_publisher group for the user (so that the manager
have the editor assets and editor ui).
Note: some python codes use the group_website_publisher for no right
reason, this has to be adapted.

Several modules defines records with the external ID `base.foo_bar` while it is
created inside this module (typically menus and groups).
While there is no technical reasons to do so but this may introduce issues:

- these records will not be deleted during uninstall
- if a language is loaded before the installation of the module, it won't be
  translated

The uninstallation will only remove the records with an external id linked to
this module (these would only be removed when removing base).

Installing a language before the module will drop the translations not linked
to an existing external id (as it can not be resolved).

This commit correct all the external ids tagged as from base or other incorrect
modules.