starred/SMSSync

Fork 0

mirror of https://github.com/ushahidi/SMSSync.git synced 2026-04-26 00:05:57 +03:00

[GH-ISSUE #38] Test button #31

New issue

Closed

opened 2026-02-28 01:22:50 +03:00 by kerem · 5 comments

kerem commented

2026-02-28 01:22:50 +03:00

Owner

Originally created by @mitra42 on GitHub (Aug 29, 2012).
Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/38

Could I suggest that there is a way during the setup of the URL process to test it. For example by sending a well defined query to the server that then responded. I am imagining someone in a country disconnected from the server trying to setup the gateway and not knowing if it is set up right, and that a TEST button would be useful .

Maybe the TEST button could send a copy of the settings, and get back feedback … For example we will need to make sure the phone is set to Poll the server for outgoing SMS, and I am seeing as a significant failure point being the likelihood that the owner of the Phone sets up the gateway incorrectly and that we are trying to debug this by international phone call from the US for example.

A test button would also help debug the server (something I’m trying to do now) with otherwise no way to generate the JSON calls

Originally created by @mitra42 on GitHub (Aug 29, 2012). Original GitHub issue: https://github.com/ushahidi/SMSSync/issues/38 Could I suggest that there is a way during the setup of the URL process to test it. For example by sending a well defined query to the server that then responded. I am imagining someone in a country disconnected from the server trying to setup the gateway and not knowing if it is set up right, and that a TEST button would be useful . Maybe the TEST button could send a copy of the settings, and get back feedback … For example we will need to make sure the phone is set to Poll the server for outgoing SMS, and I am seeing as a significant failure point being the likelihood that the owner of the Phone sets up the gateway incorrectly and that we are trying to debug this by international phone call from the US for example. A test button would also help debug the server (something I’m trying to do now) with otherwise no way to generate the JSON calls

kerem closed this issue

2026-02-28 01:22:50 +03:00

kerem commented

2026-02-28 01:22:51 +03:00

Author

Owner

@olliebennett commented on GitHub (Dec 21, 2012):

In order to test the setup, I simply send myself a SMS message, and then monitor what request the server receives.

I agree that a test button would be useful, but would also add complexity and it could be unintuitive for the user as to what the button really does.

@olliebennett commented on GitHub (Dec 21, 2012): In order to test the setup, I simply send myself a SMS message, and then monitor what request the server receives. I agree that a test button would be useful, but would also add complexity and it could be unintuitive for the user as to what the button really does.

kerem commented

2026-02-28 01:22:51 +03:00

Author

Owner

@eyedol commented on GitHub (Jul 11, 2013):

When a test button is hit, it should send a ping to the configured URL. Upon successful ping, the test should expect a JSON format as below

{
    payload: {
        success: "true"
    }
}

{
    payload: {
        success: "false"
    }
}

We can safely assume the SYNC URL is properly configured.

Return a Success or Failure depending on the status of the test.

@eyedol commented on GitHub (Jul 11, 2013): When a test button is hit, it should send a ping to the configured URL. Upon successful ping, the test should expect a JSON format as below ``` javascript { payload: { success: "true" } } ``` Or ``` javascript { payload: { success: "false" } } ``` We can safely assume the `SYNC URL` is properly configured. Return a `Success` or `Failure` depending on the status of the test.

kerem commented

2026-02-28 01:22:51 +03:00

Author

Owner

@mitra42 commented on GitHub (Jul 11, 2013):

I think Github failed to post my comment - apologies if there is a delay and this gets duplicated.

I think that we want more from the test than this. This is commonly going to be used to check the phone, and also for diagnostics to split the problem between Mobile <> Smsync and SMSsync <> Server
The human intelligence could be either end - someone in the field trying to figure out what is working, or a support person at the server giving instructions to a non-smssync literate person in the field.

Ideally it should
a) let the holder of the phone know its configured correctly
b) let them know the server is working properly.
c) If forwarded to a support person, provide useful information to help diagnose problems.

I suggest that the message should be a correctly formatted SMS request - i.e. json to the server, and that the settings AND the phone number of the phone - should be packed into it (maybe also the location) . In case (c) this could be passed onto the support person who can check the settings, and confirm that for example in Peru the smssync gateway sits at phone number 123456

The response should also look like a SMS message - it could be human readable (allowing instructions on changing settings) or any server diagnostic message (for case b). Maybe it should be packaged so its destination phoen number is the one in the request packet).

I don't think I'm complicating it too much ?

@mitra42 commented on GitHub (Jul 11, 2013): I think Github failed to post my comment - apologies if there is a delay and this gets duplicated. I think that we want more from the test than this. This is commonly going to be used to check the phone, and also for diagnostics to split the problem between Mobile <> Smsync and SMSsync <> Server The human intelligence could be either end - someone in the field trying to figure out what is working, or a support person at the server giving instructions to a non-smssync literate person in the field. Ideally it should a) let the holder of the phone know its configured correctly b) let them know the server is working properly. c) If forwarded to a support person, provide useful information to help diagnose problems. I suggest that the message should be a correctly formatted SMS request - i.e. json to the server, and that the settings AND the phone number of the phone - should be packed into it (maybe also the location) . In case (c) this could be passed onto the support person who can check the settings, and confirm that for example in Peru the smssync gateway sits at phone number 123456 The response should also look like a SMS message - it could be human readable (allowing instructions on changing settings) or any server diagnostic message (for case b). Maybe it should be packaged so its destination phoen number is the one in the request packet). I don't think I'm complicating it too much ?

kerem commented

2026-02-28 01:22:51 +03:00

Author

Owner

@eyedol commented on GitHub (Jul 11, 2013):

@mitra42 what you've said above is more like what we want to do with the Log viewer feature. See #97

This issue is going to fix scenario a)

@eyedol commented on GitHub (Jul 11, 2013): @mitra42 what you've said above is more like what we want to do with the `Log viewer` feature. See #97 This issue is going to fix scenario **a)**

kerem commented

2026-02-28 01:22:51 +03:00

Author

Owner

@mitra42 commented on GitHub (Jul 11, 2013):

I don't think these are the same thing at all - #97 doesn't seem to solve any of a,b or c - maybe c, but only then if the log contains enough info for hte support person to diagnose the problem.

@mitra42 commented on GitHub (Jul 11, 2013): I don't think these are the same thing at all - #97 doesn't seem to solve any of a,b or c - maybe c, but only then if the log contains enough info for hte support person to diagnose the problem.