Tell Bot Functionality

Needs a lot of work. This just sets up the database schema, and shows the table in bot/tell. It also provides the API functions to add, remove and retrieve messages. Needs work done on the actual IRC interactions.

Druplicon should message/query the user instead of publicly announcing that the user has messages.

Here's the initial functionality....

Morbus left the room.
RobLoach: Druplicon: tell Morbus Where'd you go?!
Druplicon: RobLoach: Okay.
Morbus entered the room.
Morbus: messages?
Druplicon: Morbus: (Thu, 06/19/2008 - 18:42) RobLoach: Where'd you go?!
Morbus: I'm back, RobLoach!

Things to add:

1. Notify the user that they have messages when they join the channel.
2. Ability to send factoids..... Druplicon: tell chx about support.
3. Have the messages be sent as a private message instead of just in the channel.

Small bug fix and have Druplicon send the messages via a query instead of to publich channels.

Still work to be done:

1. Notify the user that they have messages when they join the channel.
2. Ability to send factoids..... Druplicon: tell chx about support.
3. Administration (ability to remove/edit messages)

Things left:

1. Have the messages be sent as a private message instead of just in the channel.
2. Notify the user that they have messages when they join the channel.
3. Ability to send factoids..... Druplicon: tell chx about support.
4. Administration (ability to remove/edit messages)
5. Clean up regex? Move query-only related stuff to bot_tell_irc_msg_query?

Things left:

1. Have the messages be sent as a private message instead of just in the channel.
2. Notify the user that they have messages when they join the channel.
3. Ability to send factoids..... Druplicon: tell chx about support.
4. Administration (ability to remove/edit messages) - Security flaw
5. Clean up regex? Move query-only related stuff to bot_tell_irc_msg_query?

Cleaned up code a bit....

Things left:

1. Have the messages be sent as a private message instead of just in the channel.
2. Notify the user that they have messages when they join the channel.
3. Ability to send factoids..... Druplicon: tell chx about support.
4. Administration (ability to remove/edit messages) - Security flaw
5. Clean up regex? Move query-only related stuff to bot_tell_irc_msg_query?

Looks pretty good to me!

Tested and works as advertised. This will be very helpful with our projects and is like memos on steroids.

The only concern is that since messages can be sent to the bot as private messages (i.e. not associated with any channel), which is great for being able to leave some private messages, it seems as though it may be a spam vector, especially if it's used on well-known bots like Druplicon.

Phenny, the bot this feature comes from, does everything out in the open. Since I'm a fan of phenny (and use it every day), I'd be perfectly fine if Druplicon only accepted messages (and optionally played them back) out in the open too.

1. Now that I think of it, I don't think I like privates messages on #Drupal at all. The whole reason to talk on #Drupal is open development discussion, Druplicon should reflect that. So, let's make the messages communicated publicly. The thing I worry about here is spam in the channel. If many people with messages join the channel at once, Druplicon would be all over the place. Minor flaw though, and there's no way around it without making the messages private. If a user wants a message to be communicated privately, they could use...... Druplicon: privately tell Morbus Hello!..... Thoughts?
2. If spam does become a problem, we could consider sticking this behind bot_auth.

Spam hasn't really been a problem with phenny. Really, the people who will use this feature the most are those that are on the channel quite frequently anyways. And, the folks they're messaging will be those who they know show up on the channel frequently enough. I'd much rather start out with a minimalist approach - if things are a problem, we'll code something else in.

@Rob Loach the problem with "privately tell" is that it would have to be set in the channel to prevent abuse of the bot so the message is already public. Also since Freenode has the Memo option one could always Drupalcon: tell Morbus sent you a memo that is important... yeah it's a message about a message and not a greatly efficient thing but since it would be the exception not the rule.

With that said I can see where bots other than Druplicon would possibly benefit from being able to have PMs enabled. So perhaps instead of gutting PMs a setting in the bot options should be selectable. (Personally this is quite handy in channels where we have contractors and clients to be able to leave a reminder for an contractor to contact an individual for example and never have it in channel).

Here it is with messages being relayed publicly. If you want to receive your messages privately, all you have to do is send the bot a private query. We can worry about truly private messaging once the Bot Authentication patch goes in, so that it is guaranteed to be delivered to the right person.

Works lovely, thanks for that Rob.

Druplicon: tell Morbus about support

.... This should listed as a feature in bot_help_tell.....

Factoid tells should also be sent as private queries immediately if the user is online.

What about the ability to invoke the messages?

This would allow you to do other things and not be spammed by messages if you're busy doing other things. Receive your messages only when you're ready. The bot would only report that you have messages when you join the chat, or once every X hours, where X is configurable in the settings.

i dont feel that this is a scope creep. THIS feature infact makes the bot tell not feel like being a spam tool. i only receive messages when i'm ready to receive message.

this however does add a number of features beyond the basic tell.

one important feature for example is to be able to configure notification frequencies per user.

for example "Druplicon: notify 5h" will set notification frequency to every 5 hours untill the messages have been received.

this however is also a self defeating feature because some one may implement "Druplicon: notify 1000h" which inturn disables the bot tell for that user.
implementing frequency upper limit may solve that problem.

despite the extra work that may need to go into this and extra features. i do feel that current method of telling people messages is very spam like and a lot of messages will be ignored if the user is busy in the moment when a tell is told.

I don't support #18. If you want 18, learn how to use the MemoServ, which is on most IRC servers. From my standpoint, bot_tell as implemented, is "done". Any further creep, and it's just not worth using it, when compared to server level support like MemoServ. Bots should not, nor ever have, come with user-level permissions - that's just making something that is supposed to be quick and simple aggressively obtuse.

Ideally, the rationale behind this feature -- 'the user is busy' -- doesn't make a whole lot of sense to me. In the past three, four years that the #swhack channel has used this feature, the only time that messages are delivered is when the user, naturally, has caused activity. This activity is almost always because the user is /available/ - why else would they be causing activity? Now, certainly, there have been times where someone has been pinged, for them to respond with "Busy at the moment", and to have the messages displayed. But that has happened so infrequently, in practice over the last four years, that complicating the module and feature set, was unnecessary and counter productive.

Things to do:

1. The Factoid Tell functionality should be removed from bot_tell and moved into bot_factoid itself. It should send the factoid as a query immediately if the user is online.
2. bot_factoid should have documented the tell functionality in bot_factoid_help

i disagree. tell should be bound to tell and nowhere else. tell invokes factoid functionality so i think that feature should be dependent on factoid but not require it. but the actual tell functionality shuld not be in bot factoid.

Committed to DRUPAL-6--1 with changes.

Yay! Thanks Morbus.

Automatically closed -- issue fixed for two weeks with no activity.