So I have a question model that belongs to User. Initially, I'd like to set basic questions with an attribute public: true, and every user can see this kind of questions which I'd like to create in the seed.rb.
Then, subsequently with an Answer model. Each users answer belongs to a certain question.
Now the issue is creating these pre-made questions for the users to answer I've tried the following in seed.rb:
u = User.new(email: "test#gmail.com", password: "testpass", password_confirmation: "testpass", gender: "M")
questions = u.questions.build(title: "What is your favourite food?")
u.save
And I'd like to call the same default questions for all users in the view with
questions_controller.rb
def index
#questions = Question.all
end
But this simply doesn't seem to be working, i.e. when I go to rails c and run u, it's an undefined method.. and the u.questions is an empty array. I've run these lines in console manually and they worked so I'm not sure what's happening here.
What am I doing wrong?
Update dev log
^[[1m^[[36mUser Load (16.9ms)^[[0m ^[[1mSELECT "users".* FROM "users" ORDER BY "users"."id" ASC LIMIT 1^[[0m
^[[1m^[[35mQuestion Load (645.9ms)^[[0m SELECT "questions".* FROM "questions" WHERE "questions"."user_id" = $1 [["user_id", 2]]
^[[1m^[[36mActiveRecord::SchemaMigration Load (48.4ms)^[[0m ^[[1mSELECT "schema_migrations".* FROM "schema_migrations"^[[0m
^[[1m^[[36mActiveRecord::SchemaMigration Load (1.0ms)^[[0m ^[[1mSELECT "schema_migrations".* FROM "schema_migrations"^[[0m
^[[1m^[[35m (0.3ms)^[[0m BEGIN
^[[1m^[[36mUser Exists (34.7ms)^[[0m ^[[1mSELECT 1 AS one FROM "users" WHERE "users"."email" = 'anthony#gmail.com' LIMIT 1^[[0m
^[[1m^[[35m (0.3ms)^[[0m ROLLBACK
DEPRECATION WARNING: You didn't set config.secret_key_base. Read the upgrade documentation to learn more about this new config option. (called from service a\
t /usr/local/rvm/rubies/ruby-2.0.0-p247/lib/ruby/2.0.0/webrick/httpserver.rb:138)
I think the issue was that the OP had bad data in the development database.
Running rake db:drop db:create db:setup appeared to fix the issue.
Related
I just recently started getting weird output whenever I run any command from the command line within my rails app. I did just add Devise to it a couple days ago so maybe that's the issue?
One example is this:
> rails g mailer UserMailer
[16:34:48] (0.1ms) BEGIN
User Exists (0.6ms) SELECT 1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER('') LIMIT 1
(0.1ms) ROLLBACK
(0.1ms) BEGIN
User Exists (0.2ms) SELECT 1 AS one FROM "users" WHERE LOWER("users"."email") = LOWER('') LIMIT 1
(0.1ms) ROLLBACK
create app/mailers/user_mailer.rb
invoke haml
create app/views/user_mailer
invoke rspec
create spec/mailers/user_mailer_spec.rb
The unexpected output is ALWAYS some sort of SQL logging. Anyone know what would cause this?
The problem seems to be uniqueness validation. You have validate_uniqueness_of :email in your model and you are trying to create a new user with the same email, at least the error shows so.
I'm trying to update a record through the rails console and am getting a rollback error:
Project.find(118).update_attributes(:featured=>true)
Project Load (2.6ms) SELECT "projects".* FROM "projects" WHERE "projects"."id" = $1 LIMIT 1 [["id", 118]]
(2.8ms) BEGIN
(1.3ms) ROLLBACK
=> false
How can I view the source of the error? I'm able to update the attribute for other records, so I'd like to inspect why this particular record isn't working.
Your Project instance is probably invalid. To see what error prevented it from saving, you can type:
project = Project.find 118
project.assign_attributes(featured: true)
project.valid?
project.errors.full_messages
I'm trying to set user's (admin) password from Rails console:
bundle exec rails console
> Spree::User.first.email
=> "admin#mysite.com"
> Spree::User.first.encrypted_password
Spree::User Load (1.1ms) SELECT "spree_users".* FROM "spree_users" LIMIT 1
=> "4ec556............................................."
> Spree::User.first.password='spree123'
Spree::User Load (1.0ms) SELECT "spree_users".* FROM "spree_users" LIMIT 1
=> "spree123"
> Spree::User.first.password_confirmation='spree123'
Spree::User Load (1.0ms) SELECT "spree_users".* FROM "spree_users" LIMIT 1
=> "spree123"
> Spree::User.first.save!
Spree::User Load (1.0ms) SELECT "spree_users".* FROM "spree_users" LIMIT 1
(0.3ms) BEGIN
(1.3ms) SELECT COUNT(DISTINCT "spree_users"."id") FROM "spree_users" LEFT OUTER JOIN "spree_roles_users" ON "spree_roles_users"."user_id" = "spree_users"."id" LEFT OUTER JOIN "spree_roles" ON "spree_roles"."id" = "spree_roles_users"."role_id" WHERE "spree_roles"."name" = 'admin'
(0.3ms) COMMIT
=> true
> Spree::User.first.encrypted_password
Spree::User Load (1.0ms) SELECT "spree_users".* FROM "spree_users" LIMIT 1
=> "1bc15d.............................................."
So far so good. It looks like the new password for the user has been changed and commited to the database. However when I try to log in later with a web client and using the new password, it fails with invalid identity/password message.
I even tried to update password with Spree::User.first.reset_password!('spree123', 'spree123') but sill cann't sign in.
Rails 3.2.12
Spree 1.3.2
Any idea what am I doing wrong ? How to properly set a new password ?
Thanks.
The problem is that every time you're doing Spree::User.first it's reloading the record from the database. This means you are setting the value on one instance of the record, reloading it, and then saving the reloaded model that hasn't actually changed. An easy way around this is to create a local instance variable containing the record and update that instead:
user = Spree::User.first
user.password='spree123'
user.password_confirmation='spree123'
user.save!
Spree::User.first.update_attributes(password: 'password')
The update function is working within my ruby console as shown below, but the updates aren't being reflected in the database for this particular user.
For all other users it works perfectly, and using update_all works, but also updates all other users. Any idea why?
ruby-1.9.2-p290 :002 > User.update(51, :introduction => "testupdate")
User Load (0.2ms) SELECT "users".* FROM "users" WHERE "users"."id" = ? LIMIT 1 [["id", 51]]
(0.3ms) UPDATE "users" SET "introduction" = 'testupdate', "updated_at" = '2011-09-13 18:53:25.896711' WHERE "users"."id" = 51
=> #<User id: 51, email: "example#email.com", introduction: "testupdate", created_at: "2011-09-13 18:45:18", updated_at: "2011-09-13 18:53:25">
FYI The user I'm trying to update is the only user created manually via log-in, the others are created as dummy accounts via seeds.rb
I accidentally had an after_save in the User model that was actually causing a validation failure. Thanks #meagar
The title pretty much explains it. I'm having an odd situation where views that allow users to delete notifications using Ajax cause the current_user to be logged out. I don't even know where to begin debugging this...
Here's the controller
class NotificationsController < ApplicationController
def destroy
#notification = Notification.find(params[:id])
#notification.destroy
respond_to do |format|
format.js
end
end
end
This is the entire controller, nothing is abridged. The notifications are generated by the system, so the only action a user can take is to "dismiss" (ie. delete) them.
I also tried this using the newer respond_with syntax and had the same effect.
I'm using Devise, and Rails 3.0.9. Any idea what could be going on -- or suggestions on how to debug??
-- EDIT 1 --
Routes.rb
resources :notifications, :only => [:destroy]
Delete link
%span.delete= link_to( 'dismiss', notification_path(notification), :method => :delete, :remote => true )
-- EDIT 2 --
Well, I noticed something new in the logs -- see **** below.
Started DELETE "/notifications/10" for 127.0.0.1 at 2011-06-21 21:47:15 -0500
Processing by NotificationsController#destroy as JS
Parameters: {"id"=>"10"}
SQL (0.4ms) SELECT name
FROM sqlite_master
WHERE type = 'table' AND NOT name = 'sqlite_sequence'
SQL (0.3ms) SELECT name
FROM sqlite_master
WHERE type = 'table' AND NOT name = 'sqlite_sequence'
User Load (0.7ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
Slug Load (0.4ms) SELECT "slugs".* FROM "slugs" WHERE ("slugs".sluggable_id = 1 AND "slugs".sluggable_type = 'User') ORDER BY id DESC LIMIT 1
****AREL (0.3ms) UPDATE "users" SET "remember_token" = NULL, "remember_created_at" = NULL, "updated_at" = '2011-06-22 02:47:15.913839', "preferences" = '---
:email_notifications: ''true''
' WHERE "users"."id" = 1
Notification Load (0.2ms) SELECT "notifications".* FROM "notifications" WHERE "notifications"."id" = 10 LIMIT 1
User Load (1.0ms) SELECT "users".* FROM "users" WHERE "users"."id" = 1 LIMIT 1
AREL (0.3ms) UPDATE "users" SET "notifications_count" = COALESCE("notifications_count", 0) - 1 WHERE "users"."id" = 1
AREL (0.1ms) DELETE FROM "notifications" WHERE "notifications"."id" = 10
Rendered notifications/destroy.js.erb (0.7ms)
Completed 200 OK in 6416ms (Views: 9.6ms | ActiveRecord: 4.1ms)
So, there it is, it looks like part of the users table is getting set to null, particularly the remember_token which I suspect is triggering Devise to end the session, or maybe this is done by Devise after the session is destroyed. But how do I track that down?
The only thing I can think of that causes notifications to interact with Users is there's a counter_cache on Users for notifications_count.
I appreciate thoughts and suggestions on how to debug!
-- EDIT 3 --
After digging with ruby-debug it looks like the issue is related to Devise and changes to the rails.js script. See:
https://github.com/plataformatec/devise/issues/913
https://github.com/ryanb/cancan/issues/280
I'm trying out some of the suggestions on those threads and will post if I find a solution.
I had a similar problem. Solution was as simple as adding
<%= csrf_meta_tag %>
to the layout.
It turns out this had to do with changes to the Rails jQuery UJS driver and Devise. I had updated Devise without updating jQuery UJS -- and Devise was expecting the CSRF token to be handled differently, so it was processing the ajax request as unauthorized which meant destroying the current user's session. Upgrading to the latest jQuery Rails driver fixed the problem.
Are you sure this controller and action are the ones that are triggered by the request? It sounds like the path you are DELETEing isnt right and you are hitting your sessions path instead.
Is it possible that the destroy notification path is redirecting to the session destroy path through JS?
Do you have destroy.js template in your notifications views? try adding one that is empty see if you get a different result.