how to create an Admin user using migration?

[sgudibanda]

Hi,

I am using act_as_authenticated plugin for authentication purposes.
Now i need to add an user (Admin) in migration so that i can use this
for authorization purposes.

Issues is how will add an user , i would not know crypted password and
salt?

create_table "users", :force => true do |t|
t.column :login, :string
t.column :email, :string
t.column :crypted_password, :string, :limit => 40
t.column :salt, :string, :limit => 40
t.column :created_at, :datetime
t.column :updated_at, :datetime
t.column :remember_token, :string
t.column :remember_token_expires_at, :datetime
t.column :activation_code, :string, :limit => 40
t.column :activated_at, :datetime
end
is the schema?
Regards,
Sandeep G

[Anthony Richardson]

sgudibanda wrote:
> Hi,
>
> I am using act_as_authenticated plugin for authentication purposes.
> Now i need to add an user (Admin) in migration so that i can use this
> for authorization purposes.
>
> Issues is how will add an user , i would not know crypted password and
> salt?
>
>

You can simply use the model itself to handle the encryption. Here is
what I use in my migration.

User.create(
:login => 'admin',
:password => 'admin',
:password_confirmation => 'admin',
:email => 'ad...@xyz.com'
)

This will create the encrypted password and save to the database.

[sgudibanda]

Hi,

I tried that, since i am using act_as_authenticated and even the
change_email feature with it, i have new_email in validation.
( validates_length_of :new_email,
:within => 6..100,
:if => :new_email_entered?) )

User.create(
:login => 'admin',
:password => 'admin',
:password_confirmation => 'admin',

:email => 'ad...@xyz.com:activated_at =>
Time.now.utc, :activation_code => nil)

i am thrown : undefine method new_email

i tried this:

User.create(
:login => 'admin',
:password => 'admin',
:password_confirmation => 'admin',

:email => 'ad...@xyz.com:activated_at =>
Time.now.utc, :activation_code => nil, :new_email => nil )

But still no luck.

[sgudibanda]

Oh Sorry! That works! I had a migration with new_email later. That was
causing problem! My bad :(

[javier ramirez]

Hi,

Oh Sorry! That works! I had a migration with new_email later. That was
causing problem! My bad :(
  

And that's why you shouldn't use migrations for db load. I know it's a very common practice, but I don't support it since it's error-prone.

Migrations are really useful for dynamic db schemas, I mean, schemas that will change over time. If schemas never changed, then we wouldn't need any migrations but just a static copy of the creation sql. So, even only for the sake of argument, we can say the use of migrations implies changes to your tables/models.

And talking about models, there is this one nice thing with them which is validations. So let's say I create a table in step 1 and I add a statement for creating a new row/instance of that Model. Then let's say in step 35 I add a new mandatory not null field and I accordingly set my validations, since in Rails we usually put the load of validating on the application-side.

Now, when I try to install my project on a new server, step 1 of migrations will crash, since validation is going to fail because of the non-existing field.

Assuming your problem is only validations and not call-backs, you could always try saving your objects with save(false). Problem with this approach is you are not going to run validations, so you better be sure what you are doing.

My solution for this is using migrations *only* for dealing with the DDL, so anything which is not a part of the schema definition is definitely out of my migrations code. And where should I put my initializations then? I like to create a task to initialize all my db content.

It comes handy also because I can put all my initializations in one single file and I don't need to be checking the migrations code. And since when you update the code of the new migrations from the repository  you are also updating the code for the tasks, you can always put the most recent version in your task code without any problems.

If you commit your changes of both migration and task together, then you can go back to any release you want and your rake task will always be in sync with your migrations. Also, if when you commit a model with references to new fields you comment in your scm which migration it belongs to, then you have everything wrapped up and you can go up/down versions of your project without any issues.

Now you can do something like
rake db:migrate
rake my_project:initialize_db

And to make it really comfortable and avoid problems, don't insert the new objects starting with "Model.new" or "Model.create" but with a "Model.find_or_initialize_by...". That way if you already inserted the row in db, you are not going to get duplicates.

I'm sure there are other approaches to this problem, but this one seems to work fine for me.

Regards,

javier ramirez