Category: Newsletters

{syntax type="tiki" editor="plain"}
When clicking the "unsubscribe" link from a newsletter email the customer is immediately taken to the site where they receive a "You are not logged in" error. If the customer were to first log into the site and then click the newsletter "unsubscribe" link in the email it works fine.

This tracker is made to help filtering and sorting the features vs categories vs options we need to tag a bug/regression/wish with.

This tracker item could not be found

Contrary to TikiWiki documentation (and contrary to TikiWiki common sense) it is NOT possible in a 3.0 wiki (specifically http://jiamcatt.ourwiki.net) to assign any permissions to Newsletters. This means that NO ONE, other than Admins can even see the list of Newsletters, to say nothing of viewing past newsletters (the archives). This is unacceptable – and contrary to TikiWiki documentation.

JIAMCATT is the community of IT-oriented managers of language (translation and interpretation) services of major International organizations and European multilateral bodies. After a slow start about a year ago this community has now agreed to try to use a TikiWiki-based system. Within the past month (since several of the TikiWiki team participated in the JIAMCATT annual meeting in Ottawa, Canada early May 2009) close to 200 users have joined up.
One key aspect of the work of JIAMCATT are Working Groups. One of these has just started work. It’s tools include wiki pages in the two working languages (En + Fr), a discussion forum (consisting already of 13 topics), and – last but NOT least – a Newsletter to keep everyone abreast of developments. This feature, it now turns out doesn’t work in a very bad way: NO ONE, other than Admins can even see the list of Newsletters, to say nothing of viewing past newsletters (the archives). This is unacceptable – and contrary to TikiWiki documentation.

I expect this should be a simple fix for a TikiWiki insider (the feature existed at the time the documentation was written); albeit impossible for someone not intimate with the insides of this system.

Screen shots are attached. The first – now shows as the last – called “ButtonsAvail-inJiamcatt-ourwiki-net-Newsletter-admin.gif” shows the buttons seen by an Admin user when trying to do “Admin Newsletters”. The second, called “MissingButton-from-doc-tikiwiki-org.gif” shows the buttons in doc.tikiwiki.org in the http://doc.tikiwiki.org/Newsletters section in the http://doc.tikiwiki.org/tiki-index.php?page=Newsletter+Admin&bl=y page, under the segment titled “Changing Existing Newsletters”. The third screen shows you what a non-Admin user who should have access to view newsletters and archives of this Working Group, sees (file: “Empty list of newsletters for (nonAdmin) WG members.gif”).

Unless someone can provide a fix quickly, this group will abandon TikiWiki as its working tool.

omstefanov

Hey there,

I know, that somebody (Xavi? Nelson?) is working on a functionality, called "Clipper", that should allow to choose certain articles headlines and to send them by newsletter.

I think it would be nice/importand to have the possibility, to send not only the header, but also the teaser for every article like the following:

topline
Headline
subline
author, date ...

teaser
bla bla bla
link

---

next topline
next Headline
.
.
.

Another guy did request this feature for blogs, to give operational stuff the possibility to send the management daily or weekly reports.

[http://dev.tiki.org/tiki-view_tracker_item.php?itemId=3474&trackerId=5&show=view&reloff=1&cant=2&filterfield=43%3A47%3A32&filtervalue=%3A%3A&exactvalue=Array%3AArray%3A45&trackerId=5|trackerID:5_itemID:3474]

So I think this "clipper" feature would make sense for blogs aswell.

Greetz
Torsten

When you first define a Newsletter if you set the "Validate email addresses" parameter this, first of all, works fine and in the Subscription screen the "Don't send confirmation mail" is shown and a validation e-mail is sent when a new user is added.

BUT if you go back and Edit the Newsletter - first of all the "Validate email addresses" is NOT ticked when the existing Newsletter details are populated - but reticking it and reSaving the Newsletter does not set the parameter. Looking at the raw database shows that whilst the validateAddr field is set to "y" when the Newsletter is first set up - it is set to NULL once the Newsletter is edited and no matter how many times the Newsletter is edited and resaved the field stays at a NULL value - and obviously the validation process for new users is no longer available.

Editing the raw database with phpMyAdmin is the only way to reset the field to "y"

since_last_visit_new is an amazing module

Now, it would be nice to be sent a weekly summary (and URLS) of everything that has changed on the site, since my last login.

This is similar to the idea of RSS to newsletter that phplist offers. However, in our case, it would respect the permissions (WYSIWYCA)

Ideally, it would only be sent if you don't login after x days or weeks.

Feature request inspired by Yannick Boily

The newsletter sent using the articleclip function will send broken links (article link and image or files from tiki).

The link for the article look like relative "http://./article1" (as you read the newsletter into a mail browser or a mail application it will go nowhere) instead of absolute "http://www.mywebsite/article1".

Same for pictures added using the file gallery system "http://./tiki-download_file.=
php?fileId=3D1374".

Note: It seams it was broken between the 29/04/13 and the 30/04/13. (i check previous received newsletter). But i couldn't track the change that has done the regression.

---

Update: I create an instance and tested on it. The article title link seams to be back. Also external image (http source) are now displayed however, internal files/image are not displayed properly as they show just fine on the article itself: http://bsfez-11581-4768.show.tikiwiki.org/tiki-edit_article.php?articleId=1

And in the preview of sending the newsletter:
{img type="fileId" fileId="483" thumb="y" noDrawIcon="n"}

Do you need more info ? {sign user="Bsfez" datetime="2013-11-03T07:02:33+00:00"}

~~#F00:Update:~~ I deleted the previous instance and recreated the use case. It is still not working for me. I tried with an internal image directly added to the newsletter using the creditor and the "article clip" plugin. Same.

I include you and Pascal so you received the newsletter and can see the problem i'm talking about. Please note, WYSIWYG editor is used and the articles header are done using CKeditor only. Also the newsletter editor is WYSIWYG (no wiki syntax anywhere). May be this is related. {sign user="Bsfez" datetime="2013-11-08T10:32:42+00:00"}

There seems to be a boundry condition in processing the HTML version of a newsletter. if the following appears in a newsletter:

~pp~

No matter which side of the door the dog or cat is on, it is the wrong side.

any tex following it is dropped. However, all of the text does appear in the plaintext version. Adding or removing any characters causes the text to appear.

When a newsletter is sent, at the end of the list of emails that it has been sent to, a 'completion' text message is shown and an option provided to download a log of that send (where download actually means list in a vanilla' white screen) ie

Newsletter successfully sent to 4 users.
Download Log File


However if newsletter throttling is set then after the final email is sent this completion sequence is no longer shown which is very confusing for the user who is left in doubt whether the send is finished

Newsletter fails to be sent properly if article clipping is involved

We tried to send a newsletter, after the discussion held on
https://tiki.org/Roundtable+Meeting+2016+07

I tested the newsletter sending with Newsletter 6 (currently renamed to "Tiki News" after that ((tw:TRM)), with 850+ people subscribed to it) and with Newsletter 7 (test, with a few emails for testing).

e.g.
https://tiki.org/tiki-send_newsletters.php?nlId=7

It had some features/preferences related to clipping:
https://tiki.org/tiki-admin_newsletters.php?nlId=7&cookietab=2#anchor2
^
(X) Allow clipping of articles into newsletter
Clip articles published in the past number of days: 30
Article types to clip: (and there were some of them: 3 exactly)
^

I did send a test newsletter (nlId=7) and just one email was sent for me, with no clipped articles (even if they were shown as html tags in the tiki send newsletter UI at sending time).
None of the other 6 emails address seemed to receive that email message.

I did unselect all the clipping features, tried again, and I got more email messages (if not all of them, mayube some servers take longer).

HTH

top & bottom bars are now showing on tiki-newsletters.php, as there is no setting to de-activate them on tiki-admin_layout.php and the master setting from tiki-admin.php?page=features is not used.

After a recent CVS update, the From: address of newsletter e-mails changed from the configured SenderEmail address to (apparantly) the address of the logged on user sending the newsletter. Since a changing number of users can send newsletters, it is difficult for recipients to configure their e-mail filters to accept all of them. The change caused a number of newletters to fail delivery.

Imagine a simple group setup in which we have an Employee group and a Manager group. Every manager is an employee and so has all of the permissions of an employee, so we make the Manager group inherit from the Employee group. We put the basic permissions on Employee, and the special permissions of managers on the Manager group. Good so far. Now we'd like to have a newsletter BossNews for managers, so naturally we subscribe the Manager group to the BossNews newsletter. But by the current group subscription rule, this automatically sends BossNews to the Employee group as well. Presumably not what we want, as the BossNews is intended to have the inside scoop that only Managers should see.

Since the inheritor group generally corresponds to a ''subset'' of the inherited group, it is very unlikely that the current rule will be useful -- subscribing the subset to the newsletter should not automatically pull in the larger set.

Even reversing the newsletter subscription inheritance -- so that subscribing Employee to a group automatically subscribes Manager -- may be problematic. The subgroup may not want to see the "chatter" of the larger group. Think BoardOfDirectors as a subgroup of Managers -- they probably do not want to see all of the Employee updates.

So I would recommend no inheritance at all for group subscriptions to newsletters, since you can always subscribe both Employee and Manager to a newsletter if that's who should receive the messages.

When creating a newsletter item, both HTML and plain text versions are requested. The plain text information is empty if the newsletter is edited.

When an HTML Newsletter is created and 'Previewed', what is shown uses the linked CSS styles for the site's theme that are available to the browser - but these will not be available when the Newsletter is received as an e-mail and viewed in an e-mail client like Outlook. Generally speaking e-mail clients need to have in-line styling/'old fashioned' HTML tags.

It would be more sensible if (somehow?) the Preview function in Newsletters only used the formats/styling that was in-line/directly embedded in the content since this would generally provide a more realistic idea of how the Newsletter would look when it arrived as an e-mail - although depending upon the e-mail client even embedded styling may sometimes be stripped out.

So perhaps, at least, the Preview screen should warn users of this problem??

FIXED with newsletter.css custom css now in use

Newsletter sends text and html and no way to choose only one

Reproduced here:
https://tiki.org/tiki-send_newsletters.php?nlId=7

Wasn't tehre a way to choose that in previous tiki versions? (tiki12 probably or earlier, I used that preference)
---
Show instance created by bchauchat and admin pass changed to adminadmin
See: [https://irc.tiki.org/irclogger_log/tikiwiki?date=2016-11-25,Fri&sel=58#l54]
---
Update:
This is affecting also the newsletter sending from tiki.org, to communicate new releases to the subscribed users, and it provides very bad image of the polishness of newsletters in our own servers. {sign user="xavi" datetime="2017-01-10T09:32:11+00:00"}

The problem has already been reported in the forum under [https://tiki.org/forumthread66743-Newsletter-Sent-Attachment?topics_offset=2]
I reproduced it on the demo system for release 18.

Open existing newsletter in demo site
and subscription
start sending
attach a simple .png file
clicked Send Newsletter
Next page shows review of newsletter to be sent, includes "Files" with bullet point
clicked Send
Next page shows "Newsletter successfully sent to 1 users."
The newsletter is received, but no attachment

Auto-eMail is generated to subscriber using template confirm_newsletter_subscription.tpl which contains the following:

In order to confirm your subscription you must access the following URL:
{$url_subscribe}?confirm_subscription={$code}

However,the url_subscribe truncates the php extension in the pagename shown in the email sent to subscriber as follows: tiki-newsletters.ph?confirm_subscription=someString, rather than tiki-newsletters.php?confirm_subscription=someString

Newsletter is generated to all subscribers containing unsubscribe message generated using template newsletter_unsubscribe.tpl which contains the following:

You can unsubscribe from this newsletter following this link:

href="{$url_unsub}">{$url_unsub}

But, the newsletter shows a truncated php extension in the pagename of the url_unsub as follows:

tiki-newsletters.ph?unsubscribe=someString, rather than tiki-newsletter.php?unsubscribe=someString

{syntax type="tiki" editor="plain"}
Clicking the unsubscribe link in a newsletter email always results in the error "Your request to unsubscribe failed", even though the subscription record and code exist in the database. The subscription is never removed.

Tiki 29.x (confirmed). Likely affects all versions where the $inputConfiguration array is present with this filter.

!!Steps to Reproduce
#Enable the Newsletters feature
#Create a newsletter and add a subscriber (email-based, non-user)
#Send a newsletter edition
#Open the received email and click the unsubscribe link, e.g.:
#https://example.com/tiki-newsletters.php?unsubscribe=bfaea1b540a27940684c99854449549c
#The page displays: "Your request to unsubscribe failed"
#The subscription record remains in tiki_newsletter_subscriptions — nothing was deleted

In tiki-newsletters.php, the $inputConfiguration array declares the unsubscribe parameter with a 'bool' filter:
{CODE()}
$inputConfiguration = [
[
'staticKeyFilters' => [
'unsubscribe' => 'bool', //post
// ...
],
],
];
{CODE}

There is a legal concern with so I will commit a fix right away.
Non-functional unsubscribe links may violate anti-spam regulations (CAN-SPAM, GDPR)

When I include article or articles plugin within a newsletter, it works well in the preview of the newsletter, but the newsletter received has lost the CSS format and doesn't display the images included in the articles.
It worked well in Tiki version 9. The bug appears as I migraed to version 12.4

Sometimes, it is useful to attach files to a newsletter.

Alternatively, it could be a newsletter with a link to a file (a unique, very long URL, which provides access to the file without entering a password)

When you create a newsletter, in the course of creating one, you can save what you've done so far as drafts. Those drafts get faithfully collected.

But all you can do with a draft is send it out - or delete it. That's it. No editing... Not even a preview. You have to send it out blindly, trusting those "auto clippings" without seeing them before your recipients see them...

The format of sent newsletters is impure. Instead of real ASCII double quotes, a special character is used (0x90)

Extract from test newsletter I sent to myself:
{CODE(Colors="Tiki")}
<!— Start of article —>
<div class”articleclip_single”>
<h3 class”articleclip_title”><a href”http:
{CODE}

Look closely at those double quotes (cannot underline them, or the CODE commands get ignored.

These are typographical double quotes. I have the feature enabled. But that feature should only swap typographical characters in displayed Wiki content - not in the ''programming'' part of newsletters... !

It's a miracle that Thunderbird renders this correctly. I am dead sure most other mail clients are not so tolerant...