Thank you Chad, this is working. Really appreciate your quick response.

I see the word option in your select statement, and the example states options, try that?

Dear Chad,

(was resolved in rP556eb9441ac4 for reference)

The commit you are referencing isn't our actual documentation, it's just an old (and incorrect) revision that has been fixed that contains our raw documentation files.

Chad, I am giving this option to my team with dropdownlist consisting of {"Task", "Bug", "Incident"} in the field "IssueType" of "type":"select".

Via email, a specific requested option is [ ] Publish in Commit Messages (or similar, wording might not be great) in Differential, to allow installs to trim down the message-of-record that arc lands.

Particularly after strengthening the "prototype" barrier, this is more of a "users want it" issue than a "this has high support costs" issue.

We want to position Projects above Blocks to make sure that they always are visible, regardless of the number of tasks blocked/blocking. See https://phabricator.wikimedia.org/T2001

I'm currently making the Phacility deployment tools load all Almanac services and filter them on the client to generate a list of instances hosted on a given machine (e.g., all instances with storage on db001). This is super gross:

In T6114#76219, @epriestley wrote:

It's also possible to implement "Advanced Custom Fields" which have arbitrary policy rules:

https://secure.phabricator.com/book/phabricator/article/custom_fields/#advanced-custom-fields

Thanks @qgil

project.query does not emits the auxiliary dictionary, so there's no way of getting custom field value with the api :(

@austinstoker, you want to see this: T3179#81309

We want to migrate to phabricator from trac, but to get buy-in we need to migrate trac tickets and their custom fields to Maniphest tickets. As I understand we can either wait on this ticket, or delve into the code and try to resolve this. Is there any other option?

The only place where custom fields aren't integrated now is Diffusion. While looking into ways how this can be done I've discovered, that both Branches and Tags custom fields aren't really used/stored at all, because branch/tag of each commit is retrieved directly from repository via ajax call when that commit is viewed.

No. See: https://secure.phabricator.com/book/phabcontrib/article/feature_requests/#setting-expectations

Can this be implemented this year? Would be great present for Christmas.

Looks like the same issue, I can confirm in my sandbox.

I traced it back to setValueFromStorage in PhabricatorStandardCustomField and got lost after that. My little designer brain gave up.

This might be the same as T5158 but I have to read them again.

Closed by commit rPef3df7e4bf5d.

I'm fine with just documentation.

Support Impact A lot of application functionality is not accessible over Conduit (or is accessible only in a confusing or broken way).
High Support Impact Removing methods gets harder over time, and this broadly limits our ability to expand many Conduit capabilities.

I haven't contributed anything to Phabricator yet, but this is a feature we need, so I might be able to take a stab at this. Any feedback whether this is something that will be accepted, and how complicated it might be?

Per @cburroughs, fields which can not be edited at all are already supported.

For the import use case custom fields already have an edit boolean which might get you most of the way there.

Another usecase: For tickets imported from previous tracking systems into Phabricator, we drop the IDs from the previous system into a custom field (and use that for URL redirects to Phabricator).
In theory that custom field should not be edited.

...and even more depending on how isolated your teams are, you might just want separate Phabricator instances. Basically, namespaces, other features will never let you reinforce your silos like separate instances will.

I like it! Thanks for listening, looking forward to this (and top level namespaces so we can stop overloading the Projects field). :)

Basically, turn this:

This is surprising to me, since Facebook had people whose responsibility this was (from pretty early on, I think). I do most of it in this project. We don't have a huge volume of tasks (about a dozen a day) but triage takes very little of my time.

We can support this and reduce the number of configuration options by allowing fields to specify options (like "required") in the field selection configuration. In particular:

Closed by commit rPb2d596846059.

Thanks for the report! :)

Haha. I took a stab at the code to try and fix it. This was way easier than I thought it was going to be. Thanks!

Thanks for your quick Update. I really appreciate it.

◀ Merged tasks: T5970.

You can add a date-based custom field and call it deadline. https://secure.phabricator.com/book/phabricator/article/custom_fields/

Given the level of interest in the community

Given the level of interest in the community, I suggest starting from the field types that are easier to extend. I know it might not be a superb way, but most it would perhaps provide a way forward.

The core custom field implementation is in phabricator/src/infrastructure/customfield/. Storage depends on the field subclasses.

Can someone point me at the implementation of custom fields and how they are stored?

◀ Merged tasks: T2277.

◀ Merged tasks: T5112.

✘ Merged into T5391.

who will track it ?

Cool, thanks for checking!

confirmed with new code.