@Grimeh, above, reports that this doesn't work over HTTP. I believe it does, but we should verify this.

As @avivey suggests, the remaining cache can be cleared with:

Anecdotally, Disqus uses Akismet and the hit rate isn't great (I've observed both a high false positive rate, and a high false negative rate).

In T4369#232848, @epriestley wrote:

I don't see any easy way to cheat through $_FILES, though. We could remove it, but we have a nonzero number of users who compile their own copy of Linux and use a window manager that doesn't support drag and drop and disable Javascript and don't believe a monitor should ever have more than 256 colors, so that would leave them out to dry. The conversion also isn't trivial, so even if we want to move in this direction eventually I think it's a significant scope expansion over just building a synthetic $_FILES.

You need to clear some caches too - ./bin/cache purge - but I'm not sure which; And then hard-refresh the in the browser.

Support for Ubuntu 15.10 ended on 2016-07-28.
Did this problem also happen with any later, still supported Ubuntu version (like 16.04) or can this task be closed as obsolete?

This should be fixed by changes in T13024.

This should be fixed by changes in T13024.

Also, in case of "arc land --merge", the merge commit is falsely authored by the revision author.

arc land still prints a warning in this scenario. Is there a way to disable that through .arcconfig? arc land itself doesn't seem to have an option to skip the warning.

(I'm also open to improvements to the XHProf UI in Phabricator if you plan to use that to store and review profiles. Many obvious features like tagging and API access which would make it more usable for handling profiles of projects other than Phabricator itself are likely very easy to implement. But I'm not sure there's tons of room for real integrations, even if you used everything else in Phabricator, and you may imagine tooling which can't realistically exist in the scope of Phabricator.)

For general context:

In PHI231, a more experienced user went through this workflow:

@epriestley what do you think of creating another column in the calendar_eventinvitee table, something like a bool futureStatus so that when we get a list of invitees back, we can check for that flag. I think this would mean a lot of date comparisons (seems inefficient), and I'm not quite sure when to populate event stubs. For example, if the futureStatus flag is set to true for instance 10, and there are stubs for instances 15 and 20, when would 15 and 20 get converted to have the updated status?

Another variation of this is that "Mailing List" users' addresses also can't be edited from the web UI.

Thank you very much!

I fumbled the task ID in D18793, but this should be resolved by that change.

I don't plan to pursue this.

I don't think this or T12421 are valid use cases, for reasons described in T12421, and don't plan to support them.