Hi, I think it''s awesome that Rails 3.1 introduces the attribute accessible roles/permissions: class User attr_accessible :name, :as => :admin end User.create(params[:user], :as => :admin) But would it be possible to make this a chained function as was done with find, where and scopes from Rails 2.x to Rails 3.0? Here''s a little more on the topic<http://ablogaboutcode.com/2011/05/12/activerecord-3-1-mass-assignment-roles/>. Maybe ARel could be leveraged to do this? I can see that there might be conflicts with user defined scopes, but isn''t chaining functions just so much more elegant than passing multiple hash parameters to a function? Thanks, Pan -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I''m curious whether you can define the :as option as a list of roles? All the examples I have seen only has the :as linked to the single role :admin. How would I use this with a roles system? Say I had a #current_user_roles method available from my Controller or whatever. def update Project.update_attributes(params[:project], :as => current_user_roles) end One possible DSL tweak allow something like this: as_role current_user_roles do |role| role.update_attributes_of(Project).with params[:project] role.create(Project).with params[:project] end Here the #as_role should return some object that has the methods #update_attributes #create and so on and a method/reader for the roles to apply the role permission check. On May 13, 2:00 am, Pan Thomakos <pan.thoma...@gmail.com> wrote:> Hi, > > I think it''s awesome that Rails 3.1 introduces the attribute accessible > roles/permissions: > > class User > attr_accessible :name, :as => :admin > end > > User.create(params[:user], :as => :admin) > > But would it be possible to make this a chained function as was done with > find, where and > scopes from Rails 2.x to Rails 3.0? Here''s a little more on the > topic<http://ablogaboutcode.com/2011/05/12/activerecord-3-1-mass-assignment...>. > Maybe ARel could be > leveraged to do this? > > I can see that there might be conflicts with user defined scopes, but isn''t > chaining functions > just so much more elegant than passing multiple hash parameters to a > function? > > Thanks, > Pan-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
On Wed, May 18, 2011 at 11:52 AM, Kristian Mandrup <kmandrup@gmail.com> wrote:> I''m curious whether you can define the :as option as a list of roles? > All the examples I have seen only has the :as linked to the single > role :admin.In short, no, it''s not a ''role'' in the sense that you mean here, rather the name of a parameter filter to use. Your app itself will need to have it''s own logic and semantics for figuring out which filter to use based on your own business rules.> How would I use this with a roles system? > > Say I had a #current_user_roles method available from my Controller or > whatever. > > def update > Project.update_attributes(params[:project], :as => > current_user_roles) > end > > One possible DSL tweak allow something like this: > > as_role current_user_roles do |role| > role.update_attributes_of(Project).with params[:project] > role.create(Project).with params[:project] > end > > Here the #as_role should return some object that has the methods > #update_attributes #create and so on and a method/reader for the roles > to apply the role permission check. > > > On May 13, 2:00 am, Pan Thomakos <pan.thoma...@gmail.com> wrote: >> Hi, >> >> I think it''s awesome that Rails 3.1 introduces the attribute accessible >> roles/permissions: >> >> class User >> attr_accessible :name, :as => :admin >> end >> >> User.create(params[:user], :as => :admin) >> >> But would it be possible to make this a chained function as was done with >> find, where and >> scopes from Rails 2.x to Rails 3.0? Here''s a little more on the >> topic<http://ablogaboutcode.com/2011/05/12/activerecord-3-1-mass-assignment...>. >> Maybe ARel could be >> leveraged to do this? >> >> I can see that there might be conflicts with user defined scopes, but isn''t >> chaining functions >> just so much more elegant than passing multiple hash parameters to a >> function? >> >> Thanks, >> Pan > > -- > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > To post to this group, send email to rubyonrails-core@googlegroups.com. > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en. > >-- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
I understand that it is just a simple symbol match and you have to write your own business logic behind it: If we imagine we have a role system along these lines, where a #the_current_user method returns a User instance that has a #roles_list method that returns an array of roles (as Symbols) Then we could imagine something like the following logic to make it a bit more convenient and logic DSL like (IMO): # as_role current_user_roles do |role| # role.update_attributes_of(Project).with params[:project] # role.create(Project).with params[:project] # end def as_role role, &block yield RoleModelManager.new role end def as_roles *roles, &block yield RoleModelManager.new roles.flatten end class RoleModelManager attr_accessor :roles def initialize *roles @roles = roles.flatten end def update_attributes_of model_clazz AttributesUpdater.new model_clazz end def create model_clazz ModelCreator.new model_clazz end class AttributesUpdater attr_accessor :clazz def initialize clazz @clazz = clazz end def with attributes = {} clazz.constantize.update_attributes(attributes.merge(:as => roles)) end end class ModelCreator attr_accessor :clazz def initialize clazz @clazz = clazz end def with attributes = {} clazz.constantize.create(attributes.merge(:as => roles)) end end end def current_roles the_current_user.roles_list end What do you think? My question is, if the current logic relating to the :as option can evaluate according to an array of symbols (using #include? fx) ? On May 18, 6:11 pm, Michael Koziarski <mich...@koziarski.com> wrote:> On Wed, May 18, 2011 at 11:52 AM, Kristian Mandrup <kmand...@gmail.com> wrote: > > I''m curious whether you can define the :as option as a list of roles? > > All the examples I have seen only has the :as linked to the single > > role :admin. > > In short, no, it''s not a ''role'' in the sense that you mean here, > rather the name of a parameter filter to use. Your app itself will > need to have it''s own logic and semantics for figuring out which > filter to use based on your own business rules. > > > > > > > How would I use this with a roles system? > > > Say I had a #current_user_roles method available from my Controller or > > whatever. > > > def update > > Project.update_attributes(params[:project], :as => > > current_user_roles) > > end > > > One possible DSL tweak allow something like this: > > > as_role current_user_roles do |role| > > role.update_attributes_of(Project).with params[:project] > > role.create(Project).with params[:project] > > end > > > Here the #as_role should return some object that has the methods > > #update_attributes #create and so on and a method/reader for the roles > > to apply the role permission check. > > > On May 13, 2:00 am, Pan Thomakos <pan.thoma...@gmail.com> wrote: > >> Hi, > > >> I think it''s awesome that Rails 3.1 introduces the attribute accessible > >> roles/permissions: > > >> class User > >> attr_accessible :name, :as => :admin > >> end > > >> User.create(params[:user], :as => :admin) > > >> But would it be possible to make this a chained function as was done with > >> find, where and > >> scopes from Rails 2.x to Rails 3.0? Here''s a little more on the > >> topic<http://ablogaboutcode.com/2011/05/12/activerecord-3-1-mass-assignment...>. > >> Maybe ARel could be > >> leveraged to do this? > > >> I can see that there might be conflicts with user defined scopes, but isn''t > >> chaining functions > >> just so much more elegant than passing multiple hash parameters to a > >> function? > > >> Thanks, > >> Pan > > > -- > > You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. > > To post to this group, send email to rubyonrails-core@googlegroups.com. > > To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. > > For more options, visit this group athttp://groups.google.com/group/rubyonrails-core?hl=en. > > -- > Cheers > > Koz-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> What do you think? My question is, if the current logic relating to > the :as option can evaluate according to an array of symbols (using > #include? fx) ?What would multiple values mean for :as? Any of these? all of these? There''s no valid / sane semantics for merging black and white lists together. You''ll probably always have to do that yourself, this isn''t intended for the use case you seem to have. -- Cheers Koz -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.