When registering to my website, users have to specify which company or group they are working for and then all the users are placed in one db table called users. I was wondering if it's possible to create a new table for every single company that registers and then put all users from that company to that one specific table while still having a single user model and a single controller.
I think you need multi-tenant application.
Here Each company/group can act as a tenant - all users are members of the tenant.
A simple library for this purpose is Milia
Please check the documentation and use accordingly.
It will save all companies users to the same table - But while retrieving apply the scope to find users of a particular tenant.
You don't need to create a table for each company. You need to create tables called Companies and Users that are in relation with each other. So User belongs_to company. Then when you are creating a user you pass company_id to that user. You can read more about it here: http://guides.rubyonrails.org/association_basics.html
Related
I'm creating a multi tenant app that something like project management software.
In my structure, there is a User table that excluded from multi tenant.
User comes my sign-up page, fills the subdomain field called Company then I create a schema for this user. So, they can access their account as companyname.example.com. Everything is okay so far.
I also have an Account table to store subdomains with a creator user.
Now, I also created a table for Account permissions. This table includes Account_id and user_id. I did something like that because, user could join more than one Company with same email address.
Conclusion;
User table
Account table
Account_permissions (to check when someone try to login to specific company. Because, they have more then one company.)
Does this make sense ? Do you have any idea in this case ?
I have two models one is Resident and other is User.Residents are the people that resides in hostel,they have enrolled manually.And Users that have enrolled using our Application,But all the Residents are manually registered then we seed our database with them,we have stored info about them as long before they have registered in our website.but if they registered we have all info about then just need email more,How could we associate then in Rails.User have permit to all the stuff in our Website.while the Residents can only see it,not edit!
You need to be able to restrict access depending on the type of permissions a person has. I would say the best solution for you is probably to use a Gem that handles this. There are several, CanCan is the one I usually use: https://github.com/ryanb/cancan
With CanCan you have a file called ability where you can segment which types of users have access to specific resources.
My app has Users and it has Chefs. A user can be a chef and a chef can be a user. Chefs have the ability to create meals, and get paid for there meals, users do not have this ability. A user can become a chef if they request and are approved.
The plan is to have one User model with a boolean field for being a chef. If the chef field is true, the chef will have more functionality than the normal user, such as creating a meal and getting paid for the meal. Where I am confused is how I structure the models so that only a chef can create a meal.
Do I create roles? Such as the post below is suggesting, or do I create two separate models one for Chefs and one for Users. My thought is that I have only one model so people do not have to sign up for two different accounts.
Rails model structure for users, or is there another alternative.
Thoughts/Advice?
I'd strongly suggest checking out pundit which will allow you to run permissions based on settings for a given user. For example, if you want to allow a User with a property chef set to true, you could set up your MealPolicy#create to check for user.chef?
In many tutorials (especially for authentication), speakers say to put user authentication and profile information in the same table (model) called User.
My question is simple: Is it safe to put everything in one table? (bonus: is this the best practice?)
I would rather suggest to separate authentication information (email, password, salt,...) and profile information (first name, last name, birth day, location, gender,...) in two models: User (for authentication) and Profile, and linking models by has_one/belongs_to associations.
Am I wrong? What do you suggest me?
Thanks.
If you want to follow database normalisations you should separate the tables. However, sometimes it is not the best option... For example, if your table users has just email, password (for authentication) and name. I won't create a profile table just to store the name, right?
So, it will depend on your requirements to make your design decisions....
I found this interesting post about it, where #D Roddis explain some advantages and disadvantages about three different approaches: Storing User Profile in Users Table, Storing User Profile in User_Profile Table 1-1 relationship to users and Storing User Profile as properties and values in tables.
I hope it helps...
I'd put them in seperate models myself.
How many actions are there which operate on user and profile together? Not many, There are a lot in both constructs where they need to know nothing (or nothing more than the id) about each other.
The problem: client needs a website to serve 10+ customers, each customer has 5-10 people they wish to grant access using login & user name, once "logged in" the user can download files specific to their company.
The files will be uploaded to a directory under the customer name, and displayed as a list. Currently using membership for all of the users, it's just the "by customer" segmentation I'm wondering about. the question being under ASP.NET MVC what is the cleanest or simplest approach to solving the customer segmentation, trying to avoid customer membership provider so was going to use the roles to assign customer group.
Thoughts appreciated.
In the past I tried to avoid the membership and role providers as well since I don't like the way they are implemented. So just use the old school way. Create two tables on your db, one stores the customers the other the users.
Just build a simple relationship like: User n ----- 1 Customer
Now if a user logs in first authenticate him/her against the User table, then authorize on the Customer table.
The provide the right downloads, just create an additional table File, which has a n:1 relationship to the Customer table (like the User table).