Category: Watch (email notifications of changes)

We are using LDAP authentication at our site and the email field is not being automatically filled in. This means we must manually setup our email for each user for the page change notifications to work.


Note we are connecting to an ActiveDirectory LDAP database which does not like anonymous binds so had to make a patch based on the following suggestion:

http://tikiwiki.org/tiki-view_forum_thread.php?topics_offset=58&forumId=6&comments_parentId=14021

Mail notification not showing wiki page name and url.Problem in objectlib.php.

I upgraded from 1.8.5 to 1.9.0 and the configured mail notifications (for 'any wiki page changes', send mail to some list) don't work anymore.

No PHP errors are generated, and my php max_limit is 32MB.

For my recently filed reports I received update notifications, whose headers look like this:

Subject: Report on Tiki Wiki CMS Groupware :: Development from 28 Dec 16 (2 changes)
MIME-Version: 1.0
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"
Content-Transfer-Encoding: 8bit
Content-Type: text/html;
charset="utf-8"

...

repeats > 20 times

The mails sent for updates to wishes are text/html only.
A choice to get them in text/plain would be nice.
I'd prefer "either or", but both as mixed/alternative would be an improvement, too. ;-)

We have this for wiki pages. Maybe add to tiki-admin_notifications.php?

The e-mail notifications of watches (wiki, tracker, article, etc.) are sent out when changes are made. This means that the user submitting the change has to wait for the PHP-Code to send out all the mails before he can continue browsing. This is annoying and even...

... more evil is that with thousands of users to notify of the change the PHP-script will tend to time out and not all the notifications are sent!

One possibility would be to set the timeout higher, but that isn't really a solution at all. So the sending of mails needs to happen asynchronously. One simple solution would be to have a daemon running on the same system, which sends out the mails and the PHP-script just notifies the daemon of what to do. This would make installation a lot harder though and can't really be a desired solution.

Any possibilities to solve this in PHP directly?

{syntax type="tiki" editor="plain"}
Bunch of malformed search query errors with some weird REGEX() stuff?

{CODE()}Malformed search query: SQLSTATE[42000]: Syntax error or access violation: 1064 P01: syntax error, unexpected identifier, expecting string near 'Array) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(stream, Array)) OR REGEX(str...{CODE}

Steps to reproduce:
# click on the bell icon next to your logged in username at top right
# Unread Notifications modal appears
# click Show More button

See https://dev.tiki.org/tiki-monitor-stream?from=-30+days&to=now&critical=1&high=1&low=1

Tiki sends emails for several things (watches, password reset, newsletters, etc.) in addition to end users via ((doc:Cypht)) webmail.

System emails should be sent with a valid sender email. Many will put a bogus no-reply@example.org but that is bad practice. We should be using a real email account, accessible via ((doc:Cypht)).

See also ((Transactional Email Providers))

There will be manual replies. There will be bounces. This should be monitored, and handled accordingly. When you have hundreds or thousands of bounces in a ((doc:Cypht))-accessible account, it's tricky and time-consuming to manage.

If you don't handle this, and repeatedly send out emails to invalid accounts, you risk being flagged as a spammer.

