Remove _account from request and use the current user service instead.

This works on the real page but not in the test.

Forgot the new file, but the problem is still that the request is not available in the request.

Just in general, even if this actually touches functionality which better will be removed in the fugure, I think at least the access checker is actually helpful in various places.

-  $request = Request::create('/' . $href);
+  $request = Request::create('/' . $href, 'GET', Drupal::request()->attributes->all());

This is bogus, given the signature of the method:

Request::create($uri, $method = 'GET', $parameters = array(), $cookies = array(), $files = array(), $server = array(), $content = null)

We are going to need to set the attributes after the request is created. But really, we probably do not want to copy over all the attributes, so we need to figure out some form of whitelist.

Starting to hit this in conversion issues. What about this for now?

+++ b/core/includes/menu.incundefined
@@ -967,6 +967,8 @@ function _menu_link_translate(&$item, $translate = FALSE) {
+  $request->attributes->set('account', Drupal::request()->attributes->get('account') ?: $GLOBALS['user']);

I don't see a reason why we still need the global user? Can you please at least add a comment why this is still needed?

I have no idea *why* its needed, just that during my manual testing, the request didn't always have the account.

Let's see if the bot can tell us anything.

#2043781: Drupal::request()->attributes->get('account') may conflict with an account object loaded from the path happened.

Since maintainers are now bouncing patches for using global $user/user_access(), and spreading the ?: $GLOBALS['user'] hack around core would be unfortunate. We need to find where the _account isn't being set and fix it.

#2032553: The _account attribute on the Request is not available during web tests is the reason why this is currently failing.

#15: menu-2040065-15.patch queued for re-testing.

Reroll and fixing the test.

This should fix all of them (just tried to book ones).

Get this bug in #1938390-62: Convert contact_site_page and contact_person_page to a new-style Controller

Let's open a new issue for fixing the non existing _account in exception cases.

I can see us having to add more and more attributes individually here. Why not Request::duplicate()?

The problem I see is that you potentially override all kind of variables you would not expect to be there, like upcasted values.

#2004086: The Request service must be synthetic has the same problem.

It's not going to fly doing this every single place a new request gets created, so at a minimum there should be a helper for this to centralize the logic. But the fact we're having to do this at all smells very bad indeed.

Re-titling.

It seems to be that this would be solved by #2062151: Create a current user service to ensure that current account is always available automatically.

Yes that's exactly what I was after, postponing.

That issue's in, is this the right status change?

Nope, 'cos #2073531: Use current user service instead of _account, remove _account from the request object was already opened by me of all people.

link to 2032553