Page MenuHomePhabricator

Bring MenuItem customization options to User Profiles
Closed, WontfixPublic

Description

ProfileMenuItem is robust enough we could look at allowing administrators to customize user profile links to other applications, though this is probably blocked by allowing MenuItems to be dynamic based on the Object (also potentially needed for Projects). Once we have that though, this should be trivial to support.

Original Request

Sometime in the past year, the link to Revisions was removed from the left side of a user's profile page. I tried looking for a relevant task or changelog but was unsuccessful.


As a user of an install with a many to one ratio of commits to diffs (most done automatically in other random repos), the commits link isn't very useful to me. Most of the time I'm looking for context given in the diff itself during review. I know it's possible to just search the user in differential advanced search, but I'd really like that link back or context as to why it was removed :(

Thanks!

Event Timeline

What is the root problem you are looking to solve? See Contributing Feature Requests and Describing Root Problems.

Or more specifically, I don't intend to add this back without spending more time thinking about the problem it solves. There are other possible solutions (including allowing installations to customize a user's sidebar) but in the context of doing a code review, I can't think of any benefit here. It's helpful for us to understand the entire problem you're looking to solve. If knowing a user's current revisions is important in the context of performing another code review, we'd like to know what that information is and why. What information do you get from it, and what decisions do you make differently because of it.

Sure, apologies for the lack of clarity.

I want to see what a user is working on/has recently landed, and the previous (like up to a year+ ago) view with an unbucketed list of the user's revisions sorted by time was helpful (example). In larger installations, seeing where a user has been making diffs is useful for a variety of purposes, not just during code review, mainly to understand what they actually do for their job or where they have been working recently. Or in the other case, when someone messages you via an external chat client and asks you to review their code that they haven't added you on, it was pretty quick to go to that user's Differential page and take a look.

I guess the root issue is that in our installation, the Commits log linked on the user page is an absolute mess, since there are several repos that are automatically committed into at seemingly random times, which causes the page to be totally out of order and a total mess. Here's an example of my commits page screencapped just now, noted that I have never directly contributed to repos 1 or 2. (note timestamps too)

I'll take a look at the commits bug here shortly. Do you expect your install to keep more up to date?

I believe there are plans to update it more than once a year at least

If you just updated after more than a year, you are probably seeing imports from the change in T6878. Once those finish, things will settle down and "commits" will begin reflecting what you expect.

Specifically, we previously did not import commits which were only reachable from a tag or ref. We now do. I would guess that all of those surprising commits are reachable only from tags or refs, and not from branch heads.

For ordering purposes (sorting, feed), we don't back-date commits because this would allow an attacker to hide activity by backdating it to a year ago (you can freely mutate the commit and author dates in Git) and possibly escape notice.

That is, we order things by discovery date (when we learned about the existence of the commit), which is tamper-proof, rather than author date or committer date, which are freely mutable by the client.

See also D16456 for commits from 40,000 A.D and D17136 for commits with no timestamp information at all.

(Commit-date ordering would also mean that forward-dated commits would be stuck to the top forever.)

Interesting, that decision makes sense to me.

I guess the other cause of commits being a mess is shadow repos that exist on our install that are automatically committed to at a later date. Contrived example, every friday at 10pm all of your commits are committed into rRepoShadow automatically. These do show up in the commits window, which makes sense, but still aren't very useful for someone just looking for the most recent activity of the user itself.

In the case of a workflow or automated setup where one diff can cause multiple commits at a later date for whatever reason, the commits view becomes less useful than the diffs view if you just want to see what a user has been up to recently

Yeah we had both "commits" and "revisions", which had a bit of overlap. My main concern was if you were using this information to learn about a person, actual commits should hold more weight over temporal information like revisions.

Fair point, there was a bit of overlap, and the end result of a revision is super important (the commit).

I find the differential view to be super helpful, since any closed one is approximately equivalent to a commit, but with the revision history attached. External to that I secretly love looking at someone's reaction to code review/feedback.

I guess the final solution to this would be allow customization of that menu. Or was there one specific diff that removed that removed that menuitem?

I don't see a compelling reason to add a link to every Phabricator install for a single user.

We're OK leaving this open to understand impact to other installs or similar needs in customizing user profiles, but to date no other requests have happened.

chad renamed this task from Add link for Revisions back to profile pages to Bring MenuItem customization options to User Profiles.Apr 11 2017, 7:23 PM
chad triaged this task as Low priority.
chad updated the task description. (Show Details)

I'm going to just repurpose this into a general "allow installs to customize user profiles" task to broaden interest.

Awesome, makes total sense to move this towards a customization of user profiles task. Thanks!

neilfitz added a project: Restricted Project.May 30 2017, 8:44 PM
neilfitz added a subscriber: neilfitz.

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.

If it's undesirable to switch the sort order back, would it be possible to, e.g., link a query for the tasks for that user sorted by priority? I think something like that would be massively helpful - sounds like this task as a whole isn't on your immediate roadmap.

Sounds reasonable to just improve that.

Possibly also, add a "See All" link to ApplicationSearch

Thanks! That should be perfect.

epriestley claimed this task.

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.)