In T418#122175, @agen wrote:

Should the custom fields are showed in the list view like

Should the custom fields are showed in the list view like

We aren't interested in pursuing changes with no upstream impact.

@epriestley: I understand your concerns about supporting custom scripts, but what do you think about creating initialised user profiles? Currently it seems that loadUserProfile() just dumps something with a PHID on you (when the profile did not yet exist), which is not actually a valid object. The fix seems trivial.

It seems indeed that the profile created by $user->loadUserProfile() is broken or incomplete.

Just for update, I updated to latest code, the custom field search (list type) is working, even per @btrahan it is a wrong configure.

And:

Sorry, we don't offer support for writing custom extensions or applications. See T5447.

The users I tried this with all do not have a user profile set in the database. Thus I assume Phabricator tries to create blank profiles, when it applies the changes to the CustomFields, which then fails to be inserted, since these do not comply with the database schema?

See T8516 for the "detect misconfiguration better" task.

In T8453#120118, @tao_qiping wrote:

Sorry I raised T8436, as this ticket is focus on search custom field. so I re-open it again as I still can re-repro it on list field, below is my custom field. can u please verify a list field to see if it is fixed, if so I may need to update my code to latest.

"tke:system": { 
     "name": "System", 
      "required": true, 
      "type": "select", 
      "search": true, 
      "copy": true, 
      "options": [ "", "SharePoint", "Agent Appointment", "Agent Registration", "AR Overdue", "Business Travel Approval", "CAPA (Corrective Instruction)", "Cash Advance Approval"]
      }

We only accept bug reports against HEAD. You're expected to update Phabricator before filing any issue. Thanks!

Sorry I raised T8436, as this ticket is focus on search custom field. so I re-open it again as I still can re-repro it on list field, below is my custom field. can u please verify a list field to see if it is fixed, if so I may need to update my code to latest.

The index should update without needing the daemons, but that code did get touched in connection with T6367, so maybe I fixed something by accident.

(confirmed did not repro when I made another new task either)

Repro'd for me then I edited the field and it didn't repro anymore. Maybe I had a daemon error or something, or all the changes here fixed it?

Seems OK here, here's the create / detail / search UI:

I'm updating my instance but will confirm it still repros when its back up

Thanks!

{"mycompany:estimated-hours": {"name": "Estimated Hours", "type": "int", "caption": "Estimated number of hours this will take.", "search" : true}}

One thought -- what type of field were you using? I tried reproing it with an "int" field, but maybe the issue is with certain field types or something like that.

I can't reproduce this:

If I read all this correctly, this was asking for the status of two existing bugs and reporting a third. I updated the task description to include links to the actual pertinent tasks here. Note I may have erroneously created the third task but I couldn't quite find it.

We are very unlikely to ever support this.

I can't reproduce this at HEAD, so I think you're either out of date or this was fixed recently (although I don't recall fixing it).

people type random junk in the next block to celebrate their freedom

FWIW It would be cool to have a list of links. We use a free text field for support cases (many external tickets:one internal ticket) which mostly working but sometimes people type random junk in the next block to celebrate their freedom.

This is possibly tricky because the user can enter some unparsable time format in their preferences, but we can assume that users mostly enter reasonable time formats until we have evidence to the contrary.

OK, it does appear to save the correct time. I'm pretty sure it did not use to work in a bit earlier version (like a week ago) of Phabricator where it would just disable the field as if no datetime was entered (or was it some configuration I've changed in my recent installation) – sorry about the confusion.

When you enter "23:00", what does it do? What did you expect it to do?

This is not really limited to custom fields: all "Order By" options could benefit from an ASC/DESC toggle...

This new bug sounds like a different manifestation of the same problem: https://phabricator.wikimedia.org/T94155

That is correct (reproduced with https://phab-02.wmflabs.org/T17). Updating the task...

I don't think the "without a description" part is correct. I think just creating a normal task with a normal description is enough to seed the problem. The custom field value is not set at creation, but only when someone edits the task (even without touching the custom field at all).

Yea. Maybe I should explicitly say that somewhere to avoid confusion. :)

Ah, now I see that @jdloft here and Negative24 in Wikimedia might be the same user. :)

This might be the reason behind Phabricator should only notify changes to the "Security" field if it is indeed changed in Wikimedia Phabricator.

Would love to see date fields supported.

Via IRC, the account.editable option currently locks "Real Name", but it would be more flexible to make this an option on the field itself.

We don't plan to implement this in the foreseeable future. If you need extremely granular control over field permissions, we recommend considering other software which is better suited to heavier process-oriented workflows.

Broadly, I'm not too concerned about the efficiency of pushing too excessive updates: the big advantage to always writing the entire correct state is that for a large class of bugs, we just fix it and move on and the dataset self-heals without an invasive migration. But we obviously shouldn't be deadlocking.

Another user (ki9a) hit this in IRC too, off API calls, with this trace:

Yeah, we can let you disable the commit message integration of fields without getting rid of the web UI integraiton.

T7329 is like T7327 basically; the user in T7329 was hitting the "Projects:" field and I'm guessing would want to get rid of it for their workflow purposes.

T7327 discusses [ ] Show on commit message template.

We have a similar request in Wikimedia that could be solved in the same way: Allow sorting by oldest and newest in Date Update/Created in search queries

Thank you Chad, for taking this up. I am trying to understand the code, and attempting to implement this functionality.

It's our general recommendation to installs that have such specialized needs to use a software product better suited to the task.

Our list of company users is here -- https://secure.phabricator.com/w/usage/companies/