{"action":"created","issue":{"url":"https://api.github.com/repos/solidusio/solidus/issues/2430","repository_url":"https://api.github.com/repos/solidusio/solidus","labels_url":"https://api.github.com/repos/solidusio/solidus/issues/2430/labels{/name}","comments_url":"https://api.github.com/repos/solidusio/solidus/issues/2430/comments","events_url":"https://api.github.com/repos/solidusio/solidus/issues/2430/events","html_url":"https://github.com/solidusio/solidus/issues/2430","id":279205496,"node_id":"MDU6SXNzdWUyNzkyMDU0OTY=","number":2430,"title":"[RFC] Events in Solidus","user":{"login":"swcraig","id":11495200,"node_id":"MDQ6VXNlcjExNDk1MjAw","avatar_url":"https://avatars3.githubusercontent.com/u/11495200?v=4","gravatar_id":"","url":"https://api.github.com/users/swcraig","html_url":"https://github.com/swcraig","followers_url":"https://api.github.com/users/swcraig/followers","following_url":"https://api.github.com/users/swcraig/following{/other_user}","gists_url":"https://api.github.com/users/swcraig/gists{/gist_id}","starred_url":"https://api.github.com/users/swcraig/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/swcraig/subscriptions","organizations_url":"https://api.github.com/users/swcraig/orgs","repos_url":"https://api.github.com/users/swcraig/repos","events_url":"https://api.github.com/users/swcraig/events{/privacy}","received_events_url":"https://api.github.com/users/swcraig/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":3,"created_at":"2017-12-05T00:49:04Z","updated_at":"2018-11-20T23:21:29Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"@derrickp and I have been working on making user notifications more customizable.\r\n\r\nHistorically, Solidus has handled “transactional” communication to users with email, sent using [ActionMailer](https://github.com/rails/rails/tree/master/actionmailer). “Transactional” emails notify users that:\r\n- Order has been confirmed\r\n- Order has been cancelled\r\n- Shipment has shipped\r\n\r\nAdditionally, in some cases we use email to notify admins that their operations have finished processing, as is the case in reimbursements and order inventory issues. Popular extensions have also used our ActionMailer settings, with [solidus_auth_devise](https://github.com/solidusio/solidus_auth_devise) using ActionMailer to send notifications for password reset or recovery.\r\n\r\nHow stores handle notifications to users is an integral part of the experience to shopping online. As Solidus stores evolved, external notification platforms (SMS, email-templating-as-a-service, A/B testing of email), individual stores have had to implement these alternate notification channels using very intrusive overrides to solidus core. While ActionMailer is the only notification system offered in core, it is not widely used and is often turned off and discarded.\r\n\r\nWe believe that Solidus core needs to support a clear, extendable, configurable system to give stores tighter control over how and when notifications are sent to users. Our goal would be to allow stores to implement whatever notification systems they desire without the need to override core. \r\n\r\nAs almost all large Solidus stores have had to completely re-write or overwrite core to build complex user notifications, it is a long-standing problem in the Spree/Solidus ecosystem.\r\n\r\nThere have already been attempts to make behaviour customizable by adding “hooks” around specific actions. For example:\r\n- [in reimbursements](https://github.com/solidusio/solidus/blob/354eb21a5469cc5487440e978ac780a06f5676cc/core/app/models/spree/reimbursement.rb#L108)\r\n- [in orders](https://github.com/solidusio/solidus/blob/354eb21a5469cc5487440e978ac780a06f5676cc/core/app/models/spree/order.rb#L431)\r\n\r\nThese have been largely unsuccessful as they are obscure, undocumented, and insufficient for most stores needs.\r\n\r\nIn addition to at least [one large-scale attempt](https://github.com/solidusio/solidus/pull/1218) to tackle the problem, we’ve made two large and distinct attempts to achieve the goal of a customizable system:\r\n  - [Command based approach](https://github.com/swcraig/solidus/pull/11)\r\n  - [Observer based approached](https://github.com/swcraig/solidus/pull/9)\r\n\r\nWe don’t believe any of our previous approaches, or any attempt made or pitched to Solidus Core, have gone far enough to solve the problems mentioned above. We need to take a more “radical” approach to solve the problem.\r\n\r\nWe find it impossible to have the discussion on the behavior of when the system should notify users and what should happen without bringing up the concept of “events”. “When a user’s order is shipped, the user should receive an email.” “When an order is cancelled, the user should receive a text message.” The actions we discuss are in response to “events” of the system.\r\n\r\nWe believe the core concept missing in previous attempts at customizing a notification system is that Solidus lacks a common feature in similar-sized systems, that of an “event bus”. We’ve attempted many things to avoid needing an “event bus”, where these notifications can be watched and responded to, but argue it's now time to add an event system to Solidus.\r\n\r\nWe [have a work in progress](https://github.com/solidusio/solidus/pull/2431) that implements an event bus. In addition to what we’re already working on, we want to:\r\n - Represent our events as classes (instead of hash arguments)\r\n - Write the methods used in subscriptions as procs.\r\n - Consider using an existing RubyGem instead of writing our own.\r\n - Use a hierarchy for our event naming so that all ‘order’ events could be subscribed to. This also needs to prevent a custom event being accidentally ‘captured’ by the existing system.\r\n\r\nWe think that this path is the most reasonable way forward and that Solidus needs a system like this to grow. We’re happy to hear from the community about this proposal.\r\n\r\n"},"comment":{"url":"https://api.github.com/repos/solidusio/solidus/issues/comments/440464763","html_url":"https://github.com/solidusio/solidus/issues/2430#issuecomment-440464763","issue_url":"https://api.github.com/repos/solidusio/solidus/issues/2430","id":440464763,"node_id":"MDEyOklzc3VlQ29tbWVudDQ0MDQ2NDc2Mw==","user":{"login":"jacobherrington","id":11466782,"node_id":"MDQ6VXNlcjExNDY2Nzgy","avatar_url":"https://avatars3.githubusercontent.com/u/11466782?v=4","gravatar_id":"","url":"https://api.github.com/users/jacobherrington","html_url":"https://github.com/jacobherrington","followers_url":"https://api.github.com/users/jacobherrington/followers","following_url":"https://api.github.com/users/jacobherrington/following{/other_user}","gists_url":"https://api.github.com/users/jacobherrington/gists{/gist_id}","starred_url":"https://api.github.com/users/jacobherrington/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jacobherrington/subscriptions","organizations_url":"https://api.github.com/users/jacobherrington/orgs","repos_url":"https://api.github.com/users/jacobherrington/repos","events_url":"https://api.github.com/users/jacobherrington/events{/privacy}","received_events_url":"https://api.github.com/users/jacobherrington/received_events","type":"User","site_admin":false},"created_at":"2018-11-20T23:21:29Z","updated_at":"2018-11-20T23:21:29Z","author_association":"CONTRIBUTOR","body":"@kochis #2431 is still being discussed, for sure, if you have ideas you should weigh in there!"}}
{"actor":{"display_login":"jacobherrington"}}