Extension:Email notification/to-do


 * This page lists all ideas related to improvements and proposals for the email notification feature. Please feel kindly invited to add your ideas here but please use feedback for any direct questions to me. Please check also the section email notification versions for already implemented proposals and such ones, which I am just implementing in the next release. --Tom Gries mail 07:23, 4 Nov 2004 (UTC)

Default From: address of the mails
should be changed from WikiAdmin which is reserved for urgent and non-standard messages to for example Enotif. (see http://bugzilla.wikipedia.org/show_bug.cgi?id=454#c21 by Jamesday).

minor edits on user_talk page are not suppressed (currently)
We use the existing mechanism which signals to a user, that he or she has a new message on his/her user_talk page (You have new messages) for memorizing that a notification has already been sent. This existing method does not distinguish between minor or non-minor edits, therefore a notification is triggered by either edits.

When implementing the other forthcoming proposal to stop the different treatment of user_talk (implicitly watched) and other watched pages, this is limitation will be lifted.

Sub-proposal: treat user_talk pages as every other page
listed as 581

Reasons:
 * The user_talk pages are currently treated differently and use other database fields than normal watch-listed (non-user_talk) pages (they use a second table newtalk and a different program module UserTalk.php).


 * It would be more convenient to have them in the normal table watchlist:
 * wl_notificationtimestamp could be used (instead of userid as a flag)
 * minor edits can or cannot be suppressed to trigger notification, like with other normal pages

Sub-proposal: stop linked watchlist-treatment of normal pages and their corresponding talk pages
listed as 580


 * In the current MediaWiki version pre-1.4, if a user adds a page X or the corresponding talk page talk:X page to the watchlist, the other page (talk:X or main page:X) is also watchlisted, but the program treats them internally as one database entry and applies logical operations to namespace identifiers.

Proposed is to stop this (program-internally) linked treatment with logical operations and instead to treat both kind of pages separately: Enotif actually adds (or removes) two entries to the watchlist table when you add one of the pages.

This is necessary to allow a clear separate treatment of memorizing when a user visits one of the pages - it could be that only the talk:X page is visited, whereas the normal page is still waiting for the user's visit (in order to get the notification timestamp cleared.)

Translations
Currently, only English is supported for Enotification mail body and user preferences page, see /languages/Language.php.

Update watchlists
Now that watching is back to normal (clicking on "watch" watches both article and talk), we need a function that'll go through the database and check whether there are any watches on just article or just talk, and if so, set both to be watched. Cphoenix 01:38, 29 Oct 2004 (UTC)


 * Agreed. Coming with a forthcoming version (as soon as possible !) Tom Gries (talk) mail me 23:15, 29 Oct 2004 (UTC)

clear all notification flags
WikiAdmins should have a tool to reset all notification flags of all watching users.

resend notifications older than ..

 * Bring forward notification: re-send notification after a certain time of not having visited the changed pages

Further notification messages are suppressed until UserX visits the changed page or a configurable time period expires. So, for example, I can set things up so that users start getting notified again 24 hours later.

Originally proposed 16 Aug 2004 14:21:41 -0700 by Luis Casillas

broadcast email function

 * Sysops might need a tool to send a mail to all users with email addresses and or to place messages into all user_talk pages. This could also be done by a "global" broadcast template, which is automatically included (rendered, not inserted) into all user_talk pages.

watchlist: "bulk remove pages" (clear watchlist) function

 * a special function or button to actually remove all pages from your watch list. With email notification, a watching user with a huge watchlist would not like to get hundreds of notifications for the watched pages. But currently with version 1.3.3, it's cumbersome to select and remove them one by one.

extended watchlist (primary, with email notification) and secondary (without)

 * add a second column of select boxes for enable email notification on the already existing [ second watchlist] page
 * enable/disable individually selected pages by their individual (second) select box for email notification
 * enable/disable all watch listed pages for email notification

email notification in form of a digest

 * user selectable digest function: a collective notification mail is only sent when one of these conditions becomes true:
 * the number of pending notifications (not yet sent to that user) is reaching a threshold eg. 10 pending notifs OR
 * maximum silence timeout reached eg. 3 days

In other words, this user will get a notification digest email on the 10th page change in an interval of 3 days (since the last notification was sent) or at latest after the 3rd day if less than 10 page changes occurred.

new-page notification
Send notification when a new page is created, and/or add new pages to the watchlist automatically (best for small wikis).


 * sub-feature: new-page notification in a certain category.

Cphoenix 15:28, 14 Oct 2004 (UTC)

features in the recent changes, page history and watchlist
show an additional (third) link: (diff) (hist) (diff-to-lastvisited) Shows directly the difference between this and the version last visited by the user