Managing newnesses
When working in group, it's important to be notified of changes that others do and we are interested on. When working with a lot of data, it's also important not to be disturbed by notifications referencing objects we are not interested on. In KMKey, we name that logic newnesses management.
Nowadays, KMKey 3 trunk has a simple notifications framework, that send notifications to users in certain prefixed events (currently, only the ISO 9001/2000 document edition workflow). Users can choose to receive this notifications by mail, by a message in the KMKey GUI "you have X new messages"), or both. Currently, a notification contains a subject, a text body, a read flag and a path to visit the newness
Doing some more work, this way of work could be used to implement a good newnesses management system. Allowing users to subscribe to some events in different levels of the tree application -> projects -> tasks -> subtasks, everybody could be notified of wanted changes, and this could be done by e-mail or GUI. An example of subscribable events could be:
* comment_added
* comment_modified
* work_added
* work_modified
* email_sended
* email_received
* document_added
* document_modified
The system administrator should be able to set this events at application level, but each user should be able to change system default settings. The same way, this preferences could be overritted in some projects, and event in some tasks or subtasks of this project. So, the granulity of the system will allow each one to be notified just for really interesting things
To allow the system to graphically show objects containing a newness, we are planning to do the following:
* Create a path index for the related_path and a field index for the read attribute
* For each notification, store a KMKey Notification object in the member area if the user has choosed to be notified by GUI, and mark it as unread
* Detect if an object has newness by a search in the catalog. Search for KMKey Notification objects with container_path in the member area, without flag read, and with related_path under the current object. If something found, then object contains newness and could be graphically market (using bold, for instance)
* Mark notifications as read when the notification is clicked in the notifications page (this will redirect to the related path), but NOT when visiting directly the new or changed related object
All the previous paragraph describe a complex solution just to mark the title of a project or a task as bold. If a message in the header saying "you have X newness", plus a page to view the detail of them, it's enough to allow the user work fine, I really will encourage the team not to implement the "bold" feature on each object.
Anyway, this will create a great number of notification objects in members areas. So we should take some measures:
* Periodically purgue already read notification objects
* Notify asyncronously, probably using ZAsync. This will include send mails and create notification objects