That doesn't look like a Phabricator 404 page.

Introducing an epoch64 type ends up being pretty messy:

Perhaps a better solution is to introduce an epoch64 datatype and store these timestamps faithfully, since they're at least sort of possible to write and do have a relatively unambiguous meaning. Introducing a new type instead of changing the meaning of the existing epoch would let us accommodate this without requiring tons and tons of migrations or exposing us to a lot of weird fallout.

After some effort, I'm unable to figure out how to generate these commits using vanilla git. I can't figure out how get them with --date or GIT_COMMITTER_DATE to git commit: dates after 2100 are treated like the current date.

I'd be interested in the Refine the workboard/form interaction idea.

Full screen disables live previews in any remarkup box.

I think this task should be reopened, because there is no way to disable live preview in desktop currently.

Developers want to push their local branches to GitHub for a variety of reasons:

• so that if their computer dies, their work doesn't disappear
• so that they can work across multiple machines (eg, if they have a separate computer at home vs at work, or if they have a cloud development environment separate from their local workstation)
• to show their work to other people before sending out a Phabricator revision (which they could still do with Phabricator, but some folks feel like they should only use Phabricator once something is ready for formal review)
• because at a previous organization, they always pushed their branches, so they're in the habit of doing it

Why are you tracking branches you don't want to land onto?

The particular issue is that that the change removed a file containing the bytes ... 0xE5 0x76 .... The 0xE5 is probably an å in Latin 1.

I extracted the response body prior to encoding as a serialized()'d object so I can narrow down what's causing the encoding to fail and it looks reasonable, looking like it's almost certainly a UTF8 issue now.

Not too surprisingly, the response is empty. AphrontResponse->encodeJSONForHTTPResponse() uses json_encode() and does not detect UTF8-related encoding failures, so the chance that this is a UTF8 issue is pretty high. We should also probably fix that so fail earlier and more explicitly (and don't emit HTTP 200).

Oh, so for the hell of it I tried using the cookie data (it's in a username=token format) as the basic HTTP authentication credentials, and it appears to work! I have no idea why Google tries to get you to set up cookies when basic HTTP authentication works just fine.... :/

The next step I want to take is figuring out what the actual problematic response body looks like, but that's slightly tricky right now because there's no way to make Conduit calls from the CLI.

There isn't really an alternative technology choice here however - not only does AWS not have an equivalent service integration of this functionality, but using AWS for this would require using EC2 for compute, which would drastically increase (e.g. double costs) elsewhere. Azure is a pile of junk in my experience, which is why I'm avoiding that service as well.

I want to avoid implementing things in Phabricator just because there's a low barrier to entry to ask us and we're responsive -- over time, this tends to punish us for being responsive by cluttering our codebase with cruft to work around weird decisions that other companies are making in their products.

I have no idea what the technical reasons are for Google's implementation to be like this. I don't have a support contract with them (they start at US$200 a month), so I have no way of asking for them to do something different. The options for setting up a repository in their system looks like this:

I've seen this happening here too (B13428)

From IRC, this might be a false positive / not the root cause since destroying the binding didn't fix the problem, but I can run through things locally.

I was ultimately able to reproduce this, but it took some work and the instructions above definitely weren't sufficeient:

Alright, let me see if I can get anywhere with this.

A potentially less controversial fix for the 2-step entry issue might be to add a keyboard shortcut that will add a task to the last used column.

I've tried a whole bunch of different post requests (after setting those config values and restarting apache) but I haven't been able to get that garbage yet.

GHC would also find support for importing keys from Github useful; we are currently working on rolling out a Diffusion-hosted staging area for use with Harbormaster but the need for contributors to submit their key to yet another Phab feels like unnecessary friction.

I think that if you use Dependencies in revisions, arc patch will pull the dependencies as well as separate commits; Then you can do something like this:

Just want to +1 that this would be a very useful feature for us. I think our usecase is similar: We have a lot of teams (especially ops teams) using phab workboards and columns extensively. Rather than try to shoe horn different types of reporting, etc. into phab they are relying on external systems/tools, but it is pretty painful to extract data on what column tasks currently live in.

Phurl is a URL shortener. This is an amazing unique type of application which I personally invented in 2015.

It relies on a server side API call so you'll have to actually extend your server install in order for it to work.

I've also never used seamless so I'm not sure how support looks in practice, but this isn't immediately reassuring:

Can you share the code? :)

I think that only prevents referrer leaking -- it doesn't deal with the other issues in T4190#60441 (or request amplification attacks), right?

Can we avoid the need for this entirely using the approach outlined in T11126 (using CSP or <iframe seamless referrerpolicy="no-referrer">)?

The vaguely related T5378 is also in the queue somewhere. It may not really intersect with this, but if we do end up trying to auto-embed any URI that ends in .jpg again it probably will. I'm not sure we should, but just a heads up for context.

The general shape of what we're trying to do here is that when a user writes the URL of an image in a comment (e.g., http://funny.lol/silly-dog.jpg, perhaps with some magic *$!symbols$*!) it would be nice to just show the image. Today, they'd have to download and re-upload it, which is somewhat cumbersome.

In T11518#191391, @chad wrote:

which devs don't? it's the designers, isn't it.

EditEngine is a slightly different way to build forms that look the same as other forms, introduced circa January 2016. Some applications have moved to it, while others have not yet. It seems pretty reasonable and stable, though, so we're in the process of moving everything over.

First, let's sort of limit the direct damage this misconfiguration causes by changing this line in PhabricatorUserLog->initializeNewLog():

Thanks, I guessed it's complex.

T7643#175911 has some discussion of this.

Is there a valid technical reason for Google to work like this?

Ah, nice! I'll write up some guidance on adding a setup check for this shortly.

Alright I was finally able to reproduce it. Calling unset($_SERVER['REMOTE_ADDR']); in the preamble didn't actually end up causing it, which is a bit strange. The only way I could get this to occur was to explicitly set $_SERVER['REMOTE_ADDR'] = null; in the preamble.

Yes, gmail hides duplicate content and that I too see as a usability problem for Phriction where the diff is not the thing you want to see but I recon that on Maniphest you want to be lead to the section of the task which caused the notification.

Would love some attention on this 😇

Seems to be duplicate of T4977

Herald firing on other things: T10109

This would be a usability loss for us though - frequently one of the issues we have with Phriction emails is that they take you to the comparison instead of the wiki page (usually because of how Google Mail hides duplicate content). Changing the behaviour of Maniphest to do that as well would make our lives more difficult.