Tiki should help detect types of bounces. Ex.:
* Manual reply
* Soft bounce (ex.: vacation message)
* Hard bounce: (user doesn't exist)

There should be a dashboard of all bounces, with a way to see
* The emails with the most bounces (top bouncing emails so site admin can go in order of priority)
* The actual emails with ((doc:Cypht))

And help Tiki admin handle this
* Show where this email is used (user profile, watches, etc.) and help remove.

See https://packagist.org/?query=bounce for potential libs.

This tracker item could not be found

On at least two sites, running respectively 3.x and 4.x:

- jiamcatt.ourwiki.net (3.x)
- terminology.tikiwiki.org (4.x)

I noticed that if I change a wiki page and save it as a minor edit, email notifications are still being sent.

I think that this only happens when the user is part of a group for which a Group Watch has been set. When I tested on the 3.x site, that's the conclusion I had come to (this AM, UK time). But this PM (UK time), I tested on the 4.x site, and it seems that the minor edit is causing notification even if a user-defiined watch (i.e. as opposed to a group watch) is set.

BTW: This bug caused a minor incident on the JIAMCATT site. Someone did about 30 minor edits to a page that was being monitored by a large number of people, because he was a newbie and was trying to master the syntax for referencing a section inside a page. As a result, 30 notifications got sent to a hundred people, and some of them got pretty pissed off, and almost walked out on the site. One person asked to be "taken off this infernal web site".

So, if the bug can be fixed quickly, I can go back to this community and tell them that something was done to prevent that sort of problem in the future, which might diffuse the crisis.

When I click on "Monitor this Tracker" It doesn't appear in the "My watches" section. It would be very nice to have a list of monitored trackers there as it would be quicker to verify. I would actually like to have the option of only seeing my trackers in the "My watches" section without receiving any emails when a change occurs.

Thanks to all volunteers on this !

Visiting nextdev.t.o (trunk 12.0) in mobile mode (using chrome for android), I can't click in the watch icon, for a tracker item.

I can't either on the printer icon on each tracker item.

There is no confirmation step on the delete action on -+tiki-user_watches.php#contentuser_watches-2+- as there is on other places in Tiki.

I can not find the ability to receive an email notification when a table gets changed.

It would be very useful if this capability were part of tikiSheets. Several other tikiwiki features have this feature through the watch capability.

non-valid url due to doubler slash in mention notification emai from t.o

Example from a real email I received:
{CODE(ln="1")}
jonnybradley mentioned you in https://tiki.org//Roundtable+Meeting+2020+07#mentioned-Xavi-section-1
{CODE}

Note that there are two slashes after tiki.org in the url, which makes Tiki reply that this page doesn't exist.
If you try with one slash only, itr works as expected:
https://tiki.org/Roundtable+Meeting+2020+07#mentioned-Xavi-section-1

I wish there was an option to choose if the notification e-mails for wiki pages watches, tracker items, etc. should be sent in plain-text or HTML formatted.

In general, wiki syntax is not parsed in notification mails. For example, the "New article post" notification email includes the full body of the newly posted article. However, Tiki includes the full wiki coding/syntax within the body of the message, and sends the mail message as plain text. Tiki should either:

1. Send the message as parsed HTML

or

2. Strip all formatting and send only the text.

^__After problem with show instance closed and set up new for user Nayana__

__New bug report with working show instance: https://dev.tiki.org/item6550__

{sign user="Torsten" datetime="2018-01-23T16:30:35+00:00"}^

After setting Mail Notifications to various users for types like:
blog_comment_changes
blog_post
wiki_page_changes
I get only notifications for wiki changes.
Using the option to output to debug file..

Tiki 17.1 php 7.0, nginx ..

After setting Mail Notifications to various users for types like:
blog_comment_changes
blog_post
wiki_page_changes
I get only notifications for wiki changes.
Using the option to output to debug file..

Tiki 17.1 php 7.0, nginx ..

Since a few days (may be a week+) I receive now a notification of my own post in the forum.

IE:
I replied to a post at : https://tiki.org/forumthread79371-Restrict-languages-in-i18n-crashes-website

I received the following email:
Bernard Sfez / Tiki Specialist __mentioned you__ in forum post "Restrict languages in i18n crashes website !"

You can view the mention by following this link:
https://tiki.org/tiki-view_forum_thread.php?threadId=79372#mentioned-bsfez-section-1

---

I'm pretty sure that I was not notified of my own post a few days ago which seems to me the normal behavior. (else we need a different text in the notification)

I created a ticket on dev.to: https://dev.tiki.org/item8472-Tracker-create-item-modal-need-to-be-clicked-a-second-time-to-show-the-modal-on-Tiki26.

I received a notification about a modification of the item by "Rodriguez Nyiringabo"

{img fileId="2098" thumb="box"}

It is unclear for a simple user to understand what was done.
I can understand that from "empty" option 2 selectors were changed to "none" option,

If I look at the ticket I don't see anything neither about the modification and only in "History" I can see that "Rodriguez Nyiringabo" selected "none" and this is the modification.

{img fileId="2099" thumb="box"}

In term of logic, "Empty" and "None" are not the same.
But for a simple user this is a confusing UX.

It can be improved.

{syntax type="tiki" editor="plain"}
Since Tiki30 I see now, when editing a tracker item, a switch to notify or not the users following the item.

Look like a good addition, but:
* it should not be displayed if no one is following the item
* it should not be displayed if no one is following the item but me
* it should be possible (accordion ?) to see which users will be notified

Without these elements this addition leads to concerns + require time to check who is concerned.

When one has a file belonging to two categories: parent category and its child category, he can subscribe to notifications from both as shown below:
{img fileId="1058" thumb="box"}

Imagine the page was changed.
In this case two identical messages are received, which decreases usability. Only one message has to be received per a file modified (created) despite the number of categories that it belongs to.

Here we see the result:
{img fileId="1059" thumb="box"}

Moreover, notice that instead of the user profile image whatever it is that is inside "alt" attribute of the image is displayed.

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.