Thanks! Currently we were adding SP support in the patch by letting the developer explictly perform a permit_all_parameters in the ActiveAdmin controller definition. That is not the way we'd like to do it but a more integrated and robust approach should involve more involved changes to AA, and since the developer has to explicitly define that all parameters are being permitted, that works for now even though it is up for debate whether that should be integrated as an option.
So for the appraisal gem- I would set up an appraisal for with SP and without SP and I could just check to see whether StrongParameters constant has been defined or not wherever controllers are defined in the AA tests to know whether to call permit_all_parameters. Sounds like a plan. Even if SP won't have a kill switch (which I agree there are arguments against), it is requiring temporary workarounds that effectively disable it so that people can use their existing code. On Thursday, October 25, 2012 1:22:30 PM UTC-4, Allen Madsen wrote: > > Check out https://github.com/thoughtbot/appraisal > > Allen Madsen > http://www.allenmadsen.com > > > On Thu, Oct 25, 2012 at 12:57 PM, Gary Weaver <[email protected]<javascript:> > > wrote: > >> Request denied by dhh. See pull request for reasons. Sounds like >> strong_parameters is living up to its name. It won't be taken down by a >> measly on/off switch. :p >> >> >> On Thursday, October 25, 2012 11:25:19 AM UTC-4, Gary Weaver wrote: >>> >>> Added ability to disable and reenable strong_parameters: >>> https://github.com/rails/**strong_parameters/pull/55<https://github.com/rails/strong_parameters/pull/55> >>> >>> Goal is to allow more hassle-free inclusion of strong_parameters for >>> testing with and without strong_parameters, because I wanted to have that >>> before adding tests for this strong_parameters patch for activeadmin: >>> https://github.com/gregbell/**active_admin/issues/1731<https://github.com/gregbell/active_admin/issues/1731> >>> >>> Know this looks suboptimal as it still behaves differently when SP is >>> disabled, but I thought this might better allow disabling without providing >>> broken behavior when reenabled. It may need more tests to flesh out any >>> issues, but this is a first attempt and it has a test to disable and >>> re-enable that appears to work. >>> >>> Thanks for any feedback. >>> >> -- >> You received this message because you are subscribed to the Google Groups >> "Ruby on Rails: Core" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/rubyonrails-core/-/4_vA4-Su-mkJ. >> >> To post to this group, send email to >> [email protected]<javascript:> >> . >> To unsubscribe from this group, send email to >> [email protected] <javascript:>. >> For more options, visit this group at >> http://groups.google.com/group/rubyonrails-core?hl=en. >> > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/xNoVq3MrtlQJ. 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-core?hl=en.
