Another possible approach is to use -o LogLevel=ERROR. This gets us into trouble if there are useful INFO messages other than "permanently added X to list of known hosts", but presumably all the important stuff is rasied at ERROR or better.

For Drydock/Harbormaster, the only real way forward I see here is:

Currently, properties on upstream build steps are driven by CustomFields. T13248 briefly discusses a bit of context.

(This is likely to be very long, very rambling, and not particularly enlightening or useful.)

somewhat tricky to explain, and somewhat tricky to resolve

From onsite:

In T5391#234838, @epriestley wrote:

Resolved by D18959 + D18960. See also T13049.

Not all custom field types have export support today, but the infrastructure is in place and additional support is generally straightforward.

and now when I re-run the command again, it gets another 7 commits and fails again. So, perhaps by me viewing the commit, I kick off a job that rebuilds something on the backend?

It's now failing on this one (consistently if I keep running it):

Thanks. That looks like a perfectly normal object to me so I'm not sure what could cause it to fail to load.

You will soon be able to give builds different "Hold Drafts" behaviors. See T13258.

Making a way to set fields to default: disabled would make this feature even better ;)

After D20229, the rules are:

I'll call this out in the changelog, but behavior here is changing slightly (see T13258 and T11415):

I'll update the documentation/setup guidance in the upstream.

Great! Thanks for the report, and for your help tracking this down by going through the diagnostic steps.

https://phabricator.example.com/debug/?a=b returns:

Here's what's happening in general:

I can't immediately reproduce this: I can log into my local development install and into secure.phabricator.com using Google OAuth without any issues right now.

In T6409#216988, @denghaodna wrote:

Would be happy to see this feature. My company use different team names as columns of the work board. When a task is reassigned from a dev to a tester, I need to manually move it from Dev column to QA column.
With this feature implemented, I would be able to configure a rule that when a task is assigned to a specific person, the task will be automatically moved to a column, say the Dev column for example.

I thought rPHU4d21f105b17f250aaaeb8937142ae4cbc978389f was meant to fix this, but apparently not.

quack

Calling PhabricatorProjectsMembershipIndexEngineExtension's rematerialize in move_to_root.php should automatically set hasSubprojects and hasMilestones

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.

This has been implemented in the meantime:

Thank you !

• 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):

FWIW I appreciate and use the mute feature (though only occasionally)

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?

Thanks for the quick reply!
Haven't played with webhooks yet so I did not know/realize it's transaction PHIDs only - "PHID" sounded generic enough that I incorrectly expected any kinds of PHIDs to be accepted as input. So this task is somewhere between either "clarify documentation that only transaction PHIDs are supported" or a "support other PHIDs" low-prio enhancement request.

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