Add the possibility to flag a HTML field as `sanitize_overridable`. The sanitizer will then be bypassed if the user doing the operation is part of the new group `base.group_sanitize_override`. The "Settings" users are part of that new group. If such a user wrote some HTML that would have normally been removed by the sanitizer, then users without the right to bypass the sanitizer won't be able to write on that field anymore. Otherwise, it would sanitize the previously written data. Such cases are detected, and the modification prevented by the system, which will warn the user about it. For instance, with a `field.html(sanitize_overridable=True)`: one being part of `group_sanitize_override` could write `<script></script>`. Then, someone not part of the group trying to add an element inside that field like appending a `<p/>` -> `<script></script><p>New Content</p>` would not be able to because it would go through the sanitizer and ultimately, removing part of the original value: `<p>New Content</p>` (`<script></script>` would be removed). == Real use case == In the website builder, there is 2 editor rights: - group_website_publisher: restricted editor - group_website_designer: editor & designer The designer editor can edit pages and views, while the restricted editor can't do anything unless he is part of other groups. In edit mode, the restricted editor will only be able to edit fields of record he has access to. For instance, being a sales manager allows you to edit a product description on the website. Being an event manager -> edit event. Slide manager -> Slides etc. As those restricted editor are able to edit those fields, they are (almost) always sanitized to prevent them to introduce malicious code. Since those fields are sanitized, even admins / designer editor are not able to fully use the website builder in such fields. Some clients don't really care about that sanitation, they'd prefer to avoid it as they trust their manager and would prefer to have the full builder capability instead. This is typically the case in small project (butcher, hairdresser, reseller etc) and in SMEs. With the new `sanitize_overridable` feature, they will be able to do that, as the "Designer & Editor" group now also receive the group `base.group_sanitize_override` (done in next commit). Part-of: odoo/odoo#97398
101 lines
4.3 KiB
XML
101 lines
4.3 KiB
XML
<?xml version="1.0"?>
|
|
<odoo>
|
|
<data>
|
|
|
|
<!--
|
|
Users Groups
|
|
Note that the field 'category_id' is set later in
|
|
base/data/ir_module_category_data.xml
|
|
-->
|
|
<record model="res.groups" id="group_erp_manager">
|
|
<field name="name">Access Rights</field>
|
|
<field name="implied_ids" eval="[Command.link(ref('group_user'))]"/>
|
|
</record>
|
|
|
|
<record id="group_sanitize_override" model="res.groups">
|
|
<field name="name">Bypass HTML Field Sanitize</field>
|
|
</record>
|
|
|
|
<record model="res.groups" id="group_system">
|
|
<field name="name">Settings</field>
|
|
<field name="implied_ids" eval="[Command.link(ref('group_erp_manager')), Command.link(ref('group_sanitize_override'))]"/>
|
|
<field name="users" eval="[Command.link(ref('base.user_root')), Command.link(ref('base.user_admin'))]"/>
|
|
</record>
|
|
|
|
<record model="res.groups" id="group_user">
|
|
<field name="name">Internal User</field>
|
|
</record>
|
|
|
|
<record id="default_user" model="res.users">
|
|
<field name="groups_id" eval="[Command.link(ref('base.group_user'))]"/>
|
|
</record>
|
|
|
|
<record model="res.groups" id="group_multi_company">
|
|
<field name="name">Multi Companies</field>
|
|
</record>
|
|
|
|
<record model="res.groups" id="group_multi_currency">
|
|
<field name="name">Multi Currencies</field>
|
|
</record>
|
|
|
|
<record model="res.groups" id="group_no_one">
|
|
<field name="name">Technical Features</field>
|
|
</record>
|
|
<record id="group_allow_export" model="res.groups">
|
|
<field name="name">Access to export feature</field>
|
|
<field name="category_id" ref="base.module_category_hidden"/>
|
|
<field name="users" eval="[Command.link(ref('base.user_root')), Command.link(ref('base.user_admin'))]"/>
|
|
</record>
|
|
<record model="res.groups" id="group_user">
|
|
<field name="implied_ids" eval="[Command.link(ref('group_no_one'))]"/>
|
|
<field name="users" eval="[Command.link(ref('base.user_root')), Command.link(ref('base.user_admin'))]"/>
|
|
</record>
|
|
|
|
<record model="res.groups" id="group_partner_manager">
|
|
<field name="name">Contact Creation</field>
|
|
<field name="users" eval="[Command.link(ref('base.user_root')), Command.link(ref('base.user_admin'))]"/>
|
|
</record>
|
|
|
|
<record id="default_user" model="res.users">
|
|
<field name="groups_id" eval="[Command.link(ref('base.group_partner_manager')), Command.link(ref('base.group_allow_export'))]"/>
|
|
</record>
|
|
|
|
<!--
|
|
A group dedicated to the portal users, making groups
|
|
restrictions more convenient.
|
|
-->
|
|
<record id="group_portal" model="res.groups">
|
|
<field name="name">Portal</field>
|
|
<field name="comment">Portal members have specific access rights (such as record rules and restricted menus).
|
|
They usually do not belong to the usual Odoo groups.</field>
|
|
</record>
|
|
<!--
|
|
A group dedicated to the public user only, making groups
|
|
restrictions more convenient.
|
|
-->
|
|
<record id="group_public" model="res.groups">
|
|
<field name="name">Public</field>
|
|
<field name="comment">Public users have specific access rights (such as record rules and restricted menus).
|
|
They usually do not belong to the usual Odoo groups.</field>
|
|
</record>
|
|
|
|
<record id="public_user" model="res.users">
|
|
<field name="groups_id" eval="[Command.link(ref('base.group_public'))]"/>
|
|
</record>
|
|
|
|
<!-- Default template user for new users signing in -->
|
|
<record id="template_portal_user_id" model="res.users">
|
|
<field name="name">Portal User Template</field>
|
|
<field name="login">portaltemplate</field>
|
|
<field name="active" eval="False"/>
|
|
<field name="groups_id" eval="[Command.set([ref('base.group_portal')])]"/>
|
|
</record>
|
|
|
|
<record id="default_template_user_config" model="ir.config_parameter">
|
|
<field name="key">base.template_portal_user_id</field>
|
|
<field name="value" ref="template_portal_user_id"/>
|
|
</record>
|
|
|
|
</data>
|
|
</odoo>
|