You can award and revoke badges from conduit, though we may build a more robust award api later.
Mar 24 2017
Mar 16 2017
Mar 15 2017
Mar 11 2017
Mar 9 2017
I'll send you some kind of something-or-other for dropping "Quality" from Conduit for the moment.
Mar 8 2017
Do you have a rough suggestion on what to do with badges.search? Seems like noone would use these feature regardless.
... and then there was one ...
Mar 6 2017
Mar 3 2017
Mar 2 2017
Feb 27 2017
After D17422, I used bin/lipsum to generate about 20,000 badges. (They all have USERS permission so the permission checks are about as fast as possible.)
Feb 24 2017
Feb 23 2017
Feb 21 2017
Feb 15 2017
I'm just trying to understand the feedback. There are points that come very close to "redesign badges" to which I'm like years away from doing, if ever.
I'm fine with just declining to implement that, it just seems like something we should fix if we're calling it a bug.
Why do we need T10698 specifically? Seems overkill.
Darn race condition.
Looks like search and edit are implemented, but not awards. Awarding a badge through conduit seems nice to have? but I don't see any requests for it, so not sure it's worth holding up unbeta.
This has been implemented and in use for a while, so closing and will finish up smaller tasks in backlog.
Aug 7 2016
Aug 5 2016
Jul 4 2016
Jun 26 2016
That data doesn't exist unfortunately, so it wasn't able to be migrated. You shouldn't see that on current badge awards.
I've got this on most of my Badges on the profile page (not here, 2 local Phabricator installations):
Jun 17 2016
Apr 15 2016
Apr 13 2016
Apr 12 2016
Apr 11 2016
Apr 9 2016
Apr 8 2016
That's my expectation too -- the user cycles their "2012 Hackathon Winner" badge out for "2013 Easter Egg Finder" once they get bored of it, so badges are always fresh and lookin' fly.
I expect every user to have millions of participation badges. Yet they'll have to select just two to prominently display.
I'm struggling with how to think about the 'temporal' nature of some peer awards that might fit badges. For example, I'd like to give the team that won the popular vote at a hackathon, but it would not feel so special if after a year "everyone" had an Epic badge displayed all the time. I'm thinking more "you get celebrated for a month" and less "list of all the typos I found 3 year ago".
Apr 7 2016
Apr 5 2016
I expect two more diffs for this task: one for awarding/revoking badges in the badges.edit API call, and one for querying who awarded whom.
Apr 4 2016
Yeah, I was pondering the award/revoke flow. PasteEditConduitAPIMethod is so bare bones as an example, and PhabricatorBadgesEditEngine is so different from other edit engines... I'm just not sure how that will hook into the badges edit API method.
The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.
Is there a reason, other than scope, why we're not implementing a badges.create Conduit API method? Or any of the other ones?
Apr 3 2016
What's left is adding Awarded by ... to recipient list on badge view:
Apr 2 2016
Apr 1 2016
No, badges themselves don't have an awarder.
We currently track awarderPHID in the badges_award table. Do we still need an awarderPHID in badges_badge table?
Too many deck slots, product literally unplayable.
Wait are they not Blizzard colors any more? My team can't handle using different colors from WoW and Diablo III and will find this feature too confusing if they have to learn about ponies too. Phabricator is ruined forever.