Hi Dave,

an interesting thought. Why don't we use the subscription mechanism directly?

A user mentioning a user could autosubscribe him on the artifact. So he will get all updates on it, too. **But** he will be able to unsubscribe at any time.

An additional requirement then, would be, that the user may wants to define in his settings if the auto-subscription should be done or not.

If not, they just want to be notified once about the mentioning.

In conclusion I think people just want to be informed once about the mentioning. Changes should be handled using subscriptions. And the auto-subscribe-to-mentions-option, would be an optional feature.

What do you think?

Cheers,
Ingo

Dave Brondsema <dave@brondsema.net> schrieb am Mi., 10. Juli 2019, 22:31:

Looks like a good start to this ticket. Here's some thoughts:

In get_usernames_from_md, the usernames variable should be a set instead of a list, so if a username is mentioned multiple times, they don't get multiple notifications.

Our email templates are markdown (and jinja), so might be nice to name it .md like some other templates. And since its markdown, you can make the link be within the text, instead of just a URL on its own line. Something like at [{{ project_name }} {{ mount_point }} {{ artifact.link_text() }} ]({{ h.absurl(artifact.url()) }}) (haven't tested that to see how it works or how it looks).

It might be good to change send_usermentions_notification to be a background task, since sometimes markdown conversion can take a while if the text is huge. Then it could be in Allura/allura/tasks/notification_tasks.py which would be nicer than on app_globals.py.

We'll want to call send_usermentions_notification( in more places than just comments - like tickets created, wiki pages created/edited, etc. Maybe add one or two more examples for now, but at some point you'll want to put them in many places. (You can search for create_activity( calls, which cover a lot of different artifact actions)

Thinking about overall functionality which probably is more related to unsubscribe [#8285], but somebody might get notified about something via regular subscriptions, and then also get a notification because of their username mention. Maybe ok, maybe not? Also if some text is edited, we probably don't want to notify every time its edited. But maybe we do if their username was newly added? That might be hard to keep track of. Stuff to think about with regard to that next ticket and what data needs to be stored in new fields or new models.

[tickets:#8284] gsoc19-c4: Implement the notification email sender

Status: in-progress
Milestone: unreleased
Labels: gsoc19
Created: Wed May 08, 2019 03:03 PM UTC by Shalitha Suranga
Last Updated: Tue Jul 09, 2019 04:20 PM UTC
Owner: Shalitha Suranga

Todo

This function is responsible for detecting user mentions and sending email notifications. For the detection markdown extenstion can be reused. For sending emails existing interfaces can be used; or any other better mechanism will be discussed before the implementation.

What is expected

When a user is mentioned (and the markdown is saved) the relevant user will be notified with an email

Sent from forge-allura.apache.org because dev@allura.apache.org is subscribed to https://forge-allura.apache.org/p/allura/tickets/

To unsubscribe from further messages, a project admin can change settings at https://forge-allura.apache.org/p/allura/admin/tickets/options. Or, if this is a mailing list, you can unsubscribe from the mailing list.