The support cost for the current behavior is very small. The behavior of the system is obvious. Users can file precise tasks like this one which clearly describe the problem (or find this task):

This behavior is intentional; it allows users to use a credential to configure other applications without actually having access to the plaintext.

Great! I think the Herald rule is also reasonable to build down the line if some future user arrives here via search and has a different use case for it in the future.

Two-way.

There are several classes of transaction like this. One is that all actions are restricted:

(And thanks for providing access to an environment where the issue reproduces!)

@Mnkras, I think I've undone everything I did and terminated all sessions on the host. You can revoke my key at your convenience.

I can't reproduce this. Here's what I did:

T11270 describes a major issue with asynchronous signal handling in PHP 7 which I don't believe we have a reasonable workaround for.

Yes, that's synchronous signal handling.

Yes, this reproduces on a local build of PHP 7.0.8. Here's what I did:

I'm building PHP 7.0.8 locally. In the meantime, I found these possibly similar reports:

Here's a smaller, self-contained test case:

I produced this test script to try to see about version issues via 3v4l.org, but you can't write files there. Requiring C as part of a different file is important, so I don't see a way to use that.

I put the global signal handler in run(), unresponsive.

I no-op'd the constructor and put the logic in run(), still unresponsive.

I disabled the entire actual daemon behavior, still unresponsive.

Removing the SIGINT handler entirely made it responsive.

I changed the SIGINT handler to exit immediately, still unresponsive to SIGINT:

This trivial script works correctly:

The PhutilNiceDaemon daemon also does not respond to ^C.

The debug daemon does not appear to respond to an external SIGTERM (via kill <pid> either).

With --trace, the daemon isn't doing any work, and also isn't hung (just normal queries to look at the queue).

I ran bin/phd stop and saw similar behavior:

@Mnkras gave me access to the host.

I can't reproduce that either:

I can't reproduce this. Here's what I did:

Just file a new task once you have the necessary information.

This didn't have a reliable reproduction case, but from limited spot-checking of production logs I don't see it happening any more.

We need a root problem description to move forward here.

@avivey's answer is correct.

Thanks for the report! I think this should be fixed in HEAD of master. Let us know if that doesn't work or you run into anything else.

https://secure.phabricator.com/book/phabricator/article/diffusion_managing/#branches

Turns out that CustomFields sort of just work properly with EditEngine out of the box, so D16226 provides a technically-functional dashboard.panel.edit, which allows you to edit text panels like this, for example:

I don't think there's anything about this specific to Dashboards.

We haven't seen other confusion about this in context.

In the future, we might reasonably want to put tabindex="1" on the first input on form pages, like the "Edit Task" page, so that you could press tab once to quickly begin editing. If we put tabindex="1" on global search, the cost of making this change in the future will be much higher.

Phabricator has no such sidebar item. Where are you seeing this?

Can you substantiate "f" being "typically used"? Here's what I see in use in the wild from a quick survey of popular sites and software:

This feature has a tiny impact and a huge support cost.

See discussion in D15984.

/ was removed, see D15976 and the changelog:

We probably need to do almost all of this work before adding new panel types anyway, since building a new panel type on top of CustomFields would make moving everything from CustomFields to EditEngine harder.

In T9360#183602, @chad wrote:

Is [HTTPS] simple? Not sure where to start? Nothing is jumping out at me here.

The actual panel transactions that we need to update for this aren't too bad. The board transactions are a little more involved, but we can skip them.

This could still be improved, but the immediate confusion we encountered appears fixed.

We can fix the highly-tractable web UI part, at least.

(Just bookkeeping; there's no external priority on this.)

I'm moving this to "Rugged Terrain", as the best available pathway forward leaves us with dramatically higher implementation cost than the reasonable value of the feature. We can pursue this after tasks with better aligned costs and value are addressed.

Mooted from a prioritization standpoint by D16139.

That sounds good to me, should give us more clarity around the dashboard stuff.