| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
Was part of PR #19820. Courtesy of Vauxoo
|
|
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.
|
|
Migration of website module to new API.
The tricky phase is ir_http.py : we need to use `request.env`
only when the authenfication phase is done. Normally by
calling `super` of `_dispatch` method, but website module
required it to be done before. This is important since
`env`is a lazy property of `request` object.
Some hack were kept since this commit is a migration ('RequestUID'
in ir.http, ...)
Some docstrings were added.
|
|
|
|
for html field) and website
|
|
A user (other than the admin) part of the group 'Manage QWeb views'
and the group 'Administration Settings' couldn't edit
any other view than QWeb views.
opw-640376
|
|
bzr revid: dle@openerp.com-20140502134135-zp05ecbpcj8inftc
|
|
bzr revid: odo@openerp.com-20140429123517-wtjcw6xl8qgtnkeg
|
|
bzr revid: xmo@openerp.com-20140128151009-8hie0sex8ev2pads
|
|
bzr revid: chm@openerp.com-20140117154648-sxfisxqcv8o3fvzt
|
|
bzr revid: ddm@openerp.com-20131203163131-g7o86fc08gv4if9v
|
|
bzr revid: chm@openerp.com-20131119135717-6sv54lpm5smybsib
|
|
bzr revid: fme@openerp.com-20131025152446-si9gsjujzcn40hip
|
|
bzr revid: xmo@openerp.com-20131021152651-ner2zggjfofb5rc4
|
|
bzr revid: xmo@openerp.com-20131021091542-m2e213pa6kq0bmqz
|
|
bzr revid: xmo@openerp.com-20131008122039-tzw7nq8cx0y0zh5p
|
|
bzr revid: xmo@openerp.com-20131008092233-9su66923zthl9jyg
|
|
bzr revid: chm@openerp.com-20130917082342-kgg8f52tw8tgmygu
|
