Category: Watch (email notifications of changes)

I want to enable comments on wiki pages.

I have two options right now, both have advantages and disadvantages.

Enabling comments on pages

* Pros
o Easy to configure
o Comments are visible directly on the page
* Cons
o No way for people to monitor all posts on the site. Often people post a comment on a a page and never get feedback.


Associating a discussion forum thread to each page

* Pros
o Everyone on the site gets to see every posting that's made on any page. Increases the likelyhood that someone will respond to a post.
* Cons
o More difficult to configure.
o Postings are not visible directly on the page.

It would be nice if we could have the best of both.

What I would like is something where:

* A discussion forum for the wiki can be enabled at a single click of the mouse.
* This single click of mouse would result in threads being a
utomatically created on this mailing list for each of the wiki pages
* The top 5 messages for a given page would be displayed directly on that page.

Calendar has been great for a while now as an event calendar. But what about for appointments?

For this use, notifications would be sweet. I would like to be able to configure an email reminder before an event (+ a pop-up if user is logged in.)

Time of email reminder should be configurable per event. Sometimes, I want a reminder 15 minutes before. Sometimes, I want 3 days. I could configure to send an email (or SMS) to my phone.

I guess we'd need a cron job for this to work efficiently.

Related: [tiki-view_tracker_item.php?itemId=806|Watch calendar (receive email notication of changes)]

At tiki-admin_notifications.php if I select "User" for destination I got an error that the selected user doesn’t have an email. Which is wrong.

{img type="fileId" fileId="1262" thumb="box"}

I just reviewed Canadas anti-spam legislation & it looks like we're currently not complying with it.

http://fightspam.gc.ca/eic/site/030.nsf/eng/00285.html

# Express consent (rules for implied consent are too difficult to satisfy)
# Name of the Sender
# Address of the Sender.
# A way of getting in touch with the sender. (phone number, domain name, email address) For us, a simple domain name would be ideal.
# Easy unsubscribe mechanism.

I just reviewed an email I received from a user watch at dev.tiki.org. We comply with (maybe) #1. 2-5 we do not comply on.

A lot hinges on if the emails we send out are considered "Commercial Electronic Messages" but we don't appear to fall in the exception list, so I'm guessing that means almost all our messages are considered CES, including watches.

There is implied and also explicit consent. It looks like most of our emails are explicit concent emails, so that makes things easier. However if no specific action was taken to request an email, it falls in "implied consent" and there is a 2-year limitation on this clause. That would be a lot of work to program, so I suggest that we place a line in our Terms and Conditions that states that we may send occasional emails, and require them to agree to these upon registration. This would seem to cover our basis in making a strong case for explicit consent. The onus is upon us to prove that explicit consent has been granted. The empty toggle box concent is mentioned as "acceptable" under these regulations.

Now that we have explicit consent (and can prove it) we need to comply with the required information in an email. For Tiki already has the name and domain name, but perhaps we need a field for the business address in the preferences somewhere.

We also need an "easy unsubscribe mechanism" so if someone creates a "user watch" we need to include a link to an unsubscribe page. Or a page that unsubscribes them. I'm sure we already have this within tiki, we just need to generate the link and include it in user watches, and other emails.

It would also be nice if we had some generic compliance built into Tiki. So the solution taken is not specific to *.tiki.org and everyone else needs to come up with there own solution. More and more legislation is playing a larger role in how business on the net is conducted.

I would love to see a generic feature in Tiki called something like Terms, Conditions & Privacy Policy. Where terms, conditions and privacy policy can be (almost) auto generated based on selected options. This then could be integrated into the user registration form as part of the standard process.

There is currently no history of changes to categories.

Since permissions can now be restricted by categories, it is more & more important to know when an object is changed from one category to another.

Therefore, we need this info to be logged in tiki-syslog.php and to be added to the watch item feature.

Reminder: categories can be assigned in tiki-admin_categories.php but also when editing a wiki page.

probably related to #283

possibilities:
http://phpmailer.codeworxtech.com/
http://www.swiftmailer.org/
http://framework.zend.com/manual/en/zend.mail.html


Related:
SMTP Configuration from inside Admin Interface
http://dev.tikiwiki.org/wish1711

On this site:

www.wiki-translation.com

eversince we upgraded to Tiki 1.10 (I think), the mail messages I receive when a page is modified are wrong.

If I click on the link to the diff back to the previous version, the page I get tells me that the two versions are identical.

but to the whole Tracker watches/notifications here on dev.t.o after submitting a bug.

Still an issue. Just did that and now I receive all bugs notifications. {sign user="luci" datetime="2014-06-20T15:35:08+00:00"}

So we can modify title as we do for the other mail notifications.

I would change default from:
[Todo 1.9.x] Tracker was modified at dev.tikiwiki.org

to:
[Todo 1.9.x] Tracker was modified at dev.tikiwiki.org by Jean-Paul

When writing a particular wiki page, and being set this page to be watched to a group (let say Registered users).

Then if the page has plugingroup to hide particular peaces of special text that is not intended to be known by certain users. Then every time this page changes, a notification email is sent to all Registered users (this is ok), but in the content of this email all the source code is revealed to EVERY user on the Registered group, regardless if they have the right to see Source of wikis.

Don´t know how this could survive the testing and dogfood of this community. May be there is another way to let the Registered group to be acknowledged of a change in a wiki, without compromising content. Please enlight me on how to do this much of the work done on our live tiki portal uses plugingroup to restrict snippets of text to certain groups and other snippets has to shown, in the same wiki.

There should be an option to configure a watch to be sent in a way that only alerts the user that a particular page has changed without showing all source, in respect to a particular right to see or no to see the source.

I have checked on the proper user rights and object perms to avoid them to receive this notifications in the proper way, but tiki doesn´t seem to take it.


Using Tiki 6.2

It is too difficult now to watch categories (but the feature works well).

Please see: ((Category Watch DogFood))


