Updating user status

Rails
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