If there is only one account of type Adminstrator and it is demoted to type
Standard the user can be left unable to unlock panels and perform other
Administrator tasks - prevent this by only allowing the Account Type to be
changed when the account is a standard user or, in the case that the account
is an Administrator, when there is one or more other Administrators.
https://bugzilla.gnome.org/show_bug.cgi?id=690246
This prevents users from setting invalid real names for accounts by
editing the name from the user panel. This applies the same check as is
done when first adding the account.
https://bugzilla.gnome.org/show_bug.cgi?id=699940
As a user was not set on the password dialog yet. Also make
sure that we do not try to update the password strength label
before anyone has entered anything in the dialogue itself.
Now that another panel is using ActUserManager, the one the
user panel is using may already be loaded when it starts up.
It was not dealing with that gracefully.
This makes loading faster, with less I/O, avoids unnecessary
code duplication (around 1k lines shaved), and ensures that
all the panels link and work appropriately.
By the same token, it will stop external panels from being
created, and loaded.
https://bugzilla.gnome.org/show_bug.cgi?id=690036
* By displaying the username we get the unix user name for
local accounts, and the full login name for remote accounts.
* Can now differentiate between accounts with the same display
'real' name.
* Can see the full login identity of remote accounts.
https://bugzilla.gnome.org/show_bug.cgi?id=681767
* Creating the add account dialog as the panel gets created
means that realmd is invoked, network discovery is done
and so on. Not optimal.
* We also don't really need to cache the account dialog,
and can create a new one for each [+] click.
https://bugzilla.gnome.org/show_bug.cgi?id=681852
This also adds another out parameter to pw_strength(), which is a discrete
indication of the password strength (to be used with GtkLevelBar). The
advantage of having such a parameter back from pw_strength() is that we
can make sure the fill value and the hint string change at the same
time, for better consistency.
https://bugzilla.gnome.org/show_bug.cgi?id=679984
More clear scoping and interaction with running actions in
UmAccountDialog. In later 'enterprise login' patches we have long
running actions that's why this needs cleaning up.
In particular:
* Show errors as children of the dialog.
* Errors don't make the account dialog go away, user can correct
problems.
* Use more standard GAsyncResult style callbacks:
um_account_dialog_perform() um_account_dialog_finish()
* Disable controls while the operation is happening.
* Allow the user to cancel long actions in UmAccountDialog by
pressing the cancel button.
https://bugzilla.gnome.org/show_bug.cgi?id=677548
About half-way through the user list, vertically, the user's name
would get cut off. Showing the treeview headers showed that the
"automatic login" pixbuf was added in a separate column.
To make sizing easier, and avoid the user's name being cut off
half-way through, add the "automatic-login" icon in the first column.
https://bugzilla.gnome.org/show_bug.cgi?id=659998
We were leaking various references, leading to failures to populate
the list upon reloading, or to segfaults. With this commit, all
created user objects, as well as the user-manager object are
finalized when the panel is unloaded.
gdm can't handle this currently, so prevent this situation
from happening. Forcibly turning off the autologin when an
account is disabled is a slightly odd side-effect, but
good enough in practice.
https://bugzilla.gnome.org/show_bug.cgi?id=649816