Jump to content

Gabriel Torres

Clients
  • Posts

    1,748
  • Joined

  • Last visited

  • Days Won

    4

 Content Type 

Downloads

Release Notes

IPS4 Guides

IPS4 Developer Documentation

Invision Community Blog

Development Blog

Deprecation Tracker

Providers Directory

Forums

Events

Store

Gallery

Posts posted by Gabriel Torres

  1. 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!

    6 hours ago, Martin A. said:

    All those google_* columns must be from a 3rd party

    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.

  2. 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.

  3. 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.

  4. 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

  5. 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:

    Could contain: Page, Text, Person, Face, Head

    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! 🙂

  6. On 7/12/2023 at 9:46 AM, Gabriel Torres said:

    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.

    On 7/12/2023 at 10:28 AM, DawPi said:

    Can't confirm:

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

  7. @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.

  8. 1 hour ago, JohnCourt said:

    Daniel, as far as I know if you ban or mark a member as spammer, the profile page is still visible by other members?

    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/

  9. 6 hours ago, abobader said:

    This app do not show any indicated for update, so when I saw you update the app and still not notify on the admincp as I said, only way was to click on the app and then click on "Marketplace" then you will see the update and can update this app.

    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.

  10. Just now, DawPi said:

    It wasn't there in previous version too so what you missed exactly? 🙂

    I know that it wasn't present before. I am suggesting you to add this is a future version.

    1 minute ago, DawPi said:

    Can't confirm:

    Thanks, I will test this again! I may have missed something here.

  11. @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:

    Quote

    Hi, #username#!

    (...)

    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.

  12. 3 hours ago, Marc Stridgen said:

    Generally it wouldnt be expected that people would prune banned users

     @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...

  13. @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.

  14. @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

  15. Hi,

    If we delete a user from its profile in the ACP, we are asked what to do with the user's content (delete/hide/leave).

    However, clicking the "X" button in the member's list (see below) performs the "leave" option. This is really annoying! The system could show a popup asking what we want to do with the content the user posted.

    Not to mention that there is no way to mass delete spammers/banned users, functionality that has been already asked by several board owners... 😉 

    Could contain: Text, Computer Hardware, Electronics, Hardware, Monitor, Screen

    Thanks!

×
×
  • Create New...