Change Details

I think we should deal with this stuff first: - T9010 (may require migrations) - T10798 (limit stuff only, I don't really care about order much -- badges currently won't scale on pages that use `needRecipients()` and/or aren't paginated if a badge is awarded to a large number of recipients) - T10698 - "Flavor text" on "Create Badge" form should be "Flavor Text" (title case) for consistency. - Description on new profile view feels real whitespace-y? Maybe just shove the badge itself into the menu like profiles? But then the page is probably junk on mobile so that's probably terrible. {F2930434} - Mentioning users and uploading files into a badge's description does not properly subscribe the user or attach the File object (this will sort of autofix for free by moving to ModularTransactions). - I can repeatedly award a badge to the same recipients with no UI feedback: {F2930527} - See also the "Award Badge" dialog on the profile page, which curiously says "Grant Badge" instead of "Award" or "Add Recipients": {F2930674} - Fatal error if I create a badge with a name longer than 255 characters (should be a validation error). - Or more than 255 characters of flavor text. - I can award badges to applications, other badges, etc (no validation on recipient PHIDs): {F2930751} - Since creators don't have any durable editing or ownership rights, they probably should not be automatically subscribed (instead, explicitly subscribe them as a side effect of badge creation, like Maniphest)? - The profile panel loads awards twice (once on People query, then again afterward) and does badge status filtering in PHP. The hovercard does a slightly better job of this. - The timeline view does PHP-side filtering again, though. - Since the timeline view doesn't even use needBadges on the People query, can we get rid of it so this feature isn't totally tied to the core? - The "Qualities" constraint in `badges.search` accepts numeric strings like "102". Maybe just drop this constraint from Conduit? I don't really love how badge qualities work internally, and if we hide them we don't have to fix this yet. - Revoking badges from the "View Recipients" screen takes the user back to the "View Badge" screen, but should probably stay on "View Recipients". - Cancel action (if you open-in-new-tab) also goes to "View Badge". - "Add Recipients" always cancels to "View Recipients", but could be invoked from either "View Badge" or "View Recipients" (probably not worth fixing). - NUX text on search uses the word "instance", but I think we use the word "install" to describe "your install" elsewhere, vs "an instance (on Phacility)". {F2931053} - Feed story for quality level changes doesn't list the actual change: {F2931094} - Mail sends with subject lines like "[Badge] [Updated] Badge 6", and does not list the name of the badge. - Mail includes "BADGE DESCRIPTION" section in every message about a badge with a description. Particularly, edits to the badge description have the edit and then the description. The description should only be included in the initial creation mail, like Maniphest: {F2931241}

I think we should deal with this stuff first: - T9010 (may require migrations) - T10798 (limit stuff only, I don't really care about order much -- badges currently won't scale on pages that use `needRecipients()` and/or aren't paginated if a badge is awarded to a large number of recipients) - T10698 - I can repeatedly award a badge to the same recipients with no UI feedback: {F2930527} - The timeline view does PHP-side filtering again, though. - Since the timeline view doesn't even use needBadges on the People query, can we get rid of it so this feature isn't totally tied to the core? - The "Qualities" constraint in `badges.search` accepts numeric strings like "102". Maybe just drop this constraint from Conduit? I don't really love how badge qualities work internally, and if we hide them we don't have to fix this yet. {F2931053} - Mail sends with subject lines like "[Badge] [Updated] Badge 6", and does not list the name of the badge. - Mail includes "BADGE DESCRIPTION" section in every message about a badge with a description. Particularly, edits to the badge description have the edit and then the description. The description should only be included in the initial creation mail, like Maniphest: {F2931241}

I think we should deal with this stuff first: - T9010 (may require migrations) - T10798 (limit stuff only, I don't really care about order much -- badges currently won't scale on pages that use `needRecipients()` and/or aren't paginated if a badge is awarded to a large number of recipients) - T10698 - "Flavor text" on "Create Badge" form should be "Flavor Text" (title case) for consistency. - Description on new profile view feels real whitespace-y? Maybe just shove the badge itself into the menu like profiles? But then the page is probably junk on mobile so that's probably terrible. {F2930434} - Mentioning users and uploading files into a badge's description does not properly subscribe the user or attach the File object (this will sort of autofix for free by moving to ModularTransactions). - I can repeatedly award a badge to the same recipients with no UI feedback: {F2930527} - See also the "Award Badge" dialog on the profile page, which curiously says "Grant Badge" instead of "Award" or "Add Recipients": {F2930674} - Fatal error if I create a badge with a name longer than 255 characters (should be a validation error). - Or more than 255 characters of flavor text. - I can award badges to applications, other badges, etc (no validation on recipient PHIDs): {F2930751} - Since creators don't have any durable editing or ownership rights, they probably should not be automatically subscribed (instead, explicitly subscribe them as a side effect of badge creation, like Maniphest)? - The profile panel loads awards twice (once on People query, then again afterward) and does badge status filtering in PHP. The hovercard does a slightly better job of this. - The timeline view does PHP-side filtering again, though. - Since the timeline view doesn't even use needBadges on the People query, can we get rid of it so this feature isn't totally tied to the core? - The "Qualities" constraint in `badges.search` accepts numeric strings like "102". Maybe just drop this constraint from Conduit? I don't really love how badge qualities work internally, and if we hide them we don't have to fix this yet. - Revoking badges from the "View Recipients" screen takes the user back to the "View Badge" screen, but should probably stay on "View Recipients". - Cancel action (if you open-in-new-tab) also goes to "View Badge". - "Add Recipients" always cancels to "View Recipients", but could be invoked from either "View Badge" or "View Recipients" (probably not worth fixing). - NUX text on search uses the word "instance", but I think we use the word "install" to describe "your install" elsewhere, vs "an instance (on Phacility)". {F2931053} - Feed story for quality level changes doesn't list the actual change: {F2931094} - Mail sends with subject lines like "[Badge] [Updated] Badge 6", and does not list the name of the badge. - Mail includes "BADGE DESCRIPTION" section in every message about a badge with a description. Particularly, edits to the badge description have the edit and then the description. The description should only be included in the initial creation mail, like Maniphest: {F2931241}