I can't reproduce this. We mirror from this install without Conduit access enabled, and there is no conceivable reason that Conduit access should need to be enabled for this to work.

Files now render with a download link, which I think was the core issue here:

Sounds like this is resolved.

A SAAS install is hitting the "move + rename binary" case.

@cos, which specific types of fields are you seeing issues with?

The projects attachment should let you get projects, here's an example call on this install to retrieve this task:

no need for it

• The "root problem" from our point of view is a security policy with no technical basis. As a general rule, we do not implement changes to help installs solve problems of their own making, and you have this problem only because of your policy.
• disable_functions = phpinfo does not improve the security of Phabricator, but impairs normal behavior.
• To move forward, you should either: change the policy, obtain an exemption to the policy, fork Phabricator, or select other software which adheres to the policy.

This hasn't seen activity in four months so I'm sending it to the murky depths.

Oh, yeah, in Conpherence you'd have to like :+3+space+delete+⏎ or something.

Can you just type :+3+Space?

bin/search init warns me that the index is "incorrect". It might be more clear to distinguish between "missing" and "incorrect", since it's more comforting to users to see "everything is as we expect, doing normal first-time setup now" than "something is wrong, fixing it".

If that's the case, is there an alternative way to accomplish our goal in the product? Thanks!

In fact, I'm pretty surprised that your workflow doesn't hit major bugs/issues all the time, unless this stuff is currently far bugger than I believe it is. If you ever tag "Project Y" before moving a task to "Milestone 3", you'd no longer be able to move it from the workboard since it would vanish (until T11036)? Do you have a very specific sequence of organizational steps you take to avoid these issues? Are you just not using workboards at all?

(And, unless it's also bugged, I believe moving from a milestone to a non-milestone column on "Project X" should already strip subprojects. The proposed behavior just prevents there from being any subprojects to strip.)

I agree, I don't think project tags should ever be automatically removed.

No, I don't mean that, as written.

This has been out in the world for a little bit without exploding. I'd like to maybe do a bit of UI touchup but that can happen after T12272.

If you believe you've found a bug in Phabricator, we need all the information discussed in Contributing Bug Reports to move forward. Specifically:

I believe the expected behavior is that "milestone, subproject" kicks the task out of the milestone (leaving it in only the subproject) while "subproject, milestone" kicks it out of the subproject (leaving it in only the milestone).

I'm going to close this because I think it no longer meets the modern requirements for a feature request (it was filed in 2012). In particular, I don't understand why this is a problem:

The workflow thing is somewhat nontrivial. Previously, we would explicitly downgrade "Accept" into "Accepted Older" when an author used "Request Review".

From D17564, there's a minor workflow issue with "request review" incorrectly putting accepted changes back into an "accepted" state from this.

Yep, thanks!

THANKS FOR RUINING THE JOKE EVERYONE

We need reproduction steps to move forward. See Providing Reproduction Steps.

so it's tokenizing maniphest.query as two separate tokens

(This was incorrectly closed by the text "doesn't actually fix T8918" in rP08de131da525.)

Personal notes:

In T12450#216917, @20after4 wrote:

I can not reproduce it on wikimedia's install.

Presuming this is resolved since @20after4 couldn't reproduce it after T12450, feel free to follow up there or in a new task if you're still seeing issues.

I don't plan to implement the original feature as described.