Ruby on Rails

On Jul 1, 2011, at 8:43 AM, Jatin kumar wrote:

You can make your own controller to inherit from Devise_Invitable main controller in your rails app, and then override the methods defined in Devise_invitable as per your needs.
Also change the routes too, if needed.
Or, you can come up with your Invitations controller, use ActionMailer and Devise and a bit of Rails, to get you going.
That is what I did, and I suggest you do the same.
IMO, pick a gem if it suits your needs, but if you have to change a lot of things the gem does, make your own or look for an alternative.

You're absolutely right on both counts. A bit more reading in the Invitable Wiki and I was able to add this:

class Users::InvitationsController < Devise::InvitationsController
 def new
   if cannot?( :invite, User )
     raise CanCan::AccessDenied
   else
     build_resource
     resource.practice_id = current_practice_id
     render_with_scope :new
   end
 end
 def create
   if cannot?( :invite, User )
     raise CanCan::AccessDenied
   else
     super
   end
 end
end

Walter

On Fri, Jul 1, 2011 at 5:20 PM, Walter Lee Davis <waltd@wdstudio.com> wrote:

On Jun 30, 2011, at 10:10 PM, Andrew Skegg wrote:

I may have misunderstood your question, but I don't see the need to access or
change Devise's controllers directly.  You have control over your User model
and the Controllers which utilise it, so you should be able to enforce your
business logic as described.  I would not worry too much about the methods
Devise injects into your models - you control access to them.

Here's the thing. I can certainly keep users from seeing links to the routes that control invitations, but I don't have any practical way to enforce -- at the model level or in the controller -- the user types that are really allowed to use those. It is trivial to wrap the view layer in can? conditionals, in other words. But nothing stops someone who guesses the path from writing a URL and performing an operation their user level doesn't permit.

Because Devise Invitable internals handle the resolution of new_user_invitation_path, I can't put anything in the UsersController to belt-and-suspenders check to see if the current user *should* actually be there. Those requests simply side-step my controller altogether, and point to an Invitations model that is also inside the gem.

Walter


--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.



--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group.
To post to this group, send email to rubyonrails-talk@googlegroups.com.
To unsubscribe from this group, send email to rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/rubyonrails-talk?hl=en.