Flyspray - The bug killer!

  • Status Assigned
  • Percent Complete
    0%
  • Task Type TODO
  • Category Backend/Core
  • Assigned To
    Jouni Ahto
  • Operating System All
  • Severity Low
  • Priority Very Low
  • Reported Version 1.0 alpha1
  • Due in Version 1.1 devel
  • Due Date Undecided
  • Votes
  • Private
Attached to Project: Flyspray - The bug killer!
Opened by Jouni Ahto - 20.03.2015

FS#1981 - Unify event logging and notifications

They are currently two separate mechanisms. Shouldn't be so. Events happen always, notifications when someone should be or have chosen to be notified about those events.

Besides, the current code is just a total mess that should be fixed/rewritten anyway, and we unfortunately also overlooked during the development phase 2 things: one new table, users_emails, and the fact that the user is now allowed to give several email addresses separated by a semicolon.

Project Manager
peterdd commented on 20.03.2015 20:49

If they are 2 things, why they shouldn't stay separate?

Events are more like a collections of timestamps in db with events id and don't need text oder translations.
You can everytime see what happened at a time period.

Notifications are more instant messaging but are quite loose, because sender don't know if the recipient reads them, get deleted when seen, ..

Here is the webbug of the github notfication email (html part), so probably the notification is removed when you read your email with images loaded

<img alt="" height="1" src="https://github.com/notifications/beacon/*****.gif" width="1" />

Implementing that would be a feature request, but I personal have no need for that.
(Loading external images from the internet when reading email is set off for a good reason)

But for people who have enabled this external image loading in emails it can be a gain in usability to not see old read notifications when they login into a flyspray installation.

Jouni Ahto commented on 22.03.2015 18:17

You don't get my meaning. They are in reality not separate things, but in our current codebase, they are. Instead of having a separate table notification_messages, notification_recipients should be modified and a new column, history_id, should be added, that links it to the event someone should be notified about. Maybe some more, have to think about this one a bit more.

Then, move all formatting out of Notifications class to events, make it a class too. Notifications should handle only who is getting notified, how, in what language and either sending or storing the notification, not any kind of formatting of the message.

Some really far-fetched ideas, if I'd do this in C++/Java/C#. An abstract base class EventType, has some abstract methods for formatting, and one concrete final static method EventType::getEventTypeInstance($history_id), and a lot of concrete subclasses implementing those formatting methods for various purposes just for that one event type. At least it would be a different kind of mess compared to the current case: case: case: case: etc going on already near or above 1000 lines mess in 2 different places.

Loading...

Available keyboard shortcuts

Tasklist

Task Details

Task Editing