Colin Law wrote in post #973053: > What I don't immediately see is how that links in to update_attributes > to prevent particular columns being updated. > > Colin
You can apply the same authorization on fields within models. If you have for instance 3 fields that should be updatable based on particular action responders, you can have the model update_attributes based on the currently stored value in the database, or the value being sent via params to the model based on bitfield actions accessible to the model. In laymans terms, its like saying: can_model(update_myfieldname, in_this_action, mymodel) .. if the model's bitfield allows the update of the field, matching the authorization bitfield within "in_this_action", it proceeds with the params for the field value, otherwise, it just returns the currently stored value. It's not difficult. It may seem complicated at first, but it's actually really simple to implement. You could apply the bitfield authorization in the view (which is similar to what you proposed with new_model?, which keeps the field from being entered, but doesn't restrict a post hack. You could add another layer in the controller, if you wanted to to decide which actions are usable, and/or apply merged params, removing the duplicated field before merging, and sending to the model... and/or applying bitfield permissions in the model. While this is definitely overkill IMHO, with a system in place, you only have to add "one" line of code to the view, one line of code to the controller, and one line of code to the model. 3 lines of code. :) -- Posted via http://www.ruby-forum.com/. -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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/rubyonrails-talk?hl=en.
