# How to create an Admin user using migration?

**URL:** <https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053>\
**Category:** Rails\
**Created:** [September 7, 2007, 11:47am UTC](https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053 "2007-09-07T11:47:27Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![sgudibanda](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a9adbd/32.png) [@sgudibanda](https://www.ruby-forum.com/u/sgudibanda)\
**Post date:** [September 7, 2007, 11:47am UTC](https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053/1 "2007-09-07T11:47:27Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![sgudibanda](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a9adbd/32.png) [@sgudibanda](https://www.ruby-forum.com/u/sgudibanda)\
**Post date:** [September 7, 2007, 12:20pm UTC](https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053/2 "2007-09-07T12:20:34Z")

</div>

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 => 'removed_email_address@domain.invalid'
)

```

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

---

<div class="post-metadata">

**Author:** ![sgudibanda](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a9adbd/32.png) [@sgudibanda](https://www.ruby-forum.com/u/sgudibanda)\
**Post date:** [September 7, 2007, 12:38pm UTC](https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053/3 "2007-09-07T12:38:41Z")

</div>

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 =\> 'removed\_email\_address@domain.invalid: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 =\> 'removed\_email\_address@domain.invalid:activated\_at =\>  
Time.now.utc, :activation\_code =\> nil, :new\_email =\> nil )

But still no luck.

---

<div class="post-metadata">

**Author:** ![sgudibanda](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a9adbd/32.png) [@sgudibanda](https://www.ruby-forum.com/u/sgudibanda)\
**Post date:** [September 7, 2007, 12:59pm UTC](https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053/4 "2007-09-07T12:59:43Z")

</div>

Oh Sorry! That works! I had a migration with new\_email later. That was  
causing problem! My bad ☹

---

<div class="post-metadata">

**Author:** ![sgudibanda](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/a9adbd/32.png) [@sgudibanda](https://www.ruby-forum.com/u/sgudibanda)\
**Post date:** [September 7, 2007, 2:19pm UTC](https://www.ruby-forum.com/t/how-to-create-an-admin-user-using-migration/114053/5 "2007-09-07T14:19:53Z")

</div>

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