Page MenuHomePhabricator

Project tokenizer functions like "any()" and "not()" do not include descendants
Open, Needs TriagePublic


try search in maniphest advsnced query tasks tagged In Any: Diffusion In Any: Clusters ( - you don't get tasks from milestone diffusion (v3)

pasted_file (113×376 px, 8 KB)

If you change query to Diffusion Clusters ( you don't get all of this project tasks too.

so, problem - if you manager of multiple projects, you can't put on dashboard list of all the tasks that need to monitor.

Event Timeline

I can confirm that In Any: does not seem to include subprojects. I tried to make some sense of the way the project search functions work but it's pretty complicated.

With subprojects, #project changed to mean "that project, and all its descendant projects", but any(...) and not(...) still mean "just the parameter, exactly". I think viewerprojects() and projects(user) are also "just the parameter".

There's also no way to specify exact(#project) -- that is, "just the project I typed, not any of its descendants".

This stuff hasn't been fixed for two reasons:

  • These use cases are fairly rare.
  • The pathway forward isn't entirely clear.

There's some similar stuff, sort of, with T12371 and T11462.

I think the big question is whether we build exact-viewer-projects() (i.e., one top-level function for every typeahead composition), or make descendants(projects(viewer())) work (i.e., turn typeahead functions into an entire functional language).

The second one is obviously "better" in a lot of academic/theoretical senses, but likely a pretty big amount of work, and it gets the wrong result in the common case (users who type #project generally mean descendants(#project)). Likewise, in the "Responsible Users" fields in Differential and now Diffusion, the current meaning of epriestley (all my direct reviews, and project and package reviews) is the desirable default.

We could make tokens sort of magical in these contexts and keep the default meanings broad and let a functional exact(parameter) select just the "true" token, perhaps, but that drives up the complexity of x(y(z())) a bit further.

I sort of thing x(y(z())) might actually be the way to go, but it's a lot of work for not very much benefit (handful of mostly edge-casey use cases). The server side is a fair chunk of work, but I suspect the real work is making the JS tokenizer control on the client side allow you to input this stuff.

epriestley renamed this task from Unable to query tasks from multiple projects in maniphest advanced to Project tokenizer functions like "any()" and "not()" do not include descendants.Mar 26 2017, 12:42 PM

It's possible T10872 is also related/is a duplicate.