medihack/make_voteable

[Unmaintained] User-centric voting system for Rails 3 applications

make_voteable's Issues

Typo in README

There's a typo in the README, it should be
rake db:migrate

instead of
rails db:migrate

Best regards,
Fabian

Total votes cached count

Should make_voteable models have a cached count for the voteable record, in addition to up_votes and down_votes? Right now, it seems there's no easy way to order records by total votes, only up_votes and down_votes.

For example, you'd add this to your database columns:

add_column :comments, :votes, :integer, :default => 0    

up_votes - down_votes would then be stored in in this attribute whenever up_vote or down_vote are called.

Cron job breaking votes?

I'm facing a very strange bug. Actually I'm not even sure it's related to make_voteable. Also, I'm not sure this is the appropriate place to discuss this, so feel free to close/delete/ignore the thread as you see fit. I just ran out of options and can't figure out what's going on.

My application has Projects. Projects have statuses. They start as "Developing" and after the set development deadline is reached, they change to "Pending voting", when users can vote them up or down (until the voting deadline is reached) to prioritize them.

So if the status == "Pending voting", the views show links to the following actions on my projects controller (PUT):

def vote_yes
  @project = Project.find(params[:id])
  current_user.up_vote(@project)
  flash[:success] = 'Thanks for voting!'
  redirect_to @project
rescue MakeVoteable::Exceptions::AlreadyVotedError
  flash[:error] = 'You already voted!'
  redirect_to @project
end

def vote_no
  @project = Project.find(params[:id])
  current_user.down_vote(@project)
  flash[:success] = 'Thanks for voting!'
  redirect_to @project
rescue MakeVoteable::Exceptions::AlreadyVotedError
  flash[:error] = 'You already voted!'
  redirect_to @project
end

Everything works great if I update the deadline/status/voting deadline through the terminal. Voting works as expected.

However (and here comes the bug after the long intro...) if I run the cron job I setup to take care of this, the views render the voting links, users can click as usual, but no vote is stored on the projects table. The votings table, however, gets populated normally and the user is not able to vote again.

The only thing the cron job does is run this bit of code from the Project model:

def self.close_projects
  @finished_projects = Project.where('deadline < ? and status = ?', Time.now.utc, "Developing")
  @finished_projects.each do | project |
    project.update_attribute(:status, "Pending voting")
    project.update_attribute(:voting_deadline, Time.now.utc + 1.week )
  end
end

Just an observation: I ran a migration to add the voting_deadline column to the Project table after running the migration that added the up/down_votes to the same model. I don't think this should be an issue, but maybe it's worth noticing.

New release for rails 4

I notice that rails 4.0 is already supported in 'master' branch, but not release it as a gem.

could you please release a gem?

update gem to support rails 3.1

I notice that rails 3.1 is already supported in 'master' branch, but not release it as a gem.

could you please release a gem?

Bang conventions

Just curious -- what was the logic behind the bang methods being the safe methods and the non-bang methods being the ones that raise errors?

Voter type being incorrectly set for extended classes on up / down vote

Let say we have User that inherits from ActiveRecord::Base and Admin that inherits from User. The User is a voter (make_voter). Creating an up / down vote for an instance of User works great. However, an up / down vote for an instance of Admin will incorrectly set the voter_type to "User". To compound issues, #up_voted? / #down_voted? check against a voter_type of "Admin" for Admin instances, so a voteable item that has been voted on will incorrectly report that you have not yet voted on the item in question. With this check failing, you could incorrectly display voting controls in your UI, which will raise an AlreadyVotedError if implemented against #up_vote / #down_vote.

Failing test: jeffreyiacono@2d4aa11

up_voted? does not work for STI instances.

class Post < ActiveRecord::Base
attr_accessible :type
end

class Link < Post
end

irb(main):012:0> User.first.up_vote! Link.first
INSERT INTO votings (created_at, up_vote, updated_at, voteable_id, voteable_type, voter_id, voter_type) VALUES ('2012-10-14 07:15:41', 1, '2012-10-14 07:15:41', 62, 'Post', 1, 'User')

irb(main):013:0> User.first.up_voted? Link.first
MakeVoteable::Voting Load (0.3ms) SELECT votings.* FROM votings WHERE votings.voteable_type = 'Link' AND votings.voteable_id = 62 AND votings.voter_type = 'User' AND votings.voter_id = 1 LIMIT 1
=> false

Rails 3.1 compat

need to update gemfile

Easist way to hook counter caching?

I'm seeking a simple way to hook counter caching. Any guide on how to do it?

Batch retrieval of votes

nice plugin! :)

Is there a batch retrieval for a list of IDs of a Votable planned? Else I would try to add it myself.

voteable.save fails for more complex models

I have a model which has some more complicated operations in before_save filter (parsing virtual attributes, finding or creating 2 associated models etc). When make_votable uses votable.save in vote actions my objects corrupted. The only change this save operation performs is incrementing or decrementing the count. Isn't it possible to do some kind of update on only this field instead of whole save with validation operation. This would also lead to better performance.