It's clear enough to me that higher -> more parental. It might be nice to make T123 not a link and bold, like elsewhere, for easy copy-pasta.

Not a good idea, but an idea:

After looking through real-life applications, this now seems obvious and in @avivey example A is Parent of B. At first glance - there's relation. But yeah, arrows would help, only thing problematic is agreeing on arrow notation.

@avivey Do you have any ideas on how to make that more clear? I'm imagining it will probably be obvious on real data when you know what the tasks are and you'll get used to it pretty quickly, but maybe not.

in first glance, I'm not sure if A depends on B or the other way around:

Affecting Wikimedia as well.

Now it looks pretty and actually first glance tells something :)

Seems kinda good now? Could maybe use some style/layout tweaks on the table (I'd like resolved tasks to be more obvious, for example), but that graph seems like it's actually pretty good/useful to me at first glance. Need to poke around more.

wut

Woooo pretty pictures graph! Can't say I can deduct any task relationship from graph, but nevertheless, it's very pretty!

Looks like I didn't think that one through very well.

I'm pretty tempted to try using the "graph trace" interface to show task graphs. My major concern is that it task dependency graphs tend to be fairly wide and shallow (one task has many dependencies) while commit/revision graphs tend to be narrow and deep (long chains of dependencies). The element isn't as good at showing wide, shallow graphs. If a task has ten subtasks, we'll get a graph like this:

Please see Contributing Feature Requests and Describing Root Problems to better understand what we consider to be valid feature requests. Specifically we need to know the root problem that occurred that prompted this request to begin with. Right now all we have for information is that too much email was sent out during some operation. There might be other solutions depending what exactly happened and why, to solve this core problem.

The concern here, though well intended, is that it circumvents the audit-ability we build into Phabticator on purpose. We don't know why users have requested to receive notifications,

This install now exposes two separate actions in a new submenu, although the backend is only sort of halfway converted. My plan is:

I'd like to have a clearer sense of how we're planning to resolve T10034 before moving forward here, even if we don't actually build any of it yet. Briefly, I think some of the problems here are:

I believe this is resolved and accounted for, let us know if anyone is hitting issues.

I believe this is now fixed and all the business stuff is wrapped up on our side. If anyone runs into issues, feel free to file a followup describing what you're hitting.

I think this is resolved, but see T9028 for related followups.

black-listing phabricator/ sounds good to me :)

D16134 just hard-codes phabricator/ tags as untracked, which should minimize collateral damage.

Yeah, the actual rule D16129 implements is this:

In T6878#180701, @epriestley wrote:

For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future.

"Autoclose" and "Track Only" configurations are limited to branches, and do not account for arbitrary tags/refs. For now, I think we can assume tags are always autoclose/track, but may need to refine this in the future. I'd ideally like to replace autoclose with "fork" (T10691) rather than introducing tag(regexp(...)) or whatever, but that may be a long road.

Current state of the world after D16108 is:

Thanks for testing, that's quite helpful.

In T8510#179818, @epriestley wrote:

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

See also T11134

Some ideas about how to make comments in differential more accessible (after discussion with a member of my team who is blind):

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

It's expected that the ordering in "Browse" is alphabetical/raw, and I don't plan to change that.

Here's what happens when adding wikidata project tag using the comment form typeahead:

After D16088:

This should also fix the mobile workflow stragglers from T2644.

I implemented this, sort of. However, it doesn't work cleanly because transactions are "adjusted" (have old values populated) after they are "expanded" (which generates the @user mention transactions). So when the code runs, it doesn't have access to the old text and can't easily figure out which mentions are new.

This has been live for a while and appears to be working properly. If anyone is still seeing specific, reproducible problems with cache strategies, feel free to file a new issue detailing them.

In T3670#178894, @bhush9 wrote:

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

I am wondering if is it possible to re-parent existing board to some project? I mean if I already have project A and B and I want to make project A subproject of B without breaking links etc.. is it possible?

Here's at least one specific reproduction case which still isn't working well:

From the downstream, it seems like the problem may be one specific user wanting to add mirrors to existing repositories:

It's also vaguely possible that we'll add "suggest an edit" (ala T4104) in a generic way, then untrusted users could suggest edits and trusted users could approve them. I don't currently plan to build this as a general-purpose workflow, though.

Another thing to consider is that your worries may be entirely solved at a social level. Giving people access but reminding them to only modify 'safe' fields. If your users are somewhat trustworthy this is entirely reasonable.

I don't plan to pursue field-level permissions in any application. They were somewhat recently removed from Maniphest in T10003. That task discusses some of the complications that field-level permissions create in the general case.

(I marked D15981 as fixing this but I'm going to leave it open for confirmation since I'm not completely sure there weren't more cases that I missed.)