It should show a pretty clear preview of what it's going to do before you drop, so I'm not sure how it could be unpredictable? I wasn't able to identify any weird/surprising behavior when I tried to reproduce this.

even sometime seems to me not properly working

I wasn't actually able to reproduce this -- were you, @chad?

Pagination isn't quite as simple as I'd remembered. Specifically, we do not expose internal pagination cursors to viewers today because doing so permits an information discovery attack that goes like this:

Broadly, I think the two above comments are expressing a mixture of two ideas:

The proposed behavior (no subproject columns) means that tasks could be in multiple different columns at different levels, since they'd be draggable normally on each workboard:

T11774 wants a "delete file data" transaction, which is reasonable.

This is working as intended, and not a bug. Administrators can not bypass policies. See the User Guide: Account Roles documentation:

I think this behavior is very good

This is also a potential problem in the general case, although the general case of this is very rare.

Broadly, most applications can execute Spaces queries cheaply by querying ... AND spacePHID IN (<list of spaces the viewer can see>) when Spaces are configured, which is efficient until some install decides to create 30,000 Spaces for some reason.

The reporting user configured debug.time-limit to get a stack, which confirms this is a Feed issue:

Here are slightly cleaned-up recent timeouts from the logs:

I'm going to close this since things seem to have at least mostly worked and installs have had a couple of weeks to yell at us if we blew anything major up, but let us know if anyone runs into further issues.

I can't remember if Phabricator already requires a confirmed e-mail address to do anything.

We can also let installs send us all their data, we'll decide if it's spam or not, then we remotely delete any data that we feel like deleting. But we'd have to charge like a gorillion dollars per message to make this sustainable today.

What sort of reliable and automatic solution are you hoping for? How could the system reliably, automatically detect that a user is a spammer or that a task assignment is unwanted?

After D16714, the problem tasks should complete cleanly.

This feature request doesn't describe a root problem. See Describing Root Problems and Contributing Feature Requests for help filing a feature request which we'll consider.

D16714 should fix this by adding an implicit byte limit.

Differential also currently does not substitute a diagnostic message when declining to inline a patch: it should. ("Patch is too big to inline because limit X is set to Y." or similar.)

An additional inconsistency is that the diffusion.byte-limit applies to attached patches, but the differential.byte-limit does not. There's some vague argument for this behavior (you "shouldn't" be reviewing patches which are so enormous that they can not be emailed) but consistent behavior is probably better.

Sorry, "tomorrow" definitely didn't happen. Looking at this now.

Some possible implementations of this expose an open redirect (e.g., by passing returnURI=<something> where <something> can be anything). An open redirect here isn't necessarily inherently dangerous, but the minor inconvenience we'd avoid probably isn't worth the security risk.

Broadly, I think this is better expressed as "Commits in rXYZ on master, including build status" than "Builds of commits in rXYZ on master". Diffusion proper already shows build status in commit lists, although the commit query in Audit currently does not. This probably won't get an update until T10978 happens.

As a followup, ran this script on a subset of instances to collect data about mail delivered on a per-action basis versus a per-user basis:

Per above, here are the specific queries I executed while collecting statistics about the "Self Actions" preference:

I am running a query to collect this data:

Circa September 13, 2016 we ran a query which collected this data from instances:

Ah, thanks! Yeah, looks pretty conclusive.

This is expected.

I'm vaguely suspicious that the mail is just too big (1MB of text plus tons and tons of HTML for syntax highlighting it?), and that the error is really arising from max_allowed_packet being violated, particularly given that the INSERT took 233ms to execute.

This feature request does not describe a root problem. See Describing Root Problems.

(If the policy isn't fixable, you can personally bear the cost of this policy by tunneling the traffic over 80 or 443 locally.)

Have they asked network operations to allow outbound traffic on port 22? It seems like organizations which employ software developers should reasonably permit this traffic. Particularly, security-minded organizations should reasonably prefer asymmetric keypair authentication over HTTP password authentication in the general case.