Community mailing list archives
Re: Odoo Security - hiding buttons in XML based on groupsby
Many thanks Olivier. This is much clearer now ! I will make these changes to my modules. Is there any documentation which describes these kinds of best practices ? I have gone through different documentations and websites but these kinds of details are seldom discussed.
Thanks & Regards,
On Tue, Jun 30, 2015 at 5:57 PM, Olivier Dony <firstname.lastname@example.org> wrote:
On 06/30/2015 01:25 PM, Shawn Varghese wrote: > I have a query about some of Odoo's mechanisms that I am not able to understand > at all, and would sincerely appreciate it if anyone can throw some light on the > case below: (...) > However, the *crucial *point here is that /*the approval button gets rendered > on the webpage for the normal employee as well*/ !! It is simply hidden with > CSS styling. We can right click the header bar, remove the /oe_form_invisible/ > tag for the "Approve" button and display it ! Yes, group-based restrictions in views are implemented using the invisibility mechanism, because they are often used for usability, and the field/data may still have to be /technically/ present in the view, even when hidden. The @groups attribute used in views is not a security mechanism, it is merely a way to customize views for certain groups - here, to avoid showing a useless button to users who can't click it. > But, even though we can display it, if we click on the Approve button as a > normal employee, nothing will happen and the workflow does not get triggered. Workflow transitions can be restricted to certain groups, and a workflow signal (button pressed) will only be able to trigger them if the user sending the signal belongs to the required group. i.e. for leave requests: https://github.com/odoo/odoo/blob/fadd46c/addons/hr_holidays /hr_holidays_workflow.xml#L96 > Therefore, system integrity is maintained. I had developed a separate module > with an approval process, but there, the approval button works for normal > employees and is a massive security hole. My own module does not use a workflow > however. Could someone please explain how to prevent this from happening in my > module? You simply need to validate this in your business logic. The simplest way is probably to override the write() method of your model and verify the current user group when write() is changing the approval (e.g. via self.user_has_groups()). Then just raise an AccessError.