Hello,

I bring you a new version of the notification system at the level of
  * tool / projeqtor.php: Notification Rights Management
  * db / maintenance.php: Debug (tested on migration from v6.5.1 to this version)
  * db / projeqtor_V6.5.2_NS.sql: Fixed on 'menuNotificationSystem' type = 'menu' instead of 'object'
  * lang.xls: colIdNotificationDefinition error

Sorry if I wasted someone's time with these fixes.

About Notification Rights Management:
I used accessRight which are normally dedicated to the classes related to a project. But for notifications this is not the case. I am not in the purest, but I found this way easier. If anyone has an idea that could avoid this circumvention, I am a taker and will make the change as soon as possible.

Best regards

Hi Marc,

Thanks you very much for this contirbution that seem very interesting and well thought.
I've quickly read the document, and your improvments seem attractive, with quite important code changes.

We plan to integrate it on next version.
I'll let you informed on progress of integration, and maybe will come bzack to you if some points are not clear (at first reading some points are already not clear, but they may unlighten when reading the code or when testing the feature)

Thanks again.

Hello,

Thank you for your reply.

For my part :
* I will answer all your questions and requests for corrections as soon as possible.
* I continue to do tests on non-passing cases (ex: Synthax error on the rule => Don't save and display of a message)

As a reminder, I am not really satisfied with my implementation of the rights on notifications.
Indeed, two things:
 1. Using rights on a project-related object when notifications are not
 2. IdUser inversion and idResource:
In fact, in NotificationMain.php you will see that the idUser is the receiver. idResource is the issuer.
It is an artifice to implement the fact that within the framework of a notification, the owner is the receiver (modification of the status for example).
However, this is a problem when you manually create a notification. Once created, you have to modify the creator (in the action bar of the detail of the object) to change it and put the receiver in the place.

I admit that creating a rights management 'system' similar to the one implemented for project-related objects seemed heavy, especially since I did not know if me idea of ​​notification might interest you.

On the other hand, for the implementation of the 'HR module', this system will be necessary.

Last point :
During the checkout, I encountered conflicts on 'objectDetail.php' that I resolved.
I did a lot of tests on the existing which I found conclusive.

Bests regards

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.

Hi,
Thanks for your feedback.

At first reading, I agree with your remarks.

I come back to you with the requested changes as soon as possible (before end of January)

Best regards

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.

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

Thanks for theses new patches.
I have integrated them on a testing version and will give you my feedback when tested.

Hi Marc,

Your contribution is integrated in branch V7.0.
Thanks for your efforts to bring a new feature and set it at ProjeQtOr quality level.

Here are new remarks, with some improvements / fixing to finalize this feature

POINT 3
On projeqtor_v7.0.sql
Rather that

  INSERT INTO XXX (A, B)
           VALUES (1,2);
  INSERT INTO XXX (A, B)
           VALUES (2,3);

group in one single quey

  INSERT INTO XXX (A, B) VALUES
   (1,2),
   (2,3);

=> really minor remark, to take into account for future contributions

POINT 4
Removing screen Notification Type is OK,
but you also removed creation of the 3 types.
=> Fixed in projeqtor_v7.0.sql

POINT 7
Renaming NotificationObjectClass to Notifiable is good.
But Notifiable list should be initialized.
=> Done, inserted : Action, Activity, Bill, Command, Deliverable, Delivery, Incoming, Issue, Meeting, Milestone, Opportunity, ProjectExpense, Quotation, Requirement, Risk, Ticket, Term. Possibly, this list could be extended (let's start simple, and extend it on community request).

POINT 10
Thanks for the explanation.
I understand better now.
So we'll have :
- indicator : will highlight item on expected value (date, work, cost) and possibly alert only once "before target date".
- notification : will notify on expected date, and possibly before given days, and possible repeat notification on monthly / yearly basis
=> OK, see point 21 for expected improvement (remind every day / week)

POINT 16
OK, it appears now.
See point 24 for small issue discovered.
=> We will remove bottom bar on V7.0.0. It is a major design change.
We'll add a top bar, including project selector, navigation buttons (including new tab) and new "User Profile" access.
The top bar menu, will become optional (hidebale).
We'll move your notification on the new top bar, beside the "User profile" icon.
Pay attention for further patches to always take into account latest revision, and send only "difference patch" for your new changes in order not to erase our changes.

POINT 17
Great, I like the way you did it.
Very logical, even if not standard.
=> If user have "write" access, he can create manual notifications, if he has "readonly" access, he cannot create new manual, but can change his own (to mark them as read)
Well done !

POINT 19
Great, new interface is much more explicit, and help system is great !
=> 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 ?
=> I made a small reorganization of sections, to get a better use of screen space.
=> I made some little "cosmetic" changes to increase understanding of use

POINT 20 (NEW)
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
=> really minor remark, to take into account for future contributions

POINT 21 (NEW)
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)

POINT 22 (NEW)
Notification 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)

