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…
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
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
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,
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…
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
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.
So your account is the decorator for the user. Got it.
Glad you solved your problem.