Help with delayed job #58

pconnor opened this Issue Mar 14, 2011 · 8 comments


None yet
5 participants

pconnor commented Mar 14, 2011

Can you please point me to an example of how to implement delayed_job with devise_invitable? I cannot figure out where to call handle_asynchronously :invite!.



scambra commented Mar 15, 2011

I have never used delayed_job. If you want to delay sending email you can override deliver_invitation method in your model with latest rc gem (0.4.rc4)

pconnor commented Mar 15, 2011

Thanks for the advice. delayed_job working perfectly. It seems that after upgrading to 0.4.rc4 invited_by_id is not getting set. Is the behavior for this attribute removed/changed in the new version?


scambra commented Mar 16, 2011

What version were you using before? Have you overrided some methods in InvitationsController or resource model?

It was added in v0.4.rc2 using authenticate_inviter! to set invited_by, and in rc3 it was changed to current_inviter, so authenticate_inviter! is called only once. In rc4 nothing was changed about invited_by association.

pconnor commented Mar 16, 2011

I was using 0.3.6 prior to updating to 0.4.rc4. No custom or extended controllers.

From user model...

devise :invitable, :database_authenticatable, :registerable, :confirmable,
     :recoverable, :rememberable, :trackable, :validatable

If I inspect @current_inviter in the new view, it is nil. Even if I try to set invited_by_id and invited_by_type manually (hidden params in the layout) they are cleared.

Invitations are being sent.

I am sure that I am missing something simple, but cannot see it.


scambra commented Mar 17, 2011

invited_by_id wasn't exist in 0.3.6 so I don't understand your statement about not working after upgrading.

@current_inviter is set when current_inviter method is called, but that method is not called in new action, only in create action multiple times (has_invitations_left? filter, and create method). Don't fill the form and try to submit it, @current_inviter should be set and new view rendered, then you should be able to inspect @current_inviter.

There are tests for invited_by being saved and they are working. I would need a failing test or a simple application to reproduce it, in other case I can't fix it.

@pconnor Where did you put the call finally?

handle_asynchronously :invite!

ZachBeta commented Jan 6, 2014

Solving a similar problem we put the following in our user model

handle_asynchronously :send_devise_notification, :queue => 'devise'

This set all devise notifications to be handled asynchronously. Though it looks like the specific one for an invite may be referenced in this file:
devise_invitable/lib/devise_invitable/model.rb at master · scambra/devise_invitable

mcbsys commented Apr 12, 2014

+1 for handle_asynchronously :send_devise_notification.

@ZachBeta, did you see the comments in the devise source re. delayed queueing? My devise and devise_invitable seem to work fine without all the extra code they suggest (after_commit callback etc.) but it'd be nice to know for sure that handle_asynchronously :send_devise_notification is enough when using delayed_job.

This issue was closed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment