Yes! Yes! Yes! from me :) I got my stuff working the "old" way, but I really felt I did something "nasty".
:) Michael On 26 Jun., 11:09, "Sergio Cambra .:: entreCables S.L. ::." <[email protected]> wrote: > I'm working currently in a project which requires finer grained permissions > than other projects I made before. Also bugs hard to find and fix were > reported > recently related to security code (like issue 21 in github). So I think > currently is confusing and it's not enough in some cases. > > I have some ideas to improve it: > > 1. authorized_for? called in a model should look for security methods at > class, instead of looking for instance methos in a new instance. This change > can be backwards incompatible. Code which returns true for new records won't > be affected, but code which hide links returning false for new records would > need to add class methods. Maybe I could add a method to restore current > behaviour globally. > > Problems in issue 21 were caused by ActiveScaffold calling a security method > twice, first to show or hide an action link in a new instance, second to > enable > or disable the action link with a instance loaded from DB. It wouldn't be a > problem separating methods to show or hide an action link (using class > methods) from methods to enable or disable an action link (using instance > methods, like now). > > 2. Using crud type to enable or disable an action link is not enough for > custom action links. I would look for security methods with action name and > crud_type. > For example it would look for authorized_for_update? and authorized_for_edit? > for edit action link. > > If I want to add an action link to approve an order, I would set crud type to > update. Currently it would check permissions with authorized_for_update?. I > can't disable editing but enable approving with current schema. Adding this I > could enable approving with authorized_for_approve? and disable editing with > authorized_for_update? > > 3. Remove the security method from action links. IMHO security checks should > be at the model. So we can change security method calls in views or > controllers to direct calls to authorized_for? method in the model (class or > instance). > > Security checks for nested forms don't use security method because we doesn't > want to create a new controller for associated model (and I think it's not > easy and it would have high cost). People who relies on overridden security > methods to implement security checks find it doesn't work for nested forms. If > we remove security methods and force to set security checks in the model it > would work for normal scaffolds and nested forms. > > What do you think about this changes? > -- > Sergio Cambra .:: entreCables S.L. ::. > Mariana Pineda 23, 50.018 Zaragoza > T) 902 021 404 F) 976 52 98 07 E) [email protected] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "ActiveScaffold : Ruby on Rails plugin" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/activescaffold?hl=en -~----------~----~----~----~------~----~------~--~---
