summaryrefslogtreecommitdiff
path: root/addons/website/security/website_security.xml
AgeCommit message (Collapse)Author
2019-03-05[IMP] base,*: Reorganize access rights groupsjbm-odoo
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>
2018-08-23[IMP] base: add regular user admin as uid 2Raphael Collet
User 1 simply becomes a technical user (inactive, no password).
2018-01-09[FIX] account, stock, website: access rightsNicolas Martinelli
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
2017-09-15[ADD] website: add new page managementrde
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/...)
2016-09-28[REF] website, *: review website access rightsqsm-odoo
* 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.
2016-09-02[FIX] all: remove external ids fakely from baseMartin Trigaux
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.
2016-08-04[MIG] website: migration to new apiRavi Gadhia
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.
2016-08-04[MOV] website: module directory organizationJérome Maes