444335 - E-mail notifications when someone responds to a forum thread

Status: VERIFIED FIXED

(support.mozilla.org :: Forum, task, P1)

Description

[David Tenser [:djst]]

Most of the users of the forum post anonymously today. The problem is that we have no idea of how many people actually find their way back to their post whenever someone responds. The high volume of posts with just one reply and no confirmation from the original poster (OP) seems to indicate that the amount of people that don't come back is pretty significant.

We've talked before about making it easy to register while you're writing the forum post, but this will eventually lead to some hundred thousand accounts of people who just registered to ask a question, which seems not ideal. 

Instead, we should just offer the ability to provide an e-mail address to send a notification whenever someone replies to the thread. From that e-mail, we should also offer two basic choices (hashed links) to the user:

Did this answer solve your problem?

Yes, this solved my problem -> mark thread as solved
No, my problem still remains -> link back to the thread and focus on the reply box

Comment 1

[Jason Barnabe (np)]

It's not as simple as just storing an e-mail address because you also have to have the ability to remove an address (and not remove other people's addresses). Anonymous users are also asked to enter a name. To compare:

-"Anonymous" users: Name + e-mail address + mechanism to remove e-mail address + captcha
-Registered users: Name + e-mail address + password + captcha

Really there's not much difference except the fact that we have the code to handle regular users right now.

I don't see the problem in having a lot of user accounts. What's your issue with it? Are you concerned about performance? UI?

Comment 2

[David Tenser [:djst]]

What do you mean with "ability to remove an address"? Who should have that ability and why?

My issues with lots of user accounts are

* name collisions will ultimately occur
* performance might be an issue
* generally pointless to have user accounts for a one-time support "ticket"

Comment 3

[Jason Barnabe (np)]

You have to give the user the ability to remove their e-mail address from any notification list. This might even be the law.

Name collisions can be resolved specifically in the case of new end users by tacking on a number at the end if the name's already taken or by some other mechanism. It's not a difficult problem.

I'd like to hear from Nelson or another Tiki person what effect a lot more users would have on the system.

Regarding pointlessness, I think it's pointless to set up an alternate system when we have one that would do what we need.

Comment 4

[David Tenser [:djst]]

Another issue with user accounts that I missed is that you actually have to provide a password, which is another hurdle for an already frustrated user.

From a technical point of view, I'm not sure if it would have to be an entirely different system.

Comment 5

[David Tenser [:djst]]

Removing someone from the thread should also be possible from the e-mail that's sent out. You're probably right that's it's required by law. :)

Comment 6

[Jason Barnabe (np)]

Another thing to consider: if you revisit the forum outside of the link you got in the e-mail, registered users can find their posts easily, anonymous users can't.

Comment 7

[David Tenser [:djst]]

Yes that's an interesting point. 

Comment 8

[Jason Barnabe (np)]

Regarding the idea that people don't *want* to register:

We could implement bug 398486 and see how much that gets us. We could then do some investigation on why the remaining people don't register (don't want to provide an e-mail, don't want to set up a password), etc. then design this solution accordingly.

Comment 9

[[:Cww]]

Perhaps we could periodically clear users from the database if they haven't logged in a while (do we store last login?) and haven't made themselves contributors ... maybe there's a mechanism to do this?  Some text like "This account is temporary to allow you to find your question again and post followups.  It will be removed after 90 days of inactivity."

Comment 10

[Alexander Mette [amette]]

One known problem with having many users is known from http://dev.tikiwiki.org. There on the bug-tracker are drop-down boxes for assigning a bug to someone - and those apparantly become huge after some time. Dunno of any basic problem though.

Comment 11

[Jason Barnabe (np)]

We've already had some problems with pages that display all users like the action log and the edit forum page. These problems have been fixed, so I'm not concerned about performance from that perspective. I'm more concerned about how having many more users will affect things like loading one specific user, and how having more logged in users using the site will affect performance.

Comment 12

[[:Cww]]

What about bug 446203 as an alternate proposal?

Comment 13

[David Tenser [:djst]]

Setting P1 on bugs that are "must haves" for 0.7. This bug should be targeted to 0.6.3 or 0.6.4, or kept in 0.7 which will be the last milestone for Q3.

