Security overwrite manual settings when update base

Hi Joel

It's not a bug, it's a feature :)

If you made a mistake with access right, update = all must restore the original value.

the best way to resolve this issue is to create a profil module whom depend to account, and add the original line to your security/ir.model.access.csv profile and replace the last 0 by 1 as

"access_hr_account_analytic_line","account.account.analytic.line","account.model_account_analytic_line","hr.group_hr_user",1,1,1,1

in the first columns, don't forget to prefix the value with the module name as
"account.access_hr_account_analytic_line", ....
because original lines are in the account module

Regards,

Christophe.

Hi Christophe !

Y don't agree with you even if it's may be the tiny's answer... But I will fight hard to have something better :) !

- First, I did not update = all, but update the module base via the client interface.

- Second, Tiny said last meeting that they want to improve the parametrization you can do in through the client... So, I'm asking : Why cannot we make the security parametrization perennial through the client ! It's really painfull.

- And last, thanks for the advice, but I know I can create a module, but the purpose is to not do it !! You're 10 times faster making the right mangement trough the client, rather than through the creation of an hertied new module...

So my though:

I may be agree that update=all from server could restore all default settings, I think it's not a bad features, in case you wanna restore everything by default (may be even xml data with the noupdate parameter set to true).

But when you update base module from client side, there is absolutely no reason for that ! It's dangerous and not documented at all ! You need to trust the ORM for that kind of operations. I just loose all my settings with that yesterday...

So, Tiny please, correct this.... This is unusable in a real production context...

Regards,

Joël

Hi

"""- Second, Tiny said last meeting that they want to improve the parametrization you can do in through the client... So, I'm asking : Why cannot we make the security parametrization perennial through the client ! It's really painfull."""

"""- And last, thanks for the advice, but I know I can create a module, but the purpose is to not do it !! You're 10 times faster making the right mangement trough the client, rather than through the creation of an hertied new module..."""

If you don't want create a module, just duplicate the ligne and add the missing right.

The import CSV works, i don't think it's a good idea to change it.

"""So, Tiny please, correct this.... This is unusable in a real production context..."""
If you don't want made a module, just install base_module_recorder, start him, create your rules, stop him, and save the result.
for all customer, we always made module profile, for all parametrization (view, menu, report, wizard, rights, ...) whicih depend to all module installed. We never had a problem and the upgrade works all the time.

We just introduced configration by default in v5.0.0 of Open ERP. Some
improvements or bugfixes may appear on the default access rights since
v5.2.0. If we put into noupdate, nobody will benefit for these improvements.

So I think we should put it in noupdate="..." in new version, not in
current stable version.

Christophe Chauvet - http://www.syleam.fr/ wrote:
> Hi Joel
>
> It's not a bug, it's a feature :)
>
> If you made a mistake with access right, update = all must restore the
> original value.
>
> the best way to resolve this issue is to create a profil module whom
> depend to account, and add the original line to your
> security/ir.model.access.csv profile and replace the last 0 by 1 as
>
> "access_hr_account_analytic_line","account.account.analytic.line","account.model_account_analytic_line","hr.group_hr_user",1,1,1,1
>
> in the first columns, don't forget to prefix the value with the module name as
> "account.access_hr_account_analytic_line", ....
> because original lines are in the account module
>
> Regards,
>
> Christophe.
>

--
Fabien Pinckaers
CEO Tiny - OpenERP Editor
Chaussée de Namur 40
B-1367 Grand-Rosière
Belgium
Phone: +32.81.81.37.00
Fax: +32.81.73.35.01
Web: http://openerp.com

Great Achievements Start With Tiny Investments
   -- Marty, 2005

Hi Fabien

Ok for noupdate="1" but Access Rules are write in CSV, not XML.

Regards,

Hi everyone,

I think we could find something wich will work for every situation.

We're all clear that we can make a module, doesn't matter if it's with module recorder, by copying some csv lines or whatever. This works fine ! The little problem is that you oftently correct some write access on the job, and this will not stay on the next update/upgrade.

For access right improvements coming in the 5.2.0 compare to the 5.0.0: I agree we want people to benefit of the new settings. But overall, we want to let them choose if they want that or not. I think in most cases, when people are in production, the lack of access right were corrected by somebody (the integrator, or even the customer). So, updating them will just result in a regression !!

This is not comparable with the views or the model data. Here, we may be want to reset everything in every upgrade.

So, I believe that we cannot make an update the same way for both security and view/model data. Security must be trusted, even if a standard update appear. For the view and the model, things are different, we can pretend than the new one is always better than the previous one.

