New APIs are going out tomorrow morning (Saturday, February 27). I expect to unprototype Almanac shortly after that, provided things go relatively smoothly, so it will become available the following week (Saturday, March 5).

Hmm, alright -- file a task and I'll take a look when I have a chance. I don't expect this to require any weird magic.

It looks like that can leave two external (LDAP) accounts pointed at the same Phabricator account. If that's working, great. It will be supported explicitly after T2549.

is T5954 really a fully blocking Task of this feature?

In T10449#161931, @dtf wrote:

Shouldn't restricted repositories short-names be rendered as [ Restricted Repository]? Sorry for this off-topic.

Oh, there are also really two issues here, but only one that I think is actually hard:

On external account mangling in particular:

Yeah, that's broadly the "think about" part in the task title -- I don't have a good answer. I'm not quite sure how to reconcile diffusion.edit with the current multi-page form.

Some possible tools that may form part of a solution here, roughly in order from greatest upstream willingness to greatest upstream resistance:

As a note to myself, I also need to adjust config for instances after pushing this, since empty values are now explicit. This only affects a handful of instances and they're easy to identify, so I may just do it manually rather than trying to write a migration.

I also have a small patch against rCORE, but it's pretty minor and I can't really test it fully until the rest of this stuff makes it into production.

Subscribers were removed from projects, so this policy no longer functions.

Er, almanac.service.search, rather.

D15345 adds these capabilities:

I think var_dump() will normally be hard to observe, since it will go to stdout but that isn't connected to anything by default so it will just vanish (we don't write stdout to the daemon log). My guess is that the code is running, you just aren't seeing the var_dump() output.

Let me know if you hit issues -- it should just be better in every way than maniphest.query was, but I might have missed some data or something like that.

Broadly, *.search and *.edit endpoint are replacing older *.query and *.variousnameslikeupdate endpoints, see:

It's present in maniphest.search.

Sure, happy to bring those both upstream.

Oh, this is probably actually $operation->setWorkingCopyVCSError(...);

To fix this:

See T8227 for discussion of why adding an option is a measure of last resort.

Ah, I missed "In Diffusion". Let me see if I can reproduce there.

I'm not strongly attached to this behavior and don't mind swapping it and seeing how much pushback we get, it just seemed like the much better behavior at scale, and seeing it use on the Trello meta-board suggested to me that it was reasonable and possibly familiar to users coming from Trello:

@wuup, I undisabled you since I think you weren't part of the "click shiny buttons" activity this morning.

I think @wuup might have been an innocent bystander who was caught in the crossfire. Poor guy!

Can you walk us through what broad, overall goal you're trying to accomplish more generally? See Contributing Feature Requests and Describing Root Problems for help describing root problems. As those documents repeatedly emphasize, it's really important for us to understand root problems.

T4854 is also related.

I'm having trouble reproducing this -- I attempted to follow your steps, but didn't experience the issue. Here's what I did:

The logic is that if you have 50 milestones, you are probably much more interested in milestones 50, 49 and 48 (this week / next week / last week) than milestone 1 (a year ago).

One specific thing we're starting to see more of is test users signing up and bulk-associating or bulk-merging large numbers of tasks. There doesn't seem to be any specific intent behind this, but I think these UIs are shiny and make it easy to click a lot of buttons and have a large effect. Here's one such user on this install, who has registered three accounts just because they like clicking buttons so much:

See also T4854 -- mod_pagespeed is known to be incompatible with Phabricator, and should not be used.

I guess "off" is default, so "disabled" isn't quite accurate.

From elsewhere, it sounds like there isn't driving interest in pursuing this.

The expectation with the git fetch in question is that it will run very frequently on active repositories, so we should have all but the last few minutes (or even seconds) of data in most cases, and almost all the refs should be identical to the remote refs. The fetch schedule is here, but for enabled repositories we'll never wait more than 6 hours between fetches:

I also can't immediately reproduce the root issue. Here's what I did:

I think I got 'em all, but let me know if you catch any more.

Broadly, here are the general issues we've currently seen with Diffusion URIs:

Someone on Facebook noted that I omitted the Cyclone. Eek!

You spoke to the "Track Only" stuff a little bit in the description -- for complete clarity, we have two separate options that are only sometimes available:

Oh, sorry, yeah -- for macros, you'd currently have to pick the file off your desktop with the file picker thing. I'm thinking more about a general "select some existing file" feature for other cases like cover images, where you can drag-and-drop.

Before pursuing this, I'd like to develop a better understanding of the root problem. Particularly: