Sorry that was a little unclear- by that "perform CRUD UI" part, I was 
trying to say that AA can automatically provide a CRUD UI for models 
without having to define permitted attributes- well, not taking into 
account mass assignment security in Rails 3, that is. I'm actually not sure 
whether it looks at protected attributes or not. I assume all that would 
have to change in a Rails 4 version of AA, but right now we just want to 
make it work with Rails 3 and SP, so whatever gets us there is a hopefully 
secure and DRY fashion is what we are looking for (or at least it is what 
at least a handful of us would like to see that are using SP with Rails 
3.2.x).

On Thursday, October 25, 2012 3:17:06 PM UTC-4, Gary Weaver wrote:
>
> As per convention, SP's definition of what is allowed in a controller is a 
> hash, which doesn't really fit into the AA definition of a controller from 
> what I see, but I could be wrong.
>
> And AA's definition of a controller is done via a DSL for a controller, 
> not an actual controller.
>
> Hooking into what columns are editable in AA I *think* is going to take 
> some work to work with SP, per cursory review of their code. I could be 
> wrong.
>
> In ActiveAdmin, you can just generate a controller, make changes to the 
> model via migrations, etc. and you still have the ability to perform CRUD 
> UI on the model without having to permit new parameters (fields/attributes) 
> in the controller. So, to have AA perform as it did before, the default 
> would need to be something similar to permit_all_parameters and although we 
> could just make this assumption and say all AA controllers should permit 
> all, we decided to make it a method that said you were permitting all so 
> you could see that in your AA controller definition.
>
> I'm probably misunderstanding though so feel free to point out specifics 
> as to what it could be doing.
>
> Thanks for the feedback!
>
> On Thursday, October 25, 2012 2:47:31 PM UTC-4, Pedro Nascimento wrote:
>>
>> Just a tip: I think CoC would help you here. Why not look for a 
>> specific method defining what parameters are allowed and if there is 
>> one, use it? You would be able to get rid of the 
>> permit_all_parameters. 
>>
>> On Thu, Oct 25, 2012 at 4:43 PM, Gary Weaver <[email protected]> wrote: 
>> > 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]> 
>> 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 
>> >>>> 
>> >>>> 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 
>> >>>> 
>> >>>> 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]. 
>> >>> 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. 
>> >> 
>> >> 
>> > -- 
>> > 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. 
>>
>

-- 
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/-/YwQvUJphTesJ.
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.

Reply via email to