If you'd like us to look at it, please file a new issue following Contributing Bug Reports.

See also T3472.

I can't reproduce this, so we can't move forward. Next steps:

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

Closing for lack of feedback.

So, is it possible that the email field is shown when there is already an existing phabricator account with the same email address?

I was able to reproduce this locally -- or something close enough, at least -- by recreating the simpler graph in T12114#207542, so I have enough to move forward.

Starting arc diff and then making changes probably races, although I think that's likely pre-existing. I can look at it when arc gets another update, but I think we can't really fix it on the server side.

Actually I can't reproduce this? I did this:

I can't reproduce this issue with the information provided. To move forward:

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

There was previously a shouldOverwriteWhenBlahBlah() method that probably didn't get transitioned forward cleanly.

• I changed CIReleaseNotesDifferentialCustomField->shouldAppearInApplicationTransactions() to return true to make the web edit to work correctly. (Did you not want this field to be editable from the web?)
• I changed CIReleaseNotesDifferentialCommitMessageCustomField::FIELDKEY to integrator:release-notes (the same value as CIReleaseNotesDifferentialCustomField::KEY_RELEASE_NOTES). Although this is not strictly required, it needs to be the same in some cases to bind the CommitMessage field to the Custom field, and making them the same makes several behaviors work correctly without additional changes.
• I implemented CIReleaseNotesDifferentialCustomField->shouldAppearInConduitTransactions() to return true;.
• I implemented CIReleaseNotesDifferentialCustomField->newConduitEditParameterType() to return new ConduitStringParameterType();.

Alright, I'll take a more detailed look.

@jcox, do you have 62cf4e6b95abbebc8ae2b1591039967651188c6e (D17207) yet? That might be the fix. Nothing jumps out at me as wrong, but I can take a closer look if that change doesn't help.

no no those are for the Meterology application

also conflicts with Phabricator Health Records Application

Or use heart for favorites?

I'm going to close this since the original use case seems to have not panned out. We're still open to building this, but would like to see a modern use case driving it -- feel free to file a new request (or leave a comment here) if you have one.

We probably would not use an option to turn the feature off (versus just supporting it) so don't worry about adding it on our behalf. At the point where I was set up to convincingly test that turning the feature off worked -- and we had navigated bundle2 in some way -- I'd probably be most of the way toward proper support anyway.

It also occurs to me that Project profile menus already show up in a main menu dropdown on mobile, so we must have some PhabricatorActionView::newActionViewFromItemView(...) sort of code in there somewhere.

Sweet.

Yes, if you aren't in edit mode. Here's normal mode (includes field):

In particular, your code may just work as-is after updating. If not, compare them with those "MagicFlag" fields and/or let me know what you're still seeing?

Alright, after D17207 I think these are analogous to what you're doing?

please also add "close menu" and a label that says "menu items" and help text that says "click an item to activate it"

Yeah, I'm not aware of any real difference between them or good reason to have both. Maybe I'm forgetting something but I'm pretty sure we can merge them eventually.

I think there are two approaches:

These are now in production. I inched some other automation forward but no major changes.

They are not related. That search uses fulltext indexes (see T11922 / T11741 for recent discussion), not ngram indexes.

uhoh

Hour or two if nothing's on fire -- probably today, just later this evening.

@jmeador, I think I have a fix for your use case but it touches enough stuff that I'm going to hold it until after release promotion. Your use case is a bit unusual but should be possible to support.

(I no longer need access to the server.)

Having run the scripts on a new server the only thing I can think of is the fact that the scripts change #!/usr/bin/env php to #!/usr/bin/env php5.6

This was prioritized privately and PHP7 is now supported. Not sure I got everything, but I'm on PHP7 locally now so presumably I'll hit any remaining issues before too long. T12101 is the new informational task. We will now accept bug reports against PHP7. The documentation should regenerate within a day or so. These changes will promote to stable in about 24 hours.

There are at least some nontrivial effects, like searching for text without "maximum-scale" can imply a zoom:

Oh, sorry, you just wanted maximum-scale removed.

Here are some screenshots of Phabricator with this tag removed, as you suggest:

As you might already have guessed, this isn't a bug.

Chrome 56 has merged a fix for this so it should be moot in the not-too-distant future, although I'm not exactly sure what the Chrome release schedule looks like. If this only impacts ghost inlines for a few more weeks it's pretty tempting to just wait for it to resolve itself, but I may be digging around in that code soon so perhaps I'll take a more detailed look.