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
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