Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.
Maybe I'm misunderstanding this feature. For another permission ("administer forums") I get 2 users, but it says "Filtered 5 users." Shouldn't it say "Filtered 2 users."?
Check the "Allow the site administrator (uid 1) to be listed" setting on http://example.com/admin/config/people/advuser -- that setting was not being persisted to the mod's count query previously; I've just pushed a fix for that...can grab it in the nightly dev build.
Not sure about the issue described in #5 -- I think the bug might have caused by a combination of the advuser_allow_list_uid1 issue, and also an incorrect handling of paging for the new "unlimited" setting. Try out the next dev build and re-open this issue if you're still seeing problems.
Yes, the count looks better now -- I haven't done exhaustive testing, but the issues noted above are fixed, both with user 1 included and without.
Interestingly, your latest patch has added the anonymous 'user' to the list, with Status:blocked, MemberFor:43_years_9_months, and LastAccess:never. However, Anonymous is not a user but a role. None of the Action Options apply to Anonymous, and if the (interactive) user happens to include Anonymous in the selection, then applying an action will probably cause problems for the module that tries to perform that action on Anonymous.
I'm also seeing a
Notice: Undefined index: operations in theme_tableselect()
notice when I have no filter, probably caused by the fact that you've (correctly) suppressed the operations for Anonymous. However, theme_tableselect() apparently doesn't like it the way you've done it. But this is a non-issue if you remove the row for Anonymous.
BTW, if you install the Devel module and turn on its traceback error handler on your development system, then you'll immediately see those notices as you go. They usually point to problems that should be fixed, and your users will report those notices sooner or later as bugs.
"anonymous" is actually a row in the users table...this mod is using custom db_select stuff though, and wasn't correctly filtering it out; long-term it would be good to instead call core user mod's methods. For now, I've suppressed uid = 0 where appropriate.
Hopefully the notice you saw re: theme_tableselect should be taken care of now as well (I still haven't seen it before or after this change), but let me know if you see otherwise. Otherwise, kicking back to you per patch #1857602: Allow adding filters.
Comments
Comment #1
Anonymous (not verified) commentedFeature request go to the next highest version.
Comment #2
Anonymous (not verified) commentedPushing feature request to 7.x version.
Comment #3
natemow commentedPrepended table with "Filtered [count] users." Will be available in latest 7.x-3.x-dev build.
Comment #4
salvisIf I filter for a permission that no one has, e.g. "administer blocks", then I get "Filtered 1 users." (note the plural), but the list is empty!
Is the list supposed to contain user 1, even though he doesn't explicitly have that permission?
Comment #5
salvisMaybe I'm misunderstanding this feature. For another permission ("administer forums") I get 2 users, but it says "Filtered 5 users." Shouldn't it say "Filtered 2 users."?
Comment #6
natemow commentedCheck the "Allow the site administrator (uid 1) to be listed" setting on http://example.com/admin/config/people/advuser -- that setting was not being persisted to the mod's count query previously; I've just pushed a fix for that...can grab it in the nightly dev build.
Comment #7
natemow commentedNot sure about the issue described in #5 -- I think the bug might have caused by a combination of the advuser_allow_list_uid1 issue, and also an incorrect handling of paging for the new "unlimited" setting. Try out the next dev build and re-open this issue if you're still seeing problems.
Comment #8
salvisYes, the count looks better now -- I haven't done exhaustive testing, but the issues noted above are fixed, both with user 1 included and without.
Interestingly, your latest patch has added the anonymous 'user' to the list, with Status:blocked, MemberFor:43_years_9_months, and LastAccess:never. However, Anonymous is not a user but a role. None of the Action Options apply to Anonymous, and if the (interactive) user happens to include Anonymous in the selection, then applying an action will probably cause problems for the module that tries to perform that action on Anonymous.
I'm also seeing a
notice when I have no filter, probably caused by the fact that you've (correctly) suppressed the operations for Anonymous. However, theme_tableselect() apparently doesn't like it the way you've done it. But this is a non-issue if you remove the row for Anonymous.
Comment #9
salvisBTW, if you install the Devel module and turn on its traceback error handler on your development system, then you'll immediately see those notices as you go. They usually point to problems that should be fixed, and your users will report those notices sooner or later as bugs.
Comment #10
natemow commented"anonymous" is actually a row in the users table...this mod is using custom db_select stuff though, and wasn't correctly filtering it out; long-term it would be good to instead call core user mod's methods. For now, I've suppressed uid = 0 where appropriate.
Hopefully the notice you saw re: theme_tableselect should be taken care of now as well (I still haven't seen it before or after this change), but let me know if you see otherwise. Otherwise, kicking back to you per patch #1857602: Allow adding filters.