One user, single badge multiple time

Hmm, interesting concept.

I would love to see something similar to this as well. Ideas?

+1
Side note - Do It With Drupal version of stackoverflow - http://www.array-shift.com/ (no badges)
I remember a comment about the userbadges module in this video http://www.doitwithdrupal.com/2009/sessions/stack-overflow

I'm starting to think that badges would be much more flexible and customized if assigned to users as nodes using cck and userreferences, or assign users as the authors of the badge nodes. These sorts of features would be easily implemented. Just assign a node with the same title/image to the person several times. Or you could use taxonomy for the different badges. Haven't quite figured out the best approach.

I saw a post by another user on drupal.org using badges as nodes, or something like this Node badges module may work if ported to Drupal 6 - http://drupal.org/project/node_badges.

The Node Badges module looks like it assigns badges to the nodes themselves ("most read", "featured") rather than users. The upgrade from 5.x to 6.x wasn't all that hard, and the Coder module will catch 95% of the changes, so go ahead and update it.

I think we can do the multiple assignments simply by adding a counter to the user_badges_users table and then updating it. It's just a matter of having the time to do it. I'm not sure what to do if a user gets one of those badges via a role, but at least it's a beginning thought.

See also #997730: Question about performance

Subscribing

Subscribing

I think this is a different issue, please open it separately. While your experience is that the two don't play well together, please don't point fingers at either module unless you know for sure which one is truly at fault. There are 1,727 other known users of this module, and you are the first to report such a problem.

The attached patch is more than just the ability for a user to have multiple copies of the same badge. It includes the patched content from #783430 as well as sweeping changes.

The feature is implemented by switching the primary key of the user_badges_user from a combination of bid, uid, and type to an incremented new field called 'ubid'. It also installs an 'earned' field that is a unix timestamp of when the badge was earned.

This patch also includes fundamental changes to the API to accommodate this. user_badges_get_badges returns an array of 'all' or 'select' badges keyed by bid. user_badges_get_user_badges returns a user's badges keyed by ubid, with nolimit and refresh options.

Some changes may also fix or change existing bugs, such as how user_load is now implemented. The helper function _user_badges_limit operates on the statically-cached badges_all (and is reused in user_badges_get_user_badges). Another helper function, _user_badges_bid_in_badges, was made because bid is now a property of badges rather than the key.

user_badges_for_user was rolled into user_badges_for_uid.

Support for Tokens, Rules, and Views is also more robust.

The API change could have an effect on modules and themes that rely on the old functions (for instance, User Badges Avatar is susceptible on line 76).