Surely there must be some sort of authentication required

Not on cli

@laoneo You saw that unit tests are failing?

Yes, as long as we are still discussing things I will not make more changes

This is what I see before and with the pr. (User 605 is an existing user.)
Is this the exact intention of this pr?

This is correct. But I changed the code and to have a more real world test scenario.

Looks good to me

i've made this test from cli

where --user adminnotexists doesn't exist , i think if passed must be checked

the password has been changed successfully

when i checked in the backend action log

it report wrong action and wrong user who peformed the cli command

Added an extra check, so the user will only be loaded when it is not a guest in the console application.

I have tested this item 🔴 unsuccessfully on 9390dea

There is an inconsistency: the test instructions without patch mention resetting the password, but the actual result states the username was changed.
Additionally, after applying the patch, I tested and confirmed that the password was changed, and the user could log in from the frontend, but no action log entry was recorded.

I have tested this item 🔴 unsuccessfully on 9390dea

the instructions refer to resetting the password, but the result indicates a username change. After applying the patch, I verified the password was updated, the user could log in, but no action log was recorded

How did you guys check for an action log entry?

This pull request has been automatically rebased to 6.0-dev.

@brianteeman pointed out this PR related to an issue I reported, and suggested that it required testing. I'm not sure I understand what stage this is at and/or if I can help in any way. I thought the 2 failed checks were some kind of roadblock - but looking at them, they don't appear to be related to the changes in this PR.

What does that status mean for the PR, and is there anything I can do to help?

These changes have heen for 6.0 but they tested it on 5.3. That's why they failed. If you use the package from uere, then you should be able to properly test it.

I haven't yet tested this against MY application/need (loading plugins with higher access levels than public), but going over the described tests above, it does seem to perform as described. When I call user:add with the --user= flag, Latest Actions shows the created user.

I do have one question though. I also called user:add WITHOUT the --user= flag, and was still able to create the user. Is that intended? I mean, it makes sense for backwards compatibility for it to run as it does in J5 - without a user, but I just want to be sure this is intended before I claim a successful test.

The behavior should be the same, when no user is specified. So your assumption is correct.

Great! Successful test then.

I have a separate comment, however, on the functionality. I have a CLI that calls a plugin event. If this plugin is in any access level other than public - it doesn't fire, even with this PR.

$this->app = Factory::getApplication();
$this->dispatcher = $this->app->getDispatcher();
PluginHelper::importPlugin('content','indexingapi',true, $this->dispatcher);
$event = AbstractEvent::create('onContentAfterSave', $contentEventArguments);
$this->dispatcher->dispatch('onContentAfterSave', $event);

As soon as I switch the access level of the plugin to Public - it works just fine.

This behavior was reported in PR #16314 but was closed before any progress was made. I thought (hoped) your PR would solve this problem as well.

Great! Successful test then.

@stutteringp0et Then go to this PR in the issue tracker here https://issues.joomla.org/tracker/joomla-cms/44618 , use the blue „Test this“ button, select your test result and submit. Thanks in advance.

I have tested this item ✅ successfully on 46193e8