Description of problem:
It's impossible to create another user account through KDE System Settings. Nothing happens after filling out new user details and clicking on "Apply".
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Open System Settings
2. Click on "Account Details" and "User Manager"
3. Click on "New User"
4. Fill out username, click on "Apply" button
New user is not created. It doesn't make a difference if you create user as an admin or not, or if you fill new user password.
It should be possible to create a new user from GUI in KDE Spin.
Mar 20 11:48:12 localhost.localdomain systemsettings5: Couldn't load plugin: "The shared library was not found."
This happens also with plasma-systemsettings-5.18.1-1.fc32.x86_64 which was part of Beta Compose.
Proposed as a Blocker for 32-final by Fedora user frantisekz using the blocker tracking app because:
This *might violate https://fedoraproject.org/wiki/QA:Testcase_desktop_login .
Discussed during the 2020-03-23 blocker review meeting: 
The decision to classify this bug as an "AcceptedBlocker" was made as this is considered a violation of the "Default application functionality" Final criterion. System Settings is not currently among the specified apps for KDE but we agreed in the meeting that this was an oversight and it will be added, thus this bug can be accepted.
I see no reason this cannot be only a FreezeException.
That said, there's a good chance kf5-kcmutils-5.56.0 may fix this (the "couldn't load plugin" error anyway), builds underway.
I think we all basically thought this is a pretty prominent feature that ought to work at release. But let's worry about it if we can't fix it :)
When kf5-5.68 gets pushed to -testing,
Please test to see if that helps
(In reply to Rex Dieter from comment #6)
> When kf5-5.68 gets pushed to -testing,
> Please test to see if that helps
Why is it still pending? F31 and F30 updates of kf5 were already pushed to testing :/ ...
I just expicitly requested -testing queue'ing. Apparently the new side-tag feature doesn't do that automatically (as I'd expected).
I have not run into this problem since several composes.
It absolutely works on plasma-systemsettings-5.18.3-1.
I checked for the plasma version and my version is still the 5.57.
I cannot reproduce this bug on the 20200328 compose with the above versions, but I cannot verify the 5.58 version requested for testing, pulling the VERIFY back.
Frantisek, can you please re-test this with a few different composes and with the update Rex linked, and confirm where you do and don't see it, and whether you think it's still currently broken?
Installing FEDORA-2020-0c3914e282 doesn't help. Also, that update was ejected from push :/
I am still seeing:
Mar 31 10:22:24 localhost.localdomain systemsettings5: Couldn't load plugin: "The shared library was not found."
Will try some other compose in a bit.
I can reproduce it on Fedora-KDE-Live-x86_64-32-20200328 . Both with and without FEDORA-2020-0c3914e282 installed.
kf5-kcmutils-5.67.0-1.fc32.x86_64, newer than what Rex suggested with possible fix. That is present in 20200328 compose already.
The other thing I've noticed is that in order to hit the issue, you must not fill "Real Name" field in system settings. It's not obvious that it needs to be filled in, but I am not sure about blocking status
Adjusting summary, then. I guess this might explain why Lukas could not reproduce - Lukas, did you fill in a 'Real Name' when you tested?
Yeah, I can confirm, that I was always filling in the Real Name.
Since this has changed the nature of the bug (it's not completely broken, it's broken only if you don't fill out a specific field - I tested it now), I re-propose this for a blocker discussion.
We did actually discuss that at Monday's meeting, the vote was not conclusive. I'm still a tentative +1 as I think it's probably fairly common not to fill in the Real Name field and there really isn't any reason people would hit this bug and then think "oh! of course! to avoid it, I should fill in the Real Name field!" - I don't see how most people would infer that. We can of course document it in Common Bugs, but we know lots of people don't read that either.
We did agree in the meeting that Rex would look at whether it would be possible to make the Real Name field mandatory as a workaround for this; I'd count that as an acceptable resolution.
Discussed during the 2020-04-13 blocker review meeting: 
The decision to classify this bug as a "RejectedBlocker" and an "AcceptedFreezeException" was made as, while it's a close call, with the additional info that populating the 'Real Name' field works around the bug, we agreed this isn't quite serious enough to block the release on, if it is not addressed by Final we will document the workaround in commonbugs.