auto-adjusted based on location

why not using the browsers timezone by default and giving the possibility to set a static one in the settings if really required (without this message popping up)

"Adjust timezone" dialog doesn't have a way to cancel/ignore

Or, perhaps more specifically: why do you want to change your machine's local timezone, but not change Phabricator's timezone to be consistent? If you just didn't want to change your timezone at all, you could leave everything in PST while in London and your system clock and Phabricator would both remain in PST, but you did change your system clock.

Why don't you want to change your timezone?

Catching a couple more funky diffs:

I enabled Google for central auth since I think everything we need for it to work already works fine in the cluster, although it's possible some of the invite flow stuff is a little shaky.

I believe this is fixed now, but reproduction has always been somewhat elusive so I'm not completely certain. Please let us know if you still see issues after updating. Thanks for the report!

This commit now appears properly in the history view on this install, so I think the issue is resolved:

I can't reproduce this -- rGITTESTaa541e7b324424e201c124dc58588c33e48d8bf5 seems to work fine for me.

If the "Audit" setting for packages had three settings instead, would that solve your use case?

Thanks. That trace is consistent with the one I was able to reproduce, so I suspect the changes above fix this. I'll leave this open for a bit in case anyone else shows up, this fix is the kind of fix that's likely to have spooky side effects.

I appear to have found a reproduction case for this in the cluster.

I'm deploying this to the cluster now.

@ivo, if you see this before I post a fix, can you show me the output of this command so I can make sure I'm reproducing exactly the same issue?

This issue describes a narrow issue with typehinting URIs, introduced by T10227.

I'm going to merge this into T11137. They don't describe the same issue, but I'm planning to fix them in the same way.

(And those UIs might also not actually be useful for future-administrators, particularly since I don't really plan to ever help users with third-party stuff, although who knows.)

My intent with a lot of that stuff is to make administration and support (particularly in the future, once third-party applications are more common) easier, so they're targeted primarily at future-administrators who have questions like these, possibly because we've asked them for the information:

(And we can continue reducing the number of settings, but not very quickly.)

/config/ is already an attempt at chopping it up, vs /config/all/ which is the un-chopped version. If you have a better way of making it less scary there's no need to chop it up in the way it's currently chopped up, though.

Yeah -- the highlighting code is more flexible about what it matches than the actual search code is, which makes T6740 worse / more confusing.

"username" doesn't match "usernames" until T6740.

We've already declined support for this. See T6003 for discussion.

This isn't a bug; you mentioned the other object and we accurately reflect that.

Large diffs like wiki pages should render better in email now:

This report does not include reproduction instructions. Bug reports must include complete reproduction instructions. See Providing Reproduction Steps.

See Consulting if you'd like our help resolving environment-specific configuration and setup problems.

I spent a couple hours on this last night and a couple hours this morning and I think I have Paste pretty much converted, so things look promising. I'm going to hold this until after the release cut, but expect to put Calendar on top of it and whatever else converts in the future.

Looks like there's a JSON API: https://xkcd.com/json.html

Phabricator is not an LDAP administration tool and we have no plans to turn it into one.

D16094 should improve things, let me know if you identify specific problems after deploying that. It's deployed on this server now, although we have fewer similarly-named projects so it's harder to see the effects.

Config → All Settings → phpmailer.smtp-encoding

Let's just make base64 the default and see what that breaks. ¯\_(ツ)_/¯

It's expected that the ordering in "Browse" is alphabetical/raw, and I don't plan to change that.

Interesting. The same mail was delivered to me intact:

• We currently use white-space: pre-wrap to handle linebreaks in prose diffs, but at least one client (Airmail) doesn't handle that properly. We could use explicit <br /> to improve behavior.

I think this should work now. I tested it locally with HTTP and SOCKS proxies via Charles and those both seemed to behave properly.

Sounds good. I'll call this done for now, let us know if you run into issues.

I think we're relying on white-space: pre-wrap; right now. We could explicitly do \n -> <br /> conversion which might fix newlines, at least.

maybe by 2050 email will work most of the time for most people

The actual diff is further down and rendered correctly for me, at least -- that's just how we currently render "added one line to the middle of a 500 line document" right now:

No, that's this stuff from T7643#179240:

I'm leaning toward exploring this in the near term. We have four applications which may convert soon:

Oh, one more thing:

I return the other fields, but don't currently return "status" because I'd have to return an internal numeric constant. So we may need to fix that more thoroughly before you can move forward.

Actually, this is slightly more involved because you want to select open revisions.

You essentially only need the revision IDs in the response, right?

That is, if you go to the Diffusion workboard, we give you a generic create form instead of a choice between the various normal create forms, currently.

You can file stuff without those tags from workboards, and maybe "Support Request" just got caught in the crossfire of typing every possible tag, so that's a legitimate-albeit-unusual pathway here. But I wouldn't expect the short-lived "New Support Request" form to be accessible any longer.

How did you file this task?

After D16088:

We haven't seen other requests for this and it's consistent with the similar behavior in Differential.

This should also fix the mobile workflow stragglers from T2644.