Category: Watch (email notifications of changes)

((doc:Trackers)) are powerful. But there is no built-in version history like the wiki pages and the spreadsheet. A workaround is to watch the tracker and have the history in your inbox. You can also permit users to comment the tracker item instead of editing it.

A real history, accessible via the interface would be nice to have. Please see SourceForge trackers for an example.

Adding a field "Edit Summary" would be useful for this history.

Low-hanging fruit solution is to copy the diffs (that we already send by email but should be improved: [wish1982|Trackers :: email notifications of changes :: more emphasis on changes.]) to a new "history" tab.

More work would be an interface to revert to a previous value, which could be nice-to-have but too complex.

Related:
[wish953|Tracker field type: wiki page]

It is possible to watch for new articles here: tiki-user_watches.php

So why not add an "eye" in view articles and list articles?

Tiki Calendar is very nice for events. But what if someone updates the information about an event? Maybe I won't know (because I copy/pasted the event my pesonal calendar) and I will show up at the old (wrong) time.

Tiki's excellent watch feature should be added (with the little eye) to
# all calendars
# each calendar (id=1) (this could be nice on the filter tab)
# each individual event (when in view mode)

Ideally, for a modified event, I would receive in the email the old and the new value, like for watching trackers.


related code here:
http://tikiwiki.org/tiki-index.php?page=UserPagericks99#Calendar_Notifications

We should make it easier for people to watch/monitor forums

Right now, the user needs to go to each forum page and click "monitor"

All the links should be available on tiki-forums.php

luci added one line and I received the following:
{CODE()}
---------- Forwarded message ----------
From: <noreply
Date: Tuesday, November 6, 2018
Subject: wiki page "Major Features Missing In Tiki" changed by luciash d' being
To: marc



The page "Major Features Missing In Tiki" was changed by luciash d' being at 07 Nov 18 00:26 CET

You can view the page by following this link:
https://dev.tiki.org/Major-Features-Missing-In-Tiki

You can view a diff back to the previous version by following this link:
https://dev.tiki.org/tiki-pagehistory.php?page=Major%20Features%20Missing%20In%20Tiki&compare=1&oldver=&newver=1


***********************************************************
The changes in this version follow below, followed after by the current full page text.
***********************************************************


+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
@@ -Lines: 1 changed to +Lines: 1-72 @@
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+ Many open source web applications have a large number of features available as add-ons. They need to be installed separately and there are often several add-ons for the same purpose.

