Sounds good, thanks.

On re-reading T3917 I agree it has approximately nothing to do with this, but see also T5338, where I think I go through a flow like this and it doesn't trigger an audit.

Per above, not sure how to reproduce this.

I don't believe this report, but here goes:

I'm having some difficulty figuring out exactly what this and related reports are describing.

I'm going to merge this into T3917, which I think is the broadest description of this issue.

I'm going to close this as "Wontfix". Although adding custom fields is something we may still do, I no longer expect to "rebuild" on top of that infrastructure.

D17221 adds an "Auditors" field to Herald.

making the old version of arc continue working as it did, if trivial, with new versions of the backend

goes away after upgrading both to latest

No. This task covers documenting this syntax.

After a quick look, ModularTransactions doesn't currently expose a shouldHideFormMail() hook and I may want to do something a little more tailored here, so fixing this isn't a one-liner.

This does not appear to be moving forward as a valid bug report which we can accept upstream.

For context, this is a side effect of the move to EditEngine in T11114.

Thanks, D17218 should fix this.

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.