The come back of access rights

[Cédric Krier]

Hi,

I re-open the discussion of
https://groups.google.com/d/msg/tryton-dev/v8nBMe_ZBDk/qrvCml95UVYJ

I have a solution which should be a mix of both previous solution.
I propose to active the access right control only if a keyword is set in
the context ('_check_access_right'). Of course to avoid cheating, the
context will be always set on RPC calls for create, read, write, delete,
copy, search, search_count, search_read, export_data, import_data and
history_revision.
The other methods could be:

- buttons: managed by ir.model.button
- selection: should be managed by the developer (but most of them
doesn't need such access right)
- manual RPC addition: so manually managed
- default_get, fields_get, fields_view_get, view_toolbar_get: I
propose to add also the context
- on_change{,_with}, pre_validate: idem

So I'm thinking about adding a parameter to RPC to set or not the
context.

So to ease the transition, we could keep the root switch to deactivate
the access right. And later slowly remove such hack.

In this new design, the equivalent of "root switch" will be to set to
false in the context _check_access_right.

The only drawback, I see, is if someone right code which set in the
context user input data. But I think it is a very small drawback compare
to the advantage this design gives because in many places now we have to
«re-browse» or «switch the context» which slow down Tryton because it
kill the cache.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

[Cédric Krier]

Here is a POC review: http://codereview.tryton.org/8481002

[Pierre-Louis Bonicoli]

On 17/07/2014 23:21, Cédric Krier wrote:
> Hi,
>
> I re-open the discussion of
> https://groups.google.com/d/msg/tryton-dev/v8nBMe_ZBDk/qrvCml95UVYJ
>

[...]

>
> The only drawback, I see, is if someone right code which set in the
> context user input data. But I think it is a very small drawback
> compare to the advantage this design gives because in many places now
> we have to «re-browse» or «switch the context» which slow down Tryton
> because it kill the cache.

Hi,

Could not we always use a solution like the one you wrote [1] ? It seems
that "re-browse" and "context switching" are avoided.

[1] http://hg.tryton.org/modules/account_stock_anglo_saxon/rev/4d687e053521

Pierre-Louis

[Cédric Krier]

On 18 Jul 01:53, Pierre-Louis Bonicoli wrote:
> On 17/07/2014 23:21, Cédric Krier wrote:
> > Hi,
> >
> > I re-open the discussion of
> > https://groups.google.com/d/msg/tryton-dev/v8nBMe_ZBDk/qrvCml95UVYJ
> >
> [...]
> >
> > The only drawback, I see, is if someone right code which set in the
> > context user input data. But I think it is a very small drawback
> > compare to the advantage this design gives because in many places now
> > we have to «re-browse» or «switch the context» which slow down Tryton
> > because it kill the cache.
>
> Hi,
>
> Could not we always use a solution like the one you wrote [1] ? It seems
> that "re-browse" and "context switching" are avoided.

OK if we want to end by given access right to everything to everyone.

[Pierre-Louis Bonicoli]

On 17/07/2014 23:21, Cédric Krier wrote:

Instead of completely switching off access right control, each module
could declare what he is allowed to access. For example
account_stock_anglo_saxon module could declare to be allowed to access
to sale/purchase. This could be implemented using a new type of context:
a module context.

Pierre-Louis

[Cédric Krier]

The proposal is not about switcing off access right.
It is about moving access right check on the border of the application.

> each module
> could declare what he is allowed to access. For example
> account_stock_anglo_saxon module could declare to be allowed to access
> to sale/purchase. This could be implemented using a new type of context:
> a module context.

Please provide a clear example of what you are proposing because I don't
understand what you mean by "module" neither how you will do that.

[Cédric Krier]

A side effect of this change is that we will be able to enforce the
readonly attribute of the field.

[Cédric Krier]

I think this first step is ready for inclusion.
If I have no comment before the week end, I will push it.