Closed Bug 1061574 Opened 8 years ago Closed 7 years ago

[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.

Categories

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

All
Gonk (Firefox OS)
defect

Tracking

(Not tracked)

VERIFIED FIXED
2014Q4

People

(Reporter: RT, Assigned: rik)

References

Details

(Whiteboard: p=3 s=bu.2015.3)

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.

Acceptance criteria:
* When someone comments on a discussion thread opened by the helpee, the helpee receives an OS notification on his phone 
-The notification displayed is as follows: <Commenter name> has commented on a question: “<First X characters of the comment followed by … if the comment is above X characters> ”
* If the discussion thread has been tagged by the helpee as “Solved”, the helpee won’t receive notifications for new comments on this thread
* If the helpee is offline at the time of the comment submission, he won’t receive the notification
Tapping the notification will take the helpee to the discussion thread
* If the helpee has unticked the checkbox “Receive new comment notifications” on the discussion thread, he won’t receive new comments related to this specific discussion thread
* If the helpee has re-ticked the checkbox “Receive new comment notifications” on the discussion thread, he will start receiving again new comments related to this specific discussion thread

Attachments

(1 file)

42 bytes, text/x-github-pull-request
rehandalal+mozilla
: review+
Details | Review
No description provided.
Adding implementation bugs as blockers.
Depends on: 1068121
Depends on: 1083415
Priority: -- → P2
Target Milestone: --- → 2014Q4
User Story: (updated)
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?
Flags: needinfo?(rtestard)
Blocks: 1109642
Whiteboard: p=1
Depends on: 1110151
Depends on: 1110167
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.
No longer blocks: 1109642
(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?
Flags: needinfo?(rtestard)
Let's ask Fernando about SimplePush behaviour.
Flags: needinfo?(ferjmoreno)
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.
Flags: needinfo?(jrconlin)
Flags: needinfo?(frsela)
Flags: needinfo?(ferjmoreno)
Last time I read the spec, they were sending just the latest sequence id.
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.
Flags: needinfo?(jrconlin)
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.
Flags: needinfo?(frsela)
Whiteboard: p=1 → p=1 s=bu.2015.3
Assignee: nobody → anthony
Status: NEW → ASSIGNED
Depends on: 1132127
Depends on: 1132145
Depends on: 1132146
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.
Flags: needinfo?(mcooper)
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));
Attachment #8563486 - Flags: review?(rdalal)
Anthony, the API now allows ?is_read=0 and ?is_read=1.

https://github.com/mozilla/kitsune/pull/2365
Flags: needinfo?(mcooper)
Depends on: 1132544
Cool! I've updated my pull request to take advantage of that.
Duplicate of this bug: 1061593
No longer depends on: 1083415
Turned out to be a 3 pointer.
Whiteboard: p=1 s=bu.2015.3 → p=3 s=bu.2015.3
Attachment #8563486 - Flags: review?(rdalal) → review+
https://github.com/mozilla/buddyup/commit/8d1870fc24bdf8311d2e93ff50e1b6981286f839
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
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
Flags: needinfo?(a.topal)
New bug 1136600 created the Comment 17
Status: RESOLVED → VERIFIED
Flags: needinfo?(a.topal)
Flags: in-moztrap+
You need to log in before you can comment on or make changes to this bug.