Rails - Jan 2006 - Scaffold shows all attributes altough I use attr_accessible!

Hi all

I have a Model like this:

class Member < ActiveRecord::Base
  attr_accessible :username, :email, :first_name, :last_name
end

I have created a scaffold using script/generate scaffold member members

Using the URL localhost:3000/members/edit/1 I can edit all attributes, 
including created_at, lock_version etc.! But it should only show the 
attributes I listed in attr_accessible!

What is wrong here? Thanks for help.
Josh

-- 
Posted via http://www.ruby-forum.com/.

Joshua Muheim wrote:
> Hi all
> 
> I have a Model like this:
> 
> class Member < ActiveRecord::Base
>   attr_accessible :username, :email, :first_name, :last_name
> end
> 
> I have created a scaffold using script/generate scaffold member members
> 
> Using the URL localhost:3000/members/edit/1 I can edit all attributes, 
> including created_at, lock_version etc.! But it should only show the 
> attributes I listed in attr_accessible!
> 
> What is wrong here? Thanks for help.
> Josh
> 
That''s not what attr_accessible controls.  All attr_accessible does is 
put a guard on the other attributes so that they can''t be used in mass 
assignments - for example this works:

   member = Member.new(:username => ''Foo'', :email =>
''Bar@qex.org'')

Whereas this won''t:

   member = Member.new(:username => ''Foo'', :lock_version
=> 57)

The lock_version assignment will just get ignored.

The scaffolded code is rather simplistic - don''t expect it to do all
the
work for you.  There''s no method I can find that gives you a list of 
accessible attributes, so if you want to use attr_accessible to control 
the visible columns, you''ll need to define yourself your own method.

-- 
Alex

Thank you. Maybe this solves my problem?

http://perens.com/FreeSoftware/ModelSecurity/

-- 
Posted via http://www.ruby-forum.com/.

On 1/12/06, Joshua Muheim <forum@josh.ch> wrote:
> Hi all
>
> I have a Model like this:
>
> class Member < ActiveRecord::Base
>   attr_accessible :username, :email, :first_name, :last_name
> end
>
> I have created a scaffold using script/generate scaffold member members
>
> Using the URL localhost:3000/members/edit/1 I can edit all attributes,
> including created_at, lock_version etc.! But it should only show the
> attributes I listed in attr_accessible!
If you use the Scaffolding Extensions plugin, it allows you to choose
which columns are displayed in the scaffold.  Of course, if you are
generating the scaffold, you''d be better off just modifying the output
of the generator.

Jeremy Evans wrote:
> On 1/12/06, Joshua Muheim <forum@josh.ch> wrote:
>> Using the URL localhost:3000/members/edit/1 I can edit all attributes,
>> including created_at, lock_version etc.! But it should only show the
>> attributes I listed in attr_accessible!
> 
> If you use the Scaffolding Extensions plugin, it allows you to choose
> which columns are displayed in the scaffold.  Of course, if you are
> generating the scaffold, you''d be better off just modifying the
output
> of the generator.
Thanks for the hint. Because it is not standard, I stick to the normal 
scaffolding and hope that such advanced features will be added soon.

-- 
Posted via http://www.ruby-forum.com/.

Joshua Muheim wrote:
> Jeremy Evans wrote:
>> On 1/12/06, Joshua Muheim <forum@josh.ch> wrote:
>>> Using the URL localhost:3000/members/edit/1 I can edit all
attributes,
>>> including created_at, lock_version etc.! But it should only show
the
>>> attributes I listed in attr_accessible!
>> 
>> If you use the Scaffolding Extensions plugin, it allows you to choose
>> which columns are displayed in the scaffold.  Of course, if you are
>> generating the scaffold, you''d be better off just modifying
the output
>> of the generator.
> 
> Thanks for the hint. Because it is not standard, I stick to the normal 
> scaffolding and hope that such advanced features will be added soon.
I hope features won''t make it into scaffolding. Scaffold
shouldn''t
really make the basis of an app. If you can''t edit the _form.rhtml file
to comment/delete the columns,then you need to do more reading into RoR.


-- 
Posted via http://www.ruby-forum.com/.

Joshua Muheim wrote:
> 
> Thanks for the hint. Because it is not standard, I stick to the normal 
> scaffolding and hope that such advanced features will be added soon.
I don''t think there''s much chance of that.  The scaffolding
extensions
have been around for a while now, and not got any closer to the core. 
DHH has his own reasons which, while I am sure they are cogent and well 
thought out, temporarily escape me :-)

-- 
Alex

joey__ wrote:
> I hope features won''t make it into scaffolding. Scaffold
shouldn''t
> really make the basis of an app. If you can''t edit the _form.rhtml
file
> to comment/delete the columns,then you need to do more reading into RoR.
There''s arguments both ways.  It''s not just a matter of being
competent
to edit your own form - scaffolding could potentially be extended to 
give Rails a continuation framework, if anyone felt so inclined.  Code 
generation is, in general, the *right* thing to do.

-- 
Alex

On 1/12/06, Joshua Muheim <forum@josh.ch> wrote:
> Thanks for the hint. Because it is not standard, I stick to the normal
> scaffolding and hope that such advanced features will be added soon.
As other people have mentioned, that''s unlikely to happen.  If you
want basic scaffolding, use the default scaffold command in Rails.  If
you want fully custom code, generating a default scaffold and
modifying may be a good idea.  If you have many tables and just want
semicustom admin forms for them, it''ll be a lot faster to use the
Scaffolding Extensions plugin and add a few lines of scaffold
configuration code to each model than it would be to generate default
scaffolds and modify them all by hand (especially if your schema may
change).

2006/1/12, Alex Young <alex@blackkettle.org>:
> There''s arguments both ways.  It''s not just a matter of
being competent
> to edit your own form - scaffolding could potentially be extended to
> give Rails a continuation framework, if anyone felt so inclined.  Code
> generation is, in general, the *right* thing to do.
>
In the sense that code generation is better than manual copy-pasting.
It is *not* better than removing code duplication in the first place.

Douglas