MyConversations version 1.2.0 has just been released.
New features and fixes (includes fixes for the two database error messages reported by HLFadmin above):
- Adds a conversation search feature.
- Facilitates searching all conversation subjects and/or message bodies in conversations in which the member is involved.
- Provides for results as conversations, messages, or both.
- Includes various additional criteria such as conversation group, message folder, author, and participants.
- Includes "quick search" boxes at the top of the various conversation/message listing pages.
- Adds a "Mark all read" feature.
- Adds a new "Number of Conversations With Unread Messages" column to the group listing.
- Conversations with unread messages in conversation group listings are now bolded with a preceding green go-to-first-unread arrow.
- Adds two missing setting toggles to the ACP User module (allowing admins to toggle a user's default settings to receive copies of conversation messages by others and him/herself).
- Fixes bugs reported by HLFadmin here.
- A database error was generated when
sql_mode included ONLY_FULL_GROUP_BY.
- A database error was being generated when
sql_mode included STRICT_TRANS_TABLES.
- Bugfix: The per-usergroup permission allowing members to start conversations could not be reenabled after disabling it in a usergroup.
- Bugfix: The CSV mime type for conversation exports was not ideal.
- Fixes various style issues:
- Sidebar elements were not always fully to the right on the page.
- Conversation group listing headings were not bolded.
- Various miscellaneous other fixes and minor code quality improvements.
Perfect. Installation was successful.
In a clean install of 1.8.26. Single user created a PM to self as a test. Installed the plugin and activated, converted the single PM to conversation and replied to self. Seems to work as expected.
Now for the next test. Install a clone of the production database with multiple themes, then install the plugin.
I've already announced a teaser of Major Feature Change coming. My guys are looking forward to it.
Sounds good so far. Let us know how you go!
Well, it's running on the production clone.
Interesting that I either changed it back or it was changed in some update, but the test bed went back to STRICT_TRANS_TABLES, and predictably, installing the 1.2.0 plugin failed with the known error. My solution was to change sql_mode to '', complete the installation, and revert back to default sql_mode.
I have not seen any operational SQL problems since.
I'm not sure what this solution is, I suspect there is none. Received some complaints about deleted messages returning as a conversation.
A member has a message limit and deletes old messages to stay within the limit. Deletes and empties trash so message is gone. But recipient has not reached their limit and has not deleted old message. So conversion of old PMs to conversations recreates a one-sided conversation. This is not necessarily a problem, except if a message was deleted intending personal information not be retained in the system.
[edit -- oops. I thought there was a setting for message limit. Maybe not after all.]
[edit again -- it's there in Admin / Groups / Users and Permissions]
One solution is to not convert old PMs, except that messages intended to be kept are no longer available since the old PM system is replaced by Conversations. A permission-based edit/delete capability would be useful in this regard.
The window for feedback from members is still open as to whether or not to install on production forum.
Is the plugin database agnostic or does it only support MySQL at the moment?
Would you be interested in sponsored development in the future to support other database systems such as PostgreSQL if so?
(2021-05-02, 03:16 PM)HLFadmin Wrote: [ -> ]Well, it's running on the production clone.
Good to read.
(2021-05-02, 03:16 PM)HLFadmin Wrote: [ -> ]Interesting that I either changed it back or it was changed in some update, but the test bed went back to STRICT_TRANS_TABLES, and predictably, installing the 1.2.0 plugin failed with the known error. My solution was to change sql_mode to '', complete the installation, and revert back to default sql_mode.
Oh, I see that I missed a couple of other instances in which a
TEXT column was given a
DEFAULT value of
'', which is probably what's causing the error to pop up again. I'll fix those for the next release.
(2021-05-02, 03:16 PM)HLFadmin Wrote: [ -> ]Received some complaints about deleted messages returning as a conversation.
Fair enough. I think that that's a fairly easy fix, which I can get into the next release too.
(2021-05-02, 03:16 PM)HLFadmin Wrote: [ -> ]One solution is to not convert old PMs, except that messages intended to be kept are no longer available since the old PM system is replaced by Conversations.
Yes, the old PM system is replaced, but MyConversations still relies on the old system's database tables to pull out preexisting message contents. I'm contemplating whether to support "full" migration, after which all rows in the old private messages table could be deleted, potentially saving a bunch of space.
Re the solution:
Currently, MyConversations considers to be "deleted" for an individual conversation participant any message with a folder ID of -1 (for that participant+message). These messages still exist in the database, and are still visible to other participants who haven't also "deleted" them, but they are no longer visible to the participant who "deleted" them. The easiest solution then is just to set to -1 the folder ID of imported messages for each participant for whom a copy of the original private message does not exist for them in the core private messages table.
(2021-05-02, 03:16 PM)HLFadmin Wrote: [ -> ]A permission-based edit/delete capability would be useful in this regard.
Yes, and I've started a separate Git branch to work on this functionality. It will allow genuine deletion of message contents, i.e., at the database level, probably only by the author of the message, but I'm open to ideas on how this should work, and at which level(s) (conversation/group, user group, global) edit/delete permissions should function.
(2021-05-02, 03:16 PM)HLFadmin Wrote: [ -> ]The window for feedback from members is still open as to whether or not to install on production forum.
OK. I'll try to have the fixes mentioned above ready soon in case you do decide to go into production.
(2021-05-02, 05:12 PM)kawaii Wrote: [ -> ]Is the plugin database agnostic or does it only support MySQL at the moment?
It only supports MySQL/MariaDB.
(2021-05-02, 05:12 PM)kawaii Wrote: [ -> ]Would you be interested in sponsored development in the future to support other database systems such as PostgreSQL if so?
Yes. I've currently got PostgreSQL/SQLite support down as unplanned and contingent on demand: sponsorship of this feature would change that.
(2021-05-03, 07:11 AM)Laird Wrote: [ -> ]Yes, the old PM system is replaced, but MyConversations still relies on the old system's database tables to pull out preexisting message contents. I'm contemplating whether to support "full" migration, after which all rows in the old private messages table could be deleted, potentially saving a bunch of space.
Re the solution:
Currently, MyConversations considers to be "deleted" for an individual conversation participant any message with a folder ID of -1 (for that participant+message). These messages still exist in the database, and are still visible to other participants who haven't also "deleted" them, but they are no longer visible to the participant who "deleted" them. The easiest solution then is just to set to -1 the folder ID of imported messages for each participant for whom a copy of the original private message does not exist for them in the core private messages table.
I looked at the database structure and see how it has been done. Messages from prior to the conversion are still stored in privatemessages table. I can see the value of maintaining the old database intact for purposes of removing the conversations installation. Full conversion makes sense for a forum committed to the plugin. Full reversion might lose some detail.
I can go to Inbox or Sent or Trash folders and see new and old messages, and use built-in functions to move or delete. This is good. Then perhaps a task that finds messages where all recipients are folder -1 to delete the message from the db.
Just some numbers:
privatemessages 28041 records
cnv_conversations 5535 records
cnv messages 18097 records
privatemessages 20.5MB
all cnv_* 3.1MB
I suspect there will be a fair amount of space saved with full conversion, although not critical in the larger scheme of things in a 449MB database.
Yes it makes sense to assign folder -1 for participants who deleted previously. I'm confident we'll go to production with this one change. Task to purge deleted messages eventually. Full conversion or reversion is future path possibly.
[edited to collect thoughts]
Great - it seems that you have a clear and thorough understanding of the plugin and what could meaningfully be added in the future in this respect. Yes, a task to purge deleted messages would be a good addition, and I'm also thinking of checking when a member "deletes" a message (having its folder set to -1) whether all other participants have also "deleted" the message, and if so, deleting it from the DB at that point too.
DB deletion will probably not remove the associated row in the cnv_messages table entirely, only set its message field to NULL. This will be so that in the conversation view, message numbering does not change, and also so that, less importantly, also in conversation view, a "[Message deleted]" notice can be shown. (A couple of new columns will probably be added to support message deletion too, named something like deleted_by and deletion_datetime).
I've implemented the "on migration from PMs, assign folder = -1 for participants who deleted previously" functionality, but as it's such a small change, I won't release a new version (unless any other existing purchaser wants it immediately) - instead, I'll simply send you an updated archive privately.
MyConversations version 1.2.1 has just been released.
Note that this release fixes a security issue and you should upgrade as soon as possible.
New features and fixes:
- Security fix: The potential for an SQL injection attack was removed.
- Bugfix: There was a further potential for error (on top of the fixes in the previous release) when
sql_mode included STRICT_TRANS_TABLES.
- Bugfix: Ensure that deleted messages stay deleted when converting from core PMs to conversations.
- Bugfix: Ignore deleted messages when converting from conversations to core PMs.
- Bugfix: The header notification message listed conversation author instead of last poster.
- Bugfix: Non-search-result conversation listings were ordered incorrectly.
- Various miscellaneous other fixes and minor code quality improvements.