I am working on a job portal. I am confused on how I should create and manage users. For example: there will be 3 types of users(which may expand later) in my application: Company, Consultancy, and Candidates. Each of them will have a completely different role and access to the admin(i.e. account) panel/console, or you can say they will have a completely different views for managing their account. So, if a user logs in with a company account, he/she should be able to create jobs and update company profile, if a user logs in as a consultant then he/ she should be able post jobs on behalf of other companies(who may or may not be registered on the website/app) and should also be to surf/ search the jobs from companies and should be able to post applications(i.e. apply for a job) of candidates on candidates(who may or may not be registered yet on the website/app) behalf. And, if a user logs in as a candidate then he/she should be able to create their resumes/ cvs, search jobs, and apply for jobs posted by companies.
Here is what I'd thought: Create a User model and then have STI(Single table inheritance) for Company, Consultancy, and Candidate. But, STI gets complicated sooner than later. Later, I thought of creating different models for each, but then code will be repeated for login/ signups and other similar activities, which means no DRY.
I would like to follow the best approach possible. So, would like to know how experts will go about solving such a scenario? Thanks.
Some suggestions:
Look at the CanCan gem for user roles.
Look at devise for a login system where you can login users.
You can use active admin gem to create an administration backend ( crud, create remove update delete ) users. Or build an admin backend yourself
Also checkout railscasts.com ( theres a cast on cancan and devise also!) for general ruby on rails tips and tricks. http://railscasts.com/episodes/192-authorization-with-cancan
Checkout "micheal hartl ruby on rails course " for some general understanding of how models, controllers and views all relate to each other.
Related
I'm trying to create a SAAS e-commerce tool with a backend for staff that also allows customers to have accounts and checkout on the front end. I'm struggling with how to design this so that the Company, Account Owners, Staff, and Customers are all siloed off to each Company, while also having the appropriate restrictions based on their roles.
From what I've read so far most of the rails solutions use multi-tenant patterns with subdomains, such as the Apartment gem, to silo off accounts. But it seems simpler to just have your site use one big app and database. For instance Basecamp recently switched to this approach with Basecamp3. Newer apps seem to be built this way.
And, should the admin features and the customer accounts / front end shop be separate apps completely, or can you do this with a "majestic monolith"? One big app and database, while large, seems more straight forward to me.
I found this blog post that explains how to do something like this with Pundit, but I'm still having trouble groking the big picture of how this could work with Account Owners, Staff, and Customers all in the same app.
Here are the basic needs for my app:
User Roles
Account Owner (creates the company's account and has full access to their company's data)
Staff (invited to join a company and doesn't have access to some of the company's data, such as billing information)
Customer (can sign up for the site and view products, add the them to cart, but can't access any of the staff or account owner features.)
All Users (no matter the role) belong to a Company and can't access another company's data. (Thus providing the the ability to run separate stores on the same app, which is needed to run this as a SAAS app.)
Account Owners and Staff can CRUD Products, but not Customers.
A great analogy would be how Shopify's admin area and customer accounts currently work for shop owners, but unlike Shopify, it doesn't require using subdomains.
Potential Models and Associations
Company
has_many :users, dependent: :destroy
has_many :products, dependent: :destroy
User
belongs_to :company
Product
belongs_to :company
Authorization
Would it work to use Pundit to restrict the controller actions based on User roles and then ensure that data is siloed off via the Model associations?
Signup Flow
I'm a little fuzzy on how to handle scoping the different User roles and where the "staff invites" and "customer" sign up could fit into a sign up flow.
Would this approach work?
Create separate controllers for "Account Owner Signup," "Staff Signup," "Customer Signup," and then embed my signup form into those views. (Using Clearance for authentication and would like to keep that if possible, but just augment it as needed).
Account Owner Signup: So if a someone signs up through the New Account Signup controller (with embedded authentication form) they would also create a Company.
Staff Invite: The Account Owner can create new Staff Users by inputing a Name and Email address. This creates a new User with the role of "Staff" (and thus cannot become Account Owners on another account). The new "Staff" user is sent an invite email that is basically password reset email inviting them to accept the invitation by creating a password.
Customer Signup: If someone signs up through the "Customer Signup" controller, they would automatically be given the user role "customer". Not sure how to set the Company ID in this case. (Pass the company_id as a hidden input on the customer sign up form?)
Is there a better way to design this type of app that I'm missing? Am I on the right track? I have no experience building something like this so any clues would be extremely helpful.
It seems like newer apps follow this type of pattern for multi-tenancy rather than subdomains.
You open with simple e-commerce site but the questions you're asking indicate that you're looking for something that's a little more complex :) You're on the right track.
The acts_as_tenant gem is worth a look. We use this now and it helps make sure your queries are all scoped appropriately.
I would also look at & evaluate rolify if you need to do roles (but don't rule out a boolean flag on your user as well).
I wouldn't rule out devise, but clearance is quite popular.
Using a subdomain might be unrealized work depending on the amount of effort, unless you need to actually use subdomains for vanity purposes (my.example.com vs example.com/my), you can do multi-tenancy without it.
I would consider separate controllers & namespacing for the different roles if their access varies wildly; you can also combine them into singular controllers using Pundit (but this could be unwieldy). You'll still want to use Pundit, however, Pundit can do things like scope the records a user should see.
You're on the right track and asking the right questions but the answers to all of these will depend on other questions (that you probably can't even answer right now).
I have a project where I'm doing what you noted (pundit to restrict data, acts_as_tenant to silo things) but as it develops certain patterns emerge that lead me down a different path. Namespacing admin, rather than doing admin checks inside the same controller for example; because if you re-write to an API you end up trying to make the same endpoint do different things and it's much cleaner to separate out the 2 endpoints behind a namespace & document the actual behavior in my opinion.
I am developing a job portal website as part of a project for university and not exactly sure how to approach this problem, I am using Devise for my authentication system allowing users to sign, The system will have many user_types (job_seeker, company).
At the moment I am using “Rails_admin” for the admin interface, but I am looking to create an interface where a company can manage their jobs, applications, etc, and for job_seekers to view their previous job applications, and job status etc.
My plan was to develop it so in the controller it checked the user_type and then redirected it to a control panel, which would hopefully allow all users go sign in using one login page, but my question is, how do I go about developing a “job_seeker” and “Company” control panels where they can manage their details.
I am looking for information on how to approach this problem, or the best method to achieve a solution.
Did you try using a gem that allow you or simplified role user management like cancan?
A good approach is as Maxence said, have a namespace for every role and a dashboard controller to show what you need. This will help you to keep things spited and will be more easy to maintenance. You can check it here how use namespaces. You can do it as well with a resource but I dont like it.
Other thing that you can do is having a single dashboard controller and redirect depending of the user role.
I have been following 2 separate tutorials to build a rails 3 app each of which covers modelling users. however they don't cover segregating users into groups. specifically im trying to create a users model where one group of users (consumers) would be limited to browsing, making purchases updating their own accounts when logged in, and a 2nd group (admins) would be able to add and maintain products and update their own accounts and possibly create other accounts to manage their products. any assistance on how to pull this off would be much appreciated.
This sort of thing is called roles (admins, consumers) and authorization (purchasing, updating). Gems are available which can help you with both.
I use CanCan for the authorization and make my own roles table. I'd recommend looking at Rubytoolbox to find out what your options are: https://www.ruby-toolbox.com/categories/rails_authorization
I have a web app that will have 4 different users on it:
Owner Admin (My Team and I)
Common User of the App (the everyday people using the site
Company Admins (The people who pay the bills)
Company Users
Of these the last 3 will require profiles and other controller and Model relations.
My question is do I create separate controllers for each of these users and have them link through their current devise ID to their individual profile, or should I edit the devise DB tables to accommodate for profiles and different levels of access?
Cheers,
Andrew
Mostly depends on what you want. I prefer to use a single table for all user types.
should I edit the devise DB tables to accommodate for profiles and different levels of access?
Again depends on what you want since there are many ways to provide different levels of access.
Edit user table (ie. roll your own solution on top of devise)
use authorization gem (eg. cancan)
Therefore no hard answers.
I am working on an app right now where I have Individuals, Athletes and Coaches. A coach has many athletes and they create athletes as well. Whereas individuals can just come to the site and use a different set of tools. So for functionality and logic reasons I prefer to keep the individual model separate from the athlete model.
When users come to the site I want them to login but it would be confusing to have 3 logins (coach, individual and athlete). Users coming to the site will get confused whether or not they are an individual or an athlete. I was thinking of putting a login link which would have an ajax menu with all three choices, which will look nicer but I still have the multiple login issue.
Does anyone have an idea on how I can make ideally 1 login form for individuals and athletes. I am using authlogic for authentication. I am not looking for code, I can go in and mess around, just wondering if there is a trick to this (making it easier for the user).
Thanks!
You might want to look at the devise gem (http://github.com/plataformatec/devise), this supports using multiple models for authentication.
Why not have the Individual, Athlete and Coach models be subclasses of your User model.
Then you can put all the authentication guff into User and it's available to all three - all through the same login form.
You want to assign Roles to Users. You don't need separate subclasses for each user type, model it so a user has_many :roles.
Have a look at this blog post for a detailed explanation - roles can be very simple if this is all you need.