I'm just going to merge this into T8646 which broadly discusses richer search results.

@ivo Just a reminder this is a real install, please do not create test events on it. You can use a free instance on http://phacility.com/ if you want a clean, up to date install to test against.

DiffusionSSHWorkflow->execute() currently makes a proxying decision before it determines if a request is a read or write request. This needs to be reworked before we can support separate flags, since the host we'd choose to proxy the request will vary if only some hosts are readable/writable.

(For reference, see discussion elsewhere.)

My intended fix here is:

Running multiple different versions of Phabricator on a single host is not currently supported. We should probably handle this situation better than we do, and there is no technical reason we can't support this, but this use case is very rare.

I'v checked that

Thanks for the quick fix!

How about "i" for "image"?

⇧ + ↓

I am also keeping an eye on https://www.reddit.com/r/bonehurtingjuice/. It's still a small meme but if it takes off we're all going to be drinking bone hurting juice this time next month.

just need to assign a trigger for the typeahead.....hmmmmmmmmm....

Also our meme format is very outdated, the new meme format is:

This should be fixed at HEAD of master, thanks for the report!

For those looking for how to associate tasks to columns - reference the following from T12074:

Confirmed at HEAD.

Awesome, makes total sense to move this towards a customization of user profiles task. Thanks!

D17656 is legitimately pretty hacky so this is now entangled with T11110, etc.

I'm going to just repurpose this into a general "allow installs to customize user profiles" task to broaden interest.

This is a legitimate bug but I think it's very long-standing and fixing it requires doing a lot of extra data loading to get the current diff PHID. Until someone else notices, I'd rather wait for diff PHIDs to be denormalized onto revisions.

We're OK leaving this open to understand impact to other installs or similar needs in customizing user profiles, but to date no other requests have happened.

I don't see a compelling reason to add a link to every Phabricator install for a single user.

This is a sort-of-intended result of several different rules colliding to make a mess. Here's the primary rule:

So, what's the word on this?

Thanks. Deployed just now and confirmed working.

This should be fixed by D17654 and available at HEAD of master and stable. Thanks for the report!

This is technically supported, but not easy to find in the UI right now. Here's an example:

This reproduces for me locally. (??!?)

A small subset of instances were queried with this script (below) to assess the impact/priority of T12137. This script examines fulltext search queries, but the only output is a ratio of potentially affected, unique queries first issued in the last 30 days, like this:

This is currently expected, although we could consider changing it.

Here are a few of the use cases for templates (as in {{math 2 + 2}} results in 4) that I can remember from the past.

When I turn on bucketing, I can't see it actually. Although I do have a lot of diffs, so it could have overheated.

Where does it go when you turn on bucketing?

👍🏻 😄

Please put your version information on all bug reports. There has been a lot of churn here so we need to know you're at HEAD before trying to reproduce.

Thanks, closing this one!

You should have sweeping janitorial powers as a member of Community now.

Or I guess, you* can close this since I can't. Whoops.

Scratch that, you're right @epriestley . We just got confused during the workflow and didn't realize jmeador previously accepted.

Whoops, I think I may have totally fudged the screenshots. Let me try to reproduce with proper screenshots.

It looks like before step (2), jmeador can only accept for one reviewer (the package), since he's already accepted for himself. The current rule is:

This seems to have fixed the issue. Thanks for the quick fix.

T12531: Unable to upload file: failed to read 4583864320 bytes after offset 0 discusses one side effect of these changes, it should be fixed in HEAD of master and stable now.

Thanks for that catch in D17651, let me know if you're still seeing issues after updating. I'll cherry-pick that to stable too.

Yeah, that looks like it's consistent with the hypothesis above. I expect:

Not sure if this is useful:

Yeah, pretty sure what's happening is: