OU Send Limits

[QISPSK]

It was mentioned in our last Skype call that the app switched OUs to inactive if they've sent more than 30 surveys in 30 minutes. While this is great for when we distribute the phones, can this limit be increased for the pre- and post-test OUs? Trainings have up to 30 participants on one OU at a time sending 5+ surveys each. We're not sure if this is causing issues or not (it doesn't seem like it as one post-test had 90+ surveys sent yesterday), but it would be good to up the limit just in case.

[rodmelia]

There are 2 parts for the OU send limit logic:

• counting of '# of Surveys' per 30 minutes is client side
• blocking of a OU is server side

If you have 5 phones pointing to the same OU, each phone can send up to 30 surveys per 30 min. As soon as one phone send more than 30 surveys per 30 min, the OU will be blocked in the server, stopping any phone from sending more surveys.

Do you still want to consider for S6 a change on this logic, by introducing a 'training mode' to the app, so the message to block an OU doesn't get send from the app?

[QISPSK]

It sounds like the current setup actually works in the case of trainings - I thought it was just 30 surveys per OU.

Is the client side count tied to the OU? For example, in these trainings we've been switching between OUs on the same set of phones (usually: pre-test OU --> QIS test int --> post-test OU). A single phone could potentially send more than 30 surveys in 30 minutes during a training (though it's unlikely). Would the OU that the phone is on when the 30th survey is sent be blocked? Or does the limit reset with the OU change?

[QISPSK]

@ifoche Can this limit be removed entirely? It seems to have locked out a number of OUs recently that are sending legitimate surveys and doesn't seem to prevent duplicate or blank data.

[ifoche]

Sure. It was not introduced to prevent duplicate or blank data, but to avoid user abuse in case any user start sending surveys out of control. I suppose we wait for 2.25-compatible to remove it, right?

[QISPSK]

@ifoche I don't think there is any rush to remove it and we can wait for 2.25 compatibility. It's something we will monitor on our end, but we do have providers who (surprisingly) occasionally see more than 30 legitimate suspected cases per day and just need to make sure they aren't locked out of the system when they try to send cases the next month.

[ifoche]

@QISPSK that's fine, we can raise this number to something like 500 if you still want to keep this feature for extreme cases, or totally remove it, both are very simple to implement. Which option do you prefer?

Else, I've moved this issue from the old S6 milestone to the new v1.3 to follow the new versioning nomenclature we're using, where S5 is v1.2 and S6 is v1.3.

[QISPSK]

@ifoche Nomenclature change makes sense. I think we can probably just remove this feature. We haven't seen anyone abuse data entry up to this point and it wouldn't be possible to tell if they did unless they directly contact us (or we do a scan for locked OUs each month). It seems to be preventing legitimate surveys so we might as well toss it and reintroduce it if we start to see something crazy down the road.

[ifoche]

@QISPSK you're totally right. We will remove it for next release.

[QISPSK]

@ifoche Unable to test given that only KH MCS Post-Test_BMC_01 and 02 are exposed. From what I remember, OU Send Limits for pre-and post-test OUs are significantly higher than regular OUs. Will test this when we can use regular OUs on 2.25

[ifoche]

@QISPSK the OU send limit has always been equal for all OUs, and concretely 30 in an hour. If you experimented at any point that you could send more than that, then it was a bug. Now in principle you will never be blocked, unless you force it server side.