Sort of echoing this topic (https://www.simplemachines.org/community/index.php?topic=584664.0)about search functions for the ban section, I think showing the ban status in "view all members" in admin would be pretty helpful/ is sort of missing.
I was going through the mlist the other day deleting "suspicous" accounts from it. But doing so, the number of members did not adjust accordingly to the number of deleted accounts, so I was kind of surprised. It was only later that I figured out that lots of these accounts in the list were already banned and thus not accounted for in member count.
might be somewhat complicated, I think, since (I believe) the bans are not marked as part of the individual USER record and having to search through ALL bans for each user in the user list could be resource intensive on sites that have more than a few ban triggers.
It is kind of inconsistent that if I click on Members on the top menu it will show the Position column which show the Banned users. But if I go Admin, Members, View All Members, there is no column for Position.
Perhaps the Position column can be added in Admin in future releases?
Quote from: savo on February 10, 2023, 11:49:48 AMPosition column which show the Banned users
Does it, though? All I see is the position label we assigned for certain post counts.
Quote from: Kindred on February 10, 2023, 09:20:11 AMmight be somewhat complicated, I think, since (I believe) the bans are not marked as part of the individual USER record and having to search through ALL bans for each user in the user list could be resource intensive on sites that have more than a few ban triggers.
Ok, I had no idea it was complicated. Since as an admin you can see in an account's profile when a member is banned,
profile view_banned status.jpg
I thought there must be some sort of identifying marker that can be pulled for such an account so it could be displayed in the memberlist table maybe next to "last online" or something like this, just like in the profile.
that is viewing a single user.... so, doing a search and merge of two tables is less intensive...
Searching ALL users and doing the merge is a much different story
CREATE TABLE `smf_members` (
`id_member` mediumint(8) UNSIGNED NOT NULL,
`member_name` varchar(80) NOT NULL DEFAULT '',
`date_registered` int(10) UNSIGNED NOT NULL DEFAULT '0',
`posts` mediumint(8) UNSIGNED NOT NULL DEFAULT '0',
`id_group` smallint(5) UNSIGNED NOT NULL DEFAULT '0',
`lngfile` varchar(255) NOT NULL DEFAULT '',
`last_login` int(10) UNSIGNED NOT NULL DEFAULT '0',
`real_name` varchar(255) NOT NULL DEFAULT '',
`instant_messages` smallint(6) NOT NULL DEFAULT '0',
`unread_messages` smallint(6) NOT NULL DEFAULT '0',
`new_pm` tinyint(3) UNSIGNED NOT NULL DEFAULT '0',
`alerts` int(10) UNSIGNED NOT NULL DEFAULT '0',
`buddy_list` text NOT NULL,
`pm_ignore_list` text,
`pm_prefs` mediumint(9) NOT NULL DEFAULT '0',
`mod_prefs` varchar(20) NOT NULL DEFAULT '',
`passwd` varchar(64) NOT NULL DEFAULT '',
`email_address` varchar(255) NOT NULL DEFAULT '',
`personal_text` varchar(255) NOT NULL DEFAULT '',
`birthdate` date NOT NULL DEFAULT '1004-01-01',
`website_title` varchar(255) NOT NULL DEFAULT '',
`website_url` varchar(255) NOT NULL DEFAULT '',
`show_online` tinyint(4) NOT NULL DEFAULT '1',
`time_format` varchar(80) NOT NULL DEFAULT '',
`signature` text NOT NULL,
`time_offset` float NOT NULL DEFAULT '0',
`avatar` varchar(255) NOT NULL DEFAULT '',
`usertitle` varchar(255) NOT NULL DEFAULT '',
`member_ip` varbinary(16) DEFAULT NULL,
`member_ip2` varbinary(16) DEFAULT NULL,
`secret_question` varchar(255) NOT NULL DEFAULT '',
`secret_answer` varchar(64) NOT NULL DEFAULT '',
`id_theme` tinyint(3) UNSIGNED NOT NULL DEFAULT '0',
`is_activated` tinyint(3) UNSIGNED NOT NULL DEFAULT '1',
`validation_code` varchar(10) NOT NULL DEFAULT '',
`id_msg_last_visit` int(10) UNSIGNED NOT NULL DEFAULT '0',
`additional_groups` varchar(255) NOT NULL DEFAULT '',
`smiley_set` varchar(48) NOT NULL DEFAULT '',
`id_post_group` smallint(5) UNSIGNED NOT NULL DEFAULT '0',
`total_time_logged_in` int(10) UNSIGNED NOT NULL DEFAULT '0',
`password_salt` varchar(255) NOT NULL DEFAULT '',
`ignore_boards` text NOT NULL,
`warning` tinyint(4) NOT NULL DEFAULT '0',
`passwd_flood` varchar(12) NOT NULL DEFAULT '',
`pm_receive_from` tinyint(3) UNSIGNED NOT NULL DEFAULT '1',
`timezone` varchar(80) NOT NULL DEFAULT 'UTC',
`tfa_secret` varchar(24) NOT NULL DEFAULT '',
`tfa_backup` varchar(64) NOT NULL DEFAULT '',
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
so, it looks like I am correct, there is no value in the members table to account for Bans
and we try to avoid making database changes in minor or patch updates.
Yes,
@Kindred is correct. This is because bans can happen in a variety of ways.
If SMF only supported banning users by ID number, then it would be possible to just record a value in the database which could then be searched efficiently.
In fact, SMF supports multiple types of ban triggers, including ones that must be calculated dynamically when the user tries to log in (or when viewing the user's profile). These dynamic triggers mean that there's no efficient way to search for all banned members. It could only be done, as Kindred rightly concludes, by performing resource-intensive calculations on the entire members table.
Thanks for the thorough answers! While it's still a little inconvenient, I do understand why now. Always learning stuff!
One technical point: *some* bans are actually recorded on the members table directly; look for is_activated values of 10 and up. (These mirror the usual status, but +10 is for banned.)
If I remember correctly this only applies to bans directly on a person and possibly on a non-wildcard email address, I don't *think* it applies if they're banned by some other method and just visit the site, but it's been a while. Could be a good investigation into how the ban system works because it's not properly documented exactly what its behaviours are, and technically I could make the argument that a banned user is now in violation of the EU cookie law... (though you have a decent argument as to why this is so.)