Gabriel Torres

That's it: a tool for automatically pruning old reports from the database, similarly to the tool we have to automatically prune private messages. Cheers.

Thanks for the help, guys! @Ryan Ashbrook Are the conv_password and misc columns safe to remove? We moved from vBulletin to IPS 10+ years ago... LOL I also need some advice if it is safe to remove these: cm_reg referred_by gallery_perms pp_setting_count_visitors Thanks! Thanks, I was able to find their origin here in an old spreadsheet. They were from a plugin called "Sign in through Google", available in the 3.4 era, before this functionality was incorporated in the core software.

Hi, What I discovered so far: member_login_key_expire This was removed in a previous IPS version and it is safe to be dropped. See core/setup/upg_101100/queries.json. allow_multiple_accounts access_attempts registration_attempts unique_machines These belong to an app that we removed in the past, so they are safe to drop. App: CJ Duplicate Member Logger. cim_profile_id cim_payment_id cim_method These belong to Nexus and should be kept as per applications/nexus/setup/upg_11100/queries.json. cm_no_sev cm_return_group cm_credits These belong to Nexus and should be kept as per applications/nexus/setup/upg_10102/queries.json. However, there is another related column that from what I could understand, was replaced with a cookie. I couldn't find a reference to this column in the source files. I don't know if it safe to drop it from core_members: cm_reg This other column seems to have been moved to the core_referrals table according to applications/core/data/schema.json. I don't know if it is safe to drop it from core_members: referred_by These two seem to have became bitoptions. I don't know if it is safe to drop them from core_members: gallery_perms pp_setting_count_visitors The columns below I couldn't find any reference in the source files. I don't know if it is safe to drop them from core_members: google_access_token google_access_expires google_refresh_token google_pass_reset google_uid has_blog has_gallery conv_password misc If someone could review these I'd appreciate it! Thank you in advance, Gabe.

Hi, When pruning members in the ACP, no pop-up window is shown asking us what we want to do with the users' content (delete/hide/leave), differently to the behavior we have when deleting a single user. If we want to mass-delete contents created by several users, we need to delete each user individually, which can take us literally hours of work. Based on that, my suggestion is for you to add this option in a coming release. Thanks.

Tested here and the pruning does the "leave" behavior. I will open a new topic with this suggestion.

@Makoto The search function at Radical Tags > Customize (?app=radtags&module=tags&controller=customize) isn't working here with us. Can you take a look into this? Thanks.

@opentype Ops! I've never noticed this before! 🤦‍♂️ Thanks for the clarification!

Hello, I am in the process of cleaning-up our database, and as we run IPS for for ages now, I believe our core_members table has several columns that were used in previous versions and are no longer needed. I compared the current structure of our core_members table with the default columns listed in the /applications/core/data/schema.json file, and I ended up with the list below of columns that exist in core_members but aren't listed in the schema.json file. | misc | varchar(128) | YES | | NULL | | member_login_key_expire | int(10) | NO | | 0 | | has_blog | text | YES | | NULL | | blogs_recache | tinyint(1) | YES | | NULL | | has_gallery | tinyint(1) | NO | | 0 | | conv_password | varchar(128) | YES | | NULL | | allow_multiple_accounts | tinyint(1) | NO | | 0 | | access_attempts | tinyint(1) | NO | | 0 | | registration_attempts | text | YES | | NULL | | unique_machines | text | YES | | NULL | | google_access_token | varchar(255) | YES | | NULL | | google_access_expires | int(10) | YES | | 0 | | google_refresh_token | varchar(255) | YES | | NULL | | google_pass_reset | int(1) | YES | | 0 | | google_uid | varchar(255) | YES | | NULL | | referred_by | int(11) | NO | | 0 | | cm_no_sev | tinyint(1) | YES | | 0 | | cim_profile_id | varchar(32) | YES | | | | cim_payment_id | int(10) | YES | | 0 | | cim_method | int(5) | NO | | 0 | | cm_return_group | smallint(3) | YES | | 0 | | cm_credits | text | YES | | NULL | | cm_reg | int(11) | NO | | 0 | | gallery_perms | varchar(10) | NO | | 1:1:1 | | pp_setting_count_visitors | int(2) | NO | | 1 | Please let me know which columns are safe to drop. Thank you in advance, Gabe

Hi, In the ACP > Pages > Blocks, there is no option to delete a category, only to create new ones. A button to delete the category should be added. Thanks.

