I'm going to close this as non-actionable since it doesn't clearly describe a use case, there's no current customer interest, and it's not clear what problems we'd like to solve that aren't already solved by a stronger "Depends On". The "Depends On" relationship has also become stronger and better integrated since this was originally filed, and it's possible it addresses some or all of the original use cases.

• D20208 adds an authorPHIDs constraint.
• D20209 provides details for transactions which add or remove projects. See above for format and rationale, or just query something and see what pops out.
• D20211 makes the documentation less bare-bones.

A very mild point in favor of this feature is that we haven't seen any negative feedback or confusion, although I think you might be the first user to say they actually like/use it.

I ran a query against a subset of instances to determine if "Mute Notifications" sees any usage whatsover (see T13068):

Currently, project tag changes and subscriber changes don't expose data in "transaction.search" because there's no "obviously correct" way to represent these changes in a future-proof way.

To my surprise, it also seems the method does not output any project tag changes that happened on a task?

We no longer offer support for this kind of problem (that technically has reproduction steps, but is sufficiently involved to reproduce that no one has time to follow them, e.g. build a new server from scratch with assorted specific software versions).

The phids constraints matches transactions with specific PHIDs (PHID-XACT-...). Usually, you'll have a list of transaction PHIDs when you're responding to a webhook callback, so the phids constraint is most useful for webhooks.

Probably a good idea, but not worth keeping a task around for.

This is probably a natural feature if we iterate here, but not worth keeping a task around for.

We have no customer interest in this and no current plans to pursue it.

I'm looking at these storage/backend changes:

Presuming resolved by D19748 since we don't have an actual reproduction case.

D20196 removes this code.

I think it had some white-space removed from its end.

After D20194, expansion of tabs now uses the correct rule (expand tabs to the next tabstop) instead of the old rule (hard-coded replacement with a fixed number of spaces).

There are probably still a few remaining kinks to work out here, but I believe this is substantially resolved:

• The "<<" and ">>" indicators are rendering in places where indentation has changed but the entire line is also different. This is not intended.
• The ScopeEngine can raise an exception on diffs with partial context. We should probably just skip this feature if we're missing context.
• The indent depth indicators are probably generally too bright / high-vis.
• There's no color blind scheme for the indicators.
• The indentation indicators in one-up mode aren't great (?)

I'm probably not going to fix this since it's pretty minor and moderately complicated to fix, but this interaction is not ideal:

In Firefox, selecting a range which crosses an inline comment currently drops the line after the comment. Here, return arra does not copy:

Note that T6791 has an example of a change where removing the whitespace options is going to cause a behavioral regression. Here's an example:

This report is generally unclear / hard to reproduce / unusual so I'm not sure how to move forward. It's likely mooted by D20181.

See PHI701. This behavior is not ideal: