Not all calls to accountsservice require authentication and once we hit one that does and the user cancels the prompt then there might be some fields written already.
This is unexpected for the user since they expect the whole transaction to be cancelled.
To avoid this move the call to SetAccountType to the front since that will always trigger a prompt.
It's arguably a workaround for the lack of a transaction concept in AccountsService, but I don't see a better short-term solution.
BUG: 425036
This adds the column spacing into calculation for determining how many columns there are, preventing certain multiples of window sizes from having too many columns.
BUG: 428899
If accounts service is not yet running the name will not be registered
when we make our first call.
We call into AccountsService from our client code with a blocking call.
We then create a new QDBusAbstractInterface on a given service.
QDBusAbstractInterface::isValid effectively is just a check that the
service is registered. This might not be processed yet at the time we
call this. It isn't a helpful check, if it wasn't up the previous call
to fetch users would have failed. We can just remove it.
BUG: 429314
Qt 5.15 introduced new syntax for defining Connections. Fix warnings like this one:
QML Connections: Implicitly defined onFoo properties in Connections are deprecated. Use this syntax instead: function onFoo(<arguments>) { ... }
Right now, when a user changes their login password, their KWallet
password is not changed. For users whose KWallet password was the same
as their login password, this causes the two passwords to get out of sync,
and then the user will be prompted to unlock their wallet the next time
they log in. If they use their new password, it won't work. This is very
very frustrating if you don't know what's going on.
Now, when you change the login password of your own user account, and
you have a wallet named "kdewallet" (the default one) in your list of
wallets, you will be prompted to change the password of that wallet to
match the new login password. This is optional and you don't have to do
it, and you won't be prompted to do so if you don't have a wallet named
"kdewallet", which indicates that you have a customized KWallet setup
and you presumably know what you're doing.
BUG: 389030
FIXED-IN: 5.21
Fixes the following bug: Some user profile fields won't apply unless
they all have unique new values.
STEPS TO REPRODUCE
1. Start the Users KCM ("kcmshell5 kcm_users")
2. Select a user
3. Change the full name (the top-most input field) to "foo", change the
email address to "foo@example.com", click Apply.
4. Restart the Users KCM and make sure the change applied.
5. Change the full name to "bar@example.com", change the email address
to "bar@example.com" as well, click Apply.
OBSERVED RESULT: The full name remains "foo", the email address is
changed to "bar@example.com".
EXPECTED RESULT: Both fields should change to "bar@example.com".
Root cause: When the std::map used in UserApplyJob::start() is
initialized, the key-value {"bar@example.com", full name setter ptr} is
being overwritten by key-value {"bar@example.com", email setter ptr}.
BUG: 427348
Don't fail silently when an error occurs otherwise the kcm just looks broken.
Show at least an inline message so the user knows that something went wrong.
The comment was wrong. We can distinguish why an error occured. Furthermore,
even if it is a permission denied error we do not know if the user canceled
the action or if it failed for some other reason so also treat that as an
error.
BUG:425036
CCBUG:426932
FIXED-IN:5.20
CCMAIL:uhhadd@gmail.com
While there's not a graceful way to discern between user cancellation and an actual error,
the former is more likely so we bail out when encountering an error.
BUG: 422175
Laurent Montel
Marco Martin
Alexander Lohnau
Nicolas Fella
Carson Black
Guo Yunhe
l10n daemon script
Luca Beltrame
David Edmundson
Konrad Materka
Nate Graham
Alexander Potashev
David Redondo
Devin Lin