Support for multiple numbers per user [#459984]

We'd like to be able to support multiple phone numbers per user, but it looks like this functionality is being stripped out of sms_user.module.

Some of our users have numbers in different countries, and others have their own phone, plus a work phone. Also, it's fairly common outside of the US for people to have several pre-paid SIM cards (i.e. several different cell numbers), and switch between them throughout the day to take advantage of different carriers' rates.

It looks like the current schema would still allow us to store multiple numbers per user, so mainly there would need to be some discussion on how to load multiple numbers into the $user object. Also it might be good to allow users to label their numbers and/or designate a primary number.

Comment	File	Size	Author
#13	smsframework-multiple_numbers.patch	34.76 KB	univate
#13
#12	smsframework-multiple_numbers.patch	0 bytes	univate
#12

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Comment #1

mfb

they or he

CreditAttribution: mfb commented 12 May 2009 at 01:49

Related issue, I noticed that sms_user delta is only halfway removed, it's still present in some modules like sms_sendtophone and sms_actions.

Comment #2

Will White CreditAttribution: Will White commented 12 May 2009 at 21:22

Yes I'm willing to revisit this. The delta field was stripped out in sms_user.module but can be re-added if an good to handle multiple numbers is developed. This includes a user interface where we would be able to switch on support for multiple numbers.

Comment #3

schock CreditAttribution: schock commented 23 September 2009 at 16:38

Hi Will, mfb, this issue keeps coming up in the vozmob workshops, so I can say for sure that at least in our use case it would be great to have this functionality. I'm guessing that it will be useful for ALL drupal projects that are seriously trying to integrate mobile posts. Tracking the issue and suggestions for UI here: http://dev.vozmob.net/issues/229

re: UI,

As for additional phone numbers, just make a button like 'add another phone' in the mobile phone settings page. If user or admin click it they get a field to fill out phone # and [a dropdown of supported] providers. Then all the [user registered] phones appear in a list in [that user's] mobile settings. Primary phone appears at the top of the list, and that is the phone that we send SMS/MMS to.

The secondary / tertiary / etc phones, we just store so that we can post anything that comes from them to the user's blog.

To change which phone is primary, ideally the user can just drag the one they want to the top of the list (same UI like positioning blocks in order on a page).

Comment #4

glennnz CreditAttribution: glennnz commented 19 November 2009 at 01:51

+1 for this functionality

Comment #5

mfb

they or he

CreditAttribution: mfb commented 29 January 2010 at 10:32

I would still like to see the multiple number support restored and hopefully could work on a patch sometime soon.

Comment #6

mfb

they or he

CreditAttribution: mfb commented 21 November 2010 at 02:28

This is an important issue to resolve before the 2.0 release of SMS Framework. I will try to find time to work on it soon now that there is some movement happening on the 2.x branch.

Comment #7

walterheck CreditAttribution: walterheck commented 21 November 2010 at 04:00

I'd love to see this, as it is one fo the things i'm currently missing.

Comment #8

univate CreditAttribution: univate commented 7 January 2011 at 02:19

I am curious to understand the reason for multiple number and why this is an important feature to resolve?

Looking at the integration with modules like message, its actually hard coded to just send messages to one number on a users account.

The only use case I can think of is around incoming messages and identify users based on more then one number.

Comment #9

mfb

they or he

CreditAttribution: mfb commented 7 January 2011 at 03:54

Users need to be able to choose which number to use for outgoing SMS notifications. Many of our users have multiple SIM cards and swap them depending on where they are and even what time it is (see the original post). They should not have to delete and confirm a number every time, they should just be able to login and configure which is their primary number for outgoing notifications (or better yet send a text message to configure it, but that could be implemented by some other module not the framework :)

Comment #10

univate CreditAttribution: univate commented 7 January 2011 at 04:37

Ok I guess this makes sense, although it still seems like a low priority feature to me, but if you get a patch together there is probably no reason to not include it.

Comment #11

univate CreditAttribution: univate commented 4 May 2011 at 13:57

Found some work being done here on multiple number support - http://gitorious.org/vozmob/smsframework/commits/6.x-2.x-multiplenumbers...

Comment #12

univate CreditAttribution: univate commented 4 May 2011 at 14:07

Status:

Active

» Needs review

File	Size
smsframework-multiple_numbers.patch	0 bytes

Here is a patch of the differences between that repository and current 2.x-dev

Comment #13

univate CreditAttribution: univate commented 4 May 2011 at 14:07

File	Size
smsframework-multiple_numbers.patch	34.76 KB

Comment #14

univate CreditAttribution: univate commented 4 May 2011 at 14:16

Status:

Needs review

» Needs work

Most of this looks pretty good to me... I haven't properly tested it with a sms gateway, but there are a couple of small issues I could see looking just at the code.

+++ modules/sms_user/sms_user.install
@@ -20,12 +21,19 @@ function sms_user_schema() {
+function sms_user_update_2() {
+  $ret = array();
+  // @todo update all SMS_USER_CONFIRMED 2 status to SMS_USER_ACTIVE 3
+  return $ret;
+}
+
+

Need to add a query for that

+++ modules/sms_user/sms_user.module
@@ -421,24 +313,40 @@ function sms_user_user($op, &$edit, &$account, $category = NULL) {
+ * @todo this is called often, the $account->sms_user content could be ¶
+ *   update and trusted?

I can appreciate the issue being raised here. Having an extra sql query on every user_load is not the best idea - interested in alternative ideas.

Powered by Dreditor.