Closed lukeoftheshire closed 2 years ago
ParicipantID
in push payload, and can verify with logged userid. To do this, we also need permission from apple detailed here .
@saranya-sajeev please confirm it is possible with Android also.@avaidyam We can start (1) and (3) items. Let us know if we need to implement (2)
@jijopulikkottil I think we want to do (2) as well. In addition we should use this to remove notifications instead of showing a "notification expired" message.
@jijopulikkottil @avaidyam In android also we can check ParicipantID in payload against logged in user id.
iOS and Android will check on this after #643
@jijopulikkottil I think we want to do (2) as well. In addition we should use this to remove notifications instead of showing a "notification expired" message.
We can't remove delivered notification by implementing (2).
We can start working on item (2) once the request submit and accepted.
@avaidyam, do we need to fix the following case on front-end:
Since they were logged into a different study, the assigned activity didn't exist in this server and the user got a grey spinning circle.
@Linoy339 please confirm (1)
@jijopulikkottil, @avaidyam We have confirmed that notification are not firing after logged out.
We can start working on item (2) once the request submit and accepted.
@jijopulikkottil It looks like mindLAMP is not going to be permitted to apply for that entitlement. ("This entitlement is intended for certain types of apps — such as messaging apps or location sharing apps...") so we will need to ignore item (2) for now.
do we need to fix the following case on front-end:
Yes, we do.
@jijopulikkottil @Linoy339 Has this been QA tested and confirmed fixed yet?
@avaidyam QA-testing is in-progress. Can confirm tomorrow.
@lukeoftheshire Could you try once more and check whether you are able to reproduce it or not. We tried here using different user under different study but not getting the issue. We think It maybe an edge case.
@avaidyam @lukeoftheshire @jijopulikkottil
Since they were logged into a different study, the assigned activity didn't exist in this server and the user got a grey spinning circle.
This is handled and updated in zco-staging. After QA confirms, we can update in dashboard-staging.
@avaidyam QA-testing is in-progress. Can confirm tomorrow.
We couldn't reproduce this issue.
@avaidyam @lukeoftheshire @jijopulikkottil
Since they were logged into a different study, the assigned activity didn't exist in this server and the user got a grey spinning circle.
This is handled and updated in zco-staging. After QA confirms, we can update in dashboard-staging.
I just tested by programmatically manipulated the url to open when tapping on notification. And got this alert.
@jijopulikkottil Thanks! That's helpful to know. Can we also make sure old activity schedules are not cached by the iOS app and the backend (cc @Linoy339) is able to handle logout events correctly too (i.e. stop sending notifications to a device token once it is logged out)?
Yes, on iOS side, we are deleting pending and delivered notifications when logged out. On server side, @Linoy339 also confirmed this (stop sending notifications to a device token once it is logged out).
@sarithapillai8 @jijopulikkottil I believe this issue is now resolved so I'm closing the issue. Correct me if it's still pending.
This seems to be fixed in staging!
A user was helping conduct QA testing across multiple servers. While logged into the second server, they received a notification to do an activity from a prior study (from which they had logged out) at the time which it should have fired. Since they were logged into a different study, the assigned activity didn't exist in this server and the user got a grey spinning circle.
If an activity fails to load, the participant should probably be returned to the activity page instead of the app basically crashing. Additionally, the notification shouldn't have fired at all. From the logs of the SECOND user, I found this
lamp.analytics
event:Please note also that not only does this activity NOT exist on this server, this is not the correct user id even, but the old (logged-out) id.
In other words, this is like if I called LAMP.SensorEvents('PARTICIPANT_A') but this activity event was trying to open'/participant/PARTICIPANT_B/activity/qexqbpmgygcmmngacx3a'. The SensorEvent logs for PARTICIPANT_B don't show this notfication.