See some discussion in D13777.

No, there's no overlap.

Would "Role Profiles" solve this, ie, psuedo-admins?

It sounds like we could possibly resolve this by letting you change application edit policies instead, which I intend to do eventually. That said, I don't think adding an enable/disable policy is necessarily unreasonable, and it's generally in the vein of other similar policies.

A couple of things offhand:

What specific administrator abilities are you concerned about them having?

I'd rather not. We have a lot of staff who manage access and most of them I don't want poking around as an admin.

Can you just give more users admin permissions?

(See D13739.)

Fixed in HEAD.

You have been anointed "Bug Meister"

In T8976#128505, @epriestley wrote:

Do we have a "helpful bug report" badge?

I cherry-picked this to stable and upgraded the cluster.

Do we have a "helpful bug report" badge?

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)

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

This was fixed in master, I just missed promoting it to stable since the release schedule has been out of whack recently. Should be fixed now.

Yeah, I'm mostly concerned about future changes (offhand: phone numbers, emails, messenger handles, oncall schedules, events/availability).

If there is a reasonable path forward that @epriestley will approve, I can do the grunt work and close this out.

Philosophically I'm fine making People "public". The main reason for me is that all the information on a Profile is already (in the most common cases) exposed in other "public" areas of the product (like hovercards). I do think though that when an install is public, we should have an additional reminder/note when someone goes to edit their profile as a reminder. With public profiles, I think we also need to be mindful of upcoming apps like oncall schedules, where some information might be actually private (and thus displayed in that individual app, like Calendar can) and not randomly exposed.

Turns out I had a broken support/preamble.php script (or misconfigured nginx, depending how you look at it), which set $_SERVER['REMOTE_ADDR'] to an empty string.

They don't let me program much, so it'll likely delete all your data.

I'll see if I can skeleton out an application here. I don't think it will do much.

I just realized the examples use the WoW rarity scheme ❤️

Hey @chad - badges look HUUUUUGE on what You propose... As for colour - sure pink is not perfect, but it would be even better to colour-code badges. For example:

I don't need this but I want it!

In T6526#125777, @chad wrote:

You mean this: https://secure.phabricator.com/uiexample/view/PHUIBadgeExample/

You mean this: https://secure.phabricator.com/uiexample/view/PHUIBadgeExample/

I always thought it would be cool to reward stuff like:

pink maybe isn't a good choice. i'll tinker

http://www.wowhead.com/guides/vanity-collections/the-entitled-a-guide-to-titles was a lot of my inspiration, haha.

I'm fine trying both and seeing what shakes out in the long run (which may be both).

We could let specific "Important" badges generate a text tag like that but I'd like to be able to, e.g., award everyone who reports a bug a badge for it without turning every timeline into "Reported a Bug" on each comment.

I'd totally brag about my 1,000 commits. :)

Oh, yeah. That huge treatment might be good for "Administrator", "Employee" or object relationships ("Task Owner", "Task Author"), but feels pretty big for the more achivement-like "Made 100 Commits", "Registered for 5 years", "Contributed", things.

I was imagining something like this:

I'm fine slathering hovercards with tons of them, but am worried that more than 1 or 2 would make timeline cluttered. Though maybe you have a magical design for this I'm not able to envision.

I don't want to do project/badge stuff yet, just an explicit "award this badge to this user" thing for now, but imagine maybe doing that in a future version.

My v0 or v-1 pass at this would be pretty basic (and I think like 98.5% aligned with @epriestley)

Thanks for the report!

Looks good ;) Thanks.

Yeah we are on redesign-2015.

isn't that only in the redesign branch?

@ostraaten, see T1731 for general mapping of VCS usernames. This is a much more attractive feature than supporting .mailmap, specifically, given the very limited use of .mailmap.

Related to this issue, take a look at author mapping in Crucible https://confluence.atlassian.com/display/FISHEYE/Changing+your+user+profile#Changingyouruserprofile-AuthorMapping

Awesome! Let us know if you run into anything.

Just upgraded the MemSQL installation and found no issues. Thanks @epriestley!

No, I'm not using auth.email-domains.

Just out of curiosity are you using the "auth.email-domains" feature?

The approval queue is fixed, but it still doesn't log in the new user correctly:

On the second part, the condition for that query was wrong coming out of D13122: noDisabled changed to isDisabled, but the default value didn't get flipped.

See T8455 for a discussion of some issues. There are fixes there awaiting review, but if you're a larger install and/or use a lot of mailing lists, you might want to wait for the dust to settle there.

This migrated cleanly on this install, although we only had one real mailing list plus a handful of old invalid test lists (although these errored out correctly). If you run into problems with the migration or otherwise, let me know.