Tasks relating to user profiles.
Details
Feb 20 2020
Ah, thanks. Yeah, I think that's reasonable. I'm sure some other things can still be cleaned up -- like I changed the "Subscribers" UI a little bit recently, and it could now handle disabled users more clearly:
IMHO this could be closed as resolved these days.
Mar 31 2019
I think this currently lacks compelling motivations and isn't particularly actionable, so I don't plan to pursue it until new use cases arise. (It's also fully modular already.)
Mar 29 2019
Dec 14 2017
Seriously folks, why make this design decision? I have a user with a long history in my Phabricator install that now cannot get into his account and cannot remember what email address he used to create the account. Under a normal system scenario where I'm Admin, I can just go into his account, tell him which address he used, chastise him for forgetting and not keeping notes and that's it.
May 30 2017
Thanks! That should be perfect.
Possibly also, add a "See All" link to ApplicationSearch
Sounds reasonable to just improve that.
Hey, we're also interested in this by way of T12545 (which was merged in above). A couple of our teams have historically assigned their oncall/tech-debt tasks to a mailing list user, and used the priority-sorted view of those tasks to run their oncall shifts. That workflow no longer works with the reverse-chronological sort.
May 21 2017
May 10 2017
Apr 12 2017
Apr 11 2017
Awesome, makes total sense to move this towards a customization of user profiles task. Thanks!
I'm going to just repurpose this into a general "allow installs to customize user profiles" task to broaden interest.
Mar 21 2017
Feb 23 2017
@chad did another pass on user hovercards and they should be even more clear now (this screenshot doesn't demonstrate it clearly, but we also greyscale the profile photo);
Feb 17 2017
D17374 makes hovercards a little bit more clear too, although that might get some design feedback still (see "Horse" here, for example):
Feb 10 2017
I like. ♥. Thank you a lot!
I think there are some more things worth doing here, but user profiles should be significantly more clear after recent changes. Here's @demo on this install now:
Feb 6 2017
I think I'm just going to remove the "profile picture" text from the description to resolve this. The account.editable option is very old and I'd eventually like to remove it, but making the description more clear is an easier fix for now.
Jan 27 2017
For completeness, the "20 other subscribers" dialog displays disabled users in a different, unique way that isn't like any of the other ways (grey, no dot, no strikethru):
This task does not capture abuse cases. If you'd like us to build anti-abuse tools, please file a separate request describing the abuse you're seeing. See also T10215.
This is what it looks like (note the "role" is completely removed):
This task got cross-referenced with https://phabricator.wikimedia.org/T115579. My impression of the Wikimedia Phabricator task was that we wanted a way for Phabricator admins to be able to edit the title of another user without needing to edit the database contents directly (cf. https://phabricator.wikimedia.org/T115579#2973336). I'm not sure this task captures that request.
Jan 26 2017
🐈
I'm cleaning up Project/Profile UI with the nav changes, I'll just pop a tag in for Roles.
Downstream, @20after4 calls out that mentioning disabled users in comments still subscribes them, as though they were normal users. This behavior would be easy to change, but I could sort of go either way on it.
I think we have some discussion of this somewhere, although I don't immediately recall where and it's not in the obvious places. I might be conflating discussion of the recently-reworked "Available" status.
I'd probably want to fix this at the source, not the Profile Page. I think if you have to get this information from the Profile Page, we've let you down in the UI elsewhere.
Apr 18 2016
Sep 25 2015
I'm just going to merge this into T3278 since I think that covers this completely.
Sep 11 2015
That would be the summary Remarkup engine.
Then may I suggest somehow stripping away the [[ and the urls and only display the links text instead? Just an idea to not have it so cluttery at least, until (if in the future) there will be rendering of stuff there.
This is the expected behavior currently (not rendering out full Remarkup) and blocked on that we don't currently have a good "summary" type Remarkup target (which would be used say in task headers, chat summarys, hovercards, etc) where we only render a subset of Remarkup.