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: [0]

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.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-03-23/f32-blocker-review.2020-03-23-16.00.txt

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,
https://bodhi.fedoraproject.org/updates/FEDORA-2020-0c3914e282

Please test to see if that helps

(In reply to Rex Dieter from comment #6)
> When kf5-5.68 gets pushed to -testing,
> https://bodhi.fedoraproject.org/updates/FEDORA-2020-0c3914e282
> 
> 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[1743]: 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: [0]

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.

[0] https://meetbot.fedoraproject.org/fedora-blocker-review/2020-04-13/f32-blocker-review.2020-04-13-16.04.txt

This message is a reminder that Fedora 32 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 32 on 2021-05-25.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '32'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 32 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 32 changed to end-of-life (EOL) status on 2021-05-25. Fedora 32 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

So I re-tested this to be sure. It's still basically true, but I think the UI is clearer than it was as described above. The fields are now 'Name', 'Username', 'Account type', 'Password' and 'Confirm password', and the button is 'Create'. It starts out grey, and stays greyed out until you complete all fields including 'Name'. Arguably it could be optional, but I think it's fairly clear as it stands. So, setting CLOSED CURRENTRELEASE.

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 500 days