Forum: Ruby on Rails Mind-boggling problem with update_attributes()

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
232f6365e90c57dbe4be9fdbbf4fb1ab?d=identicon&s=25 Matt (Guest)
on 2008-12-28 00:56
(Received via mailing list)
So I'm working on creating a migration for a new version of one of the
projects I'm working on. But Rake seems to be selectively spitting out
errors. The same code that works only a few lines up will not work
where I most need it. (That should be a law of programming...)

So here's what's up. I've got a table that stores information on the
roles that users can have. There are four columns: id, name,
parent_id, and list_priority. The big key feature that I'm
implementing in this release is the concept of permission inheritance
across roles. So, what I've done for some roles is the following:

    puts '   -> Remove developer permissions collection'
    @developerRole.permissions.delete_all
    puts '   -> Set developer parent and list_priority'
    @developerRole.update_attributes(:parent_id =>
@officerRole.id, :list_priority => 5)

The migration handles that fine. However it throws an error on:

    @serviceChair = Role.create :name => 'Service Chair'
    @serviceChair.update_attributes(:parent_id =>
@brotherRole.id, :list_priority => 3)
    @serviceChair.permissions << @op_login
    @serviceChair.permissions << @op_service_fundraising

The rake error reads as follows:

rake aborted!
undefined method `list_priority=' for #<Role id: 5, name: "Service
Chair">

And, if I remove list_priority from the update_attributes method in
the second code segment, it will throw a similar error about
parent_id. Could anyone tell me what the heck is going on here? I'm
about at the end of my wits trying to figure this out.

Thanks in advance.
81b61875e41eaa58887543635d556fca?d=identicon&s=25 Frederick Cheung (Guest)
on 2008-12-28 02:25
(Received via mailing list)
Matt wrote:
> @brotherRole.id, :list_priority => 3)
>     @serviceChair.permissions << @op_login
>     @serviceChair.permissions << @op_service_fundraising
>
What (if any) is in between those two sections ? Are you changing the
roles table in this migration ? Where does  @developerRole come from ?

Fred
232f6365e90c57dbe4be9fdbbf4fb1ab?d=identicon&s=25 Matt (Guest)
on 2008-12-28 06:24
(Received via mailing list)
The Roles table is being changed in this migration, but I alter the
table before I start working with the data. The two code blocks are
adjacent. The @developerRole code is immediately above it, and
@developerRole is created by

@developerRole = Role.find(:first, :conditions => {:name =>
'Developer'})

Which happens immediately after the table alterations.

On Dec 27, 8:24 pm, Frederick Cheung <frederick.che...@gmail.com>
2a31ce1f0273b12896b4049bf3eb4ce8?d=identicon&s=25 Shiv N Gautam (Guest)
on 2008-12-28 07:15
(Received via mailing list)
In case you are modifying the Roles table (and then updating the new
fields)
you might want to reset the column information.

ModelName.reset_column_information

ModelName is your case might be Role.

--
Shiv

On Sun, Dec 28, 2008 at 10:53 AM, Matt <matt.foxtrot@gmail.com> wrote:

>
> >
> >
>


--

George Carlin  - "Weather forecast for tonight: dark."
232f6365e90c57dbe4be9fdbbf4fb1ab?d=identicon&s=25 Matt (Guest)
on 2008-12-28 16:34
(Received via mailing list)
That fixed my problem! Thanks!
This topic is locked and can not be replied to.