+ Instead, the Tiki community uses an ((tw:all-in-one Model)). One of the consequences is that Tiki is the ((tw:FOSS Web Application with the most built-in features)).
+
+ Not only has this been true for a quite a while now, but Tiki also has a much faster than average release schedule, with 2 major releases per year.
+
+ * 2008-08: ((doc:Tiki2|What's new in Tiki 2.0))?
+ * 2009-05: ((doc:Tiki3|What's new in Tiki 3.0)) LTS?
+ * 2009-11: ((doc:Tiki4|What's new in Tiki 4.0))?
+ * 2010-06: ((doc:Tiki5|What's new in Tiki 5.0))?
+ * 2010-11: ((doc:Tiki6|What's new in Tiki 6.0)) LTS?
+ * 2011-06: ((doc:Tiki7|What's new in Tiki 7.0))?
+ * 2011-11: ((doc:Tiki8|What's new in Tiki 8.0))?
+ * 2012-06: ((doc:Tiki9|What's new in Tiki 9.0)) LTS?
+ * 2012-12: ((doc:Tiki10|What's new in Tiki 10.0))?
+ * 2013-07: ((doc:Tiki11|What's new in Tiki 11.0))?
+ * 2013-11: ((doc:Tiki12|What's new in Tiki 12.0)) LTS?
+ * 2014-08: ((doc:Tiki13|What's new in Tiki 13.0))?
+ * 2015-05: ((doc:Tiki14|What's new in Tiki 14.0))?
+ * 2016-04: ((doc:Tiki15|What's new in Tiki 15.0))?
+ * 2016-11: ((doc:Tiki16|What's new in Tiki 16.0))?
+ * 2017-07: ((doc:Tiki17|What's new in Tiki 17.0))?
+ * 2018-01: ((doc:Tiki18|What's new in Tiki 18.0))?
+ * 2018-10 (planned): ((doc:Tiki19|What's new in Tiki 19.0))?
+ * 2019-04 (planned): ((doc:Tiki20|What's new in Tiki 20.0))?
+ * 2019-10 (planned): ((doc:Tiki21|What's new in Tiki 21.0))?
+
+ Even with all the features, there are still ((All Feature Requests|several hundred feature requests)). But most of these are requests for enhancements to an existing feature. Once a feature is in the code base and is basically usable, it usually evolves naturally/organically. In each Tiki version, most features are refined at least a bit. Some like ((Webmail)) need a lot of work. But at least, it's a start.
+
+ But when a feature is totally absent, it takes a spark to make it happen and take it to the level where is starts evolving naturally/organically.
+
+ What does Tiki __not do__ yet? (please base your answers on latest code). You can also check out the list of ((tw:Use Cases)) for more ideas. See also: ((Interesting Features from other Web apps))
+
+
+ !! Major features totally missing
+ {wishes filtervalue="163" status="op"}
+ * --Desktop publishing as will be needed for the ((Online Publishing House))-- See ((doc:mPDF))
+ * ((Naive Bayes classifier))
+ * --Something like ((kfm)) or ((elFinder))-- Done in ((Tiki11))
+ * ((WikiTrust))
+ * ((Social Bookmarking))
+ * ((Link checker)) (internal and external)
+ * ((Animations))
+ * ((Repository Browser)) for ((Code Review))
+ * --Interface with ((Monitoring)) tools: Nagios, Zabbix- etc. Would also be part of ((TRIM)) and ((Check))-- Code for Nagios was adding. Documention: https://doc.tiki.org/Monitoring
+ * Online Store (out-of-the-box solution like PrestaShop)
+
+
+ * A well-defined API for building applications on top of, or integrating application into Tiki. __People often say this but without a specific example, it's difficult to follow-up upon. Current plugins structure is very efficient to interface with 3rd party services. Can you give 2-3 specific examples of applications or types of applications you have in mind? Thanks! --marclaporte__
+
+
+ !! Major features missing from main code base, but available with 3rd party mods or workarounds
+ * [http://tiki.org/LearningManagementSystemDev|Learning Management] features like Moodle (gradebook, class management, etc.) though Tiki does have some [http://edu.tiki.org/AulaWiki|3rd party mods] for this
+ * ((doc:E-democracy system)) (we have polls and such but it's not the same as a full-fledged voting/election system)
+ * Online Help (not d.tw.o)-dthacker / marclaporte: can you explain a little more?
+ * Event Management system : while most of this can be done by using the wiki, calendar and user trackers, it's too difficult for someone new to Tiki. Added to ((info:Use Cases))
+ * Have a calendar in the main code base. Either including ((doc:Mod extcalculator)), ((doc:Mod calculator)) or another...
+
+
+ !! Incomplete features
+ __Please ((Add to Wishlist)) instead__
+ * External Authentication
+ ** Interface with SiteMinder ([http://www.ca.com]) (similar to InterTiki, except yield to SiteMinder for authentication as an enterprise-wide intranet authenticator)
+ * Debian and Ubuntu ((tw:Packaging Team))
+ * VMware and Xen virtual appliances
+ * Trackbacks in ((blogs))
+
+ See also: ((Interesting Features from other Web apps))
+
+ -=Alias=-
+ * (alias(Major Features Missing In TikiWiki))
+ * (alias(Missing Features))




***********************************************************
The new page content follows below.
***********************************************************

Many open source web applications have a large number of features available as add-ons. They need to be installed separately and there are often several add-ons for the same purpose.

Instead, the Tiki community uses an ((tw:all-in-one Model)). One of the consequences is that Tiki is the ((tw:FOSS Web Application with the most built-in features)).

Not only has this been true for a quite a while now, but Tiki also has a much faster than average release schedule, with 2 major releases per year.

* 2008-08: ((doc:Tiki2|What's new in Tiki 2.0))?
* 2009-05: ((doc:Tiki3|What's new in Tiki 3.0)) LTS?
* 2009-11: ((doc:Tiki4|What's new in Tiki 4.0))?
* 2010-06: ((doc:Tiki5|What's new in Tiki 5.0))?
* 2010-11: ((doc:Tiki6|What's new in Tiki 6.0)) LTS?
* 2011-06: ((doc:Tiki7|What's new in Tiki 7.0))?
* 2011-11: ((doc:Tiki8|What's new in Tiki 8.0))?
* 2012-06: ((doc:Tiki9|What's new in Tiki 9.0)) LTS?
* 2012-12: ((doc:Tiki10|What's new in Tiki 10.0))?
* 2013-07: ((doc:Tiki11|What's new in Tiki 11.0))?
* 2013-11: ((doc:Tiki12|What's new in Tiki 12.0)) LTS?
* 2014-08: ((doc:Tiki13|What's new in Tiki 13.0))?
* 2015-05: ((doc:Tiki14|What's new in Tiki 14.0))?
* 2016-04: ((doc:Tiki15|What's new in Tiki 15.0))?
* 2016-11: ((doc:Tiki16|What's new in Tiki 16.0))?
* 2017-07: ((doc:Tiki17|What's new in Tiki 17.0))?
* 2018-01: ((doc:Tiki18|What's new in Tiki 18.0))?
* 2018-10 (planned): ((doc:Tiki19|What's new in Tiki 19.0))?
* 2019-04 (planned): ((doc:Tiki20|What's new in Tiki 20.0))?
* 2019-10 (planned): ((doc:Tiki21|What's new in Tiki 21.0))?

Even with all the features, there are still ((All Feature Requests|several hundred feature requests)). But most of these are requests for enhancements to an existing feature. Once a feature is in the code base and is basically usable, it usually evolves naturally/organically. In each Tiki version, most features are refined at least a bit. Some like ((Webmail)) need a lot of work. But at least, it's a start.

But when a feature is totally absent, it takes a spark to make it happen and take it to the level where is starts evolving naturally/organically.

What does Tiki __not do__ yet? (please base your answers on latest code). You can also check out the list of ((tw:Use Cases)) for more ideas. See also: ((Interesting Features from other Web apps))


!! Major features totally missing
{wishes filtervalue="163" status="op"}
* --Desktop publishing as will be needed for the ((Online Publishing House))-- See ((doc:mPDF))
* ((Naive Bayes classifier))
* --Something like ((kfm)) or ((elFinder))-- Done in ((Tiki11))
* ((WikiTrust))
* ((Social Bookmarking))
* ((Link checker)) (internal and external)
* ((Animations))
* ((Repository Browser)) for ((Code Review))
* --Interface with ((Monitoring)) tools: Nagios, Zabbix- etc. Would also be part of ((TRIM)) and ((Check))-- Code for Nagios was adding. Documention: https://doc.tiki.org/Monitoring
* Online Store (out-of-the-box solution like PrestaShop)


* A well-defined API for building applications on top of, or integrating application into Tiki. __People often say this but without a specific example, it's difficult to follow-up upon. Current plugins structure is very efficient to interface with 3rd party services. Can you give 2-3 specific examples of applications or types of applications you have in mind? Thanks! --marclaporte__


!! Major features missing from main code base, but available with 3rd party mods or workarounds
* [http://tiki.org/LearningManagementSystemDev|Learning Management] features like Moodle (gradebook, class management, etc.) though Tiki does have some [http://edu.tiki.org/AulaWiki|3rd party mods] for this
* ((doc:E-democracy system)) (we have polls and such but it's not the same as a full-fledged voting/election system)
* Online Help (not d.tw.o)-dthacker / marclaporte: can you explain a little more?
* Event Management system : while most of this can be done by using the wiki, calendar and user trackers, it's too difficult for someone new to Tiki. Added to ((info:Use Cases))
* Have a calendar in the main code base. Either including ((doc:Mod extcalculator)), ((doc:Mod calculator)) or another...


!! Incomplete features
__Please ((Add to Wishlist)) instead__
* External Authentication
** Interface with SiteMinder ([http://www.ca.com]) (similar to InterTiki, except yield to SiteMinder for authentication as an enterprise-wide intranet authenticator)
* Debian and Ubuntu ((tw:Packaging Team))
* VMware and Xen virtual appliances
* Trackbacks in ((blogs))

See also: ((Interesting Features from other Web apps))

-=Alias=-
* (alias(Major Features Missing In TikiWiki))
* (alias(Missing Features))
{CODE}

Watch item on trackers sends messages in the language of the tracker poster. It should be in the language of the person watching the item.

The watch object names for trackers in My Watches could be more descriptive -- i.e. use the subject name.

When on a wiki page on my tiki, I have the options available to watch the specific page or to "Monitor the sub-structure". When clicking on the latter, I am redirected to a permission denied page and the watch for the sub-structure is not set.

Even admin is being denied the permission to set a sub-structure watch on a wiki page.

Setting a watch on a sub-structure inside the structure-admin menu works fine for any permitted, though.

When you are watching an item, the email is sent in the language of the site visitor, not your own chosen language.

Watching a tracker is no longer possible:
http://dev.tikiwiki.org/tiki-view_tracker.php?trackerId=5
http://themes.tikiwiki.org/tiki-view_tracker.php?trackerId=2

The "monitor" link is missing.

This is a recently introduced bug

I seem to be watching the page http://doc.tikiwiki.org/tiki-index.php?page=Editorial+Board+Meeting+2009+06 but have not recieved an e-mail for changes after 10 June 09 18:13 CEST

This is especially unfortunate for a page like this, where communication somewhat depends on users being informed of changes.

I do not receive notifications when watched tracker item is commented. Is it a setting or is it a missing feature ? Is it a consistency bug when wiki pages allow notifications on new comments ?

Currently, we have no history of changes to the tracker.

related [tiki-view_tracker_item.php?itemId=169|Category changes in watch and in syslog]

The "Watch Translation" feature works great however... the email notification that the author receives is the same as a regular wiki page change. It should be different it should:
#Specify ''why'' you are receiving the email
+...a translated version of a page you are watching was changed...
#Indicate the change made and which page you should update.
+...please review the following change in __PAGENAME, sp__ and update your page __PAGENAME, fr__...

Or something similar.

{syntax type=tiki}
{syntax type="tiki" editor="plain"}
This is the ((Tracking system for Tiki issues)).
If this is your first time, please read: ((How to Submit a new item on the Wishlist))

Watching a page is an amazing feature.

However, as of now, when a page is renamed or deleted, I am not informed.

# changed my email on tiki.org
# shows correctly here in user preferences on dev.t.o
# when going to Admin > Mail notifications, mail column displayed the old one still and the notifications were sent there

We've just done a sucessful in situ upgrade from TW18.5 to TW18.6.

Post upgrade, Watch notification e-mails seem to have a gained a newline prefix to the message subject.
This is also evident in the TW log file where the receiving user and the subject are now on separate lines.

Taken from the source of the received e-mail...
pre upgrade Subject: wiki page "17821020_DB_1A_pp_87-88" changed by user-real-name
post upgrade Subject: =?UTF-8?Q?=0Awiki=20page=20?= =?UTF-8?Q?"18360215=5FAccounting=5Fof=5FEstate=5Fof=5FJohn=5FReaves"=20?= =?UTF-8?Q?changed=20by=20user-real-name?=

This is only affecting Watch notification emails. Email associated with notifications from the wiki's internal Message system are unaffected. That makes me think its not a generic system/sendmail subsystem issue.

Did 18.6 introduce a new configuration option I've yet to find?

I don't think I can easily demonstrate this on the "show" system since mail isn't enabled there, but I will add a couple of screen shots showing the issue in our log files.

Thanks,
M

Update #1 - I've done the best I'm able with the show instance. I've enabled both Watches and the internal Message system. I added a wiki page and the watch notification (log ID 7) shows the subject on a separate line to the receiving user. I created a new user and sent that user a message. Log ID 10 shows that receiving user and the message subject on the same line. Screen snip attached.

I've also attached two screen snips from our system showing the log entries for a Watch notification from just before and just after the TW18.5 to TW18.6 upgrade.

I can also confirm that Tracker notification e-mails are NOT affected by the addition of this newline prefix to the subject line since the upgrade.

I've been trying to unsubscribe from the tracker on the Tiki Dev site for over 24 hours. It's been successful for everything but the Wish List Tracker. Clicking on the "stop monitoring" icon has no visible effect and I continue to receive email notifications of entries on that tracker.

{syntax type="tiki" editor="plain"}
When you monitor a page and do some changes then save, your user should not receive a notification.
This work, your user don't receives notifications on own changes.

But the success message is misleading, for exemple my user "me@blabla.com" edited a page and the feedback says:

 Success
Page 00Bernardplayground2 saved (version 88).
To review the changes you have just made compare the versions in history of this page.

 Notification sent to:
me@blabla.com, riki@blabla.com

Feedback is wrong, I won't be notified.

When watching a wiki page, emails send on change contain iso-8859-1 charset in their header, while the body is utf-8 encoded.
The result is that special characters like umlauts are not being displayed properly (without manually setting the character encoding in the mail client).

Detailed error:
In lib/notification/notificationemail.php for function sendWikiEmailNotification(..) exists for sending those notifications. This function then calls tiki_send_admin_mail(..) in lib/mail/maillib.php which then starts a new instance of Zend_Mail. At this point, the Zend_Mail constructor would need to be given the charset or it uses iso-8859-1 as default.
Since the whole procedure of sending the notification seems to be ignoring the charset settings of the general tiki settings, the constructor would need to be given "utf-8".

I guess the error, though, is that character encoding is not set at all during the process. This might have to do with the fact, that wiki notifications are sent another way then i.e. structure notifications. Someone with a clue needs to look into this, though.

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.