Document alternative to Notifications integration

Ughhhhh, I don't know if I can stand to look at rewriting Notifications integration again for a long time. I spent an entire 50-hour week reverse-engineering the module to write FBSS Notifications.

Heh, alright, thanks. :-P Good to know about this at least. One of these days I'll have to clean out the queue and I'll take a look.

I'm not going to get to Notifications 4.x integration for the 6.x-3.x branch, but I'll look at it for 7.x-1.x or 7.x-2.x.

I am tempted to do the same thing we did with Activity and just mark the Notifications submodule as only compatible with D6 for now. Notifications for D7 has been completely rewritten from scratch, and although some of the same concepts are there, there is no documentation, so it will have to be completely reverse-engineered again.

Why not add just email integration (directly without notification) to fbss. That would perhaps takes care of 70-80% of users. And they won't need to install another heavier framework.

Email is complicated, that's why heavy frameworks exist. Yes it could be made simpler but writing email integration for Statuses would require writing an email framework that would duplicate a lot of existing code. And I have very little interest in maintaining it because I wouldn't personally use it and it's hard to test and debug. (It's also not much fun to write.) It might be easier than Notifications integration though.

Not saying it won't happen, but if it does it likely won't be part of Statuses core.

I am wondering why it is complicated or you have a different use case in mind?

One the of use case for this module is, as a replacement of guestbook module. And in the guestbook, it is a simple call to send email without anything complicated. It works for most of the users. Can we have something similar? You comment on someone's status (or write on his wall) you get email with a link to the wall.

Why that simple use case and implementation won't work here?

The main thing is it's feature creep. People want to customize the email, then people want HTML email, email sent for different events, different ways to subscribe/unsubscribe, integration/synchronization with other email solutions... the best option for Statuses and maintainability is to not implement a custom solution for a problem that is not related to the main purpose of the module.

ok.I get it. If possible, would you please suggest a suitable place where I can add just send plain email (like guestbook)? That way people like me who want to a simple way can quickly add something without burdening you with future support requests. Guestbook does not have anything fancy now (other than plain text email) so users won't complain.

Normally Rules is the preferred solution for this. The main downside is that users can't choose whether to turn it on or off. However you may be able to add a Profile field or something that Rules can detect in a condition to tell it whether or not to execute the rule.

thanks.

This issue should remain active until the maintainers decide whether Notifications will be supported, and either fix the integration or remove it.

As a stopgap measure until the Notifications integration is shored up, I added the recipient's email to the list of available tokens. This should be enough to get the Rules integration working the way I need it to (send email to recipient when they get a status update). Maybe others will find this useful in the meantime as well.

PS: Since this is not directly related to Notifications integration, let me know if you'd like me to open a separate issue for this.

Please keep each issue to one topic.

Obsolutely you can create a new issue for this, however there is no need of another token here. Before sending the mail, load the recipient and use the values which is available in the new variable to send the mails or to do other things.

Through the direct input method? Recipient isn't available there. Can you explain what you mean?

Either way, seems a lot easier just to have a token for email, same as there's a token for name, link, id …

You can add an action in your rule to load a user object based on another token like the recipient ID. That will give you access to the user's email. However you need to also add a condition to make sure the recipient is a user first.

It doesn't make sense to add an email field to contexts because only the user context would have an email address and if you know you're working with users you can just use $recipient->mail directly.

Okay here is my decision about Notifications integration:

I don't want to write Notifications integration for Statuses again. It's too hard and takes too much time, given the fact that it's been completely rewritten, there is no documentation, and it appears to not be actively developed (but even so it is a moving target because there is no full stable release so the API could still change). It took me a solid 30+ hours to write Notifications integration last time (not including writing the documentation for it) and it is still pretty buggy. None of us have 3-4 solid days to dedicate to this (even though it would probably take a little less time now since we're not starting completely from scratch). Given that, let's do the same thing we did with Activity and just set the Notifications submodule to be D6-compatible only.

However, we should figure out exactly what the recommended alternative is and document it. That may mean providing exported rules (although my experience is that this can be painful as Rules changes over time, though maybe less painful than having requests for explanations from scratch coming up in the queue repeatedly) or maybe even a Feature module or something. That may also mean writing new code. Here is a rough outline of what I think we should recommend:

• Create a Rule to send an email to the recipients of status messages.
  • The event should be adding a new status.
  • Add a condition to check that the recipient is a user.
  • Add an action to load a user from the recipient ID.
  • Add an action to send the recipient an email.
• Create a Rule to send an email to the sender of a status when someone comments on it.
  • The event should be adding a new comment on a status.
  • I think it is probably necessary to load the status object to get access to the sender's email address.
  • Send an email to the status sender.
• Create a Rule to send an email to people who have commented on a status.
  • The event should be adding a new comment on a status.
  • Create a loop that iterates over all the people who commented on the status. (This probably isn't possible right now without extra code -- I mean, doing loops in Rules is now possible, but getting a list of unique commenters not including the current user or status recipient or status sender probably isn't.)
  • Inside the loop, send an email to each commenter.
• Allow people to opt in/out globally. This probably involves adding some sort of profile field as a checkbox for each kind of notification, and then checking for the value of that field for the current user in a Rule condition.
• Allow people to opt in/out per message. This probably involves adding a Flag on statuses (and possibly triggering it as soon as a status is saved) that would need to be checked in a Rule condition.

Clearly there's a lot going on here, but I like this solution better than dealing with Notifications integration again. We don't have to make 100% of it work for me to be satisfied. The first step, short-term, is to just disable the Notifications submodule, and we can move forward from there.

Committed a change to disable the Notifications submodule.

Hi IceCreamYou,

I agree with you that Rules should be sufficient for notifications (with the exception of alerting all users of a new comment on a status that they have commented on).

In Drupal 6, I had successfully created a couple of rules to send emails out to users when they received a message on their wall or a comment on their statuses.

I have tried to create the same rules in Drupal 7 but it looks like it is no longer possible to create a 'Load User' action which is necessary to load the recipient's email address. Is there another way to do this?

Thanks for your help and for the new Drupal 7 Status module. It's working well on my website.

I think we can provide some default rules for notifying the users, that will help others to build their own rules or modify it according to their needs.

Addressing #20 in #1693620: Problems with Token integration with Rules

Marked #1761172: Fatal Error when select "Status Subscriptions" and #1761162: Fatal Error when selecting "Status threads" as duplicate of this issue.

The issue mentioned in #22 has been fixed. Can we close this issue or provide some default rules.

This issue is about documenting the process described in #18. We may need to create example Rules as part of that, but the solution to this issue mainly involves creating a page in the documentation.