Motivation
Follow-up of #2004408: Allow modules to alter the result of EntityListController::getOperations
We just need a way to tell field_ui which entity type is used as bundle for a given entity (or the other way round, might be easier and that's where the route thing already is) and then we can drop the module_exists() checks in the list controllers of those and get those links automagically.
Proposed resolution
Introduce a bundle_of annotation
and
+ * Implements hook_entity_operation_alter().
+ */
+function field_ui_entity_operation_alter(array &$operations, EntityInterface $entity) {
will add the field operations items generically so they dont have to be added specifically for each entity.
ui change (see #25)
taxonomy list is different
before there is no operation in the dropbutton for managing fields etc.
after, the operations are there:
API changes
No.
Related Issues
Comment | File | Size | Author |
---|---|---|---|
#28 | field_ui_operations-alter-2021063-28.patch | 11.26 KB | Berdir |
#25 | before-operations-contenttype.png | 280.61 KB | YesCT |
#25 | after-content-types.png | 259.26 KB | YesCT |
#25 | taxonomy-list-nomanagefields.png | 257.53 KB | YesCT |
#25 | taxonomy-after.png | 252.28 KB | YesCT |
Comments
Comment #1
BerdirSomething like this.
Comment #2
amateescu CreditAttribution: amateescu commentedThis needs to be added and documented in the Annotation class.
We also need to check Field UI permissions here, otherwise looks great!
And we also need to implement it for all the other entity types as well :)
Comment #3
BerdirRe-roll.
- Documented the bundle_of key. Right now, only field_ui.module uses it but I can think of multiple uses for this, automatically generate bundle information for example, automatically trigger entity bundle hooks in the storage controller and so on, so documenting it makes sense I think.
- Defined it for node types, contact categories, vocabularies and custom block types.
- Shuffled the weights around a bit. I think the form display links that got added accidently moved the node type edit operation between manage form display and manage display, that seemed weird, so I moved it below.
- That and the added operations for vocabularies are I think the only visual changes here. The translate link weight of the config_translation module might need an update after this though.
Comment #4
amateescu CreditAttribution: amateescu commentedLooks awesome now! Thanks, Sascha :)
Comment #5
amateescu CreditAttribution: amateescu commentedOn another look..
Should we replace this with Request stuff?
Comment #6
amateescu CreditAttribution: amateescu commentedSorry for spamming, I'll answer myself: Yes, we should: https://drupal.org/node/2032447
Comment #7
BerdirI replaced it with nothing, because I'm not actually using it :) No idea what I was thinking.
I also forgot the upload the screenshots that I made.
Comment #8
BerdirAnd the interdiff, just to make it complete ;)
Comment #9
amateescu CreditAttribution: amateescu commentedLOL, even better. Should we be worried about the test fail in #3? looks related..
Comment #10
BerdirWow, that's interesting test ;)
This should fix it.
Comment #11
amateescu CreditAttribution: amateescu commentedYay!
Comment #12
YesCT CreditAttribution: YesCT commentedThis issue was RTBC and passing tests on July 1, the beginning of API freeze.
Comment #13
catch:) is there something more descriptive that could be used for this?
Also is it needed on the base class? That could be just on config entities no?
Should be camelCase.
Comment #14
catchComment #15
catchNode types are also bundles of comments (kind of) - what happens with those?
Comment #16
Berdir@catch: This is the annotation class, there's no difference between config and content entities there. And we don't camel case annotation properties.
Not sure what to put on the description, any suggestions?
Node types are no direct match to comment bundles, and with the critical comment as a field issue, they won't be the only thing. I don't think we can do anything there.
Comment #17
Berdir#10: field_ui_operations-alter-2021063-10.patch queued for re-testing.
Comment #19
Berdir#2027131: Block type operations should be listed in the same order as Content type operations got in which conflicted with this and reminded me of this issue.
I don't have a better idea for a description, suggestions welcome, it IMHO describes what it is..
Re-roll, same approach for block type list controller now as for node type.
Comment #20
amateescu CreditAttribution: amateescu commentedI thought about that description but also couldn't find anything better :(
All the other feedback has been addressed, so let's try again?
Comment #21
apadernoI would rather use "The name of the entity type for which [the] bundles are provided."
I would also avoid using e.g. to introduce another clause; e.g. should be used when introducing a list that is exauhistive, as in the following sentence.
It should be replaced by for example, but in that case the sentence is a comma-splice. The correct sentence should be the following:
Probably, field_ui should also be replaced by the name of the module; we don't normally use the short name of a module when referring to it. We say the Node module not node.
Comment #22
apadernoComment #23
apadernoComment #24
YesCT CreditAttribution: YesCT commentedI'll do a review. :)
Comment #25
YesCT CreditAttribution: YesCT commentedlooked at fieldable things:
Some like tests, we dont need to look at.
Some dont have lists which would have operations drop downs like: comment, message, user
After enabling aggregator, I dont see a way to add fields in the ui to feeds or feed items.
custom block type and contact type lists are the same before and after the patch
content type list is the same before and after
taxonomy list is different
before there is no operation in the dropbutton for managing fields etc.
after, the operations are there:
Looking at the patch...
agrees with those here.
--
I looked for an test entity type of fieldable entities and didn't find one to unhide to see if the operations showed. so... I cant think of anything else to look at here.
--
only change I made is to have the use alphabetical. If we dont want that, patch in #23 is fine.
Comment #26
YesCT CreditAttribution: YesCT commentedonly changes are in comment wording and the use reorder. was rtbc'd before.
Comment #27
alexpottComment #28
BerdirAutomerged by git rebase, only conflicted because we moved the entity classes, so back to RTBC.
Comment #29
alexpottCommitted 703e9e4 and pushed to 8.x. Thanks!
Comment #30
BerdirCreated https://drupal.org/node/2073793.
Comment #31.0
(not verified) CreditAttribution: commentedadded resolution description, ui changes and api changes section.