Loading...
 
Features / Usability

Features / Usability


article_submitted only sends an email to members of the admin group

posts: 2 Netherlands

The challenge:
User watches on a article_submitted event only send an email to members of the admin group.
It does work when I create a watcher on article_*, but in that case every minor article update triggers 1500 emails.
- tiki 15.4 or 15.6 same issue.
- feature_user_watches_translations makes no difference.

How to fix this and enable this article_submitted for normal users?

posts: 2 Netherlands

Found it!
according to lib/notifications/notificationlib.php and the function get_global_watch_types function the article_submitted trigger is related to 'url' => 'tiki-list_submissions.php'
article_edited tiki-list_articles.php
article_deleted tiki-list_submissions.php
article_* ' ' (no url)
article_commented ' '

So with my 'hack' to provide users with a article_submitted watch and without the admins using the submissions feature, this submitted watch is never triggered.
In fact, there is no way to ever trigger an article create watch without getting a edit, delete or commented on notification. This is in tiki 15.4/6

My current solution: remove the url element from the $watches'article_submitted' array

Suggestions:
1. create separate events for create, edit, delete and commented on.
2. rename the label tra('An article is submitted, edited, deleted or commented on.') to
tra('An article is created, edited, deleted or commented on.') as this "submitted" references the wrong action.
3. mention this in the current documentation.

Please let me know if I'm not correct, and or how to assist in these actions.

Hans.



posts: 126886 United Kingdom

Hi Hans

That all sounds quite likely but i'm afraid i haven't been into the articles code recently as i always find there's something wrong with them and building a custom solution in trackers is generally far more flexible.

However, can i suggest a couple of things that will make it easier to test your theory.

  • Reproduce it in trunk (will be Tiki 19 so all fixes should start there)
  • Add a wish/bug report to the dev wishlist (and maybe set up a show instance, but debugging notification bugs is often tricky)
  • Attach an svn patch or diff file of your suggested solution on the bug report


Sorry to ask you to do so much, but i just don't have time to experiment on this (hence the delay in replying, apologies)