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.

Thanks :)

This seems to be happening consistently for all new commits.

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:

I'm having difficulty reproducing this. Here's what I did:

What are the view, edit and join policies of the parent project set to?

Ah, interesting. I have F1 bound to "Expose: All Windows" so the flow for me is "Click > F1 > Drop Anywhere" to save, then "F1 > Drag > F1 > Drop" to load. I'm pretty sure I can get through that faster than I could copy-paste/type-select a file by Fxxx or from a browser UI.

Note that being an administrator doesn't matter: administrators have no special privileges, and can not bypass policies. See:

Thanks, your reproduction instructions are clear and complete. I was able to reproduce this by following your instructions and narrow it down to a root cause. This should be fixed shortly.

I'm having trouble reproducing this. I tried to follow the instructions you provided to recreate the issue, but didn't seem to experience it. Here's what I did.

Hi! Can you please let us know what version of Phabricator you're running?

In conclusion, we should never add options to the product.

(The difference between the dark and default background colors is so subtle on my monitor that I never noticed it.)

Oh, I do have that set locally -- I thought phui-theme-dark was just the default (since we got rid of light?) but this fixes itself if I switch to, e.g., the red header.

When creating the first subproject there is a note that all members of the project will be moved to the subproject. In fact, members were copied to the subproject

T10349 has a similar use case, where a user would like to select an existing file for use as a cover image.

Thanks, that's helpful.

This gets a brief mention in the documentation, but generally:

Hi! Can you tell me what version of Phabricator you're running?