commit "Do not ask for root permissions when it's unnecessary" makes it difficult to add a new user. Refs: https://cgit.kde.org/user-manager.git/commit/?h=Plasma/5.8&id=a666712102be7ef4dd48202cc2411921fc4d392b and https://phabricator.kde.org/D3102 Steps to Reproduce: 1) Open user manager and attempt to add a new unprivileged user, entering username and password 2) Click apply Actual Results: - No pinentry etc authentication dialog to approve the new user. - Cursor switches to the 'I'bar' and remains that when hovered. - The user-list is not updated with the new user. - The new user was not added to the system. Note: With some ticking and unticking of the administrator option and adding/removing a real name etc, it seems possible in some cases to trigger a case where the authentication dialog is produced and the new user is added. Expected Results: As with user-manager prior to this commit, an authentication dialog box should be produced for permission to add the new user to the system, and this should result in the new user begin created and appearing in the user-list Additional Information: I see the same issue on KDE Neon user edition. Building user-manager with the referenced commit reversed and no other changes, restores the functionality to it's previous working state.
I can confirm this one. My observed behaviour reported here: https://www.kubuntuforums.net/showthread.php?71029-Zesty-Testing&p=395985&viewfull=1#post395985 I also have the two -staging repos enabled [for frameworks and Plasma 5.8.4]. When I go to System Settings > Account Details > User Manager, give it a login name. real name and password, the cursor never changes back from the text entry I-beam to a pointer, and Apply seems to do nothing.
Same behaviour confirmed in chakra's Plasma 5.8.4
same hear on Neon-/dev/stable ,,,,,cant add user , no authentication dialog.
I get this one but randomly. Hit or miss. I can add and modify users, sometimes they disappear from the panel as soon i leave "user manager" window some other times i need to modify them in order for it to happen. A directory for the newly created user and the ones that disappear alone, is always created in "/home". I have to remove manually the ones from the users that disappear alone otherwise the system detects that said username is already in use although no user is shown on the panel with said name.
Git commit f2c69db182fb20453e671359e90a3bc6de40c7b0 by Harald Sitter. Committed on 06/12/2016 at 10:54. Pushed by sitter into branch 'Plasma/5.8'. Revert "Do not ask for root permissions when it's unnecessary" Summary: This reverts commit a666712102be7ef4dd48202cc2411921fc4d392b. This broke adding new users when not setting realname or adminflag (i.e. at present there is no way to create a !admin user at all). Distributions, as we are still 3 weeks away from 5.8.5 I'd advise patching this to restore working behavior for the time being. The problem in particular is that the model gobbles up setData requests to new rows and forwards them to newUserSetData which in turn caches them until username&realname&admin are present and only then forwards the call to accountsservice. By calling setData on-demand the three fields are not set unless they in fact all where "toggled" from their default. I suggest that the noop decision be moved into the setData itself. In there it should be possible to accurately decide whether or not the data actually changed and accountsservice needs to be called. (Ideally though IMO the collection in newUserSetData should be gotten rid of. I haven't had a close look, but creating the user with random data for everything but username and then manipulating it on the subsequent setData calls should be a more future-proof and reliable approach) CCMAIL: kde-distro-packagers@kde.org CCMAIL: larrosa@kde.org PHAB: https://phabricator.kde.org/D3102 Reviewers: davidedmundson, mart Subscribers: antlarr, plasma-devel Tags: #plasma Differential Revision: https://phabricator.kde.org/D3605 M +10 -20 src/accountinfo.cpp M +2 -0 src/lib/accountmodel.cpp https://commits.kde.org/user-manager/f2c69db182fb20453e671359e90a3bc6de40c7b0
*** Bug 373432 has been marked as a duplicate of this bug. ***
*** Bug 373874 has been marked as a duplicate of this bug. ***