@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.

We haven't seen significant additional interest in this in more than a year. I expect to implement T7860 but, not a query microlanguage.

Presuming this is resolved by D17384, see T12450 for followups.

Presuming this is resolved by new indexes in D17384, see T12450 for followups.

This was tagged ElasticSearch and may now be resolved (see T12450) but also lacks information we require in a modern bug report (specifically: precise reproduction instructions). If this is still an issue at HEAD of master, feel free to follow up on T12450 or file a new report with reproduction steps.

Presuming this is resolved by D17384 (but maybe @20after4 can correct me).

Presuming this is either resolved by T9893/D17384 or no longer relevant. Follow up on T12450 or file a new task if you're still seeing issues.

I'm just going to close this in favor of T12450.

As a general product decision, I do not expect search to be substring search by default -- searching for pricot on Google does not match documents containing apricot. But we can sort this out in the long run.

These are now up to date.

I'm going to presume this is approximately resolved.

But if you say "Haskell" you may have to wait a minute.

Maybe easier would be for you to tell me what language you want to use and I'll just write you a snippet which encodes a request?

The page implies that all I should need to do is POST up, for example, the following: