Creating Point Rules Outside of Controllers about merit HOT 11 CLOSED

As points are just an integer, what I do is define an observer which updates de points field directly. I don't see a reason to define an API for that, as we are not saving history on that field yet; Merit treats it as a simple integer change.

When we need more logic than the provided "visited this action", we change that value inside controller actions.

Would this fit your needs?

from merit.

Updating points directly was my alternative. It does spread the point logic out from a place where it's held nice and tidy tight now.

The history is another feature we are considering adding. We typically show our points history as a spark line, and are considering some type of point snapshot every time points change along with some daily aggregation and sparse data population.

Another feature we're needing is recording points in specific skills (e.g. strength, dexterity, charisma, etc).

We were planning on building our own pointing and badging, but found Merit and loved it's simplicity. I don't know if bloating Merit with our additions is desirable. We may end up with our own anyway, but Merit looks great.

from merit.

Interesting. Saving the history for points granting is definitely desirable. And agree that spreading the reputation logic out is not best.

Points right now are the greenest part of Merit: only one attribute, no history, kind of too simple. I don't think it would be bad to add some logic to it.

Right now I'm merging a little fix for allowing different point rules on same controller actions. I have a project which would benefit from having split points (as "normal" user and as other type of users), so I'm open to suggestions. Thanks for your feedback!

from merit.

Great! We'll look at adding them to Merit first.

from merit.

Our first thought was a polymorphic Point model that would be would be an

from merit.

Yes, makes sense. So, a User has_many Points (or better name).

And we would need a PointsLog model for logging these kinds of changes. We'll also need a method for adding points to a meritable resource ("User").

from merit.

Woops. Prematurely hit send there.

Yea. A user has many points/score/award. Each point can have a value, timestamp, category (e.g. strength, charisma), a target maybe (e.g. the post that earned the points) and maybe an action (e.g. edited, approved). That was our thought, but, as usual, I don't know if we're overcomplicating things.

from merit.

Scores is a good model name, and inside of scores we have category, points (the final computed value) and sash_id ("target", no need of polymorphism thanks to that intermediary object).

The Score#points attribute builds from PointsLog, which holds score_id, points and description string (have to define a nice way of logging yet, so we get the action, source, etc).

I'm also thinking out loud, but this should serve as a rather good foundation.

from merit.

@MarkBorcherding, just reviewed all your commits. I just cherry-picked a nice refactoring. What I saw is that through AwardedPoint (which I'll call Score) you were able to handle different categories, but not history.

My sketch adds the PointsLog for logging everything related to that attribute, pretty important for recomputing rules if they are adjusted, and monitoring changes and how do points move in the system.

So I'll start this changeset in the opposite direction: will get running both new models, focus on the PointLog functionality, ignore for now Score#category string attribute, and then make categories work.

Are you using your fork/branch in an app, so we can test? My goal is to do some plumbing but not change the API whenever possible. Thanks!

from merit.

Unfortunately, the project we were planning to use Merit on got stalled, and still hasn't picked up. I wouldn't worry about perserving any API I created. We aren't using it anywhere and once we pick back up on it, we can just adapt what we have then.

from merit.

Just released merit version 1.0.0.

• About points on models, with callbacks it will work, check the new add_points and substract_points methods.
• Points history is done. From a meritable resource, check it's scores, and inside of it the point entries, that's the history from where we compute user#points, which is now an SQL SUM instead of an attribute. More info in https://github.com/tute/merit/wiki.
• Recording points in specific skills will come out almost automatically from scores indirection, not yet done though. As this issue is becoming a little cluttered, I'll close it; we may open a new one with Merit::Score#category testing and implementation if you need it.

Thanks for your feedback and help!

from merit.