Filter by bundle in EntityConverter route param converter

What about the _entity_bundles requirement? See EntityBundleAccessCheck

Following the #8 I should say that indeed, there are cases where for different bundles you have distinct functionalities, e.g. Wanting to send a newsletter for the new blogpost content but not for a new page content. Returning 403 for the mail send page is not the best candidate to return in this case as it is really not a forbidden, it is not a functionality, non-existent.
This worked like a charm for me. Thanks.

So #2858776: Make defining bundle-specific routes easier is the issue which added the _entity_bundles functionality, which I worked on a bit.

I think if we'd thought of this approach, we'd have done this instead. I don't think we need both - so IMO we should deprecate _entity_bundles as part of this issue, and use this approach instead - less code and doesn't require the piped format to list the bundles. Needs work to add the deprecation though.

#2858776: Make defining bundle-specific routes easier facilitates some things that this does not allow e.g node/vegetable/manufacture or node/vegetable/inventory. Just saying.

Sorry, I was not thinking properly.

1.

 *     parameters:
 *       example:
 *         type: entity:node
 *         bundle:
 *           - article
 *           - news

There's an inconsistency in the format here. I would have expected either
A:

 *     parameters:
 *       example:
 *         type: entity
 *         entity_type: node
 *         entity_bundle:
 *           - article
 *           - news

or

B:

 *     parameters:
 *       example:
 *         type: entity:node:article

What we have in this patch is kind of hybrid. That seems OK to me though. (A) and the patch handle arrays better than (B), but (A) is not backwards compatible.

2. Deprecated in drupal:9.2.0 and is removed from drupal:10.0.0 Isn't that "will be removed before" by convention?

3.

 *     parameters:
 *       example:
 *         type: entity:node
 *         bundle:
 *           - article
 *           - news

The singular bundle makes it sound like bundle: article is OK. Maybe this should this be bundles in plural. And if bundle: article works, we should ideally have test coverage for it and mention in documentation.

Fair enough.

Committed f6bde54 and pushed to 9.2.x. Thanks!

I'm having trouble finding the right syntax to do what we need to do re: our "add content" routes.

Some example URLs in our client's site are:

/sales/customers            <- list of customers
/sales/customers/123/edit   <- edit customer 123
/sales/claims               <- list of customer claims
/sales/claims/234/edit      <- edit claim 234

We need to use the "edit" examples above instead of /node/123/edit in order for our menu highlighting to work. That is, when you are editing customer 123, the "Sales" menu is expanded, and the "Customers" submenu item is in bold.

The overrides we've added for edit and delete routes are working fine. But we also want to do the same for "add" routes, like this:

/sales/customers/add
/sales/claims/add

That's what I can't get working. It was working fine in D8, but not in D9. The biggest problem, it seems, is that we have no "variable" part of our route. Meaning {node_type} is not in the URL. Some of the things I tried before I found this issue worked, but made our URLs come out like this:

/sales/customers/add?node_type=customer
/sales/claims/add?node_type=claim

We don't want that in our URLs. I've also made it work by defining the paths like this:

/sales/claims/add/{node_type}

But that makes the actual URL look like this:

/sales/claims/add/claim

...which we also don't want. Using the node.add configuration from the Drupal core node.routing.yml as a starting point, adding what I've learned from this thread, I've tried everything I can think of to get this to work. This config...

example_reroute.claim_add:
  path: '/sales/claims/add'
  defaults:
    _entity_form: 'node.default'
    _title: 'Create Customer Claim'
  requirements:
    _node_add_access: 'node:claim'
  options:
    _node_operation_route: TRUE
    parameters:
      node_type:
        type: entity:node
        bundle:
          - claim
        with_config_overrides: TRUE

...gives a "Missing bundle for entity type node". I can "fix" that error by adding back something in our original config, which is:

example_reroute.claim_add:
  path: '/sales/claims/add'
  defaults:
    _entity_form: 'node.default'
    _title: 'Create Customer Claim'
    node_type: 'claim'
  requirements:
    _node_add_access: 'node:claim'
  options:
    _node_operation_route: TRUE
    parameters:
      node_type:
        type: entity:node
        bundle:
          - claim
        with_config_overrides: TRUE

Note the addition of "node_type" under "defaults". This gives a "Page not found" response.

I think the issue stems from the fact that this new "bundle" option is under the "node_type" entry of "parameters". We don't have (and don't want) a "node_type" parameter in our URL, so specifying those parameters in our routing config is not really doing anything.

Is there a way to get these URLs to work as we intended?

@ExTexan please don't use closed issues for requesting support. The best way to get help with this is probaly Drupal Answers.

@Jonathan,

Sorry about that. I figured this would be the appropriate place for my question for two reasons... 1) Previous comments have examples of how to use this feature (examples that didn't work for me), which would help anyone answering my question get up-to-speed on the issue more quickly; and 2) The devs who implemented this feature have commented here, so by default, they are following this issue; I thought they would be my best source for an answer.

But, no worries, I'll create a new support issue.

Created a revision version of this issue at #3273229: Filter by bundle in EntityRevisionParamConverter route param converter. Ideally this issue makes it in for 9.4/10, otherwise I'd prefer EntityBundleAccessCheck deprecated by this issue to be un-deprecated so we have a solution for revision parameters.

The solution implemented here does not work if we have multiple routes with same path, but for different bundles.

The ParamConverter is only called _after_ the route was already picked in Router::matchCollection().
So it is too late at that point.

I found that even the old mechanism would not have worked.
So nothing was made worse in this issue.
Sorry for the noise.

The Router::matchCollection() does not call the access checks.
It only calls $route->getCondition() which seems to provide some additional regex checks, but this does not really help to distinguish bundles.

So this is a dead end: We should not have multiple routes with the same path.