POINT 23 (NEW)
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

POINT 24 (NEW)
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 ${}

POINT 25 (NEW)
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).

POINT 26 (NEW)
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.

POINT 27 (NEW)
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

POINT 28 (NEW)
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

POINT 29 (NEW)
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

POINT 30 (NEW)
I don't understand use and interest of _drawLike_xxxx, that has high impact on objectDetail.php
=> Please explain

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_

I integrated you new patch.

Here are few answers and completion remarks

Point 20 : Duplication in lang.xls
I still made few changes.
Please notice that we don't use any more lang.xls file to manage translations.
We have new translation application (lang.projeqtor.org)
But for external contribution, we'll keep the lang.xls way (we plan to build an import from xls file to translation application)
So sending only new lines is a very good thing for us.

Point 21 : Notification System can remind every open Day - week
Great !
This is now a very fluent system.
You'll notice I change few captions to improve readability.

Point 22 : ${} Notification System can remind before hours
Great !

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...

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.

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.

Point 31 : No notification menu if notification system is inactive
Good idea

Point 32 : Force draw Header in tab
Good idea, as fields may 'appear' depending on selection of frequency.

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.

Point 34 : "Notify in advance" and "To notify" - NEW (for confirmation)
If my understanding is correct, the "Notify in advance" concerns the frequency.
It indicates that frequency of recurring notifications will start before the given number of days.
It then seems to be mostly interesting for frequency "each day".
In other cases it seems more complicated. For instance with frequency "each month" we should enter at least "31" to be sure to generate a notification in advance, but possibly smaller values could generate a notification in some cases : if reference date is 2018-02-05 and I send recurring notifications every month on 1st day of month, then "Notify in advance"=5 will generate first notification on 2018-02-01, then we'll have notification at reference date on 2018-02-05 and next on 2018-03-01 (if rule is still true)
(NB : this seems to be confirmed by setting this field to readonly if no frequency is selected)
The "to notify .... days before ... minutes before" will determine, for each notification (including recurring ones depending on frequency) when Notification will be raised on interface, before the calculated notification date. So in previous case, if I set "to notify 3 days before", then notification will appear on interface on 2018-01-29.
(NB : if this is confirmed, possibly attribute readonly for "day" and "minutes" is not correct. "days" should never be readonly, and "minutes" should be readonly if reference date is a date with no time. But bot sould be exclusive : either I notify days before or minutes before but not both (no real interest to notify 1 day and 15 minutes before...).
Can you please confirm my global understanding ? (or explain if I'm wrong)
Can you also precise if "Notify in advance" and "to notify .... days before" are in "days" or "open days" ?
If my understanding is correct , I think I'll change labels to avoid confusion with both notions, and possibly move "notify to" just after reference date.
Also I'll improve attribute readonly for days and minutes.

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"

We now have a great notification system 😉

Here are improvements that we are thinking of, and I included in the roadmap :

1) Add a notification pop-up / combo menu
Clicking the notification icon should show "notifications list" (like message or existing alerts, with title and message, and just button "read the notification")
There should be a "go to notification screen" to go to current notification screen with list and all filtering features (like existing navigation).

2) Change existing Alert system (from indicator) to store notifications instead of alerts.
To see all notification and alerts in a single screen.
Each user should be able to choose to activate this feature or not.

3) Give possibility to define as reciever "all assigned resources"
For objects with $Assignment, it will be ggod to give possibility to send notification to all assigned resources.
It will be very usefull for instance for meetings.

We plan to work on these improvements.
If you plan to work on some, please let us know so that we don't work both on same feature.

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,

Thanks for your last patch.

Also new modules are good ideas.
Pay attention to some local constraints about HR module, possibly storing "personal" data. This could lead to specific declaration (like CNIL in France), and possibly this module should be optional (designed as a plugin) to avoid to have to to bring this constraint to users how won't use the module.