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.

Anchor tags got cleaned up in D16083.

This report doesn't include reproduction instructions and doesn't clearly demonstrate a problem: all of the screenshots are explicable through user error.

We haven't seen other requests for this in many years.

I can't reproduce this at HEAD, presuming it was resolved some time in the last year.

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.

Here is a string of 2048 unbroken "M" characters:

Oddly, in the prior case where mail was mangled for a user on their install but similar mail was not mangled here, the unmangled mail I received was encoded in "8bit", which tends to suggest that this might be an MTA problem rather than an "8bit" problem, per se. But changing the encoding away from "8bit" might be the only real lever we have to fix the MTA.

The trigger for the behavior is likely just "long lines of text", we had an earlier report of something similar occurring inside an inline comment snippet (but it could not be reproduced on this install).

It's possible that adjusting phpmailer.smtp-encoding (say, to binary or base64) might fix this.

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.

Particularly helpful would be to write some comment on this task which reproduces the issue for you, then tell me which client you're using.

There are no plans to implement this for Git. Git has had robust history rewriting for a long time.