1061574 - [User Story] As a Helpee, I get a OS notification when someone added a comment on one of my discussion threads, so that I can review it quickly.

Status: VERIFIED FIXED

(support.mozilla.org :: BuddyUp, defect, P2)

Comment 1

[Michael Cooper [:mythmon]]

Adding implementation bugs as blockers.

Comment 2

[Anthony Ricaud (:rik)]

Romain: * If the helpee is offline at the time of the comment submission, he won’t receive the notification

This is confusing to me. If the helpee is offline, I was thinking he should receive the notification as soon as he gets online again. If I understand SimplePush correctly, this is what it will do. Am I missing something?

Comment 3

[Anthony Ricaud (:rik)]

I'm moving this user story out of the sprint because it will only be complete after bug 1083415 is done and some other front-end work.

Bug 1110151 is the part that we covered in this sprint.

Comment 4

[Romain Testard [:RT]]

(In reply to Anthony Ricaud (:rik) from comment #2)
> Romain: * If the helpee is offline at the time of the comment submission, he
> won’t receive the notification
> 
> This is confusing to me. If the helpee is offline, I was thinking he should
> receive the notification as soon as he gets online again. If I understand
> SimplePush correctly, this is what it will do. Am I missing something?

My understanding from SimplePush is that it delivers the message without knowledge of availability of the endpoint. If the end point is offline then there is a timeout and the message gets lost.
I may be wrong though and could not find an answer to this question on the wiki, who helps us with technical integration of SimplePush?

Comment 5

[Anthony Ricaud (:rik)]

Let's ask Fernando about SimplePush behaviour.

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

AFAIK the UA needs to acknowledge the SimplePush server about the reception of the version message. If the ack is not received by the server it keeps retrying to send the same version message until the ack is received or a new notification for the same channelID is received, in which case the server can queue both notifications or discard the previous one. I am not sure what are the current server implementations (TEF and MOZ) doing in this last case, if they queue or discard these messages.

(In reply to Anthony Ricaud (:rik) from comment #2)
> Romain: * If the helpee is offline at the time of the comment submission, he
> won’t receive the notification
> 
> This is confusing to me. If the helpee is offline, I was thinking he should
> receive the notification as soon as he gets online again. If I understand
> SimplePush correctly, this is what it will do. Am I missing something?

Yes, that's my understanding as well. As soon as the device gets online again, it should receive the pending notifications from the server. As I said before, I don't know if all the notifications (queued) or just the last one for each channel ID, but AFAIK it should get at least a notification per channel ID.

Fernando Rodriguez and JR Conlin probably know with more detail.

Comment 7

[Francisco Jordano [:arcturus] [:francisco]]

Last time I read the spec, they were sending just the latest sequence id.

Comment 8

[JR Conlin [:jrconlin,:jconlin]]

The server will send only send one notification regardless of how many notifications were sent. Notifications are collapsed. The notification may expire if the last request was beyond the time limit imposed by the server (~72 hours for Moz). 

The notification should contain a "version" number that is set by the original App server. 
So if an app gets "version=100" then later gets "version=120" it would know that there is a gap of 19 messages. Coordination of message dissemination is left to the app to implement.

Comment 9

[Fernando R. Sela (no CC, needinfo please) [:frsela]]

The TEF SimplePush implementation also sends the last version received for a channel as JR Conlin said.

In our case, if the notification can not be delivered, we store it and we'll retry later or as soon as the device connects to the server again, all pending notifications will be delivered.

Also the notification SHALL contain a "version" number, if not it will be rejected.

Our server store all information in a Sharded MongoDB so they aren't lost after server outages.

Comment 10

[Anthony Ricaud (:rik)]

Mike: Is it possible to only get unread notifications? I tried "api/2/notification/?is_read=0" and "api/2/notification/?is_read=false" but it didn't work. I'm filtering on the client side for now but I assume we don't want this response to grow indefinitely.

Comment 11

[Anthony Ricaud (:rik)]

Attachment: https://github.com/mozilla/buddyup/pull/79

Because of a SUMO bug, you'll need to manually trigger a simplepush message to verify the flow.

Just do 'http PUT <url_of_endpoint>' with httpie.

To get all endpoints registered by your client, you can run this in the WebIDE:
var req = navigator.push.registrations();
req.onsuccess = () => console.log(req.result.map((a) => a.pushEndpoint));

Comment 12

[Michael Cooper [:mythmon]]

Anthony, the API now allows ?is_read=0 and ?is_read=1.

https://github.com/mozilla/kitsune/pull/2365

Comment 13

[Anthony Ricaud (:rik)]

Cool! I've updated my pull request to take advantage of that.

Comment 15

[Kadir Topal [:atopal]]

Turned out to be a 3 pointer.

Comment 16

[Anthony Ricaud (:rik)]

https://github.com/mozilla/buddyup/commit/8d1870fc24bdf8311d2e93ff50e1b6981286f839

Comment 17

[Christos Bacharakis]

Everything works fine except:

Flame, Firefox OS 2.0
STR:
1. Helpee: Post a new question and then go offline (turn the wifi off)
2. Helper: Reply to the question
3. Helpee: Connect the flame to the internet again
4. The helpee won't receive any OS confirmation / notification that his question is answered

Comment 18

[Christos Bacharakis]

New bug 1136600 created the Comment 17