← Back to Upcase

Thoughts on polymorphic users and current_user


(David Barkley) #1

I’ve implement polymorphic users in an app I’m developing. To avoid clunky method chains when accessing the associated object (in my case an account) I’m using a helper method…

def current_account
  current_user.account
end

So that I can call current_account.foo rather than current_user.account.foo. This has served the purpose so far but for some reason it doesn’t feel right to me.

Besides authorization, I imagine that 9 times out of 10 the behaviour I want on current_user will be implemented by the account object, but the behaviour is only on Account because of the polymorphic implementation, it’s really extending the behaviour of User.

I’d maybe feel a bit more comfortable if the models that a polymorphic user comprised of were called something like Identity(for the auth) and User(for the behaviour) rather than user and account, but I’m using the conveniences of Clearance rather than rolling my own.

Another option I can see is to pass in the Account object into Clearance’s sign in helper, and delegate the methods that clearance requires of User.

I just wanted to throw this out there to gain some other perspectives and opinions, and to see if anybody has resolved a similar issue. That is of course if it is an issue, I could have just become fixated on something that really shouldn’t be of concern.

Looking forward to hearing some thoughts,

David


(Luís Ferreira) #2

Have you tried STI on the user? Maybe your problem is solved by having different classes for each type of user, instead of an account.

Inheritance is not a good first approach, IMO, but if everything else fails…

It’s hard to be more precise without knowing your use case, but you can also delegate stuff from the user the account, and always go through the user.

You can also add a decorator for the user, that knows the user and the account, and interacts with both…


(David Barkley) #3

Thanks for the input. I had considered STI and whilst it would be an option for the very early stages of development I didn’t want to start down that road knowing that I’m going to end up splitting the table later anyway.

Delegating from the user to the account, I’d also thought about but thought with different associations on each account type that it would involve alot of allow_nil: true which would lead to alot of nils floating around, never a good thing.

Decorators - I feel like the account is already just decorating the user really. I think my issue was really with the naming of the objects and that I’ve just got to get over it. I’ve actually overridden current_user in ApplicationController now to return clearance_session.current_user.account. I had initially thought that overridding current_user like that could have caused some problems for clearance but digging deeper it seems like clearance only relies on the session method.

Thanks again,

David


(Luís Ferreira) #4

So your account is the decorator for the user. Got it.

Glad you solved your problem. :wink: