Just taking the site_user_list for a test drive and found a few bugs I posted. It looks like it has some potential for my needs, but would need some work. I had been planning on working up something that would work with the profile listing in the core profile module. Instead though, maybe if my needs are in line with where this module is going I could contribute some code to get it there.

All I'm looking for is a useable profile directory listing, similar to what you've done, but a simpler UI. No real need for searching, but sorting is important. Needs to be able to be filtered by role. It should work with the existing theming layer so that returned user records could be themed and include avatars.

Not meaning to be presumptuous, but here is what I would be interested in seeing changed in the site_user_list module - Note that most of my ideas would add options not remove current features. IMO it would make it more functional without removing any existing functionality.

  • Add additional admin settings to:
    • Toggle Display Options
    • Toggle Search Options
    • Filter users by roles (user list would only work for selected roles)
    • Use contact form if enabled instead of mailto links for email links; ideally would let users decide
  • Integrate with theming system to allow for custom, non-tabular listings & avatars

Also some UI suggestions:

  • Simplify the UI - add a text box & button for a simple search to top of form
  • Rename Search Options to Advanced search options & make less prominent

Any thoughts?

Comments

pukku’s picture

pukku commented
Assigned: Unassigned » pukku

Hi!

Regarding toggling the search and display options, that definitely makes sense. I can add these as permissions, so they would be available on a role-by-role basis.

I'm not sure what your item "filter users by roles" means — do you mean that you can search with the role as a criteria? Or that only certain users can see the list? Or that only users with certain roles are available to be displayed? The second option already exists. For the first and the third, you could create a small helper module that used the hooks available to do this. I'm not particularly interested in making these in the core of the module, in part because for my purposes roles aren't nearly powerful enough; you might take a look at my module Organizational Infrastructure to see what I use instead (this isn't ported to 5.x yet; I'm still working on it).

The option to use the contact form is interesting, but complicated. Is this meant to be configurable on a user-by-user basis? If so, it makes the database lookup time much slower, because we need to do an additional query for every user in the list. An alternative that I'm considering is some way to control the formatting/display of items, which would allow you to simulate this with not too much work. This works better with themeing (see below).

The current layout was intended to make it clear to users that it was possible to search / change display options; in our original version which had the searching form at the bottom, nobody saw that it existed. We then moved it up to the top, with just a simple text box and a link to the complicated version at the bottom, and still nobody saw it existed. Actually, about half of the users of my site probably still don't know that they can search or change the display options.

One problem with using theming to allow for non-tabular listings is handling the ability to sort. In fact, it's a huge problem. The sorting stuff is all based off of the standard drupal tablesort_sql and theme_table stuff, which automagically handles fixing the query string when creating links for the table header. However, it does make sense to leverage the themeing stuff for display of fields. I will look into this.

So I guess to sum up: it makes sense to make access to sorting and display settings be permissions, I think it should be possible to use theme stuff to make it possible to change the way that items are displayed, which you could use to do your contact form bit, and you could very easily use the hooks available to allow filtering by role (if you want static filtering by role, just don't give users a way to pick which roles they want filtered by). I'm not as enthusiastic about changing the location of the search and display options, but I will take a look at maybe making their location configurable. I'm not interested in non-tabular displays because then I lose sorting abilities (although if you can contribute code that doesn't make things too complex, I'm more than willing to look at it).

HTH,
Ricky

scafmac’s picture

scafmac commented

Hi Ricky,

Thanks for the thoughtful response.

With regard to toggling the display and search options as a permission. That might be useful to some folks, but I was thinking of an administrative option that applied to everyone regardless of role or permission. For example, on my site I would not want either of them to be visible for anyone, so unchecking a toggle on the admin/settings page that would disable them would be ideal. But clearly the same functionality could be achieved with the permission as well.

With regard to filter users by role, I was thinking of only listing users within the set of selected roles. For example, many of the sites I'm working on are for a university. Faculty will be listed in a department directory listing while students will not. They have separate roles. Again I had been thinking of checkboxes on the admin/settings page that corresponded to all of the roles; if none selected, all roles would be listed in directory; if any where checked, only users with those roles would show in directory. This would put the control in the hands of the site administrator to use the module in a number of different circumstances. This would again complicate the sql.

The contact question is more complicated, at least for views. It might not be a big deal to embed a flag into the table during a regen. Since users have the ability to turn on and off their contact form, it would have to be user-by-user to that extent; no need to put a link to contact form that will not work. However it would also be nice to allow a user to choose whether to use the contact form or a mail to address. At the very least it seems like many users might not want their email to be visible on a directory listing, so an option on the user edit form to enable or disable that might be a feature to consider regardless.

Designing UIs is such a crap shoot. It's funny to hear you already tried my suggestions with poor luck. Most of the time I like the advanced search boxes and I get harassed by regular users that want a clean simple "google-like" search. So I don't blame you for not wanting to change this and in fact if I can toggle the display and search options off, that would cover my needs.

I haven't used the tablesort_query api, but perhaps I'll look into it. Really, just being able to include a user profile photo in the table would be enough. I'm sure from there I could theme the table to resemble more of a list, which is all I want. I'll look into what the options are for something like this.

Would you consider a patch for the first two requests if I got something together and working?

pukku’s picture

pukku commented

Hi!

For toggling the display and search options, I would prefer to do that via user permissions — it seems to me that that's the kind of thing they're there for. Are there reasons why this wouldn't do the same thing as a setting? I will create a few new feature requests for how I see this most easily being dealt with; please follow up there...

For the filter users by role, this would be very doable with a small local module. There are two hooks, although you probably would only need to implement one. hook_site_user_list_search_form returns a form group that is added to the search options, and hook_site_user_list_restrict allows you to add join and where clauses to the SQL query. You could create a module that allows site admins to select what roles are allowed, then add the joins and where clauses to restrict all queries to those users.

With regards to the contact thing, I think that the best bet going forward is to figure out some way to allow themeing of the individual cells (how best to do that, I'm still looking at). Then, you would add a profile field that was "allow emails via contact page", and your theme function for that column would display a link to the contact page. Alternately, in a private message someone else suggested (well, implicitly suggested) that hooks to modify the view/table generation might be useful. This would allow contact.module to make its flag available to the table, and you could theme the results.

For putting images on, are the images located in some well defined place? Could you use a profile field of type url to point to the image and theme (if that was possible) the result to display the image? This would require users to be marginally comfortable with putting an image location into their profile (unless someone who gets training is responsible for keeping the profiles up-to-date).

I'm going to create a bunch of feature requests for the items I see here that make sense; could you comment on those?

Thanks,
Ricky

scafmac’s picture

scafmac commented

Hi Ricky,

Just wondering why you believe the best way to handle the restrict listed users by role should be a local module? Dependent modules make sense to me when each accomplishes a separate function. For example the ldap integration module relies on the profile module. The profile module does profiles regardless of the ldap module. The ldap module does ldap authentication independent of the profile module, it just uses the profile module to store additional user attributes - exactly what the profile module does best. No reason to add custom user attribute support directly to the ldap module when a) it has nothing to do with ldap authentication, and b) is already supported via the profile module. I believe this is the intent of hooks, so that modules that do different things can make use of the functionality of other modules to support their functionality.

