Item14520: MailerContrib rendering newletter topic content as user WikiGuest

Regardless of the specified user/recipient of newsletter, the content of the topic is always expanded with user/permissions set to WikiGuest. One would expect the topic to be rendered according to the permissions of the recipient.

-- LynnwoodBrown - 20 Oct 2017

It depends on what personalisation you are trying to perform. Permissions are dictated by the user who runs the mailer job (usually www-data). Mailer "targets" (people receiving the mails) are determined by a number of routes; explicit wikiname, mail address, group membership etc. and when the outgoing mail is compiled, only the target email address is known. Since this doesn't map 1:1 back to a Foswiki user it would be inappropriate to apply the personality of any specific user. {MailerContrib}{RespectUserPrefs} allows you to configure a subset of the user prefs when personalising mails (see MailerContrib::_loadUserPreferences), though TBH I'm not sure how well (or even if) this works. It does this by mapping back from the email to a target user, and then reading their prefs direct from their user topic (clunky).

Using the same mapping, you could change the code to re-load the permissions matrix for each user, but I suspect it would slay the performance.

-- Main.CrawfordCurrie - 22 Oct 2017 - 08:39

Crawford - is there a way to specify the user running mailer job other than the default server user (similar to the user parameter to cli call to view script)? The most basic issue I'm confronting here is that if a web has restricted access, then SEARCHes within a newsletter topic return no results at all. If there was way to assign a user for the mailnotify script such that it would have view access to the target web, perhaps I could work around other user settings via RespectUserPrefs as you mention.

-- LynnwoodBrown - 23 Oct 2017

Setting to confirmed.

-- GeorgeClark - 11 Dec 2017

Commenting is disabled while not logged in