These new methods will allow users to query and update badges via the API.
Badges already uses EditEngine and SearchEngine in a modern way, so they should largely be simple to implement. You can look at PasteSearchConduitAPIMethod and PasteEditConduitAPIMethod for examples.
After implementing the API method classes, the method should appear in the web UI in the Conduit application, and be callable from the web UI console.
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | lpriestley | T6526 Implement "Badges" or "Medals", for annotating special users | ||
| Resolved | chad | T10671 Implement `badges.search` and `badges.edit` Conduit API methods |
Is there a reason, other than scope, why we're not implementing a badges.create Conduit API method? Or any of the other ones?
The new *.edit endpoints can both create and edit, so a badges.create method would be redundant.
The badges.edit endpoint will also be able to award/revoke badges (with a little work), so we don't need separate endpoints for that.
The new *.search endpoints are also strictly more powerful than many older endpoint types.
So most of the answer is probably "we don't need it, since edit/search can do it now". Were you thinking of anything in particular other than create?
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.
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.
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.
D15622#180612 has more discussion.
You can award and revoke badges from conduit, though we may build a more robust award api later.