Auto generate routing entries for entities based on an 'admin_path' and 'admin_permission' annotation

+1 here, awesome idea!

IMHO it would be vital that we rely on the same path/route definition mechanism that entities use already. See #2083615: Use links annotation for config entity URI like for content entities where I propose to reuse the same links{} structure that is widespread for content entities. That lets us remove the url() method implementations for most entities. I see this just proposes we establish a common URL structure for list/add/edit/delete for all config entities. I think that is in itself a good goal, but it would be good to reconcile that with how content entities do this, so we can share implementations / know-how and not a custom implementation for config entities only. My approach for the instance URLs at least solves that for the instances. It does not provide a way to autogenerate the listing but at least from the instance level, it would equally let you autogenerate. Maybe we should just use the list url link type in the links array?

Being able to specify a basic permission (possibly even separate ones per operation?) is something I always wanted to do, maybe we can do that in a separate issue, I think it's quite unrelated to the routing stuff?

And +1 on using the links stuff for this.

#2083615: Use links annotation for config entity URI like for content entities landed and can now be built off of, yay! :)

Updated issue summary.

I think #1783964: Allow entity types to provide menu items would be suitably covered by this, should we mark that as a duplicate?

Marked #1783964: Allow entity types to provide menu items as duplicate.

I will try to work on it.

This is fun as long as you want it exactly standardized. Looking at core, many entity types have some special cases and handling.

The part that I'm worried about is when it's magically generated, is that it's going to be a) harder to understand and b) harder to extend/alter when you don't want it to work exactly like the generated standard.

I'm wondering if we should pursue code scaffolding approaches instead, that generate a routing file (for example) for you, that you can then easily change and customize as you need to.

At the very least this needs work, because the routes use permissions directly rather than entity access, which is a bug and a possible security problem.

I also agree with what @Berdir said in #17: this works fine for a few entities in core, but not for all of them, let alone the ones in contrib. It also only takes some operations into account. What about #2201137: Introduce a "duplicate" entity operation, for instance?

Suppose this suitable for the most of config entities, they just need "administer" permission, but fields and instances...

This looks like a very similar problem to #2150747: Switch back to URI templates in entity annotations where generating those routes is also of key discussion now.

From my perspective the motivation is not based upon any kind of core usecase or other issue. The goal for this issue, as far as I understand the initial post is not some kind of unification, some kind of having to write less. The goal is to make the out of box DX better.

You just write your basic $entity.php file and you get some kind of admin UI for free. Yes, in the real world most entity types might need some kind of customization but you get a lot of nicer experience on the way to your final code. For example provide an add/edit/delete form out of the box would really help you to write the entity type. Additional some kind of listing (implementation differs with your personal taste) would also help you on the way.

Maybe both goals (unification/autogeneration and the better DX during development) lead to similar/the same solutions, but I just wanted to write down the thoughts.

This blocks two critical issues atm, so bumping to critical.

Whoops, guess this missed the actual critical part.

There is simply no reason EVER to use the assigned flag. You simply cannot trust people to work on something.

Regarding the actual issue. My primary usecase was developer experience during developing code, so you have at least something which can be shown really fast.
I didn't expected to actually use automatic route generation for production code, which seems to be the usecase of this issue.

Here is a basic start.

Yay, for working on this!

@dawehner++++++

1. +++ b/core/lib/Drupal/Core/Entity/EntityRouteBuilder.php
   @@ -0,0 +1,58 @@
   +    if ($entity_type->getAdminPermission() === TRUE) {
   +      $requirements = array('_access' => 'TRUE');
   +    }
   

   I don't think we should support this, as it's really a test-only use-case. Couldn't we rather have an EntityTestAccessController, that always returns TRUE?

2. +++ b/core/lib/Drupal/Core/Entity/EntityRouteBuilderSubscriber.php
   @@ -0,0 +1,49 @@
   +      foreach ($entity_type->getLinkTemplates() as $name => $link_template) {
   ...
   +            $route_builder->addRoutes($name, $link_template, $entity_type, $event->getRouteCollection());
   

   Awesome! This will allow us to expand this to more templates later on.

reroll of #25.

1 conflict resolved in the area of of RouteBulder
locally RouteBuilderTest is green.

+++ b/core/lib/Drupal/Core/Entity/EntityRouteBuilder.php
@@ -0,0 +1,58 @@
+ * Contains \Drupal\Core\Entity\Controller\EntityRouteBuildController.
...
+class EntityRouteBuilder extends ControllerBase {

Why would this be a Controller?

1) #31 I agree it makes no sense ControllerBase.. removed

2) Trivial update of Contains comment to reflect the correct class/filename.

Just pulling information together from test logs... while I mull things over.

The following tests fail with one of two common failure routes.

Tests
TermFieldTest, CustomBlockCacheTest, TermCacheTagsTest, DataTimeFieldTest

Routes
/entiy_test/{entity_test}
OR
/entity_test/delete/entity_test/{entity_test}

#2281645: Make entity annotations use link templates instead of route names is needed for this

See also #2316171: [meta] Improve DX of entity defining (if you want a UI)

Let's be a little bit more honest.

:)

I'm not quite sure why/how this is blocking criticals? Is it not the other way round?

This is postponed on #2281645: Make entity annotations use link templates instead of route names which is major, so yes I don't think it's blocking any critical issues, and nor is it critical. If we add a bc layer where routes don't get auto-generated there's no API change.

Sounds like a clear duplicate of #2350509: Implement auto-route generation for all core entities and convert all of the core entities. at this point.