users-admin does not sort when Name/Login/Homedir field clicked

Bug #259163 reported by Jordan Erickson on 2008-08-18
This bug affects 1 person
Affects Status Importance Assigned to Milestone
gnome-system-tools (Ubuntu)

Bug Description

Ubuntu 8.04.1 (Desktop i386)
gnome-system-tools 2.22.0-0ubuntu9

This is probably the main reason that I train my clients to use KUser instead of the default users-admin tool in Gnome - you cannot sort the fields alphabetically (which is a big problem when you have hundreds of users).

When running users-admin from shell, and attempting to sort by "Name", the following output is as follows:

(users-admin:14188): Gtk-CRITICAL **: gtk_tree_sortable_get_sort_column_id: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed

(users-admin:14188): Gtk-CRITICAL **: gtk_tree_sortable_has_default_sort_func: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed

(users-admin:14188): Gtk-CRITICAL **: gtk_tree_sortable_set_sort_column_id: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed

P.S. Should I file a separate bug for a feature request of "Search Users" functionality or similar?


Jordan Erickson (lns) wrote :


Changed in gnome-system-tools:
importance: Undecided → Wishlist
status: New → Confirmed
Jordan Erickson (lns) wrote :

Wishlist? Don't you all think that sorting is kind of important for any system with > 10 users? This is pretty basic functionality that I would assume just works OOTB...Wishlist doesn't sit right with me on this.

David Groos (djgroos) wrote :

There needs to be some kind of out-of-the-box solution for this--hands down, unless of course you believe that the only people who would use GNOME on a server would be a parent managing a household LAN. This is acceptable because there would be only a few users.

But, I argue, there is a place for people like teachers who don't want to (and shouldn't have to) dive into the CLI to manage users. I've got about 130 users and I need to alter group membership often. If you can't alpha-sort a list of 130 users you have to plow through the unsorted list, examining each individual to see if it is the person you are looking for--unpractical. Wouldn't it be simple to make it so that you could click on the column heading and sort that list A-->Z or click again and it sorts it Z-->A.

This doesn't seem to be a wishlist item but indeed a potential deal-breaker for many of the users we want to bring into the Ubuntu fold? Thanks for your work!

Steve Jackson (aearenda) wrote :

I find it hard enough managing my tens of users on an LTSP system using this tool without proper sorting, it must be a nightmare with hundreds! I believe this issue should receive a higher priority. Clicking on column headings to change the sort order is just expected behaviour these days.

Gavin McCullagh (gmccullagh) wrote :

I've been looking through the code for this and am adding some notes here in case they help anyone else (or me to recall later).

As Jordan observes, these errors are telling us about the problem:

(users-admin:724): Gtk-CRITICAL **: gtk_tree_sortable_get_sort_column_id: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed
(users-admin:724): GLib-GObject-WARNING **: invalid cast from `GtkTreeModelFilter' to `GtkTreeSortable'
(users-admin:724): Gtk-CRITICAL **: gtk_tree_sortable_has_default_sort_func: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed
(users-admin:724): GLib-GObject-WARNING **: invalid cast from `GtkTreeModelFilter' to `GtkTreeSortable'
(users-admin:724): Gtk-CRITICAL **: gtk_tree_sortable_set_sort_column_id: assertion `GTK_IS_TREE_SORTABLE (sortable)' failed

What seems to be happening is that the function create_users_model() in users-table.c is creating a GTKTreeModel of type GTK_TREE_MODEL_FILTER instead of eg. plain type GTK_TREE_MODEL. When the code in create_users_table() calls gtk_tree_sortable_set_sort_column_id() this fails because the GTK_TREE_MODEL_FILTER is not sortable.

There is some discussion on this issue and a proposed solution here:

This is all I have gleaned so far and may be well wide of the mark, but I shall persevere.

Gavin McCullagh (gmccullagh) wrote :

I've reported this bug upstream to the gnome developers and linked that bug to this launchpad bug.

Changed in gst:
status: Unknown → New
Milan Bouchet-Valat (nalimilan) wrote :

Regarding your comments on bug 379944: I'm not sure how Edubuntu people work, but you're working on a fix based on the release in Karmic! In Lucid the column headers are gone, so that can't be fixed that way.

Could you explain what's the main use case that justifies we need sorting users? I think we should make the default sorting more useful then, e.g. sorting by login instead of keeping the order from /etc/passwd.

Gavin McCullagh (gmccullagh) wrote :

It's a while since I've actually looked at this. There was a "bug day" coming up among edubuntu developers and I mentioned this bug as one which was causing problems for some people. Jordan said he had a fix, though I'm not sure what version that was against.

On an LTSP system, it's not uncommon to have hundreds of users. As it was, the gnome users-admin showed an (effectively) unsorted list of people which made it very difficult to use with large numbers of accounts. For this reason, some users had installed the KDE user admin tool.

(the thread entitled "Directory tools for Edubuntu server")

The first step that seemed worthwhile was to fix sorting of users so you could find people. Searching might also help.

Does the new version add some feature to help in this scenario?

Milan Bouchet-Valat (nalimilan) wrote :

The new users-admin is not really best designed for systems with hundreds of users, since it takes more vertical space than the old one: see the column on the left of the dialog at [1]. I'm not sure that's a real problem, though. What we could do is sort users by login, and use gtk_tree_view_set_search_column() so that you can type-ahead the beginning of the login to find an user. How does that sound to you and Edubuntu people?

(Anyway, the biggest problem for now is that we don't support LDAP, but that's another story...)

This bug is not high in my priority list since I have to fix all regressions before we enter feature/UI/string freeze, and then I'll start tackling this kind of little issues.


LaserJock (laserjock) wrote :

After talking with Milan and others on IRC, it looks like my patch is pretty pointless. On the other hand, the new UI is slick and looks nice for typical users. I think maybe we want to solve these "mass-user" issues elsewhere.

So if you don't have more proposals about this bug, I'll try to find the time to sort the list by login name. Other ideas to help managing many users are also welcome, as well as patches (this one isn't too hard)! ;-)

Changed in gnome-system-tools (Ubuntu):
status: Confirmed → Triaged

So in users-admin 2.29.90 users will be sorting according to their login, and search-as-you-type for the tree view is using the login too, so that people can easily find a user when there are many of them. This will be for Lucid.

Fix released upstream with the gnome-system-tools 2.29.90. (Even if upstream task is not updated correctly.)

Changed in gst:
importance: Unknown → Medium
status: New → Expired
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.