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.