May be introduce a new option to reset the security could be a good solution:

- Standard update=MODULE_NAME or all update everything, but not the security

- A new parameters can do it, setting it at True, like --update-security=True. This will update security in every module concerned by the update=MODULE_NAME or all

What do you think ?

Regards,

Joël

> This is not comparable with the views or the model data. Here, we may be
> want to reset everything in every upgrade.

It is comparable. If you create or update objects on new versions (add
links to others objects, for example), you will have to create or update
access rights too.

If we set access rights as non-updateable, create will work but not
update. (think about a sale order that generates or updates picking lists).

The problem is exactly the same than the view editor:
* if you change a view, you have to do an inherit or record in a module,
otherwise you may lose your changes at next update.

For access rights:
* record them in a module (quite easy with module recorder because you
don't need to record anymore but can save afterwards) or
* create new groups/rules for what you want to change.

I understand it is frustrating to lose your changes, but I think it's
also critical to have two users on 5.2.0 having a different
configuration, because one migrated from v5.0.0 and the other one
installed v5.2.0 directly. Just think about how complex can be to manage
these side effects after several migrations.

I still don't know which solution is the best one.

But, for me, it's exactly the same problem than the view editor. So we
must keep like that or change both at once, but not change the access
rights only.

""" It is comparable. If you create or update objects on new versions (add
links to others objects, for example), you will have to create or update
access rights too."""

=> I think here, creatie only new right management, and don't update existing one could work. So new object come with new right, and old one keep the old settings.

"""The problem is exactly the same than the view editor:
* if you change a view, you have to do an inherit or record in a module,
otherwise you may lose your changes at next update."""

=> I agree, but at the end, you find a way that will kept your updating view ! Making them as "inherit". Isn't possible with security... ?

"""I understand it is frustrating to lose your changes, but I think it's
also critical to have two users on 5.2.0 having a different
configuration, because one migrated from v5.0.0 and the other one
installed v5.2.0 directly. Just think about how complex can be to manage
these side effects after several migrations."""

=> It's already the case now ! With views for exemple,... No one of our customer get the same sale order view, and so on... The same with security... No one of our customer has the same security. We have to deal with that.

I still don't know which solution is the best one.

"""But, for me, it's exactly the same problem than the view editor. So we
must keep like that or change both at once, but not change the access
rights only"""

=> Difficult to find a good solution... And I understand that you may be want to find the same solution for both view editor and security. But it's not really the same in fact, view are more "cosmetics" things that security are not ! If you change a view with the editor, it's not that bad if they disapear, you won't break datas...

With security issues, it's not like that, my bad experience : Disallow the accountant to write account period, cause they change the period dates insteed of the period in it-self. Next update => this is gone, and the first thing the accountant made : change the periodes dates !!!

In my point of view, default update must create new security rules, but keep the existing one on existing objects => this will ensure people they keep their settings. A new parameters need to be place on the server to reset every security configuration, and restore the default setting.

Well, this was my2cents,

Regards,

Joël

Hello Guys,

I think security is really has for views => If we are able to say noupdate = true for views, we should be able to do it for security because security is link to views to.... it is just a question to be consistent....

security is really simple to change now in the new 5 version => and it is false to think that only default security will be used (link views... too) => people will change it for sure because each company are different => in this case, security is linke translation, it is a parametrisation and not a developpment.

really, fabien, i think is should be improved.

regards

luc

Hello Subscribers,

Would you please put your view on this point?

The security.xml/csv files to be moved on init_xml key under __terp__.py. As a Result, these files won't be into act while updating/upgrading modules.

Thank you.

Hello Jay,

Thanks to came back on this one :) ! Your solution could solve part of the problem, but :

1. If I update my module with a new object and security, then it will not update it :(

2. Adding a security if didn't exist will not take effect.

My solution is:

1. On update: by default, keep all existing security settings but add new one (If for one object and one group security exists, then do nothing, otherwise create the security line)

2. Add a parameter somewhere (in the config file for example) to restore default security from files, even if it already exists.

Doing this, you're safe with custom settings, but you can still ask the server to restore the default security !

What do you think ?

Best regards,

Joël

Personally I think having the standard security groups update with new versions of the software is a good idea.

For example if a new object is added to a module in an upgrade, users need to get access to it.

If customers want to have their own versions of the groups, why don't they just Duplicate them and assign their users to the custom versions?

as security rules evolved a lot, I don't think it's a good idea.