sibomots

Setup/Upgrade.php, line 139 Checks if the row format is suitable and if not, warn. We never got the warning. In terms of support, it's a little late for that. I asked repeatedly for support and was rebuffed because IPS wouldn't quite take us very seriously. IPS gave the excuse that since our DATA was legacy but the SOFTWARE was new, we wouldn't qualify for support. It doesn't matter. We'll have to perform some down-time to repair the tech-debt accumulated.

I respectfully disagree that MySQL 8.0 is a viable path. We saw issues crop up during installation. SQL was failing during installation and regretfully (since it happened in May-2022) I have since forgot the actual error. Test it out on your BETA license key if you're that interested in knowing what will happen. What version of MySQL is this (right here) site using? dpkg --list | grep -i mysql Thanks. Also, another word of caution. The IPS software install doesn't quite ensure that your row format is dynamic. After all the installation is creating the tables, yet it created them in COMPACT row format vs DYNAMIC. That's a technical debt to have to deal with down the line. For admins upgrading, ensure you're table/row formats are DYNAMIC. The ACP will alert you to this under the Support section, but if you want to dig into it (where your Instance of IPS Database Name is DB_NAME (replace as appropriate) SELECT table_name FROM information_schema.tables WHERE table_schema = 'DB_NAME' AND `ROW_FORMAT` <> 'DYNAMIC' ORDER BY table_name DESC The results should be zero rows if tables are created correctly. If after installing or after upgrading you have tables that are not DYNAMIC, you'll eventually have to deal with that conversion later. So far IPS hasn't drawn a line in the sand on enforcing it. When they do, it'll mean a significant down-time to convert the tables.

Invision Community v4.7.4 How about the maximum version of MySQL that is compatible? 5.6 is somewhat (not ancient) but relatively older. We'd like to spruce up the DB and get the most whistles and bells without breaking the IPS software. How far can we take the version of MySQL ? Thanks.

That might be the answer.. We'll try out the scheme and see if that's the fix for PM replies that contain email addresses in their body.

It's not about merging messages. It is about body of PM that contain an actual email address. If the PM is the initial salvo (the initiation of the PM thread) then the IPS system allows the body of the PM to contain the email and the PM is sent. If the PM is a reply, then the IPS system does not allow the reply to contain an email address in the body. If the PM is a reply, but the reply is made very quickly (within the limit of when merge can occur) and the body does contain an email address, then the PM is sent. It's that middle case "PM replies that contain email addresses" that won't go through.

So on the latest bits (version) when you compose a PM within IPS to some other member on the site (as a PM) and in the body of the message something like: "Hey bob, here's my email address alice@whatever.com" No issue? Interesting... Hmm.

Update. So another edge case: Receive a PM. Reply to the PM In the reply put NO RFC822, etc. email address in BODY. Press Submit Expected Behavior: The message is sent. Actual Behavior: The message is sent. (So far so good) Now very quickly ( in order to leverage the "merge" message feature) make another reply to the same PM thread. In the second reply (done quickly) put an RFC822, etc. email address. Press submit. Expected Behavior: The message (2nd) is merged into the first and is SENT Actual Behavior The message (2nd) is merged into the first and is SENT. (So this is strange... when the Message is merged (being so soon after the first), the PM with the 822 email address is not a problem in the BODY. It goes through as a PM). If I wait to reply, and make a REPLY with the BODY containing an RFC 822, etc. email address then it won't go as a PM (as originally described). Another weird edge case: Initiate a new PM with a member. Steps: Initiate a PM with a member on the site. In the BODY include an RFC822, etc. email address. Press sent. Expected Results: The message is sent as PM to the member on the site. Actual Results: The message is sent as PM to the member on the site. Upshot - works as expected IF the PM is initiating the thread and the BODY of the message contains an email address. Why wouldn't it work. It's as expected. It seems that late replies to PM's that contain RFC822, etc. email addresses is the problem (?)

Invision Community v4.7.4 PHP 8.0 Repo-case: Receive a PM (Direct message) from another site member within the site. Read the message. Initiate a reply within the PM (DM) feature of the site. In the body of the message include an email address (user@domain) Press Submit Reply Expected behavior: The body (whatever it is) of the message is sent to the Member on the site through the in-site PM feature. No actual email (RFC822, etc..) sent. Example: (In the PM) Thanks for the note, here is my email address: user@whatever.com Actual behavior: The PM message is not sent through the IPS feature to the other member on the site. The text-buffer holding the message in the on-site editor is cleared No error shown in logs ACP logs. Please note -- the repo-case does NOT expect the message to be sent to the email address IN the BODY. The body of the message just happens to contain an email address, but there is NO expectation that the message is sent to any address mentioned in the body. The bug (?) is reproduced when the body of the PM contains an RFC822, etc.. address. Remove the email address from the body, and the PM is sent to the other Member. Leave the email address in the body, then 1, PM is NOT sent to the Member (on the site), and 2, the buffer clears. Again to be clear: There is no expectation that the PM is sent to any email address IN the BODY. The problem is PM's between members on the site (and only sent/received through the PM feature of the site) cannot be sent if the body contains an email address. Anyone else see this behavior? Is it a configuration issue? Is this a feature? (to prevent PM's to other Members where the body contains an email address) ?

