Add a user:login command to generate a one-time login link

MR is in good shape except for a test failure when actually logging in with the link during a BrowserTest. The links work outside of tests but are giving a 404 inside the test. Help wanted.

Wonder if we should check for the super user access policy before falling back on user 1? Or maybe it's fine, since in most cases user 1 is going to be the primary admin, regardless of that policy.

✅ Its ready for review now.

What would we do if the site disabled the superuser via access policy? I bet some folks would ask for configuration for a fallback uid. I'm not keen on adding configuration for commands. This cost us dearly in complexity in Drush. I'm inclined to point folks to wrappers like DDEV commands, composer scripts, and Task

For #5 I think falling back is OK - we may eventually deprecate the super user access policy entirely, and that will mean giving user/1 the admin role so it can do the same thing for existing sites. If a site has a non-admin user/1 then the fallback isn't useful but also doesn't do any harm.

Configuration would mean a site either has a shared admin account that's not user/1, or has multiple admin users and needs to pick one. If there's really a big demand from that from people who won't also write a ddev command or whatever, we could always look at adding it later.

Mostly looks great, thanks! Opened a few MR threads for consideration. Not moving to NW over any of them. Very excited to see this moving forward! It's probably my 2nd most used drush command (after cr, which dr already supports).

Moshe addressed my feedback. Pipeline is green. Cleaning up the summary a bit by removing "To be determined" from a bunch of sections that aren't relevant. Title is accurate. Nothing else to complain about or improve. RTBC.

Thanks!
-Derek

+1 on RTBC

Comments on the MR.

Thanks for the review, godotislate! Addressed all points.

Also, moved the string change to #3600628: Remove misleading help text after using a 1-time login link so that this is simple and non-disruptive for 11.4.x backport.

Feedback addressed

It occurred to me that none of the tests of the command failing need a browser, since we don't have a link to test. All of that can be Kernel. Pushed a commit. Locally, it cuts the time for the new test coverage in half.

Previous (commit f98299cc) with all Functional:
Time: 00:18.475, Memory: 10.00 MB

Now (commit 73df00da) with the original Functional, and all the failure cases Kernel:
Time: 00:09.029, Memory: 12.00 MB

See attached phpunit output for details.

The Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.

Wow, had no idea that was zsh being smart and helpful. Didn't realize bash would handle this differently. But I tried it locally and see the same.

Pushed a commit to restore the newline to the default output, and to call trim() before we call drupalGet() inside the Functional test. Everything is happy locally. I assume the bot will agree. But back to NR, not RTBC, so someone else can sign-off.

Thanks,
-Derek

OK, back to RTBC.

Committed to main and pushed

OneTimeAuthentication is in 11.4.x so technically this could be backported but now we're at RC we're at patch rules.

Nice work folks

Looks like the commit didn't make it.

Pushed for real this time

We could backport this to 11.x for 11.5?

Thanks @longwave - backported to 11.x - I keep forgetting about 11.5