search

WordPoints / buddypress

WordPoints module integrating it with BuddyPress
GNU General Public License v2.0
1 stars 0 forks source link

Message send event #1

Closed JDGrimes closed 8 years ago

JDGrimes commented 9 years ago

To award points when a user sends a message to another user.

JDGrimes commented 8 years ago

I was going to introduce an entity attribute for the message sent time, but WordPoints core doesn't include any date or time data types yet. I'm thinking we could bundle one with the module for now, but also work to get it into WordPoints 2.2.0. The value is stored in MySQL DATETIME format, so I guess we could call the data type 'mysql_datetime'.

Actually, as far as bundling the data type registration with this module, I don't know that that is really needed. We can't really use it at all without any conditions for that data type anyway, and of course none of them exist either. They'd likely need a fairly advanced UI in addition to the underlying handler, so I don't know that we could pursue them as part of the initial version of this module. For example, we could add "Before", "After", and "On" conditions for this data type, but they wouldn't be very useful if they were always precise to the second. They'd need to be able to be configured for a particular day, month, etc. Or a particular time of day even.

So at the very least, this should be explored further in a separate ticket it we pursue it for this module at all. However, I will still go ahead and register this entity attribute, and I'll mark the mysql_datetime date type as reserved but not yet handled in the developer docs.

JDGrimes commented 8 years ago

Reversible?

I'm wondering whether this should be a reversible event or not. The messages themselves aren't really deleted specifically, that is, not independently of the message thread as a whole. And I'm wondering whether users might routinely delete messages, sort of like how you clean your email inbox. And there's also another issue, which is that the message is marked as deleted on a per-user basis, and only completely removed from the database when every recipient (including the sender) has deleted it.

JDGrimes commented 8 years ago

I think that probably reversals for messages won't be good behavior for the points reactor. However, I think that there is a difference between that and us not registering a toggle_off action (which should probably be when the message is fully removed from the database, as with the per-user stuff we'd run into all kinds of strangeness). I think that we have to look beyond this one, single implementation. On the other hand, as far as badges go (which is the only other implementation that we've thought up that we'd likely use this event with), I don't think we'd want to count messages on a "how many messages currently exist" basis either. Rather, we'd probably want to award a badge for how many messages the user has sent, not how many messages they've sent that are just sitting there in folks inboxes (which I guess really could be perceived as a bad, rather than positive, thing).

JDGrimes commented 8 years ago

And that makes me think, that really what this event is is the message sent event, not the message created. Deleting a message doesn't "unsend" it, there really is not "unsend" action. So until there is, this will be a non-reversible event.

JDGrimes commented 8 years ago

That said, I think that the event should probably still be using the toggle_on action type instead of just fire, since it is theoretically possible that the event could be reversed (an "undo" button after a message was sent and before it was read or something). Which is different than a user visiting the site, which once they have done is an irreversible action. It isn't a state of things, but a piece of history. But this sort of is a state of things. Kind of in-between, really, since sending the message is an action, but as we said, it is something that the user could conceivably have the opportunity to undo without rewriting history, if the message hadn't been read yet.

JDGrimes commented 8 years ago

The only thing we have to consider is what kind of affects registering toggle_on actions without any toggle_off actions would have. Reviewing the core code, it seems that the answer is really none, except of course the obvious, that it would mean the actions would never be reversed. I thought that it might trigger the periods extension to be enabled for the event, but that is actually based on whether the event has any non-stateful args or not. So periods wouldn't be enabled just because of this.

JDGrimes commented 8 years ago

I think we'll go ahead and just register toggle_on for now, and if we have any surprises, we can reconsider then.