Broad update here after T9132:

I've marked D14699 as fixing this, but it only applies to the EditEngine form, see T9905.

Our goal is always to solve the core problem, and workarounds are not something we'd generally want to add to the product. If the core problem is poor integration / discoverability between other ticketing systems, that's the problem we'd want to solve. That's Doorkeeper right now or maybe even parts of Nuance. Overall it makes more sense to me to track and resolve external monograms as first class objects than to hack something into custom fields to do something less flexible/powerful.

Well, Doorkeeper looks like hard-integrations. Situation like searchable
zendesk links are IMO more suited for simple custom fields - for example we have
customers that use Kayako, Zendesk, osTicket, etc, and simply link to those
externals with cusstom fields. Partial searches for perticular ID would be great
for all those cases, using single field like "external ticket id".

In T9921#147407, @chad wrote:

Is this feature request only for Zendesk URLs?

Exactly what @johnny-bit said. But in my specific use case, it indeed only applies to Zendesk URL's.

External ticket system sync / coordination is Doorkeeper for us. If this task is just about making other ticket systems better integrated in Phabricator, it'd just get merged over there.

this could be used with any ticketing system - most ticketing systems have constant prefixes for urls.

Is this feature request only for Zendesk URLs?

Ah, I figured out how to reproduce this.

This no longer reproduces for me at HEAD in EditEngine (see T9905), although I can't immediately reproduce it in the old editor either. Since it seems like it got fixed somewhere I'm not going to worry about it too much.

The use case I'm trying to cover is to create notifications for open tasks that are past their Due Date (custom date field that we use).

I think that should clear the way for you, let me know if you hit issues.

Our general plan is to drive custom email needs through Herald (T655) and reduce general email settings (T9161).

I'm going to merge this into T9132, as any pathway forward here runs through that.

I'm experiencing something a little different using a custom select field.

Thanks for the very fast fix, for my two test cases it works now! If I encounter any further problems related to this, I will report :)

This has been fixed in master and cherry-picked into stable (as rPc0a52201). You should be able to update to pick up the fix.

Cool, glad things are working again.

Also, we certainly disable and re-enable users occasionally, so hopefully that will continue to be a supported use case.

@epriestley, I got a flood of emails starting at 1 PM, thanks! I'm not aware of any further issues with this.

The queue has flushed so I think this is now resolved (there are no longer any publish actions backed up in the queue), can you let me know if you're still seeing issues when you have a chance?

I've deployed this to repo001 (where this instance's daemons are located) and the queue appears to be flushing. I'd expect that you'll start receiving missing mail shortly (there are about 100 affected commits in the backlog). I'll follow up in a few minutes once things flush or otherwise stabilize.

This isn't blocked on anything but not adjacent to other planned work in the near future. It likely makes sense as part of a "Projects v3" with T3670. I'll see what else is in queue and tentatively organize anything projects-related if there's some more of it.

Thanks for clarifying.

That's supported after D13618.

We have a custom field for "Task type" (feature, bug, etc). Would *love* the ability to use herald with this field.

I think T9132 is the most promising approach for reducing the complexity in exposing transaction writes in a general way.

I will get to it eventually but realistically I haven't started doing anything here. Feel free to reassign.

In my current company we are just starting with Phabricator. People are still learning their way around, but I already have few engineers (smart, awesome, capable, etc.) coming up to me and asking if it's possible to have project field required(maybe soft with a rule in Herald). Having a rule that send notification / email doesn't really do much - engineers tend not to notice notifications when tasks bounces back to them or they notice that in a few days. And having someone on the team look at such tasks regularly seems inefficient when you have a small team.

@joshuaspence are you still considering completing this?

Having the ability to mark certain fields as required would certainly address the root issue but looks like it might be a long time before this is addressed no? This task is close to a year old.