Hi, We enabled archiving here and I noticed a behavior that you may want to address. When a topic is archived, the "state" row is kept in its original value (e.g. "open/closed"). When a closed topic is archived, then we end up having two messages saying that the topic is closed: one because it is archived and another becaise it is closed: This is clearly redundant. When the topic is set as "open", the second message doesn't show up. I believe the row "state" is kept with its original value because if we ever need to restore the topic, it must be restored to with its original state. Anyway, maybe it a matter of adding a logic it a template to supress the second message if the topic is archived, so we get rid of this additional message. For instance: forums > front > topics > topic Original: {{if $topic->commentForm() || $topic->locked() || \IPS\Member::loggedIn()->restrict_post || \IPS\Member::loggedIn()->members_bitoptions['unacknowledged_warnings'] || !\IPS\Member::loggedIn()->checkPostsPerDay()}} Change to: {{if ($topic->commentForm() || $topic->locked() || \IPS\Member::loggedIn()->restrict_post || \IPS\Member::loggedIn()->members_bitoptions['unacknowledged_warnings'] || !\IPS\Member::loggedIn()->checkPostsPerDay()) && !$topic->isArchived()}} This worked great here and I hope you can adjust this in a coming release. Cheers! 🙂

Ok, this is something I believe should be added. What is the default behavior when prunning (delete/hide/leave)? Do you know?

All good, everything is working fine, I was probably tired when I tested this.

@Nathan Explosion @Matt @Adriano Faria Thanks, cleared the cache here and the pop-up window is now showing up when I hit the "X" button for deleting a user. However, when using a search option and clicking in the "Prune Members Found" link, I get straight to the "Confirm Prune" page instead of the pop-up window asking if I want to delete/hide/leave the contents. Could you test this on your side to see if this is an issue with my install, the expected behavior or a bug? Thanks. Matt, can you move this topic to the correct forum, as this is not a "feedback" issue anymore, but a technical problem at my side? Thanks.

This is actually something I'd love to see added to the platform. In the past, we achieved this with a third-party plugin, which became incompatible with PHP8 and we had to remove. There is actually an app for that currently available in the marketplace: https://invisioncommunity.com/files/file/10175-tb-banned-members-enhancements/

Same happened here. I had to go to the Marketplace section inside ACP and look for it to update it to the latest version. I knew a new version was out because I am subscribed to receive emails whenever the app is updated.

I know that it wasn't present before. I am suggesting you to add this is a future version. Thanks, I will test this again! I may have missed something here.

@Nathan Explosion @Adriano Faria I will investigate this further and let you know what I find. Thanks!

Wow. Different behavior here. Running 4.7.11.1. No popup is shown. Maybe because you are using dev mode?

@DawPi Installed the latest version and when adding the content, I missed a tag for the user's name! So we can write something more personalized like: Another issue I faced is that when a post is hidden, no notification is generated. The notification is generated only when a whole topic is hidden. You may want to take a look into this. Thanks.

Just keep both options, then! Max number of lines AND max number of chars. We have this disabled here.

@Marc Stridgen At least here with us, we are always looking into ways to reduce the size of our database and pruning unecessary data. Our community for 20 years now, so you can imagine the size of everything here. In our case specifically, we think we can do a nice cleanup by pruning old spammers (e.g. over 1 year ago) and their offending posts/topics. Banned users are a different case, however, with new privacy laws in our country, it is always a concern to keep personal data from these users...

@Nathan Explosion A couple of suggestions to improve this amazing app, if possible. In summary, add options also to the topic title, in order to prevent low-quality titles: 1. Minimum number of word/characters in the topic title. 2. List of ban words for topic title. Here we would enter phrases such as "help me" and others that don't help others to know beforehand what the topic is about. I hope you can add them to the app. Thank you in advance! Cheers.

@Nathan Explosion Excellent app, we were really needing it here. The "limits enabled" string is hard coded in the two available templates. The best would be to include it as a language string: <li>{lang='neapp_contentlimits_type_word'} limits enabled E.g. a new language string as: %s limits enabled Just my two cents! Cheers

PS: Ditto for the "Prune Members Found" option.

I actually found a workaround. Use the search (gear icon) the the ACP member page to select a desired criteria, and then click on the "Spammer" button. This time the "prune members found" option will show up! 😉