[pmwiki-users] self-registering for notification emails

[Pico]

Tegan Dowling wrote:
> Please confirm I'm understanding this correctly:
> 
> I want to give users the ability to administer their own watchlists as
> far as that's possible.  I know that PM has further embellishments to
> the present set-up in the plan, but for now, I believe
> 
> 1) I can write-protect Site.NotifyList, restricting it to admins or
> giving it its own password,
> 2) on Site.NotifyList, I can put, for each user (for example):
>    notify=user at example.com trail=Profiles.User-watchlist squelch=86400
> OR
>    notify=user at example.com trail=User.WatchList squelch=86400
> 3) then each user can create a trail on his/her own watchlist page.
> 
> BUT
> 
> 4) The trail functionality is limited to manually, individually keyed
> links - meaning:
>  4a) no pagelist-generated list will work to populate the trail, and
>  4b) There's no point in placing a Group.RecentChanges on the trail, either.
> 
> SO
> 
> 5) If a user wants to watch a whole wikigroup, for instance, or other
> dynamically-defined selection, that will need to be put on the
> Site.NotifyList page by someone with edit-rights to it.
> 
> Correct?  Or am I missing something (which wouldn't surprise me one bit)?
> 
> Thanks!
> 
You could always control the Site.NotifyList by assigning a password 
that is shared among trusted users.  On PmWiki.org, the password is 
shared more generally among anyone who reads the list.

Don't like that?

Ok, how about using include directives to password protected author 
pages?  Assuming that the include directive actually works in 
SiteNotifyList to cause included notify instructions to be passed along 
and processed, you  might be able to implement the following:


Example 1: Broad control farmed out to trusted individual users

Site.NotifyList

    (:include Profile.User1-Notify:)
    (:include Profile.User2-Notify:)
    etc

Profile.User1-Notify:

     notify=user1 at example.com group=XYY squelch=86400


Note: That user could put any malicious notify arguments in their page 
to send email to other addresses, but they couldn't control the 
Site.NotifyList page directly, and the administrator could remove their 
include line

Example 2: Apparently narrow control farmed out to trusted individual users

Site.NotifyList

     notify=user1 at example.com (:include Profile.User1-Notify:)
     notify=user2 at example.com (:include Profile.User2-Notify:)

Profile.User1-Notify:

     group=XYY squelch=86400

Note: Appears to be more limited than Example 1, because the e-mail 
address is already supplied (but, in fact, an author could simply add 
new lines listing other email addresses)

Example 3: Narrower control farmed out to trusted individual users

Site.NotifyList

      notify=(:include Profile.User1-Notify#email#group:)\
      group=(:include Profile.User1-Notify#group#trail:)\
      trail=(:include Profile.User1-Notify#trail#squelch:)\
      squelch=(:include Profile.User1-Notify#trail#end:)

Profile.User1-Notify:

    [[#email]]\
    user at domain.com\
    [[#group]]\
    PmWiki\
    [[#trail]]\
    Profile/User\
    [[#squelch]]\
    300\
    [[#end]]


Note: Requires much more testing and setup than examples 1 and 2, but if 
implemented correctly, this could provided narrower control over parameters.


Conclusions:

All of the above assume that included pages will be password protected 
and that notify will only be extended to users in a trusted community, 
or to trusted users in a mixed community.

With that main control, and a relatively trusted community of authors, 
example 1 may be a suitable tradeoff (or, more specifically, transfer of 
control).  Example 2 is not much better, or harder, and might be more a 
choice of what signal do you want to send.  Example 3 seems like too 
much trouble in light of the underlying risk.

Pico