Can we adjust an existing test or add a new test for this?

Not too easily. We don't use any password settings in core. Except of an example in the ExampleSettingsPlugin. But that one doesn't have tests or is enabled in tests at all. Might be easier to add tests for that in QueuedTracking plugin, where such a setting is really used. But I can look into it and see if we can somehow inject a fake setting for tests only

Fair enough. With this change I'd say we probably want to have it covered somewhere as to not have a sudden regression where the password would become visible again.

I've now added a test

Thanks for adding the test, that all looks good.

One last question that just crossed my mind — shall we throw an exception when someone tries to set the password to ****** (the value of the masked placeholder)?

One last question that just crossed my mind — shall we throw an exception when someone tries to set the password to ****** (the value of the masked placeholder)?

Currently this value is simply ignored. Throwing an exception would break it, as the UI sends this value to the backend. I don't really see a solution how to change that. We could adjust the UI to avoid sending through the placeholder at all. But it would then also be not possible to distinguish if the placeholder was provided manually to the input field. So the UI would then ignore the value and not the backend...

I guess the best way around it is to implement a password validator requiring a set of different character types in a password that would prevent using six asterisk characters by default, but that's out of scope here. All good.

👍