Authenticated users should not have permission to access the dashboard by default, because there's nothing for them to do there

I agree that we might want to not redirect to the dashboard, but I also think this needs some product input before we do this. Mainly because, in addition to being useless (same as the dashboard), the profile page is also ugly and does not put our best foot forward. :)

Tagging for product owner review.

Is this Drupal CMS OOTB?

If a user can register, is because they can _do_ something on the site. The solution might be having a dashboard according to what they can do in the site.

Well, the screenshot in the issue summary is for Byte.

But Byte is an example of a site template where you wouldn't have user accounts in the first place. It's a SaaS product brochure site. What use does a site like that have for authenticated user accounts?

OOTB, authenticated users cannot do anything, and they cannot register. It's up to the site to handle this, if they are creating authenticated users.

The dashboard is not only for administrators, it is for content editors too. So I don't think we should be adding additional custom logic to account for a scenario where the site should be responsible. (Not to mention I agree with @phenaproxima that there is no value in redirecting to the user page.)

Perhaps the best thing to do is to remove the granting of these permissions to auth users? It's not really clear why we are adding those permissions at all.

There's no MR here so setting back to NW.

Thanks @rajab natshah!

The tests are failing, it wouldn't surprise me if we had test coverage for this but the fails look unrelated :(

This would be a regression. The tests are probably catching that.

Where will we grant these permissions, without introducing a dependency that we shouldn’t?

This needs to be addressed more carefully. I will ponder some possibilities here.

Where will we grant these permissions, without introducing a dependency that we shouldn’t?

Why do we need to?

Because if we don’t, the only user who can see the navigation, for example, is admin.

Content editors, a role we ship with another recipe, won’t have any of these permissions by default and is not guaranteed to get them, unless we set up a dependency that we shouldn’t.

I don't really see the point of granting these permissions when they don't allow you to do anything, but I guess navigation shows you have logged in and lets you log out. We can resolve the dashboard redirect by just removing that permission I guess. Certainly, there is no value in having access to the dashboard that is empty for you.

Update the MR to only remove the dashboard permission.

OK, @phenaproxima explained to me that the reason these permissions are granted is that it's an end-run around making content_type_base depend on admin_ui -- this way, we create the content editor role and it inherits these foundational permissions from the auth role.

I don't particularly care about the dependency isolation but will leave it to him to decide whether to contort the dependencies to accommodate this, or to mark it 'won't fix' -- because at the end of the day, this is really not a huge issue. I think if a site is creating auth users they should ensure the permissions make sense for them.

With my Architecture Lead hat on, I maintain that dependency isolation is important; there's a reason it's one of the hard problems of computer science. :)

But I see where @pameeela is coming from. In practice, most people will be using both drupal_cms_admin_ui and drupal_cms_content_type_base in the same site, since they are both foundational recipes. Nonetheless, I don't think I'm comfortable tying both together; they are two of the "heaviest" recipes we offer. For that very reason, the integration should probably remain somewhat fluid.

I think I have an approach in mind which will do what we need, though.

I'm happy with this solution -- allow permissions to be ignored dynamically in certain circumstances. Combined with recipes' ? prefix, an optional integration is pretty easy.

The only thing I'm waiting on before committing this is confirmation that we could put the grantPermissionsIfExist action into core. It won't block commit either way, but if the action could get into core, I just need to open the core issue and mark this action as a polyfill that will be removed, rather than part of our developer-facing API.

On second thought, let's start with this being internal and referencing a core issue. If the core issue gets wontfixed, we can just call this action part of our API and make it non-internal.

Merged into 2.x and cherry-picked to 2.0.x.