"Close" makes sense to me. And, yeah, I agree that long-term some kind of "All Badges" link that leads to, like:

I wouldn't mind having these somewhere on profile though, even it it's hidden by an "all badges" link or something.

Yeah, I sort of wonder "beta" wise if we should add the ability to "Close" a badge, which essentially locks it from (easily) adding new members. So a temporary badge like "Attended First Meetup" gets assigned out to 10 people, then closed & locked. Those could still show. "Archive" is still essentially in my mind, "delete from the UI".

If you know you had three badges yesterday and then visit your profile and see only two badges, there's no way to figure out what happened (without examining the edit history of every badge), if we completely hide them, is there?

I'll probably kill them everywhere, since you can dig them up in ApplicationSearch in Badges if you're really curious.

First approaches that come to mind, for whatever that's worth:

Awesome, will do!

(We maintain a vulnerability program with HackerOne, but this specific issue is pretty fluff and in a prototype application so I don't think it meets the minimum bar for a vulnerability award ("significantly compromise ... typical installation"). Feel free to file through HackerOne if you hit anything security-esque and more substantive in the future, though.)

Thanks for the report! This should be resolved in HEAD and deployed to this server.

Do it have notifications or hook for email or slack?

I don't remember the last edge -> object conversion we did, I don't think we've done one for a while.

Thanks, good explanation.

Edges have a data field, but you can't put keys on any of the data since it's just stored as a JSON blob. For example, it would be possible to store an awarderPHID in the data, but then as soon as you want to show a view of "all badges given by epriestley to other users" you can't query by it (since you'd have to load every edge, then deserialize all their JSON data, then look through it).

Feel free to ignore me if you don't have the time to explain, but what's the difference between an edge and an object. More specifically, why do we want badges to be objects rather than edges?

Maybe I'll take a shot at this before T9132 starts rolling out since that will probably involve touching every /edit/ route in every application, much like we previously replaced every /query/ route for ApplicationSearch.

I've historically thought about this mostly from the point of view of having the $object reach up to the $application and get URIs from it -- since the Application defines the routes -- but maybe that's not really the right way to tackle it, especially since it's hard to generate URIs from routes but relatively easy to generate routes from URIs.

getApplicationURI() only solves this for the first part of the path (although that happens to be the issue here), and isn't available inside the Editor where mail is being constructed. One thing we could do is throw if URIs passed to getApplicationURI() don't route when in development mode, although that doesn't feel amazing.

From memory, that just gets the /badges/ part of the URL? I'm talking about this (I'm on the train so excuse the pseudo-code):

getApplicationURI is available in most (all?) applications I believe

I've seen a bunch of cases where dead URLs have persisted for a while before being caught... Have you given any thought to improving the way that we handle URLs? I feel like there should be some getUrl() method for most (all?) objects.

@epriestley is there any edge->object conversions I can crib notes from. I presume I can read out each Badge, loop through recipients, then write out a new "Award" object.

@epriestley: I would also like to tag "internal" users (who are all in one Project), because they also have elevated rights compared to "external collaborators". Or alternatively tag "external users", which in the end has the same effect (T9162).

Badges is a prototype application:

I think projects/badges are a better approach for this.

Do you want this capability in general, or all your intended use cases also account attributes (e.g., administrators)?

Another solution to the mentioned use case would be to automatically put users into Projects (T3980 or external scripts until that is implemented) and then award Badges based on Projects (T9163).

Very unlikely to pursue this because:

Im so sad this is closed ...

I would imagine either a type ahead or a text box to enter the name of an icon that isn't one of the standard 16.

This IS kinda reasonable, but imagine browsing icons for match when creating badges... not only are there ~6 levels of badge awesomnes, there would be hundreds of icons to choose from...

is even better for the fire fighting badge :3

I mean, just look at how pretty these are with their icons (I set these via SQL updates):

It'd be nice to also have a note as to why the badge was awarded (and not just who awarded it + date)

In T6526#128262, @eadler wrote:

• Another use case: in certain cases badges directly map to projects ("member of admin team" ~= "phacility high command" or "trusted contribute" ~= "trusted contributor" project)

aww

Yeah, I understand. I think the feeling for us is we have to draw a "support" line somewhere, and not providing support for prototypes reduces our load quite a bit. We want to build, test, experiment, but not maintain production perfection.

Yes, I've seen that link. I was just letting you know since it seemed like it was in active development right now.

Badges is a prototype application, and in general we prefer not to provide support for these. Mostly because prototypes are in developement and incomplete.

A few pieces of feedback:

• It would be really nice to be able to split "being able to award this badge" and "being able to edit this badge". You've already said that this isn't something that you're likely to consider but I wanted to mention it here
• Another use case: in certain cases badges directly map to projects ("member of admin team" ~= "phacility high command" or "trusted contribute" ~= "trusted contributor" project)
• It would be nice to be able to "bind badges to external things": for example: we've already had requests for "submitted the most diffs" or "closed the most tasks"
• There is no way to go from a user's pokemon center to the list of other users with the badge. Clicking on it just flips it over.
• The mini-badges don't show up when posting inline comments only or when updating a diff: see this for example: https://www.dropbox.com/s/zu97klycfzb7jtf/Screenshot%202015-07-25%2013.13.36.png?dl=0

T6526 will stay open for general feedback though.

Not likely a use case we'll pursue. "Badges" as a prototype is about 90% done, I'm just fixing some loose ends and that'll be it likely for several years.

I think they could probably be like 1/2 or 1/3 the size they currently are and still get the point across, maybe.

I agree. Seems too big. personal opinion

(when it compresses multiple actions, i think)

yeah some bugs, idk

maybe 4/5

1/3, really?

I think they could probably be like 1/2 or 1/3 the size they currently are and still get the point across, maybe.

they certainly contribute to the flavor of the project.