Email notification on reply

[dwhly]

Steps for implementation

• When someone replies to your annotation, you should get an email. - https://email1.dokku.hypothes.is/
• Design e-mail template (currenty we have a very simple one)
• Implement email subscription to streams / searches / replies #581
• Implement a backend api for generating a reply annotation properly.
• Implement an e-mail monitoring service which parses e-mails sent to an e-mail address.
• When you in turn send an email reply to that email, it should end up as as reply annotation from you (using the previous two points)
• Implement @username invitations / mentions into conversations #580

This will be important as part of the overall W3C work here:
http://docs.webplatform.org/wiki/WPD:Annotations

[csillag]

I think #581 is the closest one, but in only covers the email notifications part, and does not specifically mention replies. (I will add that right now.)

The ability to parse emails, and turn them into annotations is new, so this is not a duplicate.

[csillag]

I have updated the OP with pointers to individual issues describing the wanted features, and changed title to focus on the remaining new feature

[gergely-ujvari]

Currently it is hard to test this in a dokku instance, but here is what should be done for testing it.

• Since every dokku update purges the user db, you've to register a new user to be able to reply
• You've to reregister the user whose reply you're willing to reply.
• After this you'll get the e-mail notification.

In normal working the user db is in sync with the annotation db, so this is a dokku case only. I've fixed the bug that it simply returns if the user is not found. (We should do this for redacted annotations)

[gergely-ujvari]

New test server: https://email2.dokku.hypothes.is/
It is doing what email1 does, but it uses user subscriptions according to v2 specification. (I'll add the ui endpoint for streampage soon)

[gergely-ujvari]

Sending e-mails to document owners feature may be delayed by this issue: #1046
(I'm investigating)

[tilgovi]

Closing in favor of hypothesis/vision#44

[BigBlueHat]

@dwhly I'm guessing from this re-open that hypothesis/vision#44 is insufficient?

If this issue is due in the currently connected milestone (2014-08-08), do you want all the mentioned issues completed? If so, we need to associate those to 2014-08-08 so it's scoped properly.

Thanks!

[tilgovi]

This issue is not sufficiently well described here and the implementation steps are not at all in the direction I'd like to take this.

I would like to move this outside the h repo, which is why I opened hypothesis/vision#44 and even left a message there stating it obsoletes this.

I'm guessing that @dwhly just wanted this on the roadmap. As such, I've added the Roadmap: Major label to the vision issue and I'm closing this again.

[dwhly]

I think this got reopened during our roadmap back and forth discussion about where things belonged. It was also scheduled on the current milestone. updating hypothesis/vision#44 accordingly (assuming it's ok when only portions of things are addressed in milestones?)

[BigBlueHat]

@dwhly only if those "portions of things" are shippable in themselves, or the shippable issues are also scheduled for the milestone. Vision issues are representative of a "large effort" so they shouldn't ever be expected to close during a milestone--without lots of related, implementable issues closing "under" them.

We'll likely need to start making implementable issues more often--vs. just these big guys.