I think of a local module as you describe it being used to alter core functionality of a module, something that would not benefit other module users or something that breaks the normal functionality. With regard to the role filtering, I don't understand why you want it put in a local module. It doesn't break anything the Site user list module already does, in fact it adds common Drupal functionality, so it would probably be used by many users. The local module would have no other purpose other than to add functionality to your module. It will never do anything independent of your module, so why separate it?

Are you concerned about performance, coding standards, or having to code it yourself?

Cheers,
Matt

pukku’s picture

pukku commented

Hi! Part of the complication is that there could be several different things that you want to be done. For instance, you want to be able to restrict the users who are listed in the listing to users who have certain roles — that is, a static filter. However, other users may want instead to be able to search by users who are in a particular role. Which one should I code? I guess I see small local modules as ways to make use of hooks provided by modules to customize them for particular purposes.

Also, I have no interest in filtering by role; I need to be able to search by OI entity, which OI provides by the hook structure.

Of course, this all just became a lot more complicated for the role use-case. A user's roles, as it turns out, aren't actually stored at a table level as something that can be queried with SQL. They're serialized into the 'data' field of the 'user' table. So whatever provides for this kind of filter will require one of two things: a) user_load every user and look at the roles for them, or b) modify hook_user to create some other copy of the data in the serialized column in some kind of table that can be joined against. 'a' might be feasible for a small site with a few users (I actually use something similar for a site with about 12 users, although not using this module, which is both too powerful and not powerful enough). But once you hit a certain number of users, calling user_load over every user every time you need to display the list is going to become untenable. So it will need to be dealt with via 'b'. Which is going to be a huge pain to write...

Incidentally, the status of the contact page for a user is also serialized in this 'data' column.

I have no idea how to proceed with this need at this point. Well, that's not entirely true; someone else has sent me privately a version of the module which does deserialize the data and make use of it; I need to look at what he does, but either it's going to make every visit much slower, or it's going to need to be very complex, and somehow create a table which duplicates the user data, and manages to update that whenever the user data is changed.

Do you have any suggestions for this?

Ricky

pukku’s picture

pukku commented
Status: Postponed (maintainer needs more info) » Fixed

Hi! I think at this point the only item remaining on your list to be dealt with is avatars, and I have another issue about that, so I'm claiming this is fixed.

The reason I can make this claim now is that I've just committed a site_user_list_roles module into the module which (using the new module codebase) allows restricting on the basis of roles.

Does this do what you wanted?

(If you haven't upgraded site_user_list since early May, you'll need to run update.php and update site_user_list before the site_user_list_roles module will work).

Ricky

pukku’s picture

pukku commented
Status: Fixed » Closed (fixed)
jayakrishnan-1’s picture

jayakrishnan-1 commented

1. Option to not to display the users list as it does by default when you goto site user list page.
2. Option to expand the search option when the user visits the page and not manually click on it

Are these two things possible now?

Regards

pukku’s picture

pukku commented

Hi! There are already open feature requests for these items. Before I implement them, however, I need to move a bunch of stuff around so I can do shadowing of profile items, so that it's possible to display dates.

Ricky