Redmine

Well said Terence!

This kind of ticket is very useful because it sums up all separated ideas related to this topic giving it an clear course.

However, I'm also afraid because even the smaller tickets related to this one weren't implemented yet. I prefer to be wrong, but how one can think that a bigger and more complex ticket will be implemented soon? There are tickets dated from more than 2 years ago.

+5 for this feature

+1 !

I created a plugin that sends an email digest of project activity. It's not very configurable (yet), but at least it's a start: http://www.redmine.org/plugins/digest.

I'm new to Ruby coding, so improvement patches are welcome.

+1!

Dupes

• #415
• #8268
• #8331
• #8374
• #8382
• #8268
• #8331
• #8409
• #11619

• #3069 (notfication part)
• #8241
• #3857

Needful code snipets

• "extend the watcher functionality to send email notifications for issues" /boards/1/topics/22313?r=22390#message-22390
• "Email reminders sent for closed issues" #8108

Plugins doing some of the stuff

• https://github.com/ascendro/redmine_issue_reminder#readme
• https://github.com/applify-adrian/redmine_notification_manager_plugin

Exmample for New pluggable Notification format, see Notifo

Has there been any work done on this? I'll probably look into tackling the idea of a notification digest system for the e-mails that we typically receive.

A plugin I authored does most of the things noted in the original post, with some caveats. For my small team where most of the "users" have never even logged into Redmine, it works fine for me.

See http://www.redmine.org/plugins/digest or https://github.com/drewkeller/redmine_digest (there are some screenshots in the file list).

• The event types are determined in code (basically everything).

• The notification schedule is determined by the project administrator.

• The notification format is determined by the Redmine administrator setting for email format.

So the only option the user has whether to receive the digest. A number of people have requested providing more settings for the user, but I haven't got around to doing it (not to mention that I'm not really a Ruby programmer). Improvements are welcome (github makes it easy).

• Global (admin) level sets default for all users
• project level sets defaults for project members (receive notification right for role)
• user level can control all: unregister for defaults from upper level and configure new own rules

