History:Implementing Email Communications: Difference between revisions

From MusicBrainz Wiki
Jump to navigationJump to search
((Imported from MoinMoin))
(e-mail -> email (Imported from MoinMoin))
Line 3: Line 3:
[[Image:Attention.png]] '''''Status:''' This feature has been implemented in [[Server|MusicBrainz server]]. This page will be kept for historical purposes.''
[[Image:Attention.png]] '''''Status:''' This feature has been implemented in [[Server|MusicBrainz server]]. This page will be kept for historical purposes.''


This page describes the work necessary to be able to use moderators' registered e-mail addresses as a form of communication; in the first instance, to allow moderators to communicate on moderation issues.
This page describes the work necessary to be able to use moderators' registered email addresses as a form of communication; in the first instance, to allow moderators to communicate on moderation issues.


=Confirmed E-mail Address Registration=
=Confirmed Email Address Registration=


So far the e-mail addresses in MB (moderator.email) are just single line free text. The data in there so far presumably includes completely valid addresses, faked addresses, things which aren't addresses but which represent them (e.g. "x at y dot com"), random meaningless text, and of course blanks.
So far the email addresses in MB (moderator.email) are just single line free text. The data in there so far presumably includes completely valid addresses, faked addresses, things which aren't addresses but which represent them (e.g. "x at y dot com"), random meaningless text, and of course blanks.


What we need to do is to implement a confirmed registration system, and then attempt to migrate the existing "email" column - whatever it contains - to a confirmed e-mail address.
What we need to do is to implement a confirmed registration system, and then attempt to migrate the existing "email" column - whatever it contains - to a confirmed email address.


==Confirmation System==
==Confirmation System==
Line 17: Line 17:


For new users:
For new users:
* register and enter e-mail address as normal. Set emailconfirmdate to NULL
* register and enter email address as normal. Set emailconfirmdate to NULL
** enforce that the e-mail address is either blank, or "looks ok" (e.g. something a bit looser than ^\w+\@\w+(.\w+)*$)
** enforce that the email address is either blank, or "looks ok" (e.g. something a bit looser than ^\w+\@\w+(.\w+)*$)
** do we still allow blank e-mail? Or shall we insist on a valid e-mail address?
** do we still allow blank email? Or shall we insist on a valid email address?


* send confirmation e-mail to the cited address
* send confirmation email to the cited address
** the e-mail message includes a web link back to MB, e.g. /user/confirmaddress.html
** the email message includes a web link back to MB, e.g. /user/confirmaddress.html
** the web link includes query string params for user ID, new e-mail address, time sent, and a checksum (tamper-proofing)
** the web link includes query string params for user ID, new email address, time sent, and a checksum (tamper-proofing)


* the user then clicks the web link to confirm their receipt of the message
* the user then clicks the web link to confirm their receipt of the message
Line 33: Line 33:
** If something goes wrong, e.g. checksum or timestamp failure, show appropriate message
** If something goes wrong, e.g. checksum or timestamp failure, show appropriate message


When a user wishes to change their e-mail address:
When a user wishes to change their email address:
* enter new moderator details on form as normal. Save all details except email address.
* enter new moderator details on form as normal. Save all details except email address.
** e-mail field validates as for new users
** email field validates as for new users


* system sends e-mail containing web link as for new users. Message is sent to the new address.
* system sends email containing web link as for new users. Message is sent to the new address.
* changeaddress page operates as before
* changeaddress page operates as before


For existing users, we need to validate their existing moderator.email values:
For existing users, we need to validate their existing moderator.email values:


The easy option: we could just tell all moderators that, next time they log in, they should go to their "profile" page and re-enter their e-mail address. Then follow the rules as for "changing address", above.
The easy option: we could just tell all moderators that, next time they log in, they should go to their "profile" page and re-enter their email address. Then follow the rules as for "changing address", above.
* How about we ask the moderator to verify their email if they have an unconfirmed email addy after they log in? We can also give them the option of removing the email addy. [[User:Ruaok|Ruaok]]
* How about we ask the moderator to verify their email if they have an unconfirmed email addy after they log in? We can also give them the option of removing the email addy. [[User:Ruaok|Ruaok]]
* OK, but what state do they start off in? Do you just leave them all as uncomfirmed (the above option) or try to confirm them automatically as part of the data migration process (the below option)? [[User:DaveEvans|DaveEvans]]
* OK, but what state do they start off in? Do you just leave them all as uncomfirmed (the above option) or try to confirm them automatically as part of the data migration process (the below option)? [[User:DaveEvans|DaveEvans]]
Line 55: Line 55:
* two extra columns: lastverifysent and numoutstandingverifies
* two extra columns: lastverifysent and numoutstandingverifies
* when emailconfirmdate becomes sufficiently old (e.g. 3 months), and when lastverifysent is also not new (e.g. 1 week), then:
* when emailconfirmdate becomes sufficiently old (e.g. 3 months), and when lastverifysent is also not new (e.g. 1 week), then:
** if numoutstandingverifies is high (e.g. 3) then we can no longer contact the user. Blank out their e-mail address and/or mark as not valid (i.e. set emailconfirmdate to NULL)
** if numoutstandingverifies is high (e.g. 3) then we can no longer contact the user. Blank out their email address and/or mark as not valid (i.e. set emailconfirmdate to NULL)
** otherwise, send out a "please click this link to confirm your address is still valid" message, and increment numoutstandingverifies
** otherwise, send out a "please click this link to confirm your address is still valid" message, and increment numoutstandingverifies
** when the web link is clicked (user ID, email address, time, checksum as before), set emailconfirmdate=NOW, numoutstandingverifies=0
** when the web link is clicked (user ID, email address, time, checksum as before), set emailconfirmdate=NOW, numoutstandingverifies=0
Line 63: Line 63:
It certainly makes sense not to bother checking for someone who never logs in. Maybe we should have a "lastloggedin" datetime field, and only perform the above checking for users who have logged in recently (say, three months). - [[User:DaveEvans|DaveEvans]]
It certainly makes sense not to bother checking for someone who never logs in. Maybe we should have a "lastloggedin" datetime field, and only perform the above checking for users who have logged in recently (say, three months). - [[User:DaveEvans|DaveEvans]]


Reply via e-mail instead of (or as well as) web link
Reply via email instead of (or as well as) web link
* as well as a web link (as described above), formulate a special "reply-to" address (including user ID etc) so that the user can just reply to the message to perform the activation
* as well as a web link (as described above), formulate a special "reply-to" address (including user ID etc) so that the user can just reply to the message to perform the activation


=Ways of Using E-mail (once the above is implemented)=
=Ways of Using Email (once the above is implemented)=


==Password reminder==
==Password reminder==


Given username only, e-mail a web link to the user's e-mail address. Web link includes checksum, time, etc. The page at that link allows the user to change their password without having to know the old password.
Given username only, email a web link to the user's email address. Web link includes checksum, time, etc. The page at that link allows the user to change their password without having to know the old password.


Or, even simpler: just e-mail the user's password to them.
Or, even simpler: just email the user's password to them.


In both cases, if the user e-mail is blank, show a "we can't help you" error message. What if it's unvalidated? Just send the message and hope for the best? - [[User:DaveEvans|DaveEvans]]
In both cases, if the user email is blank, show a "we can't help you" error message. What if it's unvalidated? Just send the message and hope for the best? - [[User:DaveEvans|DaveEvans]]


==Mod-to-Mod Email==
==Mod-to-Mod Email==
Line 87: Line 87:


A moderator is notified when a new moderation has been entered or a moderation has been closed for one of the artists they subscribed to.
A moderator is notified when a new moderation has been entered or a moderation has been closed for one of the artists they subscribed to.
* opened ''and'' closed? That could be a lot of e-mails. I was thinking more like just whenever a mod is inserted; again, optionally with a daily digest. - [[User:DaveEvans|DaveEvans]]
* opened ''and'' closed? That could be a lot of emails. I was thinking more like just whenever a mod is inserted; again, optionally with a daily digest. - [[User:DaveEvans|DaveEvans]]


[[Category:To Be Reviewed]] [[Category:Proposal]] [[Category:Development]] [[Category:History]]
[[Category:To Be Reviewed]] [[Category:Proposal]] [[Category:Development]] [[Category:History]]

Revision as of 12:57, 23 January 2009

Status: This Page is Glorious History!

The content of this page either is bit-rotted, or has lost its reason to exist due to some new features having been implemented in MusicBrainz, or maybe just described something that never made it in (or made it in a different way), or possibly is meant to store information and memories about our Glorious Past. We still keep this page to honor the brave editors who, during the prehistoric times (prehistoric for you, newcomer!), struggled hard to build a better present and dreamed of an even better future. We also keep it for archival purposes because possibly it still contains crazy thoughts and ideas that may be reused someday. If you're not into looking at either the past or the future, you should just disregard entirely this page content and look for an up to date documentation page elsewhere.

Attention.png Status: This feature has been implemented in MusicBrainz server. This page will be kept for historical purposes.

This page describes the work necessary to be able to use moderators' registered email addresses as a form of communication; in the first instance, to allow moderators to communicate on moderation issues.

Confirmed Email Address Registration

So far the email addresses in MB (moderator.email) are just single line free text. The data in there so far presumably includes completely valid addresses, faked addresses, things which aren't addresses but which represent them (e.g. "x at y dot com"), random meaningless text, and of course blanks.

What we need to do is to implement a confirmed registration system, and then attempt to migrate the existing "email" column - whatever it contains - to a confirmed email address.

Confirmation System

I think the following new moderator columns are needed, or at least useful:

  • emailconfirmdate - date/time the email address was last confirmed, or null for never confirmed

For new users:

  • register and enter email address as normal. Set emailconfirmdate to NULL
    • enforce that the email address is either blank, or "looks ok" (e.g. something a bit looser than ^\w+\@\w+(.\w+)*$)
    • do we still allow blank email? Or shall we insist on a valid email address?
  • send confirmation email to the cited address
    • the email message includes a web link back to MB, e.g. /user/confirmaddress.html
    • the web link includes query string params for user ID, new email address, time sent, and a checksum (tamper-proofing)
  • the user then clicks the web link to confirm their receipt of the message
    • the confirmaddress page then checks the checksum against the other parameters
    • checks the time sent (the link expires in e.g. one week to prevent replay attacks - at least, really old replays)
    • sets moderator.email to the email parameter
    • sets moderator.emailconfirmdate to NOW
    • shows a confirmation message
    • If something goes wrong, e.g. checksum or timestamp failure, show appropriate message

When a user wishes to change their email address:

  • enter new moderator details on form as normal. Save all details except email address.
    • email field validates as for new users
  • system sends email containing web link as for new users. Message is sent to the new address.
  • changeaddress page operates as before

For existing users, we need to validate their existing moderator.email values:

The easy option: we could just tell all moderators that, next time they log in, they should go to their "profile" page and re-enter their email address. Then follow the rules as for "changing address", above.

  • How about we ask the moderator to verify their email if they have an unconfirmed email addy after they log in? We can also give them the option of removing the email addy. Ruaok
  • OK, but what state do they start off in? Do you just leave them all as uncomfirmed (the above option) or try to confirm them automatically as part of the data migration process (the below option)? DaveEvans

Or, we try to send the "change address" message automatically to all existing moderators. We might want to send it only to addresses which "look valid".

Most of the above stuff has now been implemented. I'll finish off the remainder of the stuff in the am and check it into a branch. Ruaok

Optional Features

Automatic re-verification of addresses (identifying stale addresses):

  • two extra columns: lastverifysent and numoutstandingverifies
  • when emailconfirmdate becomes sufficiently old (e.g. 3 months), and when lastverifysent is also not new (e.g. 1 week), then:
    • if numoutstandingverifies is high (e.g. 3) then we can no longer contact the user. Blank out their email address and/or mark as not valid (i.e. set emailconfirmdate to NULL)
    • otherwise, send out a "please click this link to confirm your address is still valid" message, and increment numoutstandingverifies
    • when the web link is clicked (user ID, email address, time, checksum as before), set emailconfirmdate=NOW, numoutstandingverifies=0

I don't think it matters for MB to have correct email addy's at all times. It only really matters if the user is subscribed to something or moderating. Perhaps we should check to see if users have a valid email when they enter a moderation? Ruaok

It certainly makes sense not to bother checking for someone who never logs in. Maybe we should have a "lastloggedin" datetime field, and only perform the above checking for users who have logged in recently (say, three months). - DaveEvans

Reply via email instead of (or as well as) web link

  • as well as a web link (as described above), formulate a special "reply-to" address (including user ID etc) so that the user can just reply to the message to perform the activation

Ways of Using Email (once the above is implemented)

Password reminder

Given username only, email a web link to the user's email address. Web link includes checksum, time, etc. The page at that link allows the user to change their password without having to know the old password.

Or, even simpler: just email the user's password to them.

In both cases, if the user email is blank, show a "we can't help you" error message. What if it's unvalidated? Just send the message and hope for the best? - DaveEvans

Mod-to-Mod Email

tbc

Moderation note Email

When a moderator gets a note to one of their moderations. the modbot sends a note to the moderator.

Subscribed Artist Email

A moderator is notified when a new moderation has been entered or a moderation has been closed for one of the artists they subscribed to.

  • opened and closed? That could be a lot of emails. I was thinking more like just whenever a mod is inserted; again, optionally with a daily digest. - DaveEvans