No worries, we appreciate the quick fixes!

@bizrad6 Thanks, I think D16118 should fix that once it lands. Sorry about these issues, the actual global stuff happened at the very end of the settings changes and I didn't test it as thoroughly as I should have.

Bug: The global email preferences are not being respected when Phabricator decides whether or not to send an email.

as per T11149, my email format setting defaults do not reflect active instance config

Confirmed it fixed the issue we were seeing, thanks for the quick response!

My tentative plan is to define keys in local config with some sort of structure like:

One thing I've seen people do is something like an encrypted ssh key (For SSL certs):

Cool, pretty sure I've got a repro then -- real fix coming up in a second.

Yup, that did the trick!

Ah, I think I've got a repro. Does this "fix" it?

We are seeing an issue where the global default email preferences are not reflected in the user email preferences.

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!

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

See also T11134

thx!

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

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.

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.

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

Here's what happens when adding wikidata project tag using the comment form typeahead:

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

Oh, one more thing:

After D16088:

This should also fix the mobile workflow stragglers from T2644.

After a little thought, I'm leaning strongly to putting every schema on every database. I think this makes a lot of the administration, maintenance and implementation easier.

I implemented this, sort of. However, it doesn't work cleanly because transactions are "adjusted" (have old values populated) after they are "expanded" (which generates the @user mention transactions). So when the code runs, it doesn't have access to the old text and can't easily figure out which mentions are new.

As an alternative to Luke081515.2's request for an option, I just filed T11118. This would also allow an easy return to the old behaviour of always triggering audits, regardless of who the author is.

O.o

This one feels a bit un-human-like, although it might be tricky to fix:

It would also be nice to develop an inline version of this for title changes like this:

For completeness, T11107 was also related to this.

My device is part of my life based in a real timezone. My OSS development and other intensive online community activity occurs in UTC, to simplify my mental calculations about other people's current time and aiding communication of timestamps and deltas.

I'm not sure I understand the use case for that. Do you set your client OS to local time, but prefer to use Phabricator in UTC? Offhand, this seems unusual. Do you have any particular reason for doing this (e.g., you live right next to a timezone boundary and change zones multiple times per day)?

Could we special case UTC, with a custom message and simpler "no change" process?

I'm sure there are still some cases where we don't do a particularly good job, but let me know when you run into them.

In T7643#179137, @epriestley wrote:

Diffs should be less choppy now, here's the improved version of the above change:

In T6916#179233, @epriestley wrote:

I have no idea if this is MP4 or not:

IMG_0370.MOV0 BDownload

I think this one works:

I have no idea if this is MP4 or not:

Diffs should be less choppy now, here's the improved version of the above change:

Calls to .edit endpoints fail with cache exception:

I think this pretty much boiled down to three technical pieces, all now better covered elsewhere by more specific tasks:

This is pretty rough (particularly, the actual diff part), but wired up everywhere. HTML email includes a link: