Thanks @epriestley, I was reading this earlier today. Appreciate you putting together a migration guide. :)

@carlsverre, this probably impacts you, too.

"Available" means "not in a meeting", which he isn't.

What is your expectation here? We don't makes object disappear just because a person is disabled.

I rolled this into D13122.

fwiw, as expected, this is an issue on prod

D13024 fixes this for Owners.

I wouldn't plan for this to supersede the grey "disabled" dot or the red "away" dot in the general case (those show up in a lot of contexts where badges won't) but it would be reasonable to consider showing a special automatic "Disabled" or "Away" badge in timelines, like the proposed "Admin" badge.

• I assume this would also supersede how disabled user accounts are currently displayed ("handle-disabled" CSS adding a black bullet in front of user name). Not mentioned in the task summary; just pointing out for completeness.
• I assume this would also be the way to go to indicate new Phabricator users (e.g. dateCreated within last 60 days) to be treated even friendlier / with more patience? Mozilla's Bugzilla has such a visual indicator. See their background discussions why this could be useful in communities, but could also discriminate new users.

This looks like a recent regression, at least, it works in the redesign branch.

Should be fixed in HEAD. Thanks for the report!

In T4830#74187, @epriestley wrote:

(@btrahan, you're the only repro I have, so don't change your profile picture!)

Closing for lack of feedback; this request doesn't describe a problem.

We have a user_transaction table but I don't think we expose it anywhere in the UI and I'm not sure how much stuff gets dumped into it. We should record important account-related events there (creation, username changes, admin/un-admin, etc).

In T8044#111257, @eadler wrote:

I want to be able to see every user that has access to my phabricator install.

I want to be able to see every user that has access to my phabricator install. Ideally I'd like to be able to see all non-bot non-disabled users specifically.

What problem are you trying to solve?

I just tried to repro on a clean firefox profile and was unable to do so. Its either an edge case or something in my environment. Sorry for the noise.

I can't reproduce it either, including on Firefox/OSX.

I can't find any way to reproduce it. @epriestley?

It is fully reproducible for every user for me, including for myself.

I can't reproduce this, I get the correct response:

I'm going to merge this into the general 'work through a bunch of stuff' task, which we should generalize to many different applications, including with this task, People

This particular issue is something I'm running into on the test install, before enabling it in production.

Are these tasks for a real instance or a test instance? That is, are these theoretical issues or "omg i hate doing this every day" issues against a production install?

A big banner is totally fine by me. I just proposed an action menu item since it seems simpler.

I'd rather, UI-wise, have a big banner at the top of the user, with a button to just approve them. It seems like if a user in unapproved, that's the quickest solution, and it's then easier to find than picking out a link in the action menu.

So there are two workflows which are annnoying, and one general UI issue.

I don't personally want to add additional action links unless absolutely needed, it devalues the links that already exist there and if we can find another way to link to admin actions, I'd prefer to do that.

(posted just as memorabilia; no need to implement this) :)

Why not both? badges awarded manually for annotating special users + badges given automagically for gamification. Second part would propably depend on being able to write herald rules like "If commiter has 100 accepted revisions, award 'No Longer a Peasant' badge" ;-)

When I first read the title of this ticket, I thought that you were going to add gamification.

They could, yeah. We'd probably need a "List all users with badge X" UI to avoid losing functionality, but that seems pretty reasonable.

Could badges be used for policies? For example, Blessed Committers could be replaced with a badge potentially. This would (at least partially) solve T5602.

Yep. I personally intend to create hundreds of badges to award myself once this is built.

Can a single user be awarded several badges?

Here's a rough sketch of this. This is a ton of work and should be split into like 300 revisions. See T6526#107028 for product details.

If a user joins the Policy project here and by doing this they get a "Member" badge for free

Ok. I hope my feedback helps you somehow to improve the Calendar after prototype.

Sorry, meant to complete that sentence. Isn't a good fit since where Calendar may be after the prototype will likely be dramatically different than it is today.

You can create a Calendar Event from the Quick Create Menu (+ in the header) on any page. This task isn't a good fit for Calendar.

I would say my report classifies as a Use Case, in addition to indicating General Interest…

Sorry, we don't accept feature requests for prototype applications like Calendar. This document explains prototype applications and why we don't accept feature requests for them in more detail:

I think we're nearly consistent about that, although @joshuaspence caught at least a few other cases where we're missing the disabled style and there are probably a few cases that are arguable or ambiguous (for instance, user creation is no longer necessarily admin-only, it's just admin-only by default and at-most-admin-only in all reasonable setups we're aware of in the wild).

I probably have a slight preference for:

In a lot of cases, a user will have permission on some objects but not on others. For example, you can often "Edit Project" on some projects, but not on others. In these cases, the intended behavior is to always to show the action, but show it with a disabled style if it isn't available on that particular object. This makes the UI more consistent (the same actions are always available, and the actions are always in the same positions) and more discoverable (you can see that the action is available) and more comprehensible (you can click the action to figure out why you aren't allowed to take it).

It just seems inconsistent to sometimes hide the button and show a grayed-out button in other places.

... and in any case there are many instances where we don't show users what they don't have permissions to do anything with. I think this approach is correct, since it shows simpler and cleaner UIs to the majority of new/plain users.

We don't intend to pursue this direction with crumbs, most create actions will get moved elsewhere.

Specifically, PhabricatorPeopleListController has this code:

It's in the "Quick Create" menu... Lemme look into it.

I guess we can remove the TODO comment then?