[For 1.8] MyConversations: a conversation plugin for MyBB

[Laird]

Well, it's running on the production clone.

Good to read.

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.

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.

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.

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.

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.