Notification System

Hi,

Here are the new patches and my answers to your remarks.
I hope that this new version will suit you.

POINT 1
=> Integration will be done on V7.0
Please provide new patches (with following remarks) from this branch
In attachment, patches from release '4287'.

POINT 2
=> 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.
Done in attachment files 'images.zip' and 'customIcons.zip'

POINT 3
=> 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)
Done in projeqtor_V7.0.0_NS.sql

POINT 4
=> 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.
Done

POINT 5
=> 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.
Implemention of a new table 'statusNotification'

POINT 6
=> 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.
Done

POINT 7
=> 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.
Done. NotificationObjectClass is rename in Notifiable

POINT 8
=> 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.
Corrected.
In view/css/projeqtorFlag.css, i comment with // and not with /* */

POINT 9
=> 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
DONE

POINT 10
=> 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 ?
An example :
Automatically restart each beginning of the month of unpaid bills.

I want to notify and send an email to the project's customer contact for each invoice that has not been paid by the due date at the beginning of each month.
By the way, I want to 'customize' the title and the content.
Unless I'm mistaken, with the indicators, I do not know how to do it.

With notifications:
Notifiable Element = Bill (Invoice)
title = Invoice not paid - External Reference = # {billId} - Sent the # {sendDate}
content = Unless I'm mistaken, the # {billId} invoice for the # {idProject.name} project that expired on the # {paymentDueDate} is still not paid.
rule = paymentDone = 0 AND paymentDueDate <now ()
reference date = Payment deadline
Every month = checked
Day = 1
Notify before = 0
Receiver = idContact
Sending email = checked.

This is therefore a recurring notification definition (every month) related to an element (bill).
It will be able to generate as many notifications (and email) as unpaid invoices due on the 1st of each month.


POINT 11
=> 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.
You are right

POINT 12
=> 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 don't understand the remark.
For me it works. I have not done anything special at this level. This is a field that is treated as a textarea at objectdetail.php (I checked with the debugger).

POINT 13
=> 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 ?
In fact, because the manual notification is not linked to an item, it is not processed in the display of unread notifications.

Correction :
I created a 'Manual' tree to take into account these manual notifications.

POINT 14
=> 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 ?
No. It was a bug.
Clarification. When you change a NotificationDefinition to save it, the generation system is activated (regardless of whether the CRON is active) to take into account the changes on the notifications to be generated.
So there is no need to wait for CRON execution (or even activate it) to see the effect of a change in NotificationDefinition

POINT 15
=> 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 ?
Idem point 13.

POINT 16
=> 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.
In fact, the top menuBar sometimes hid it.
Not finding the solution, the notification icon is moved to the bottom right.
I did what I could with the styles

POINT 17
=> 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).
DONE.

POINT 18
=> Click on icon "refresh" of Notification Area "closes" this area (message console is displayed)
It was voluntary. In the same vein, this area automatically appears as soon as there is an unread notification exists.
I changed. The zone is no longer closed when there is no unread notification. However, it opens automatically as soon as an unread notification 'appears'

POINT 19
=> 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)
I changed the interface.
I let you discover

Best regard

Hi,

Here is a new patch integrating your requests base on revision '4300'.

In addition, follow my comments on your previous remarks.

Point 19 : Great, new interface is much more explicit
=> I saw some entries in lang.xls for "menuNotificationDefinitionNovice" and "NotificationDefinitionNovice" but this class and menu do not exist.
I removed them, guessing it was some first idea of yours to have advanced and novice interface, but finally proposed only one form for both user types.
Can you confirm ?
=> I also saw that on js file, you use condition "if(context==='Novice')".
But it seems that this comes from parameter of function called only in NotificationDefinition::getValidationScript() where parameter is always set to "".
So condition may never be true...
Can you please "clean" this part of code ?

lang.xls => I confirm
if (context==='Novice') in js
Done

