The form still does nothing useful, but it's not a default any more

Closing per lack of feedback. If you figure out how to reproduce the bug, please let us know. Mostly, this looks like someone else (admin) changed the permissions on the application.

See also T3472.

Alright, then this is it. I think a visual indication would be helpful. But apart from that, this can be closed.

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

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

Fixed by D17188.

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.

I'm only trying to help you improve your own software - I have no personal interest in this issue being fixed. Imposing barriers on people taking a brief moment out of their day to draw your attention to bugs in your software seems counterproductive. If you choose not to accept reports of bugs that are backed up by a screenshot clearly showing the issue, then that is your loss.

For the records, Version info for that downstream instance says:
phabricator ef44831309df7b8d4b75ab653d1cd22813147c85 (Dec 16 2016)
arcanist 9c8774f9d30b921f0e4a5a10b98a7820517789a6 (Nov 10 2016)
phutil 77ace948f90c1003c2917175eb0a93c158023bdc (Nov 15 2016)

Is it test facility Master branch synced. Because there all works but here is master updated not stable.
I'm afraid that can't revert to Stable due to database changes.

So I asked a coworker to register with *his* credentials, and it turns out he can't see the email field. I strongly suspect it has to do with the fact that I already registered with the same email address when setting up the admin account initially.

Here is my ldap auth config

I tried again on a clean phabricator install (git master as of 10 minutes ago) on Ubuntu 16.04 and php7.1 from https://launchpad.net/~ondrej/+archive/ubuntu/php and still observe the same issue. So it looks like it's specific to our ldap server? Does the output I gave you above ring any bell?

Finding version information seems non-trivial if you're not an administrator of the Phabricator installation. We appear to be running 0426ce73f0e63f1900f1cc285cfa1465ea72317e.

Thank you for your extremely intensive efforts to reproduce my issue.

Please read and follow Contributing Bug Reports. This isn't a valid bug report and won't currently be accepted as is. Specifically we require version information of the install and steps we can follow locally to reproduce the issue.

If they need to bridge the difference as some fields are migrated and some aren't consider something like

For the record, D17207 is needed for any custom field implemented in accordance to this ticket (without shouldAppearInCommitMessage) not just ones in the not-editable special case.

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.

D17209 reverted on me twice if you look at the transaction logs. I can try again. Basically I'd start arc diff, which takes 1-2 minutes on my server, go edit the form, then arc diff would actually land, the changes would be reverted. Maybe it's that I started arc diff then made changes?

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:

We also encountered this bug but after updating it disappeared.

ah yep that seemed to work. I was still specifying releaseNotes for the field which I'm guessing is why it wasn't getting saved. Thanks again for all the help! If you're ever in Pittsburgh I think I owe you about 50 beers at this point.

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.

I pulled in that change and I'm still seeing the same issue. Editing the field from /differential/revision/edit/... seems to work normally, but adding it via the differential.createrevision endpoint does not.

@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.

Please follow the guidelines in Contributing Bug Reports. Specifically this ticket is missing reproduction steps we can follow locally to see the bug, and version information. We don't accept incomplete bug reports. Thanks!

Are you able to reproduce the bug on a test instance on Phacility? We need to be able to locally reproduce a bug to accept it.

Checking in for guidance in case this is the wrong way to go. I have a custom field which extends DifferentialStoredCustomField and I'm trying to convert it in the same way as the above. Thus far my field isn't being saved when calling differential.createrevision. I've included the DifferentialCommitMessageCustomField and the DifferentialStoredCustomField below.

Having recently installed and configured Phabricator for our work environment, we need to host hg repos with largefiles in it, so we can't wait for this ticket to be completed. Feel free to ask if you need some testing, as we have no development capabilities to offer for this project.

Additional info - Phab is updated to Master stream after appearance of problem.

Assuming "git extensions" is https://gitextensions.github.io/ - this is rather outside of the scope of support you can get here. I suggest you contact them to figure out how to get the PATH to be properly populated (git isn't in your path).

no no those are for the Meterology application

Theres like 20 thermometers for a health application.

also conflicts with Phabricator Health Records Application

Nobody loves making tasks and projects… what is this, a tool for PMs?

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.