Rails has many built in validation methods to ensure that an ActiveRecord instance cannot be created or updated under certain situations (typically caused by invalid data). However, I can find no methods to govern whether an ActiveRecord instance can be destroyed. Essentially, I wish an error to be raised when a user tries to delete an ActiveRecord without first adhering to a certain set of conditions. I currently achieve this via before_destroy method, where I set a custom error for the ActiveRecord in question. I then persist the ActiveRecord across the session, so that I can redirect from ''delete'' to ''list'' as usual without losing the error in the process. To display the error, I use an overridden error_messages_for, so that the header will say "from being deleted" instead of "from being saved". This all seems a remarkably round about way of doing things for what must be a not uncommon problem. Is there a more "Rails-like" way of doing this? Has anyone else come across the problem where an error message should be raised if the user attempts to delete something important without doing X, Y and Z first? Thanks in advance, - James Reeves -- Posted via http://www.ruby-forum.com/.
On Aug 1, 2006, at 1:23 AM, James Reeves wrote:> Rails has many built in validation methods to ensure that an > ActiveRecord instance cannot be created or updated under certain > situations (typically caused by invalid data). However, I can find no > methods to govern whether an ActiveRecord instance can be destroyed.Return false from before_destroy to abort the destroy.> Essentially, I wish an error to be raised when a user tries to > delete an > ActiveRecord without first adhering to a certain set of conditions. I > currently achieve this via before_destroy method, where I set a custom > error for the ActiveRecord in question. I then persist the > ActiveRecord > across the session, so that I can redirect from ''delete'' to ''list'' as > usual without losing the error in the process. To display the error, I > use an overridden error_messages_for, so that the header will say > "from > being deleted" instead of "from being saved". > > This all seems a remarkably round about way of doing things for what > must be a not uncommon problem. Is there a more "Rails-like" way of > doing this? Has anyone else come across the problem where an error > message should be raised if the user attempts to delete something > important without doing X, Y and Z first?before_destroy { |record| record.crucial_destroy_condition_met? } ... def destroy unless @record.destroy flash[:error] = "#{@record.name} was not deleted" end redirect_to records_url end Validating destroy is uncommon, but shouldn''t require so much contortion. jeremy
On Tuesday, August 01, 2006, at 1:50 AM, Jeremy Kemper wrote:>On Aug 1, 2006, at 1:23 AM, James Reeves wrote: >> Rails has many built in validation methods to ensure that an >> ActiveRecord instance cannot be created or updated under certain >> situations (typically caused by invalid data). However, I can find no >> methods to govern whether an ActiveRecord instance can be destroyed. > >Return false from before_destroy to abort the destroy. > > >> Essentially, I wish an error to be raised when a user tries to > >>delete an >> ActiveRecord without first adhering to a certain set of conditions. I >> currently achieve this via before_destroy method, where I set a custom >> error for the ActiveRecord in question. I then persist the > ActiveRecord >> across the session, so that I can redirect from ''delete'' to ''list'' as >> usual without losing the error in the process. To display the error, I >> use an overridden error_messages_for, so that the header will say > "from >> being deleted" instead of "from being saved". >> >> This all seems a remarkably round about way of doing things for what >> must be a not uncommon problem. Is there a more "Rails-like" way of >> doing this? Has anyone else come across the problem where an error >> message should be raised if the user attempts to delete something >> important without doing X, Y and Z first? > > before_destroy { |record| record.crucial_destroy_condition_met? } >... > def destroy > unless @record.destroy > flash[:error] = "#{@record.name} was not deleted" > end > redirect_to records_url > end > >Validating destroy is uncommon, but shouldn''t require so much contortion. > >jeremy >_______________________________________________ >Rails mailing list >Rails@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/railsI would personally add another layer of protection. Put a before_filter in your controller that checks to make sure the current user can destroy the record. Then redirect if they don''t so that the destroy can''t be issued normally if it is not valid to destroy it. Keep the before_destroy in your model. For stuff like this you want belts and suspenders. _Kevin www.sciwerks.com -- Posted with http://DevLists.com. Sign up and save your mailbox.
Jeremy Kemper wrote:> Return false from before_destroy to abort the destroy.That''s what I have already, I''m afraid :) My problem is not that I cannot protect an ActiveRecord from being destroyed; as you point out, before_destroy can handle that simply by returning false. My problem is that such an approach does not integrate well into the rest of the Rails validation framework. Ideally, I''d like to have a consistant error handling framework (both in terms of user interface and code), rather than a piecemeal approach. You make an excellent point about the use of the flash hash, however. I''d quite forgotten about that. Thank you! The best way I can think of to achieve what I want to do is to construct a plugin to extend ActiveRecord error handling to give it the range of flexibility I need. I think I prefer such an approach over using two different error handling systems. - James Reeves -- Posted via http://www.ruby-forum.com/.