How to create an Admin user using migration?

Rails
1

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

2

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

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

3

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 => '[email protected]: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 => '[email protected]:activated_at =>
Time.now.utc, :activation_code => nil, :new_email => nil )

But still no luck.

4

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

5

Hi,

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

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