Comment 14

[Majken Connor [:Kensie]]

We could require a username and email and then generate a password and send it to the user. If they decide to come back they can use the login details and even set up their profile.

Removing email from lists without accounts is fairly simple, you send a confirmation note to the email address and then the user clicks that link. Not sure how simple that is to implement, my first suggestion is probably more useful though.

Comment 15

[David Tenser [:djst]]

We've been talking a lot about how this notification would also include links allowing the user to tell whether or not the answer solved the problem. To clarify, for this bug this is not a requirement, as it depends on "Implement per-thread status of 'problem solved,' so we can tell which answer in a forum thread is the solution."

What we need for this bug is:

1. A way for the user to specify an e-mail address when posting a question, e.g. a text box and a label saying "If you specify your e-mail address, we will send an e-mail to you whenever someone responds to your question."
2. A notification to be sent out whenever someone responds to the thread, along with 
  - The answer to the question
  - A link taking you back to the forum thread
  - A link to subscribe yourself from the notifications

Comment 16

[Nelson Ko [:nkoth]]

As far as implementation method is concerned, I recommend that we use a new db table like:

tiki_anonymous_watches (which is basically a modified version of  tiki_user_watches but using email as primary key), and modify/extend the existing user watches code to support anonymous watches. One should not write new functions unnecessarily --> just need to extend the existing functionality to use different (new) queries if no user is specified - to use email instead.

Comment 17

[Les Orchard [:lorchard]]

Getting this bug into my todo list

Comment 18

[Les Orchard [:lorchard]]

Attachment: patch to add anonymous email notification watches to forum threads

Okay, I think the attached patch should do the job:

* A new field for an anonymous user's email address is added, which will create a new anonymous watch for the current thread.  Only one watch for that thread and that email address will be allowed.

* The anonymous user's detected language is saved along with the watch so that the emails sent out can take advantage of translations for the email message templates

* The emails sent out on thread posts will include a link to the thread, the new comment posted, as well as a link to cancel the watch.

To use this patch, the following DB tweaks are required:

alter table tiki_user_watches add column language varchar(16) not null default '';
alter table tiki_user_watches add column is_anonymous tinyint(1) not null default 0;
create index idx_is_anonymous on tiki_user_watches (is_anonymous);

Comment 19

[Les Orchard [:lorchard]]

Checked into trunk as r18558

Comment 20

[Laura Thomson :laura]

SQL changes have been made on support-stage.  Stephen, please test away :)

Comment 21

[Les Orchard [:lorchard]]

marking fixed since it's in trunk and DB changes done on stage

Comment 22

[Stephen Donner [:stephend] Not actively reading bugmail]

Les: can you point me to URLs on staging where this is supposed to show up, when you get a chance to look at it again?

I'm not seeing the Email Address field when I posted any of the test postings on http://support-stage.mozilla.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=165154.

Thanks!

Comment 23

[Les Orchard [:lorchard]]

Just snuck in another quick fix to get the email field into the new thread page (view_forum) in r18581

But the email address field should already be showing on the view_forum_thread pages - not sure why it's not.  I see it added in the template in trunk, so I know I checked it in.

http://viewvc.svn.mozilla.org/vc/projects/sumo/trunk/templates/styles/mozkb/comments.tpl?r1=16280&r2=18558&pathrev=18558

I wonder if there's something being cached by smarty in templates?  ugh

Comment 24

[Les Orchard [:lorchard]]

checked in to prod branch as r18617 - looks like staging pulls from prod, so hopefully this makes things go

Comment 25

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED:

The email address field shows up on both http://support-stage.mozilla.org/tiki-view_forum.php?locale=en-US&forumId=1&openpost=1 and subsequent postings, such as:

http://support-stage.mozilla.org/tiki-view_forum_thread.php?forumId=1&comments_parentId=165153

* Anchor link to the appropriate message in the thread works
* Answer is present
* The unsubscribe functionality works immediately, as well.

Note that the email address entered does NOT persist when clicking "Preview", because it's not stored in a cookie; as Les mentioned in #sumodev, future enhancements might have a checkbox to persist your email address, though.

Nice work, Les.