You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 21, 2022. It is now read-only.
I was curious if you had any pointers on how you were thinking of approaching this? I have a need to send users email on creation of "any specified model"...so not necessarily user User creation. For my needs (at least now), it is just model instance creation that would need to trigger email, so post_save is the only signal I'd need to support. I do need to have the admin interface allow the admin to choose the model that would trigger the drip. So one drip might be associated with the creation of new Articles while another might be associated with the creation of new BlogPosts.
For my current needs, adding a ForeignKey to a ContentType into the Drip model, a post_save signal handler connection, and the signal handler itself seem sufficient to accomplish what I'm looking for, but far less ambitious than what seems to be envisioned for this issue...so I was wondering what thoughts you might have already had on how to add general "trigger on signal" support? Essentially I'm wondering if I can fit my needs into the approach you may have been thinking of taking, and thus try to feed back work I do for my project into building out this feature.
For reference, this: caktus@1d0c9e4 accomplishes what I need in terms of signal triggers. But it's seems more limited than what's envisioned here so I'm not sure how well it would fit in with the overall direction you were thinking of taking for this feature?
Ideally drip would maintain a list of available signals (though it is likely post_save would be the most common). There would be a new model called Trigger that would represent both querysets (like we do already) but also let you register to signals (and the sender Model for post_save) as well. Drip would connect to that signal, and each time it receives the signal it would do a query to see if there are any drips to be sent.
The problem with this is it is done inline with the signal, meaning it is rather expensive. Much better would be a task that gets dumped into a queue. This is all a rather complicated process TBH, not sure if it is worth it...
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Might be cool to trigger off of any registered Django signal like User created, updated, deleted, etc...
The text was updated successfully, but these errors were encountered: