Hi Marc,
I tried and include your paths on V7.0.0.
Here are my remarks :
Notification system remarks
=> Integration will be done on V7.0
Please provide new patches (with following remarks) from this branch
=> I cannot retrieve images directly from patch (my SVN system does not take into account binary files)
Could you please provide images in a zip ?
Also iconSum.png is missing for blue theme.
=> All the updates in maintenance.php should be moved to projeqtor_V7.0.0.sql
Only complex updates (coherence or such) should be done in maintenance.
Please move updates to .sql (see below requested simplifications)
=> I don't see any interest for defining other notification type than the 3 already defined (Alert, Warning, Information).
Screen for Notification Type is useless.
Moreover, it is not consistent : behavior section does not fit Notification fields, color is missing (which is the only interesting thing to change).
Please remove this screen.
=> Management of workflow and statuses for Notification seem useless : a Notification only has 2 statuses "unread" and "read".
A simple boolean should do the trick.
Or if you prefer a list, a dedicated NotificationStatus, with fixed values (no screen) will be enough.
No need to complexify with "status", "workflow" and so on.
Moreover, you indicate that "name must not be changed" !!! But if it is a status like any other, sure it will be changed for instance to translate it.
My proposale : create new table and class NotificationStatus, with 2 values, translatable, check id for this status (and not caption) and don't bother about workflows.
=> Notification type should have translatable name
(if list is fixed)
You can take example with class Message that already has Message Type with 3 same values.
=> NotificationObjectClass should not have its own screen.
There is very little interest.
We'd better insert "Notificable" items in the table at setup, with more accurate ones (possibly limited on a first version), and extend on request.
=> There is a mess in CSS.
I didn't identify yet where, but some styling does not work anymore after patch is applied.
For instance "orange" color on number of items in the list has disappeared.
=> Generation alert check in hours : all other CRON parameters are in seconds.
It should be more homogeneous to have parameter in seconds, default value should then be 3600
=> I understand the interest for Notifications on an item (even if I don't really see difference with existing alerts on indicators)
I can see great interest for recurring Notifications, but I don't understand why recurring Notifications must be linked to an item.
Could you explain the idea ?
=> We can create notification manually : so it's not a notification anymore, it's a message
But this notification is not linked to an item, so it's possible to have notifications not linked to items.
=> the content of a notification is long text : we can use some formating.
But when defining the notification, the content is a small text field, without possible formating
=> I just created a notification (manually). I am the receiver and the sender, but I did not see the Notification in my "not read" notification area.
Have you got an idea why ?
What am I missing ?
=> I created Notificaton Defintion for Action, with rule "1=1" (always true) on target date "initial due date" with idResource (responsible) as receiver.
I set due date to "today" : I expected to have new notifictation but never got it.
CRON is running.
What am I missing ?
=> When I connect, I have a warning about one unread notification (the one I created manually), but cannot see it on Notification Area nor have icon "Notification" displayed.
What am I missing ?
=> I cannot see notification icon on top right.
When I connect, I can see it is here, but it automatically disappears, as if it was "behind" something else.
=> About access rights, why not just fit right like existing for Alerts ?
Users can only see and change their own alerts (the ones they are receivers).
=> Click on icon "refresh" of Notification Area "closes" this area (message console is displayed)
=> I consider that the Notification Defintion system it too complex and too "technical".
You must know internal naming of fields to understand what to do, and this will concern, I guess, less than 10% of users.
For instance, it is not intuiitive (unless you read some code) that "Responsible" receiver should be defined as idResource.
There should be a "Novice" way (possibly with less features, but guided on how to use system without knowing the database schema) and an advanced way (existing one)
Also separate interface for "unit" notification definition and "recurring" notification definitions could be a good idea (the second one should not be linked to an item)
As a summary, your system is promissing, but not in a sttus that will have it integrated in next version.
Please improve your system and come back to me with new patch, I'll be pleased to test again.
Babynus
Administrator of ProjeQtOr web site