The repro case is something like:

Its on another page for scalability, we used to just have a single page.

Yep, that would be the page. I was expecting to see details ala "Related Objects" in Maniphest and failed to move my eyes sufficiently left.

This page?

This got a mention in D17499, but when rendering a timeline we currently need two awards for each user who is going to get a full-sized profile image rendered.

I'm going to close this as resolved, added 9 more icons. I'm going to open a new task to allow any IconSet be extended, which seems a better path for any similar product.

• Create a badge.
• Award it to a user.
• Visit their profile page.
• On the profile page, the badge title should link to the badge detail page (currently: no way to get to the badge detail page).

We should get this punted out of prototype status, don't think there is a lot to cover before that. See T11167 if you find additional items.

Isn't Badges a Prototype?

This only affects badges awarded before we began tracking who awarded them. Badges is a prototype application, and I don't think it's worthwhile to maintain code to do something nicer in this case, since the number of affected awards is maybe in the realm of 200 worldwide for all time, of which 80 are on this install.

We should probably substitute in "Unknown Ghost" then.

Looks purposely set to VOID in the migration, maybe this information isn't recoverable historically.

This is fairly messy and probably not worth fixing until the surrounding code is more modernized.

Sorry, Vehicle VIN Identification Numbers.

(It mostly has reference stuff like our vehicle VIN numbers, our PG&E account number and credentials, etc. If you hack it, you can pay our electric bill!)

There is, but we don't use it very much.

Is there an internal Phabricator for the Priestley household where you assign him stuff as well?

I think these steps should reproduce the issue:

How do I reproduce this error?

D15545 should fix the infrastructure part of this, and make this error more clear by returning an explicit diagnostic error rather than a mostly-working string and a log.

Oh, I believe the actual issue is that the translations are variant on the wrong parameter. I think this is the correct fix (adding an extra array()):

D15544 (changing %s to %d) shouldn't be the fix for this -- %s is correct, because we want to render "1,234,567" if the number is large:

Pretty sure I covered all the badge transactions.

It's currently impossible to sort badges by rarity because they rarities are internally 'grey', 'white', 'green', etc., and there is no natural order to these. For example, MySQL has no idea what order 'indigo', 'orange' and 'yellow' should go in, except alphabetical, which is not actually the correct order.

There's a lot of junk in "any icon", maybe 10% of the Font Awesome set is useful. We also don't have a chooser for "any icon", so we'd need to build something as such. I could be wrong but I think since Badges is on EditEngine you could set any icon over Conduit. I don't know if I read Evan's diffs right or not.

Can I get clarification on philosophical opposition to this? Is it leaking abstraction of the "icon" interface to the end user?

• Do T8996 first.
• Add an awarderPHID or similar to the new table and start storing who awarded the badge.
• Render it in the UI somewhere.
• That's good for unbeta, we can add commemorative notes and stuff later. I want to rework the award flow a bit sooner or later anyway.

We want to be able to store metadata about badge awards (like who awarded a badge, when, why, a little commemorative note, etc) but currently can not because they use a very simple storage mechanism (edges). For example, see T8940.

Here's the remaining bug: when a transaction group mixes a comment and another action, badges are not shown, even though we render the profile image in large size and have space to show them. Here's a screenshot of the bug from this task: