See also PHI347.

I think T11934 and an explicit !claim Txxx action (which would mean "reassign + ref"; maybe with a !claim-and-fix Txxx to mean "reassign + fixes" or some kind of !claim+fix X syntax which expands to !claim <args>; !fix <args>) is a possible way forward on this, but I don't want to make "ref" automatically mean "claim".

T11934 is a possible way forward on this (and other niche things) without adding a lot of Javascript and UI complexity, by supporting it through !fixes.

We shipped "Mentions" and "Duplicates" some time ago.

More or less obsoleted by work in T13049.

I've marked D18879 as fixing this. It does not extend bulk editor support to all custom field types, but makes such support generally trivial. We'll fill in and test more field types as use cases arise.

After D18868, which rewrote the relevant code in the bulk editor, I can no longer reproduce this. My expectation is that the modern pathway these edits take can correctly collate multiple edits to the same field.

Hi @tappers, I can't get your query flow to work on my machine, would it be possible for you to give me a simple example of a working query ?

Yes. I am also looking for shortcuts even as simple as closing the current task. Currently we need many mouse clicks: 1. Add Action.., 2. Click Change Status, 3. click submit button, totally 3 mouse moves.

The chatbot was removed completely in D17756.

unfortunately, this no longer exists, is there a new documentation for it somewhere?

We need something like this too because the exporter doesn't include points at the moment.

oh, nice work, it will trigger parent task as well when subtask changed, seems I need to add the "condition" like subtask status instead of a "action" for this... any samples? Thanks!

Question: When subtask was fixed, the parent task want to have a action, for example, add a tag or change status if all subtasks were fixed.
So how to get this work in the extention of herald action? Thanks in advance!~

This is resolved by the Ferret engine, using title:...:

In T10890#231066, @epriestley wrote:

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

This isn't a bug; they aren't subscribers, and aren't listed in "Subscribers" in the right-hand column or in "Subscribers" in "Edit Task".

I don't think this clearly describes a root problem. PHI33 touches on similar issues, and I'll file something vaguely in this realm if anything comes of that.

I think this is resolved with Related Objects now.

Seems better to pursue this as an CustomField extension. https://secure.phabricator.com/book/phabricator/article/custom_fields/

There's also bin/mail receive-test but that only accepts mail --to an existing object, not a random email address, right now. We could make that more flexible to make testing a little easier (raw_mail.txt must be a full piece of mail with proper headers and encoding, but bin/mail receive-test accepts just the plain text of a body and simulates all the headers/encoding/envelope stuff).

Something like:

I think I have a fix but can't find the command line trick you showed me to test it.

The easiest fix is probably to add a TYPE_CREATE transaction into ReplyHandler or MailReceiver alongside the other creation transactions.

Does this also include the functionality to specify what subtype to be used when you click "Create subtask", or is this just the visual element?

At HEAD of master:

You can find tasks with no owner by searching for "No Owner", like this:

This is something that is needed every day, e.g. find tickets which are not yet assigned..

Specifically, the issue is that multiple different priorities used the same keywords ("low", "high").

A related issue surfaced recently. Actual use case (forensically reconstructed):

Ahhh, that makes more sense. I parsed that as saying "we could migrate the code" instead of the saved objects. If you want to add the glue code now and then assign it back to me after, I'll work on the migration in my Copious Free Time™.

Oh, sorry, maybe I wasn't clear. My plan is this:

If you're happy long-term with accepting all three types, I'm ok with that as a permanent fix. I'm planning on working through this week, just with weird/inconsistent hours.

Yes, we could migrate these instead.

Are saved queries/EditEngine forms things we could write migrations for? That might be even more brittle (for example, what to do about saved queries for priorities that no longer exist on the install), but accepting three different priority specifications of two different types seems a little too Postel's Principle for me.

I'll see if I can smooth this over a little before installs figure it out.

After some additional poking, there are a couple of other compatibility issues here:

Thanks! Will check.

@aurelijus, D18111 is landed now in HEAD if you'd like to test this. Let us know if you have any issues.

It would be really nice to default newly added fields to hidden. Going through 20+ forms to hide the fields is tedious.

Yeah -- the workflow from the Maniphest side dumps all the values into inputs in the body and does a POST, I believe.

Interestingly I worked around the issue by doing the batch edit from the Maniphest search UI which is passing the selected tasks an HTTP body instead of a URL query I guess?

@swisspol hit a variant of this with 1,172 tasks bumping up against an Apache URL limit in the Phacility cluster when editing from a workboard column.

With only those fields:

{
  "data": [
    {
      "name": "Open",
      "value": "open",
      "special": "default",
      "closed": false
    },
    {
      "name": "Resolved",
      "value": "resolved",
      "special": "closed",
      "closed": true
    },
    {
      "name": "Wontfix",
      "value": "wontfix",
      "closed": true
    },
    {
      "name": "Invalid",
      "value": "invalid",
      "closed": true
    },
    {
      "name": "Duplicate",
      "value": "duplicate",
      "special": "duplicate",
      "closed": true
    },
    {
      "name": "Spite",
      "value": "spite",
      "closed": true
    }
  ]
}

Maybe just include name, value, closed and special?

Similar example for new maniphest.status.search. I'm happy to drop any of these fields if you think we won't need them (prefixes and suffixes leap to mind).

That looks great to me.

Actual example output:

Yeah, with whatever wrapping context maniphest.search has, so like:

So should the return value for priority.search look something like this?

That is, the specific error "use lists" is aimed at preventing is this:

The config also looks like this right now:

I guess we already have "keywords" and should probably accept any of them, too, so "!priority high" in mail, /priority high in a comment, and "high" in Conduit all work consistently even if the actual key is "elevated".

Ideally, we should maybe freeze maniphest.querystatuses (which has a sort of ridiculous output format, I think?) and provide maniphest.status.search and maniphest.priority.search, which return results similar to other modern *.search methods even if they aren't implemented quite the same way (at least make the output format similar enough that a client library with methods like "turn a x.search call into a list of objects" would work on these methods, too).

It looks like what we really need is a new method like maniphest.querystatuses, called maniphest.querypriorities to avoid anyone trying to hardcode these values.