on ((SUMO)): [https://bugzilla.mozilla.org/show_bug.cgi?id=498001|Improve UI and feedback for watching categories to say you'll be e-mailed and offer easy way to turn off]

There might be many emails from the bug tracker in dev.t.o (like in other tiki sites with heavy activity in one or several trackers).

Notification emails come with this type of common subject:
{CODE()}
"[Bugs & Wish list] (Tracker was modified at dev.tiki.org by userfoo)"
{CODE}

And content of the changed item brings the changed fields, but if there is no change in the title of the bug tracker (the first "isMain" field), the user getting the message still has no clue about the changed item.

Proposed solution:
* Add a new option in trackers to include the first "isMain" field (the first field linked to the full item view) in:
## the notification email subject first, before or instead the string needed for email filters "".
## the content of all emails frmo changes in items from that tracker

This would allow people like me, to clearly identify in which tracker items I'm requested to take some action, or help on the follow up on some topics, when you get many emails from the same source and currently with too similar subjects.

When displaying diff and you have some non-ascii characters in page content, e.g. "é" in French language or others, the characters do not show up in the diff output anymore. It happens when viewing diff in page history and also in the email notifications when you watch a page. The rest of the page source displays them though so it is only happening in the diff part.
Example of page with missing characters in diff:
http://tiki.org/tiki-pagehistory.php?page=Home,cs&history_offset=1&diff_style=sidediff&diff_style=sidediff&show_all_versions=y&compare=Compare&newver=0&oldver=23&tra_lang=sq&paginate=on&history_pagesize=50

For example for [https://suite.tiki.org/tiki-pagehistory.php?page=Tiki%20Suite%20alternatives&compare=1&oldver=84&newver=85|this diff] change in the e-mail notification there is this empty HTML plugin shown instead of showing its content:

{CODE()}
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -Lines: 143-146 changed to +Lines: 143-150 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
!!!! Freedombone
{HTML()}{HTML}
+
+ !!!! Cloudron
+ {HTML()}{HTML}
+

!! Services
{CODE}

maybe affects BRANCH-1-9 as well.

Below is a bounce message when Tiki sends notification emails from tikiwiki.org (watch feature). I altered some the emails & domain names.

---


Attention: info@tikiwiki.org


A policy-violation was found in an Email message you sent.
This Email scanner intercepted it and stopped the entire message
reaching its destination.

The policy-violation was reported to be:

Disallowed characters found in MIME headers


Please contact your IT support personnel with any queries regarding this
policy.


Your message was sent with the following envelope:

MAIL FROM: info@tikiwiki.org
RCPT TO: xxxxxxx@xxxxx.com

... and with the following headers:

---
MAILFROM: info@tikiwiki.org
RCPTTO: xxxxxxx@xxxxx.com
IP-Addr: 111.111.111.111
Received: from paris117.server4you.de ([85.25.20.236])
(envelope-sender <info@tikiwiki.org>)
by smtp55.mailnet.xxxxx.com (qmail-ldap-1.03) with SMTP
for <xxxxxxx@xxxxx.com>; 24 Apr 2007 17:05:19 -0000
Received: (qmail 8044 invoked by uid 33); 24 Apr 2007 17:05:17 +0000
Date: 24 Apr 2007 17:05:17 +0000
To: xxxxxxx@xxxxx.com
Subject: Tiki email notification
MIME-Version: 1.0
From: info@tikiwiki.org
Reply-To: <info@tikiwiki.org>
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Message-ID: <jh0i4t.shjfns@tikiwiki.org>


---

{syntax type="tiki" editor="plain"}
One of our users reported that she was receiving watch notifications whenever she clicked the "Discuss" button for a wiki page, even though she was not posting anything in the forum topic.

The cause was a Watch on "A user posts a forum topic (forum_post_topic)" for the Wiki Page Discussion forum. (Our Tiki uses a forum for page discussion instead of page comments.)

The preferred behavior is that this type of watch would only generate a notification the ===first=== time the Discuss button is clicked for a page, when the new topic is actually created, rather than just accessed on successive clicks.

If a user Alain sets a watch on a page, and there is already a group watch on that page for a group to which he belongs, then Alain gets two notifications whenever the page is changed.

This was found on terminology.tikiwiki.org which runs 4.x

edit article doesn't save if you change any setting in the advanced tab: to email.

Reproduced in
https://tiki.org/tiki-edit_article.php?articleId=442#content_edit_article1-5

Add any email in the "to" field, and you won't be able to save your edition, or your new article if it was the first time you were writing that.

The action log, in addition, says:
{CODE()}
/New article post at tiki.org [Invalid "To" header; contains no addresses]
{CODE}

Email a periodic digest (report) of a tracker activity (new open, and changed to pending or closed).

For sites with low activity but high interest in the users on a specific tracker activity, such as Barter networks ( http://intercanvis.net and similar) such feature is needed for users, who register, but then, after a few months, they don't visit the tiki site any more to see notifications of changes (and they didn't know how to browse the categ. tree to select which categories to watch.

However, other (closed source) bartner software sends a monthly digest to registered users with new items added to each tracker. And this would be very welcome by users (usability)

{syntax type="tiki" editor="plain"}
When I evaluated the software for my project, I was very happy when the documentation said that it was possible to create a workflow with categories, transitions and watches. But I realized that watching a category only triggered a mail notification when the transition was made in the tiki-admin_categories.php page. It was useless for me!! :-((

Email notification don't work except if "watch minor" is checked

/lib/tikilib.php only processing mail notification on update_page if user watches switched on; notifications not being sent if set on the perms for the page. see line 5472

global $feature_user_watches;
if ($feature_user_watches == 'y') {
// Deal with mail notifications.
include_once('lib/notifications/notificationemaillib.php');
global $histlib; include_once ("lib/wiki/histlib.php");
$old = $histlib->get_version($pageName, $old_version);
$foo = parse_url($_SERVER["REQUEST_URI"]);
$machine = $this->httpPrefix(). dirname( $foo["path"] );
require_once('lib/diff/difflib.php');
$diff = diff2($old["data"] , $edit_data, "unidiff");
sendWikiEmailNotification('wiki_page_changed', $pageName, $edit_user, $edit_comment, $old_version, $edit_data, $machine, $diff, $minor);
}

I think something has to be changed on tiki-admin.php?page=general with the SMTP settings (or perhaps Sendmail could work again?).