Problem/Motivation

For three content entity types (menu_link_content, shortcut and taxonomy_term), in respective overview form, the operation list is hardcoded (e.g. core/modules/taxonomy/src/Form/OverviewTerms.php:269).
If I add a new operation via the hook_entity_operation, the new operation don't appear in the list.

Take taxonomy_term as an example:

Define the new operation

function mymodule_entity_operation(EntityInterface $entity) {
  if ($entity->getEntityTypeId() == 'taxonomy_term' && $entity->hasLinkTemplate('mymodule-link')) {
    return [
      'my_operation' => [
        'title' => t('My operation'),
        'weight' => 50,
        'url' => $entity->toUrl('mymodule-link'),
      ],
    ];
  }

The new operation don't appear in the list /admin/structure/taxonomy/manage/{taxonomy_vocabulary}/overview

Proposed resolution

For me, each entity could provide his operation list.
I would add (like linkTemplate):

  • In the entity type (\Drupal\Core\Entity\EntityType): To replace the hook_entity_operation, a couple of method setOperation() to add operations and getOperations() to retrieve all operations defined for the entity type
  • In the entity (Drupal\Core\Entity\Entity): a new method operations() the get the operation list for one entity
  • Each entity (e.g. taxonomy_term \Drupal\taxonomy\Entity\Term) can override this method to add own specific operations

Remaining tasks

Discuss
Writing the patch

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

vpeltot created an issue. See original summary.

woprrr’s picture

I think this issue is a part to [#1823450: [Meta] Convert core listings to Views] and opérations links are correctly recover in operation collumn in this case. But i am all in your proposed solution to implement an setOperation / getOperation methods in Entity/EntityType interface.

cilefen’s picture

Is this in fact a regression from 7 and therefore, a bug?

dawehner’s picture

Yeah I don't get the point either, isn't hook_entity_operation exactly for that usecase? IMHO we should not try to add another method to the entity class, its already so full of stuff.

Version: 8.1.x-dev » 8.2.x-dev

Drupal 8.1.9 was released on September 7 and is the final bugfix release for the Drupal 8.1.x series. Drupal 8.1.x will not receive any further development aside from security fixes. Drupal 8.2.0-rc1 is now available and sites should prepare to upgrade to 8.2.0.

Bug reports should be targeted against the 8.2.x-dev branch from now on, and new development or disruptive changes should be targeted against the 8.3.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

woprrr’s picture

hi @dawehner,

I understand and it's true entity class are so full of stuff ! But what we can purpose to retrive all operations available for an entity other than edit / delete ? We can't supose we need to override overview form with RouteSubscriber to re-define all form and not Form-alter (GOOOOOOOOOOOD). The real solution IMHO is migrate all overviews pages in views core like #1823450: [Meta] Convert core listings to Views to retrive dynamically all operations available Or use system core overviews system (that seem to be aborded).

woprrr’s picture

woprrr’s picture

@vpeltot Infact getOperations() method already exist on entityManager system.

I've found these solution for wait better.

we need to change

      $operations = array(
        'edit' => array(
          'title' => $this->t('Edit'),
          'query' => $destination,
          'url' => $term->urlInfo('edit-form'),
        ),
        'delete' => array(
          'title' => $this->t('Delete'),
          'query' => $destination,
          'url' => $term->urlInfo('delete-form'),
        ),
      );

By

      $operations = $this->entityManager->getListBuilder($taxonomy_vocabulary->getEntityTypeId())->getOperations($term);

That work fine and retrieve all operations available.

But to do that we need to override Original \Drupal\taxonomy\Form\OverviewTerms with another one extend it and change $operation element for each elements.

What do you think about ?

EDIT : you can seen that tricks on FormModeManagerOverviewTerms on Form mode manager.

woprrr’s picture

Version: 8.2.x-dev » 8.3.x-dev
effulgentsia’s picture

Title: Cannot add new operations for Taxonomy term, Menu link content and Shortcut entities » hook_entity_operation() and hook_entity_operation_alter() are not invoked for Taxonomy term, Menu link content and Shortcut link entities
Category: Feature request » Bug report

Seems to me that this is a bug rather than a feature request. All core forms that display operations for entities should gather those operations via hook_entity_operation() and hook_entity_operation_alter(). Having lists of these entities on something other than EntityListBuilderInterface UIs is ok, but then these custom entity listing UIs still need to gather the operations via the correct hooks.

effulgentsia’s picture

Priority: Normal » Major
Issue tags: +Contributed project blocker

Tagging as a contrib blocker, because according to #2838938: Taxonomy term overview, Form mode manager is one example of a module that needs to add operations to taxonomy terms. It's likely there are other contrib modules running into this as well.

Raising to Major as this is affecting 3 core entity types and is likely causing pain for multiple contrib modules.

effulgentsia’s picture

Untagging "Contributed project blocker", because https://www.drupal.org/issue-tags/special defines that tag for blockers to porting a contrib module from an earlier major version of Drupal. Form mode manager is a 8.x only module, so the tag doesn't apply. Furthermore, hook_entity_operation() and hook_entity_operation_alter() are new hooks for Drupal 8, so it's unlikely this issue is causing porting problems for other modules.

Leaving as Major priority though, because nothing in the documentation of these hooks says they don't work for certain entity types, and it's completely reasonable for 8.x contrib modules to want to add operations to entities of these types.

woprrr’s picture

That issue is a part of https://www.drupal.org/node/1823450 i think. If we convert that into views (standard) all problems are solved or use my trick on #10 ;) I prefer the first solution.

effulgentsia’s picture

Looks like #1823450: [Meta] Convert core listings to Views has an existing child issue for converting Drupal\taxonomy\Form\OverviewTerms to a View: #113344: Taxonomy term manager view. However, there's no patch for that yet (last patch on the issue is for Drupal 6).

I don't see any child issues of #1823450: [Meta] Convert core listings to Views for converting Drupal\menu_ui\MenuForm or Drupal\shortcut\Form\SetCustomize to Views.

Converting all of those to Views is a fairly large effort. I don't see a reason to hold up this bug fix on that.

I think #8 is on the right track. But:

$operations = $this->entityManager->getListBuilder($taxonomy_vocabulary->getEntityTypeId())->getOperations($term);

That's a clever hack to use the vocabulary list builder, but no, we need to use the term list builder. Which means we need to add one to Drupal\taxonomy\Entity\Term.

But to do that we need to override Original \Drupal\taxonomy\Form\OverviewTerms with another one extend it and change $operation element for each elements.

If you're trying to solve this within a contrib module, then yes, but since this is an issue against core, you can fix it directly in Drupal\taxonomy\Form\OverviewTerms itself.

One thing we need to decide here is whether to make the scope of this issue about fixing all 3 of the places identified here within a single patch. Or whether to open separate child issues for each of the 3 forms. On the one hand, we might want to get a fix in for Drupal\taxonomy\Form\OverviewTerms without holding it up on the other two. On the other hand, we might want to see if a similar solution applies consistently across all the places before committing them.

Either way though, uploading a patch here that does #8 with the above feedback would be a great place to start.

zalak.addweb’s picture

Issue tags: +taxonomy term
woprrr’s picture

Status: Active » Needs review
FileSize
3.68 KB

I purpose to Fixe Menu / Menu links problems in other issue to have more simple patch to test etc... That is the patch + one small fix of standards (entity_type.manager service DO use instead of entity.manager).

For Menu links the solution are pretty more complex and i do have more time to verify if all is okay. In ALL CASES we need to add tests coverages to verify if operations are correctly visible on Overview pages.

Status: Needs review » Needs work

The last submitted patch, 17: hook_entity_operation-2704387-17.patch, failed testing.

effulgentsia’s picture

Thanks for the patch!

+++ b/core/modules/taxonomy/src/Form/OverviewTerms.php
@@ -261,25 +269,9 @@ public function buildForm(array $form, FormStateInterface $form_state, Vocabular
+      $operations = $this->entityTypeManager->getListBuilder($taxonomy_vocabulary->getEntityTypeId())->getOperations($term);

Per #14, it's wrong to use the vocabulary's list builder. We need the term's list builder. #2469567: Entity operations for terms are hardcoded in taxonomy terms's overview page has a nice patch that does that, so I suggest continuing over there. Looks like there's test failures (both with that patch and this one) that might require changes to some forum module code to fix.

effulgentsia’s picture

I haven't tested it, but just from reading the code of CommentAdminOverview, it looks like those also contain hard-coded operations not using the hooks. So we'll need a child issue for that one too if there isn't one already.

Berdir’s picture

Do we want to make this a plan/meta issue and split it out into separate issues per entity type/list? We already have one for taxonomy term that's much further along and clearly not trivial at all.

effulgentsia’s picture

Category: Bug report » Plan
Status: Needs work » Active

Sounds good to me.

woprrr’s picture

Title: hook_entity_operation() and hook_entity_operation_alter() are not invoked for Taxonomy term, Menu link content and Shortcut link entities » hook_entity_operation() and hook_entity_operation_alter() are not invoked for Taxonomy term

@berdir THANKS to your intervention about that. I am totally agree .. At the begin i just want to fix taxonomy case if we try to fix all cases we finish that in 3 years ...

Per #14, it's wrong to use the vocabulary's list builder. We need the term's list builder. #2469567: Entity operations for terms are hardcoded in taxonomy terms's overview page has a nice patch that does that, so I suggest continuing over there. Looks like there's test failures (both with that patch and this one) that might require changes to some forum module code to fix.

I think it's good way... @see \Drupal\views\Plugin\views\field\EntityOperations::render views too use that method to retrives all operations. I need to investigate more but the fail is only due to changes entityManager to entityTypeManager i repatch fast !

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

kerasai’s picture

Looks like #1848686: Add a dedicated permission to access the term overview page (without 'administer taxonomy' permission) fixed the entity operations used in the term listing pages for 8.5.x and beyond.

I've attached a patch that adds the bare minimum to get the entity operations working for the terms on the admin listing in 8.4.x.

Berdir’s picture

Status: Active » Closed (duplicate)

Indeed, this is resolved, so I'm closing this as a duplicate.

Sivarama krishnan’s picture

anyone please helpme..
how to unset operation entity (like manage-fields,manage-display,edit)in drupal8
i try like below code.

/**
 * Implements hook_entity_operation().
 */
 
  function remove_entity_operation_alter(array &$operations,Drupal\Core\Entity\EntityInterface $entity) { 

                updatedisplay($operations);
}
function updatedisplay($operations){
	unset($operations['manage-display']);
}