Plugin developers trial-and-error their way through? Or is there an SDK with some modicum of documentation about the underlying engine (sufficient enough for a Plugin developer to have a field day) ? Point me in the direction of: "So, you want to write a Plugin for IPS? Here's the SDK/docs you need. Good luck."

Does your plugin provide capability in this scenario: (version 4.7.2.1) Alice posts. Bob reports it (bad post Alice) Moderator Charlie is aware of the Report and moves the disposition to some state -- In work, or whatever the enumeration is. Bob is notified of the event that Moderator Charlie is working the issue? Moderator Charlie works the issue and resolves it, moving the disposition of the report to "completed" or whatever the enumeration is. Bob is notified again by the system that this change of disposition has occurred. When Moderator Charlie closes (final state in the state tree of the Resolution), Bob is notified yet again that the issue is Closed/Finished/etc.. whatever. In other words, when the Moderator Charlie does "work" on the issue and the disposition (state) is changed, Bob is notified of those events. In other words, the Moderator doesn't have to literally manually notify Bob. Mere changes to the state of the Report cause Bob to be notified? Is that what your plugin provides -- or close to it? Do you have PDF (or web) manual of your Plugin? Thanks.

Platform: version 4.7.2.1 Scenario (what we see today) Alice posts something (Forums) Bob reports it (bad post, Alice) Moderator Charlie gets the notification that Bob reported on Alice. Moderator Charlie handles the problem/post Bob doesn't get notified when Moderator Charlie dispositions the progress of the Report. Bob gets zero notification that the issue is in-work or resolved, etc.. Question: Is it just a configuration issue on the vanilla 4.7.2.1 version that Bob can be notified for each administrative step taken by Moderator Charlie? Is it a situation that requires a Plugin ( Marketplace ) to add fine detail capabilities to fire off PM/email to Bob when Moderator Charlie moves the progress of the Report from state to state through the Reporting system? Without an additional Plugin, is it possible to configure the system such that when Moderator Charlie takes a step in administration of the Report that Bob (the Repoter) is notified (PM/Email) of those stages of work performed by the Moderator? I've searched for a Manual (PDF) of the Administrative features and can't quite find it -- to tailor the way in which Report notifications work (or should work, or could work?) Ping me if more details are necessary. Thanks. ps. We're trying to avoid the hack of scraping the DB looking for the residue when Moderator Charlie takes administrative steps and deduce from those records the state of the Resolution and firing off email to the Reporter (outside of the IPS software domain). We don't want to go there. We'd rather use either as-is Vanilla capability of IPS or purchase a Plugin that enhances the feature of Reports such that Bob (the Reporter) is notified (or kept up to date) on the progress of the Moderator Charlie's work on handling the Report.

This may not be an IPS configuration. In fact I think it is probably outside of IPS configuration, but Elastic Search is a selectable feature for driving search. Since Elastic Search is a configurable choice to use for driving search results, this issue came up. When a user searched for a term, what happened was that the ES query turned out results that matched similar words. This was not intended. So the question I'm asking is, for those who have integrated ES into their IPS for search, did you customize the ES back-end to tune the search to be verbatim search? Here's an example of what we saw in a live-site: The observation was that a term was searched: "Dominators" (this term means something specific to the Members and the Content of the site). What the ES/IPS search did was look for matches on these: With and without double quotes return a lot of posts with dominant, dominance, dominated, etc. burying the actual content about Dominators. In hindsight this reminded me of old WAIS type of behavior (for those who remember WAIS...). I did a skim for looking for the query formation in ES and stumbled across this. https://www.elastic.co/guide/en/elasticsearch/client/net-api/current/verbatim-and-strict-query-usage.html The question again is -- is there a feature or Admin accessible configuration that can control if a Search is literally verbatim (and suppress the attempt of ES to try words -- without the user's request -- that are close-to-the term searched on) ? Open to ideas.. Point me in a direction that I should look if this isn't an IPS configurable thing. Questions, ping me. Thanks. Caveat -- Unable to change the version of ES used.

Cool. That's the answer I was hoping for: "based off of the server's timezone" Simple. Thanks.

Understood. Let me repeat it back a different way to make sure I grok with an example: If the usage log shows a local minimum at 03:00 PM and if the host system is configured in the UTC TZ, then 03:00 PM (15:00) is the date-time that IPS will render in the usage log. IPS does not massage the date time in the usage log based on some other TZ offset configured in the IPS software. The exception apparently is the Leaderboard... that ACP setting "Leaderboard Timezone" is an offset applied from date time of host system. If you intended to paste a link, it didn't. It pasted the image. FYI.

In the user activity log, metrics are dated. I would like to know if there is a setting either in the ACP or a configuration setting in the `conf.php` that declares the time zone used for log dates is based on? The underlying system is set to UTC. I'm suspecting that the ACP log data attribute for when a log entry occurred is also in UTC, but I cannot verify. Is that metric on Aug 9, 2022 6:50:01 PM in UTC or ? If there is a time-zone offset setting in the ACP, I cannot find it. If there is not a TZ offset setting, am I to assume that date-time is based on the system date-time (eg., UTC if so configured). Thanks. Rationale for knowing: I need to adjust miscellaneous crontab entries to occur at a lull in activity and I want to notch them to occur at the least amount of usage. We have pattern of behavior to indicate when it is, but if I'm off by a TZ offset, it wouldn't do any good. Hence to pin point when the log-date-time is relative to the system date-time.