Bug 1815463 - Cannot create another user account through KDE System Settings if 'Real Name' field is not filled in [NEEDINFO]
Summary: Cannot create another user account through KDE System Settings if 'Real Name'...
Status: NEW
Alias: None
Product: Fedora
Classification: Fedora
Component: plasma-user-manager
Version: 32
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Rex Dieter
QA Contact: Fedora Extras Quality Assurance
Whiteboard: RejectedBlocker AcceptedFreezeException
Depends On:
Blocks: F32FinalFreezeException
TreeView+ depends on / blocked
Reported: 2020-03-20 10:53 UTC by František Zatloukal
Modified: 2020-04-13 19:40 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed:
Type: Bug
awilliam: needinfo? (rdieter)

Attachments (Terms of Use)

Description František Zatloukal 2020-03-20 10:53:34 UTC
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):

How reproducible:

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

Actual results:
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.

Expected results:
It should be possible to create a new user from GUI in KDE Spin.

Additional info:
Mar 20 11:48:12 localhost.localdomain systemsettings5[1724]: Couldn't load plugin: "The shared library was not found."

Comment 1 František Zatloukal 2020-03-20 11:00:05 UTC
This happens also with plasma-systemsettings-5.18.1-1.fc32.x86_64 which was part of Beta Compose.

Comment 2 Fedora Blocker Bugs Application 2020-03-20 11:02:52 UTC
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 .

Comment 3 Geoffrey Marr 2020-03-23 19:39:50 UTC
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

Comment 4 Rex Dieter 2020-03-24 17:37:46 UTC
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.

Comment 5 Adam Williamson 2020-03-26 00:51:36 UTC
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 :)

Comment 6 Rex Dieter 2020-03-26 16:45:20 UTC
When kf5-5.68 gets pushed to -testing,

Please test to see if that helps

Comment 7 František Zatloukal 2020-03-30 09:48:06 UTC
(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 :/ ...

Comment 8 Rex Dieter 2020-03-30 15:32:44 UTC
I just expicitly requested -testing queue'ing.  Apparently the new side-tag feature doesn't do that automatically (as I'd expected).

Comment 9 Lukas Ruzicka 2020-03-30 16:14:38 UTC
I have not run into this problem since several composes. 

It absolutely works on plasma-systemsettings-5.18.3-1.

Comment 10 Lukas Ruzicka 2020-03-30 16:26:56 UTC
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.

Comment 11 Adam Williamson 2020-03-30 17:51:21 UTC
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?

Comment 12 František Zatloukal 2020-03-31 08:24:12 UTC
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.

Comment 13 František Zatloukal 2020-03-31 10:08:36 UTC
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

Comment 14 Adam Williamson 2020-03-31 17:13:56 UTC
Adjusting summary, then. I guess this might explain why Lukas could not reproduce - Lukas, did you fill in a 'Real Name' when you tested?

Comment 15 Lukas Ruzicka 2020-04-06 07:31:14 UTC
Yeah, I can confirm, that I was always filling in the Real Name.

Comment 16 Kamil Páral 2020-04-08 08:35:56 UTC
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.

Comment 17 Adam Williamson 2020-04-08 16:41:27 UTC
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.

Comment 18 Geoffrey Marr 2020-04-13 19:40:23 UTC
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

Note You need to log in before you can comment on or make changes to this bug.