00291: MailPosts enhancement to support Group/Page "$MailPostsTo" parameters
See also: PITS.00358
I'm thinking about an enhancement linked to MailPosts feature. Then setting up MailPost would have a wiki wide effect.
The enhancement could be linked with the ?action=attr page by adding the "$MailPostsTo" parameter at the page or group level.
This will make flexible the page modification reporting feature, by allowing the users to ask email reporting for there own page.
This Feature also brings the option to "Do not send" a mail for the others pages. I think the easiest way will be to have in the config:
$MailPostsTo=""; # If empty do not send mail
Regards Isidor, Paris/France
At least in the case of the "Do not send" option I see problems coming, from redundant entries, that could differ.
In regards to the $MailPostsTo variable:
Would that override the page config? Or would it be additional to page configs?
In my mind it would be override Isidor
I'm guessing that the above is asking for a feature whereby users could indicate that they want mail sent to them whenever a page (or group) has changes in it.
Implementing this feature is relatively easy -- the problem arises two-fold:
1. Preventing malicious authors from adding unwanted email addresses to the list 2. Preventing the email addresses from being harvested by spammer robots
Still, if you're willing to live with these two potential problems (and there may be others), I can code up an extension fairly quickly. Hi Patrick, I want to know if could do it ? Isidor
A validation process like the one existing for listserv is required.
Someone give an adress for inscription. A mail containing a special (randomized) page link is sent to the address, and the inscription is only validated when clicking the link. A temporary validating page with a cryptic address can be created when asking the inscription. This page should be deleted after having being opened, or after some time.
Why the list of address should be publicly accessible ? PRZ
In fact on our system the we could control the security issue outside the wiki, but I agree that securing the feature will be a must. If I could suggest, to have a first version "with risks" will be great and work on a more secure design in the same time Is this acceptable? Isidor
According to my needs, it seems interesting to have such fonctionalities. A solution to limit the "risks" could be to have the choice to "enable" or "disable" this feature (in the admin section). so if the admin see that some users "cross the line" this feature could be disable. But for a fair community of users (as you have to be if your are "wiki minded") it will not be a problem. And it is always interesting to not to have the browse all the pages to find "news". Jessy
This enhancement would be welcome in my Intranet. Al-Kashi
It will be usefull for me too. Jessy
I'm always looking for the changes in "Release Notes". But with this functionality, I will be able to "subscribe" to the changes of this page without having to consult it (push vs pull). On the other hand, Patrick will have a list of users and people interested in PmWiki. The beginning of a known community. I dream to know the users of my wiki website or users of part A or part B... Jessy
Radu: Isidor and others, would you like a pull rather than push version as described at PITS.00358? That way there are no email privacy issues and people interested in a given wiki can just bookmark their own watchlist and check it every day if they like. Less inbox spam too.
Christopher -> mailto:thindraug [snail] gmx [period] de: I want to set up a roleplaying/storytelling/cooperative-writing Wiki (or, as it will be UserAuth'd, a CMS?) and several of my interested players/co-authors have stated it would help them very much if they could be notified by eMail when the pages in which they participate get added to. If it gets to two (or more?) eventually concurring groups with the same in-game targets, it would be equally vital that the "befiended" groups don't get access to info they're not supposed to have and not be notified about it.
I would prefer a "push" variant as many users in my intranet consider it a good thing if their attention is only required when there is something worthy of attention.
In my opinion, that's typical for the "naive user" targeted by the PmWikiPhilosophy.
(I can tell from my logs that few people use "recentchanges", and even fewer use diffs.)
Malevolent users are not a problem as my intranet is a benevolent environment.
--Henning May 02, 2006, at 05:00 AM
Since all my wikis require HT access authentication, security inside that context is not a big issue. All my users are "naive" users, and they only want to know about changes in pages they are participating in, and changes may occur infrequently. It has to be super simple: The access the wiki, are prompted for USER-PASS.. they get in... navigate to a page, make changes, added themselves to the "watchers" list. exit; later the get email their page was updated by so-and-so, they click link, access wiki, apacher requests their user-pass again, usually they save it so it's already inserted for them. This seems pretty simple to me.
-- Sivakatirswami May 18, 2006
I have not yet done much with mailposts, but think a feature like this would be extremely useful and powerful. I am willing to deal with risks to have a simple and easy to use email capability. A recipe would be fine. (Doesn't one or more already exist?) Caveman
This feature is now available in 2.1.7 through the PmWiki.Notify capability.