Point 20 : Duplication in lang.xls
New items in lang.xls redefine some caption already existing.
Better use existing translation code rather than creating duplicate.
This will avoid extra large lang files and will ease translation for community translators.
or => OR
and => AND
buttonInsertInTextBoxNotificationDefinition => operationInsert
colIdNotificationStatus => [Not used]
colIdStatusNotification => colIdStatus
idNotificationType => idType

OK
The lang.xls in the zip contents only add and chance i do for the patch.


Point 21 : Notification System can remind every open Day - week

Notification System can remind every month / year
=> I think it would be interesting to add possibility to notify every "day" (or open day only) and "week"
For instance for an action not done, I could notify responsible every (open) day or every week (depending on urgency of action)
Done :
Every 'Open Day' and Every Week.

+ You can be notified every day, week, month or year after than the reference date is passed
+ You can choose a range before the reference date (notificationDaysBefore) in witch notification can be generated and the number of days before you want be notified (notificationGenerateBefore)

Point 22 : ${} #{} Notification System can remind before hours
otification System can remind "before" given days.
=> I thing for some items or some dates, it would be good to notify before given "hours" (or possibly minutes, but it would require higher notification frequency than 3600s)
For instance, for a Ticket, I would like to notify responsible 1 hour before ticket due date/time.
Or for meeting, I could notify 15 mn before meeting date and time (more complex as meeting has 2 fields for date and time)
Done for fields DateTime (notify before minutes)
Not done for composition Date + Time (meeting).
For meeting why are stored Date et Start Time in two fields. If you store they in 1 field (for exemple meetingStartDateTime), it will be work.

Point 23 : user docs for Notification & NotificationDefinition
Screen "Notification Definition" and "Notification" don't have a user manual entry.
I think it is important to explain how the system works (need to update some .rst files in docs/user)
=> Please create entry in user doc
I am not familiar with your documentation format.
Also, I made a doc 'user' in .odt (in the zip).
I leave it to you to transform it.

Point 24 : user ${} rather than #{}
When defining TITLE and CONTENT in notification definition, fields are inserted as #{field}.
Similar system already exists (for instance for email titles, and for new Email Template system) with syntax ${field}
=> Please upgrade system to use existing syntax with ${}
Done

Point 25 : Manuel notification not count if automatic notification
On the notification icon (on bottom bar), number on "unread" notifications is wrong. It seems "manual" notifications are not taken into account.
(I had 3 notifications, 1 manual, 2 automatic, icons show "2" notifications only).
It seems the same for the "unread notification" on message section (above console message). As long as I have only one manual notification, it is correctly displayed.
If I also have automatic notification, unread manual notification is not displayed.
=> Please fix this issue (if confirmed).
I can't reproduce.
Please give me your notification et notificationdefinition tables to see what's append.
Before this release, in the tree 'Unread notification' and in icon 'bottom bar' all notifications were counted, but in 'loginCheck' only notifications with notificationDate <= current date were counted.
Perhaps, it's the cause.
Now are only counted notifications with notificationDate <= current date in all components (Tree, icon, loginCheck).

Point 26 : Insert with CK Editor doesn't work
Help to insert field in content (using CK-Editor) does not work : nothing happens
Error logged in browser console : Cannot read property 'getValue' of undefined at addFieldInTextBoxForNotificationItem (projeqtor.js:4468)
=> Please fix this issue.
DONE (also for dojo editor)

Point 27 : Remove NotificationMain and NotificationDefinitionMain

Notification and NotificationDefinition are not supposed to be changed through "Screen Customization" plugin.
So structure with Class and ClassMain should not be used.
=> I removed Notification and renamed NotificationMain to Notification
OK

Point 28 : bug { in comment
There was an error on api/api.php and too/adminFunctionalities.php : closing } was included in comment, so these scripts were not working anymore
=> Fixed
Thank you

