Flag form element shows on entity delete forms

1) Manual testing ...

- OMG yep bug is real!
- Patch fixes bug

2) I think the new return early condition is comprehensive. and I'm happy that if I am wrong we can always adapt later.

3) Can't see any unwanted side effects.

+1 from me

There is no guarantee about a form mode being called edit. Might need to be configurable just like the view modes are configurable for some settings.

Form modes and form operations more or less have a 1:1 relationship.

Just look at user as an example:

 *     "form" = {
 *       "default" = "Drupal\user\ProfileForm",
 *       "cancel" = "Drupal\user\Form\UserCancelForm",
 *       "register" = "Drupal\user\RegisterForm"
 *     },

There, default is basically edit.

I'm really starting to not be a fan of non-field display methods...

Can we add a description to the "Display checkbox on entity edit form" checkbox, specifying that this will only work on entities with an "edit" form operation?

Alternatively, we can make this option node only, where we can be sure it will work as expected.

What about checking if the form is a not an instance of ConfirmFormInterface? that works for delete and also other confirmation forms which some entity types have, e.g. payments can be refunded and that has a confirm form too.

How about letting the FlagType specify what operations it should show on? Something like this.

Just looking at core entities:

default: terms, comment, aggregator feeds, contact message.

edit: node, block_content.

That doesn't scale.

My suggestion in #13 is IMHO trivial and should work fine.

Just ran into this, working on implementing #13.

This implements the suggestion of checking for the confirm form interface.

With this approach, the flags still appear on the book module's 'outline' tab. Seems odd to hardcode an exception for the book module, but I'm not sure how else to approach this...

Form modes are extensible, book.module is a good example that is added to node by another module. In that case, you wouldn't want to have it show up, but I expect that people are adding custom form modes to edit things in different places in different ways, we do that with users for example and then you might want to have it show up.

I'm wondering if we can do something based on the form display, but since that book form extends from ContentEntityForm, it might actually have a display and just not call it.

Here's an attempt to implement the approach from #22. The alternative suggestion from #24 may also make sense.

Note that even though in both 7 and 8 the config setting text for 'show_on_form' only mentions the edit form, as things are now in 7 (as well as 8) this setting also adds the element to the add form--and it works as-is too. Given this, the new method that I added checks for both add and edit operations.

I've included a test to demonstrate the current behavior. Note the only fail in the test-only patch is that the flag appears on the delete form--the add form already works.

Given this, we might also want to update the admin help text to indicate the element will appear on add and edit forms.

This is a rebase of #25.

Oops, re-roll missed adding a use statement to the closure.

Not finding anything than formatting nits, so I think this is ready to go!

Thanks everyone!

I'm going to file a 5.x issue to consider this

Sounds like a good idea. Maybe we should start tagging 5.x issues?