user can't configure notification detailed
Major thing missing is that user himself can't influence how often, when and in which fotmat he shall be notified. Thats exatcly what this feature request is about.
At the moment the digest is send global by admin config (user can't configure poeriods himself) and the digest is send for every project instead of one digest e.g. per day/week for all of them. For most users this feels like spam, so they skip the digest.
The digest only and reports on all isses in a project. Users can't filter on issues, so can't perosnalize their notification conten in any way. Furthemore there is only notification for ressource type issue, but none for threads, changesets, files, documents, news... - all event types seen in activity pane.
see https://github.com/drewkeller/redmine_digest/issues/19

project manager can configure notification templates for his project
This feature is comarable to shared issue filter's in redmine
User can select this template

configure reciepient filter "role"
Role based there shall be a right to be ablele to configure project specific notification:
Like sending digest dependent on user base it's also feature missing to send notification based on roles per project.
https://github.com/drewkeller/redmine_digest/issues/11

Being as I'm looking on trying to hammer this out, I want to get a clear picture of what would be best for Redmine (not just where I work), so input is valuable to me...

project manager can configure notification templates for his project
This feature is comarable to shared issue filter's in redmine
User can select this template

Can you give an example of this? Would this be all e-mails that go out? Digests are on a per-system basis (at least in my mind), so I'm kind of confused on how project level templates would work. Otherwise I'd have to send one e-mail per project (ick).

The plugin is a good place to start, but yeah.

1. A message digest system / notification overhaul should be part of the Redmine core.
2. Also requires backwards compatibility, basically unallowed to touch current notification tests.
3. Digest rule sets can be applied at the system level (lowest priority) project level (mid priority) or user level (highest priority).
4. Digests should be driven by a task that can be cronjobed.
5. Notifications should pretty much operate as they do now, with the ability to basically disable them on the user level and rely on digests.

As for the requested feature sets:

• Event type: is new or change on any item, eg. news, issue, thread, file
  • This can be accomplished by checking the object passed during a notification method against notification rules.
  • Make it easily expandable to other plug-in objects, also allows us to tag things like version updates (so some way at runtime to find
    all objects tagged with this property easily).
  • Need a "for all other notification events" base type, to catch not implemented event types (plug-in notifications and such).
• New: Just a new entry in any project i am involved and have view rights
• Change: changes on Item in project i am involved, have view rights and the filter is met. If no filter is set any change will be notified.
  • This may be a bit difficult to work out, I believe notifications are fired after save, so I can't just pick up the new record flag if I'm not mistaken...
• Notification schedule
  • Immediate: easy, no digest engine settings needed, use old observation (IIRC) system plus the additional tweaks above for filtering on rule sets.
  • Historical based digests: Task and a cronjob pulling historical changes depending on rule sets.
• Format
  • E-mail: Well that's what we get now, we'd have to have new templates for the digest though.
  • Popups: Would require digest results to be saved after completion for easy access.
    • If the popup hooks and whatnot aren't included in the first implementation, at least include this functionality so that it'll be easy to add later.
    • Can we delete this cache after viewing it?
• Improvment on this side will also open paths towards other information drop palces e.g mobile or web services like twitter notification, because the model only needs another notification format, e.g SMS or twitter to be added.
  • So delivery method should probably be abstracted so it can be easily extended.

The ability for short/medium/long formats aligns with my need on issue #11619, and I'm tempted to dump the time into this instead (the company I work for has expressed a lot of interest in a digest system, and changes to the notification system).

• Object types (Issue, Project, Wiki, Forum, Etc.)
  • Change type (New/Change).
  • Include object fields (maybe a 2nd phase feature).
• Notification times (Immediate, Hourly, Daily, Weekly)
• Projects this rule applies to.
• Rule trigger delivery method.

Am I missing anything?

Maybe this weekend I'll look into posting some UI mocks.

Hi William,

Thank you for your interest and goodwill. You're right, better make clear what to do, and since you ask for feedback, here is some.

Notifications of activity and notification of reminders¶

Redmine content represents things to be done, some with deadlines.
Notifying of activity is good but insufficient. E.g. some issues without activity are abnormal and should be notified, too.

So we need two types of notifications:

• Notification of activity is what we had first in mind. It's needed to make users aware of changes.
• Notification of state, a.k.a. reminders is also needed in some contexts to remind users of some need still unmet.

Does it make sense to handle both in what you're offering ?

The latter may actually be easier to code than the former (just look at objects state, no need to look for transitions/events). What's your opinion ?

Reminders: current status¶

Current approach for reminders in Redmine has little flexibility, that would be greatly enhanced by what you sketched here. What you wrote above, if applied on reminders, will benefit right away.

• to be notified more often about some other projects
• some specific issues (by importance, deadline, etc) should be sent on a separate list
• be notified about unassigned issues
• be notified about issues with close deadline and no activity for a moment (that one would be more difficult I guess, so we can leave it out for now).

A simple solution to implement these needs and more, plus intuitive for the user, would be for the user to just create whatever query he likes in the "issues" tab (or pick one query made available by the administrator) and have an option that the result is sent to him following some schedule (by the way, it's done that way in Jira).

• query 1 : projects foo and bar, what is due by me in following week, send every week
• query 2 : projects x and y, what is due by my team in following month, send every week
• query 3 : all projects, what is due in following week and marked high importance
• query 4 : all projects, what is unassigned and due in following week, send every day

The last example shows that not only "assigned to me" is a relevant example of notification, so (1) creating a query then (2) asking to ne notified about it, is relevant.

Shared thought about this might enrich the approach for notification of activity, too, but let's stay focused.

Both notifications seen as fundamentally the same¶

• Notification of state (reminder) is basically a query in an "issue table".
• Notification of activity (or activity tab in Redmine) is basically a query in a "change events table".

The "change events table" is what provides data to the activity tab and, in issue view, the issue history.

A notification engine properly design might then just focus on what it's designed to do : run queries on a schedule and send the result. Separately, the ability for redmine to query on issue stats and on change events may be viewed a separate task.

I'm not sure what is the most valuable approach (that is, provide what users need with lowest UI and development cost). What do you think ?

@Stéphane - Your description of a new reminder framework above is exactly what I am looking for. To put it simple, the user is able to configure a filter (or the administrator) which can then be enabled as a 'Reminder' type filter which can be set on a schedule.

Out specific requirement is for a bi-weekly reminder email the contains all due and overdue issues for certain configurable projects and trackers.

Half of this is covered by the existing reminder script, but the management here wont use it as, in their mind, it may lead to a false belief that nothing needs to be done if it doesn't show up in the reminder.

+1

+1

+1

+1
it could be very useful

+1

+1

Our organization need the function like "If status of an issue equals XXX then send email goes to user YYY"
I need a function by using which every assignee can switch special custom status on the issue and "The Big Boss" will be reminded by email.

Or better idea - to make available customizable "email" action in special email place(where aggregated all email admin functional) in redmine, that would be triggered on issue status or update, оr comment, or custom field state, or expiration.

Simply there should be the way to operatively inform someone by email while you in the process of resolving issue.

+1

+1

+1

+1

+1

+1

+1
a function where different roles get notification when status didnt change after a period of hours

+1

+1

+1 Would be unbelievable helpful and increase productivity.

+1

+1
plus, please also include options to enable/disable including the descendants_tree/relations/notes(full notes list of journals history).
and, it's 2019 now...

+1