Point 29 : css - icon standart
Icons for standard themes (non flat) where not colorfull as expected.
Moreover, it's not necessary anymore to design each icon in three sizes (use css3 background-size)
=> Fixed
Thank you

Point 30 : Utility of _drawLike
See in notificationDefinition :
I need to have 2 representations of everyDays (for month and year).
The first is a spinner 'day' on class attribut ($fixedDay), the second is a spinner 'day' but in specific item.
Rather than to create a specific function (drawSpecificItem), you use _drawLike_nameOfAttribute (in my case, _drawLike_fixedDay) and the _spe_ attribute is drawed without specific function.
$fieldsAttributes of xxxx is not used for _drawLike_xxxx.

Point 31 : No notification menu if notification system is inactif
NEW
If in global parameter, 'notification system' is inactif, then all menus that contain 'Notification' are not displayed


Point 32 : Force draw Header in tab
NEW
Force drawing of headers even if the fields are hidden.
Optimize width of column in _tab_

Hi,

Here a new patch and my reponses :

Point 20 : Duplication in lang.xls
I give you in lang.xls only the changes.

Point 23 : user docs for Notification & NotificationDefinition
OK, we'll upgrade user manual. It's right that Sphinx-doc syntax is not so easy, but system is so powerful to manage hight quality html manual and pdf with same code...
Well. I'm going to look at what Sphinx-doc is to be more efficient in the documentation in the future

Point 25 : Manuel notification not count if automatic notification
I could not reproduce with current version, so possibly it's fixed now.
I'll run more tests and will let you know if I find new strange behaviour.
Well

Point 30 : Utility of _drawLike_
The _drawLike_ feature is not needed.
I changed $_drawLike_01_fixedDay to $fixedMonthDay
Then added :
private static $_databaseColumnName = array('fixedMonthDay'=>'fixedDay');
This does the trick : both fields $fixedDay and fixedMonthDay refer to same db column, so they have same format.
To complete, I adapted save() to be sure correct value is stored and it works like a charm.
So I removed the _drawLike_ feature in objectDetail.php that unusefully complexify this already complex script.
OK - I cleaned up comments on this in ObjectDetail.php

Point 33 : SqlDirectElement::execute query should not be used - NEW
SqlDirectElement functions should not be used on save() statement.
These functions are reserved to technical updates, migration and possibly some complex reports queries (with UNION, INTERSECT or else).
Moreover, the where clauses used several non ANSI MySql functions that will not work on PostgreSql, and we must preserve both compatibilities.
So, I replaced the DELETE query with a $this->purge() with a simplified Where clause.
Hope this new clause will fit expected purge.
OK - I remember that in th future

Point 34 : "Notify in advance" and "To notify" - NEW (for confirmation)
In the .zip, you have 'Notification System.odp' that explains to you, through diagrams (which are better than long comments), the operation of Notification System.
I hope that it will bring you all the information necessary for your good comprehension.


Point 35 : "Notifications for meetings" - NEW (completion of point 22)
I added fields meetingStartDateTim and meetingEndDateTime, automaticaly alculated from meeetingDate+meetingStartTime and meeetingDate+meetingEndTime
Then will be able to notify before meeting starts (and possibly before meeting ends)
I tested, it works fine (even if it requires to shorten "Automatic notification generation cron delay"
Super

We now have a great notification system
THANK YOU

Here are improvements that we are thinking of, and I included in the roadmap.
Good ideas.
However, I now plan to focus on

• a bill generator from the terms (fixed price projects), time worked (projects governed), etc
.

• an HR Management in projeqtor with the following features:
  1. Absence management
  2. Salary management
  3. Career Management
  4. Benefits Management (TR - Executive Cars - Premiums - etc.)
  5. Management of employment contracts

I think that will bring another dimension to Projeqtor and for my part will avoid me to use several tools that must be synchronized.

With regard to these points I will create in this forum new topics and give you the specifications (especially for HR Management).

Hope this will hold your attention and win your membership.

Best regards,