Scaffold shows all attributes altough I use attr_accessible!

Rails
1

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

2

Joshua M. 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!

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 => ‘[email protected]’)

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.

3

Thank you. Maybe this solves my problem?

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

4

On 1/12/06, Joshua M. [email protected] 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.

5

Joshua M. wrote:

Jeremy E. wrote:

On 1/12/06, Joshua M. [email protected] 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.

6

Jeremy E. wrote:

On 1/12/06, Joshua M. [email protected] 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.

7

Joshua M. 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 :slight_smile:

8

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.

9

2006/1/12, Alex Y. [email protected]:

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

10

On 1/12/06, Joshua M. [email protected] 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).