Improved support for bundle options, configuration, and managing per-bundle fields

Having all the operations in one table does look really clean. I think that the edit operation is a little deceiving, as it does not take you to a place to edit anything related to the bundle, but it takes you to the list of entities of that bundle. Also we might want to get rid of the tabs since everything that can be done (all operations) can be accessed from the table.

The patch no longer applied, so here is a reroll.

Some major changes were required to deal with the fact that in the interim, a "bundle_form" feature was added to the module to allow bundle properties to be created, but it was only on the form for editing existing bundles, not for adding new ones. So this patch now consolidates those forms so that it works in both places. Consequently, I'm changing the issue title a bit.

Other small changes from the earlier patch (in addition to the reroll which fixed conflicts):

1. Fixed regression in the page title (the previous patch made it say "Edit", but it should be the bundle label as before).
2. Went back to $form['entity_type]['#value'] rather than $form['#entity_type'] (and similarly for the bundle), since there's no real reason for this issue to change that (and also, it avoids some conflicts with the Entity Translation module; see #1846104: Entity Translation shouldn't assume $form['#entity_type'] is a string).

In response to #3:

I think that the edit operation is a little deceiving, as it does not take you to a place to edit anything related to the bundle, but it takes you to the list of entities of that bundle.

Hm... That's not what I saw when I tested the original patch here against the RC1 release (or the new one against the latest dev code). The Edit tab allows you to edit the bundle, and the "Entity List" tab is where the entities are listed.

Also we might want to get rid of the tabs since everything that can be done (all operations) can be accessed from the table.

The Node module uses both for its bundles (tabs in addition to table operations), so I don't think it's a good idea to deviate from that pattern without a reason. Personally, when editing content types, I often switch back and forth between "Manage Fields" and "Manage Display" a lot, so having them as tabs is actually very useful.

Made a couple small fixes:

1.    $form['bundle_label'] = array(
   .....
   -    '#description' => "A Human readable name for the bundle",
   +    '#description' => t('A human readable name for the entity type'),
   

   This change from the original patch was incorrect.

2. The code in the submit handler which tried to print different messages depending on whether the bundle was new or not didn't work correctly.

We need the ability to turn off some of the default messages this module assumes namely ("Entity {$entity->id} - @entity_label has been saved"), this patch adds to the work above to provide an option on the entity type to disable these messages. For example we use this to create a list of users who are subscribing to a newsletter the message Entity x has been saved is meaningless and confusing to them.

this issue and many other just stand there for RTBC,

1.Are these issues were fixed by other methods?
2.Are these issues still relevant

in any case either issue owner or the patch provider or maintainer should close this with some note

we are confused on so many patches or in the state of needs review
Should we patch the module with this patch?
could some one please update them for relavance

@kaizerking is there something in the patches for this issue that particularly interest you? If so, try it out, and give feedback. What is confusing you about the needs review status on patches? All that simply means is that we need more feedback from people that care about the functionality they are addressing. This here is useful, and will get in when we get to that point in the queue of important things, but I do not believe is critical functionality. I am willing to be persuaded otherwise.

that means the status "needs review" of any issue is relevant to today's status of the module?

Its been a couple of weeks since I did issue cleaning, but I would say that the majority of issues that have patches are not irrelevant. If you still have your doubts, go ahead and comment on the particular issue you are interested in, and I could quickly let you know where we are at. The only thing that I feel a little out of the loop in is the language stuff, but I am planing to catch up on that soon. Also it is important to keep in mind that a 3.x branch of the module is now being worked out, so any features that did not make it to 2.x will have to be worked out in 3.x. Bugs, and other critical fixes will be added to 3.x and then rolled to 2.x.

I am aware that there will be always some issues too specific. I am not particularly interested in any patch
just was searching to see the status of the module for usability
I would say, it will be a good idea to update the issues so that it will be clear on, if it is not relevant or planned for 3.x. you are the best judge.
one may not need them but needs review status will be confusing, because some time maintainer takes different approach and actually the issue is fixed, and que is not updated because the patch becomes irrelevant.
I see this module as back bone for building any site especially in the current D8 approach scenario.
my apologies for bugging you on this.

sorry i did not intend to change the status inadvertently changed

Here's a version of #6 brought to rc2, needs more work to chase HEAD.

This bit has been left out on eck_entity.inc for the moment as conflicts with #2006710: ECK has some weird messaging
Once that's in, we can bring it back.

+   if (variable_get('eck_default_strings_' . $entity->type, TRUE)) {
+     drupal_set_message(t("Entity {$entity->id} - @entity_label has been saved", array("@entity_label" => entity_label($form['#entity_type'], $entity)) ));
+   }

We're dropping support for Drupal 7 since it has officially reached end of life on the 5th of January 2025.