Hi all, I'm looking for some help with code for a 6.x-1.1 release.
I know that frazras, univate, shushu, andybill and chrisdbarnett have offered to help, but I didn't know how to address those individuals alone - hence the group post :-)
I am currently working on Gateway return code capture, Message archiving/tracking module, Virtual gateway (to aid development) and Clickatell gateway updates.
I would really like help to address the following tasks. Each bullet-point item is for an entire module (or modules), so requires some ownership of issues at least until the 6.x-1.1 release.
- CRUD interface for sms_email_gateway, as implemented in the 6.x-2.x-dev core module (and with many updates in the 6.x-2.x-dev sms_email_gateway module), and with good info in tickets #453126, #331630, #587090, #318896. I think that the code belongs in the sms_email_gateway module, but the forms interface must be integrated with the admin settings form implemented by the SMS Framework core module. It would be best to begin with the sms_email_gateway module in 6.x-1.x-dev.
- sms_user improvements. There haven't been any updates in the 6.x-2.x-dev release, so nothing to port back. It would be best to start with shushu's group post below and tickets #279926, #411058, #581400, #661134, #459984.
- sms_sendtophone improvements. It would be best to begin with tickets #296793, #619908, #619410.
- sms_blast to a pool of numbers. See ticket #429482. This should be implemented as a form similar to the sms_send_form() in the SMS Framework core module - these form functions are structured such that they can be included as part of a developer's existing form.
Please note that since this is a 1.1 release, all updates MUST be fully backward-compatible, and should begin with the 6.x-1.x-dev branch. Note that the branch will change as we commit updates.
There is a little more to do on a gateway module directory so that we can recognize all of the gateway-module provider's efforts. It would also be great to have some of these gateway modules improved to a level that they at least support outgoing and incoming messages. I also want to open further discussion (in a separate post) about International number validation. Since so many people have had unique problems with number validation, I believe that the way to approach this is by giving the users/developers options for how the validation functions would work.
So, please comment on this post or private-message me (aspope) if you would like to discuss any of this work or would like to take some of it on. It would really be appreciated!
Thanks everyone,
Comments
sms_user
Hi,
I will be happy to take over the sms_user tasks.
I guess the way to handle it is to provide patches on each of the issues, ready to merge.
Thanks shushu!
Thanks @shushu! We all really appreciate your help.
Take a look at the issues listed in the post, and any more that you think are relevant in the queue. Feel free to private message me or anyone else if you want to discuss ideas or questions. I'll touch base with you in a week or so to see how you're getting on :-)
sms_blast
I can do SMS Blast - but there are a number of questions that arise. How should the options be presented.
Im envisioning a set of radio buttons that have these options
Message:
_____________________________________
| |
| |
| |
| |
| |
| |
| |
| |
|___________________________________|
x of 160 characters left
[] Send to All Users
[] Select Contact List [Drop down menu of Contact list Nodes |v]
[] Send to these users:
Enter contacts here, one per line
_____________________________________
| |
| |
| |
| |
| |
| |
| |
| |
|___________________________________|
______________
[ Send Message ]
---------------
Thanks frazras!
@frazras, saving the day again :-)
I think you are right about having all of these options. There are a few ways that I think we could go about it:
1. Provide a form (as you have described) with all possible fields and options.
2. Provide a form whose fields can be turned on/off and defaults set by options on an admin-settings page.
3. Provide a form include (just like sms_send_form()) with hidden fields that would allow the developer to to instruct the _submit function where to send the message.
The contact selection could get interesting too. I'm not sure about how contact groups could be implemented (maybe you have some ideas) and the username autocomplete doesn't seem to work for non-admin users, although a list of phone numbers should be fine.
contact / group selection
we've done this using OG & notifications, but it's a bit messy (average group membership is 100 - 120, and it changes monthly, so there's an amount of admin involved in that; the bigger problem is that the membership lists are coming out of another system which has no "sanity checking" of the mobile number field - so in the imported data every month we end up with some landline numbers, some international numbers (that should be used), some other international numbers (that shouldn't be used), and a premium rate service.
Given that this is probably a fairly extreme case, you could however use OG for the contact list; with a few extras (e.g. OG membership expiry, or subscription schedules, for example) it'd be a fairly flexible setup without the specific problems we've been coming across, but it also might be more complexity than is strictly needed?
In terms of the approach to number validation, yes - everyone's requirements are different, so it's probably as you say easiest to provide people with the tools to work out their own validation. The alternatives to that are just too messy .......