add backend support for Article voting

[ppotoplyak]

@ilanbiala,

Continuation of #537 but for branch 0.4.0 and error code changed to 500.

Tests are coming back clean, let me know if missed or fat fingered anything in the branch 0.4.0 adaptation.

grunt test
<chop>
 User Vote up/down/none on Article Tests:
    ✓ should not be able to vote if not logged in
    ✓ should not be able to vote if direction is invalid (47ms)
    ✓ should be able to vote none and then none on an article if logged in (86ms)
    ✓ should be able to vote none and then up on an article if logged in (50ms)
    ✓ should be able to vote none and then down on an article if logged in (51ms)
    ✓ should be able to vote up and then none on an article if logged in (72ms)
    ✓ should be able to vote up and then up on an article if logged in (52ms)
    ✓ should be able to vote up and then down on an article if logged in (53ms)
    ✓ should be able to vote down and then none on an article if logged in (49ms)
    ✓ should be able to vote down and then up on an article if logged in (69ms)
    ✓ should be able to vote down and then down on an article if logged in (53ms)
<chop>

thanks

[ppotoplyak]

Small fix up pushed to take care of two missing semicolons.

[ilanbiala]

@ppotoplyak is this in any way different other than the error code compared to the other PR?

[ppotoplyak]

@ilanbiala yes, /api prefix added to routes, and user.votes.server.routes.test.js has shorter msgs and has been changed to make it consistent with 0.4.0

[mleanos]

Does this really need to be implemented into the User model? It seems that the most common use case would be to use this voting feature in the context of an Article.

What I mean by this is that the relevancy of the article vote makes more sense when interacting with the actual Article model itself.

If we want to keep track of the User's that have voted, then just track that in the Article model. I'm not a fan of this feature separating the up & down votes. Shouldn't this be a cumulative value?

This is my proposal for the Article model implementation...

votes: [{
    user: {
        type: Schema.ObjectId,
        ref: 'User'
    },
    value: {
        type: Number,
        default: 0
    }        
}]

We could add date fields to this schema as well. What worries me about this pull request is that it seems very specific to one use case, and there's unnecessary updates to the User model, and User server controller. My proposal keeps things simple, and can be modified to meet individual needs.

[rhutchison]

@ppotoplyak I agree with @mleanos's concerns. Can you let us know your thoughts? If I want to use meanjs and remove articles, now I also have to modify the users module.

[lirantal]

@ppotoplyak I tend to agree, would you go ahead and modify?

[lirantal]

@ppotoplyak ping - look into the comments?

[ppotoplyak]

Sorry, had my head down and was not paying attention.

Perhaps this particular implementation is indeed too opinionated and specific to a particular use case. Hopefully, someone with a similar use case will find the PR as a helpful reference.

Please feel free to close the PR.

thanks,
-pavel

[lirantal]

Thanks Pavel.

I'll close this PR then unless @mleanos would like to continue this PR although it's not high priority and is really only nice-to-have feature, definitely not a must for 0.4.0 as a framework.