Welcome to the Treehouse Community
Want to collaborate on code errors? Have bugs you need feedback on? Looking for an extra set of eyes on your latest project? Get support with fellow developers, designers, and programmers of all backgrounds and skill levels here with the Treehouse Community! While you're at it, check out some resources Treehouse students have shared here.
Looking to learn something new?
Treehouse offers a seven day free trial for new students. Get access to thousands of hours of content and join thousands of Treehouse students and alumni in the community today.
Start your free trialdavidalvarado
7,544 PointsTaking Treebook up a notch help me get this right
So I'm thinking how do design this app that would take the simple Treebook app with status feed and expand on it. If you had 3 different types of users, that had nothing similar other than and email and username, how would you best approach this? One Devise User model for authentication and then 3 different user account model types? or 3 different Devise models.
Also, one thing I don't think we covered is how to avoid a logged in User being able to edit or add a status update. Say each user has a profile page, all Devise does is ensure that a user is logged in, not that the logged in user is the actual owner of the profile.
Thoughts?
3 Answers
David Moore
13,916 PointsYou could use Pundit for user types on a single Devise user model.
As for updates, I have not been through the whole Treebook series but I would assume the status update is scoped to the user who created it. You are correct that Devise itself does not do that but a has many/belongs to relationship between the user model and status_update model is what will create this functionality. I.E the user has_many status_updates and the status_update belongs_to a user.
http://guides.rubyonrails.org/association_basics.html for additional info on how to set the relationship if needed.
davidalvarado
7,544 PointsHmm well I've looked at Pundit and CanCan but they seem to deal more with user roles than actual different user types, they deal more with like Admin, Author, Guest, etc... I have 3 models that are completely different users like Banker, Policeman, Army Guy that all have different requirements and data that need to interact with each other. I get the association part but I'm having trouble getting my head around the part that say Banker has_many Accounts and architecting how Banker A, wont be able to go in and see, edit, update, destroy, registered Banker B's info.
David Moore
13,916 PointsWell, as for the users, I guess it really depends on if you want/need to bust them out into their own authentication models. I would still think you would have a base user and then use Pundit and subclasses to add on whatever additional resources are required for the user type.
As for the resources, you need to access and edit via the user who owns the resource, for example:
def new
@account = Account.new
end
def create
@user = User.find_by( id: params[:user_id] )
@account = @user.account.create( params[:account] )
end
Hope that helps!