Add "List content" operation to the content type administration page

Here is a first patch.

A few remarks :

1. I did that in Drupal\Core\Entity\EntityInterface\NodeTypeListBuilder to target node entities, but this could be generalized at a higher level for all kind of entities, in Drupal\Core\Entity\EntityListBuilder
2. I would suggest
   

   List content

   instead of
   

   List {node type} content

   , like the labels we have elsewhere ('List terms'), otherwise we can not guarantee the buttons width. As an example :
   

3. Any suggestion is welcomed !

@rachel_norfolk, update with suggested permission

I'm sorry, my fault, my shame.
Here is a new patch

Thanks for mentioning me, happy to help!

In the train for Firenze, I let you the remaining work! See you next time !

I would say RTBC +1, but I guess I should not make it.

As I agree with @stevepurkiss suggestions at #15, I applied them here.

@stevepurkiss, thanks for this review

Seems this is a bot failure ?

This is an adding an additional option in a difficult UI. While I think it probably will help people who are trying to view their content for the content types and end up on this page, we should have a usability maintainer verify the change, since there is a tradeoff whenever we add new options. So tagging for usability review.

Also, it's best to include before and after screenshots (not just the after screenshot) so that reviewers can compare them side by side.

Thanks everyone!

I am not convinced this is a good idea. We want to clearly separate listing UI's from editing UI's. We don't have this pattern elsewhere, and if we do we make the Name link to the relevant object. I am therefore unsure, if we should continue with this path of duplication. I like the connecting the dots, but we need to evaluate a consistent approach to it - not a one off.

Applied patch working fine sharing screenshot ...

Applied patch #43 , and it works fine in Drupal 9.5.x. Adding screenshots for reference

Patch #43 tested and Applied successfully on Drupal 9.5.x.

Verified and tested patch#43 on drupal 9.5.x-dev. Patch applied successfully.

Testing Steps:

1. Install drupal 9.5.x-dev version.
2. Go to admin/structure/types
3. Check Operations it is labeled as " Manage fields"
4. Apply patch.
5. Clear the cache and reload the page.

Test Result:
After applying the patch Manage fields label has been changed to "List content".

Can be moved to RTBC

We should add test coverage that the link works and only lists content of the expected type.

Also #29 @Bojhan of the usability team said that they were not convinced this was a good idea. This was challenged by @rachel_norfolk in #30 but I'm not sure that there has been an resolution. Going to tag for the usability team to reconsider this one.

We reviewed this issue at #3314117: Drupal Usability Meeting 2022-10-14, that issue will have a link to the recording.

For the record the participants were: myself, @benjifisher, @rkoller, and @simohell.

We agreed with the overall idea that providing a way to easily access the relevant list of content is a positive change, however we felt that adding this link under the operations was not appropriate, mainly because:

1. Everything under operations takes you to a page which sits under the specific content type, both in terms of the Breadcrumb and URL, so from an IA (Information Architecture) perspective, the user remains within the same part of the structure.
2. Similarly, everything under Operations also has a corresponding Local Task.
3. Therefor, by placing this link under the Operations drop-down, we would be creating a confusing experience, where the "List" link takes the user to a completely separate part of the admin UI, while all the other operations keep the user within the same area of the admin UI - a "sub-page" of that specific content type if you will. By not using the Operations links, we ensure that navigating back or between operations using the breadcrumb and local tasks is consistent across operations.

To address the point about precedent: What we are doing here is different to the previously mentioned examples of Menu and Taxonomy, where in those cases the "List" operation does not take you to a completely different part of the admin UI, the user remains within that part of the admin UI and still has access to the same Local Tasks and Breadcrumb when on the "List" page. If we were doing a like for like implementation, then we could use that existing precedent, however that is not the case here.

We also noted that Menu is not a good example because the List is presented on the Edit form, which results in the one form trying to do too many things and creates a poorer user experience than if the List and Edit form were on two separate tabs/pages; But that's for a different issue.

Instead, what we are proposing is to add a new column, to the left of the Operations column, which contains the proposed link. We also felt that it would be useful to have the link text indicate how many content items each content type has. This approach has the added advantages of:

1. Allowing the user to see, at a glance, how many items each content type has; This could be useful if the user wants to delete a content type and so can easily see if there are any remaining content items, this could help to prevent accidental deletion where the user didn't realise that the content type still has some content.
2. We considered whether appending this count and link to the Name column was a good idea, but concluded that a dedicated column would be better, as it is then easier to scan down the number of content items. Typically, numbers are easier to scan and parse if they are all aligned consistently.
3. For sites with large number of content types, a dedicated column further aids in making the information easier to scan and parse.

We did not have an opportunity to make any specific text/wording recommendations during this meeting, however general guidance would be:

1. Keep it short, less is more; By adding a new column we're reducing the space available to the description column, so we should aim for as small a width as possible.
2. We need to communicate both the number of items but also that by clicking the link the user is taken to a different part of the admin UI.

I'm removing the Usability Review tag, but feel free to add it back when these recommendations have been implemented, the group can then review the proposed solution/text. At that point, please ensure there are up to date screenshots in the issue summary.

I'm not actually sure if there's a good way to achieve this. For example, what happens if a user changes the key of the type filter in the Content view? Those links would now be broken.

As per #50 it doesn't look like we should go with the operation so I'm removing the Needs tests tag since we'd need a new solution.

Closing this as won't fix based on #50 and #52

If anyone feels strongly that this should be implemented and has a way around the limitations mentioned, feel free to reopen this.

For #52, how this works with other types is that there is an entity list handler that provides the link, which is then overridden by the view. If the view is altered to no longer provide the operation, then it would fall back to the basic handler (I think).

That said, I'm also a bit skeptical of the proposed alternate approach, and of introducing a new pattern just for this; a separate column seems equally problematic to an operation link for me. So (committer hat on) I also agree with the wontfix here, given that there isn't a clear UX win. If we want to close the loop for site administrators on this somehow, we should probably start from scratch with design.

Adding credits from the usability meeting and for various reviewers and maintainers.

Thanks everyone!