View ProjeQtOr On SourceForge.net
ProjeQtOr - Project Management Tool
Supportez nous sur Capterra
OIN - Open Invention Network
ProjeQtOr free project management software - Notification System - ProjeQtOr

Prochaines sessions de formation

Les prochaines formations et démonstrations sont ouvertes, inscrivez-vous rapidement !

 

Démonstration de ProjeQtOr

(gratuit, sur inscription)

Mardi 23 avril (10h30-12h)

Jeudi 16 mai (16h-17h30)

Jeudi 13 juin (10h30-12h)

 
 

Planifiez avec ProjeQtOr

3 et 4 avril (9h - 12h30)

 
 

Administrez avec ProjeQtOr

10 et 11 avril (9h - 12h30)

 

 

 
 

Notification System

More
18 Déc 2017 19:22 #1 by tabary
Notification System was created by tabary
I built a notification system in Projeqtor whose principle is as follows:

This notification system consists to notify (on the GUI or by email) users according to applicable rules on the elements of the system (ex: Bill) having at least one field of type Date (excluding date of creation) and which is automatically generated from a reference date of the system element.

To define the notifiable elements, it is to create the Notifiable Object Class (NotificationObjectClass)

To set the automatic notification generation rule, create the corresponding definition (notificationDefinition). An automatically generated notification definition is to give:
* The class from which the notifications will be generated (through notificationObjectClass)
* The type of notification (Alert, Warning, Information)
* The title of the notification (which can contain values ​​of the fields of the class and related classes)
* The content of the notification (which may contain values ​​of the fields of the class and related classes)
* The rule that will generate the notification (to be built as a WHERE SQL clause and that can contain values ​​of the class fields and related classes)
* The reference date (one of the dates of the class) which will give the date at which the notification must be generated
* The ability to generate the notification
* every month for the year of the reference date
* every month to a fixed day for the year of the reference date
* every year to the month and day of the reference date
* every year to a fixed month on the day of the reference date
* every year to a fixed month and day (the reference date is no longer required)
* The possibility to choose the receivers of the notification from a list of fields corresponding to the fields linked to the resource table
* The choice to generate a corresponding email

If the notification system is active (it's a global parameter), then :
1. An 'Unread Notifications' pane appears below the menus.
This panel contains the unread notifications intended for the user and represents a tree presenting the notifications
* Level 1: by Type
* Level 2 : by Class
* Level 3 : by Definition
* Level 4 : by the identifier of the element of the class which is at the origin of the notification (by clicking on this element you go directly to the element)

2. An icon at the top right that shows the number of unread notifications and accesses the notifications screen

3. In each detail of the notifiable classes is presented a section of the unread notifications corresponding to the element and to the receiver.

4. An update of unread notifications is made every x hours (x being defined as a global parameter) and modifies the contents of the 'Unread Notifications' panel as well as the counter of the notification icon at the top right of the screen

5. If the Crons are active, a cron generates notifications every x hours (x being defined in the same parameter as before) according to the definitions and values ​​of the impacted elements.

In attachment, you will find the code patch on the revision '4264' and a more complete documentation of this evolution proposal (in french).

Hoping that this work will meet your approval.

Indeed, I intend to implement an 'HR' module (management of absences, competences, meetings of objectives, missions, etc.) which will be based on this notification system (notification of reminder of time recording, reminder of preparation of goal meeting, etc.).
I am also enclosing the Alpha version of the conceptual data model.

In the meantime, happy holidays of the end of the year.
Attachments:

Please Connexion or Create an account to join the conversation.

More
20 Déc 2017 00:24 #2 by tabary
Replied by tabary on topic Notification System
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
Attachments:

Please Connexion or Create an account to join the conversation.

More
21 Déc 2017 09:53 #3 by babynus
Replied by babynus on topic Notification System
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.

Babynus
Administrator of ProjeQtOr web site

Please Connexion or Create an account to join the conversation.

More
22 Déc 2017 12:33 #4 by tabary
Replied by tabary on topic Notification System
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

Please Connexion or Create an account to join the conversation.

More
05 Jan 2018 15:28 #5 by babynus
Replied by babynus on topic Notification System
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

Please Connexion or Create an account to join the conversation.

More
05 Jan 2018 22:25 #6 by tabary
Replied by tabary on topic Notification System
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

Please Connexion or Create an account to join the conversation.

Moderators: babynusprotion
Time to create page: 0.038 seconds

Paramétrages de cookies

×

Cookies fonctionnels

Ce site utilise des cookies pour assurer son bon fonctionnement et ne peuvent pas être désactivés de nos systèmes. Nous ne les utilisons pas à des fins publicitaires. Si ces cookies sont bloqués, certaines parties du site ne pourront pas fonctionner.

Session

Veuillez vous connecter pour voir vos activités!

Autres cookies

Ce site web utilise un certain nombre de cookies pour gérer, par exemple, les sessions utilisateurs.