Notifications in formulize

Hello,

Notifications are a key feature for a lot of applications, so it would certainly be great to improve it. It does already do a lot more things than regular XOOPS/ImpressCMS notifications does, such as letting you be notified only about entries that meet certain criteria, instead of all entries, and notifications can be sent not just to you, but to people referenced in the entry (in a name list) or the author of the entry, or all users in a certain group (if you have permission to use that feature).

Are there particular use cases that you're thinking of that aren't met right now?

--Julian

Thanks for the comments Steve. :-)

The problem with the built in notifications for XOOPS/ImpressCMS, is they are subscriber based, so users have to sign up for them, you can't enforce subscriptions on them, and they also only get triggered by certain events in the module, there's no default way to add awareness of the content of the thing you're getting a notification about...it's either notify-on-new-posts, or notify-on-updated-posts, but that's as granular as it gets.

At least by default. The notification system does have some API hooks that make it possible to do some more advanced things, which Formulize takes advantage of, like this:

(This is not exactly the flow of the code, this is just basically what happens.)

Notification requests in Formulize get stored in their own data table, since we're tracking more information than normal notifications (such as who the notification should send messages to, ie: user who just submitted the form, user who created entry, user who created the notification, etc...as well as what criteria should be applied to messages, such as fieldX = blah, etc.)

When a possible notifiable event in Formulize happens (new entry, updated entry or deleted entry), then the sendNofitifications function gets called (it's in the include/functions.php file).

That function retrieves all the defined Formulize notifications anyone has made on the form.

It makes a list of all possible users who have permission to see the entry that just got added/updated/deleted.

It checks to see if the entry meets any criteria specified, for each notification that's been defined.

If the entry meets the criteria, then it checks, for each notification, to see if there's an overlap between the users that are supposed to be notified, and the users who have permission to see the entry.

Then for any users that actually match, it then calls the notification API and subscribes any users that should be subscribed but aren't. See, there are only three notification events declared to the core in the Formulize module (in the xoops_version.php file: new, update and delete. So those are the only events that can actually be triggered in the core. But if a notification in Formulize says "send a notification to the user who created the entry, when the entry is updated and valueX is greater than 6" then we can't have that user always subscribed to the notification, otherwise they'd be notified every time the entry is updated. So we have to do the checking above that Formulize does, and then subscribe the user to the update notification ourselves, only when we're sure they should be notified. All these subscriptions are made so they are send-once-and-then-delete (the people who made the API were thinking ahead...but the default implementation is very simple, that's all).

Then the "trigger notifications" part of the API is called, so the core sends all the notification messages in the normal way.

The big architectural problem with the notifications, is they are not handled by a separate thread. In Drupal the cron.php file take care of all these kind of things, and there are other ways to hand off processing of this task to a separate thread, so the user doesn't have to wait for all the messages to be sent before the page loads. That's something we can live with for the time being though.

That's about it. The tricky parts of this process in Formulize are determining who the user is who should be notified, when the specified user is highly dynamic (such as notify-the-user-who's-name-appears-in-box X-in-the-form). Many hoops to go through there. But in the end, it allows for lots of flexibility.

If users have setup a normal kind of notification, ie: notify me of all new entries, then we setup and leave a notification subscription in the core for that user. So those notification do show up if they go to the user profile page and then click the notifications button, and they can be turned off there too. But more advanced notifications don't show up there.

Last thing...there's a permission that has to be set per-form before users in a group can create notifications that affect other people besides themselves... set_notifications_for_others or something like that. So normal users can't start wreaking havoc with this system.

And to answer your last question...you cannot subscribe to notification in Formulize using the standard UI that normally appears the bottom of the page (although certain basic formulize notifications will appear in the list of your active notifications in your profile). The basic UI never appears on Formulize pages. But as the above description says, we handle notifications using the core API, we just have to interact with it differently. You can effectively deactivate notifications in Formulize entirely using the module preferences, just like any other module, because at the end of the day, it is the core system that is used to send the notifications.

--Julian

We should probably check for the module preferences before offering the notifications button to users. :-) That would be a simple IF condition to add in the entriesdisplay.php file at the point where the button code is drawn...there's one function that creates all the HTML for all the buttons, if anyone's interested....

As you found out, since the core notification system is involved, nothing actually happens if you have the module prefs set to "notifications off".

--Julian