updating user status

rubyonrails-talk
1

Hi   I have the models

User belongs_to user_status and UserStatus

     user_statuses is a master table having values

id name 1 Pending 2 Approved 3 Deleted

   Now when ever a user is created for the first time his user_status_id is 1 (ie pending). Administrator when click on Approve button status changes to "Approved". My question is implementing this. Is it right to update like

In user controller update action

user = User.find(params[:id]) user.update_attributes(:user_status_id => 2)

      Rather than hard coding user_status_id = 2, is there any other approach?

Thanks in advance Tom

2

Hi,

Maybe you could try acts_as_state_machine

3

user_statuses is a master table having values

id name

1 Pending

2 Approved

3 Deleted

My first question is why do you have a table for user_status? Are administrators of your app going to be adding new statuses via a web interface?

if not, why not just have constants:

class User

STATUS_PENDING = 1

STATUS_APPROVED = 2

STATUS_DELETE = 3

…

end

user = User.find(params[:id])

user.update_attributes(:user_status_id => 2)

  Rather than hard coding user_status_id = 2,  is there any other

approach?

user.update_attributes(user_status => User::STATUS_APPROVED)

It sounds like you’re making it more complex than it needs to be.

Alternatively if you wanted to keep it your way you could do:

user.update_attributes(:user_status_id => UserStatus.find_by_name(“Approved”).try(:id))

This finds the UserStatus record with the name Approved and uses it’s id (if it’s found)

Cheers,

Andy

4

I recommend keeping the table. Let me explain why and try to explain how to set it up better.

This type of information is known at the outset of the application and it sounds like it is unlikely to change significantly over time. As such it could be pulled into a domain table, similar to states and zipcodes for example.

Some benefits: 1) allows you to ensure referential integrity at the database level. This will ensure that your rails app, the pgsql or mysql prompt, another app, etc can only enter valid user roles. 2) changes can be made in one central location in the database 3) more importantly it scales the app may require additional information. For example, if you ever want to add more data associated with a role you can do this in an appropriate table. Take an address model and zipcode field as an example. Since zipcodes are known at the outset of an application they can be pulled into a domain table that the address table references. Then if you add latitude and longitude info to do distace calculations, you have a place to put this information and not repeat it many times within the address table. The same may be true for your user roles as the app evolves.

Drawbacks this is a bit more work upfront but I argue that it is well worth it in the long run. Setting up a solid data layer is the most important part of any application. The data will likely outlive the app built atop it. Best to use solid db techniques.

Make a migration for your user roles and a AR::base model. Make your constants there. For example in UserRole < AR::Base define ADMIN = 1, etc. Then in the code for a user set @user.user_role_id = UserRoles::ADMIN. You can also write a function to create and cache these automatically based on the name you provide. I will leave that part to you.

Just my thoughts

Andrew

5

Hi     Thanks for all your help

Tom