I know a lot of startups and tech companies essentially allow you to register, and you end up registering a company and your user.
An example would be basecamp for example. I'd like to achieve the same thing, however I'm not quite certain on how they do it, and what the best way to do it is.
My thought is to have a user and company model, where on registration you register a company, and it accepts nested attributes for user. As in my head at least the relation is:
User belongs_to :company
Company has_many :users
and the registration is a Company#new with a company.user.build.
However for some reason this does feel a bit strange, as to me it would make more sense that you register a user, and create the company it belongs to.
I just want to lay the foundation right, so I don't start building anything massive on top of a system that isn't good.
More info:
The purpose is to make the person that registers itself and the company an admin, and only allow new users to be a part of a company by being invited by an admin. Everything that goes on within the project is company based only for those within the company. You can also group users that belongs to the company, and create segments or say departments of the company. Beside that the company has no function other that being the connector between all the users that belong to the same company.
Related
I am currently trying to create a system which allows for specific users to create a Course record which can be enrolled in by many other users. I've tried a few association techniques such as has_and_belong_to_many, has_many :through and number of other setups but have been unable to get it right.
Basically all that I need is the following:
Course belongs to (is created by) a single User (foreign_id => admin_id).
Course has many enrolled Users (Join Table?).
User has many created Courses.
User can belong to many Courses.
If you have any idea how this would be accomplished I would greatly appreciate your input.
A pretty good design is Canvas LMS.
In short:
A User is just a user.
A Course is just a course.
An Enrollment is an association between a user and a course. An enrollment has a type, which is either a student, a teacher, a TA or an observer. Each type has its own set of permissions.
So, if a user is not in any course, he/she is nothing but a user. A user can at the same time be a teacher in course A and a student in course B. Also, he/she can be both a student and a TA in the same course.
You can add your own enrollment types in your application, such as creator.
I am designing a multi-tenant app. A business rule requires a user to belong to many accounts (and accounts to have many users). To facilitate the join, there will be a has_many :through relationship between Accounts and Users with the accounts_users model holding additional information such as last_logged_in, is_active, is_guest, etc. The user will be authenticated against the usual email/pw located in the users table. For every record (i.e. a post, task, etc.) created in the db, the creator's user_id and account_id will be attached to it.
So, my question is: which user_id should the current_user be associated with - the one from the user's table (user_id) or the one from the accounts_users' table (accounts_users_id)?
Thoughts: it seems using the accounts_users_id would add an extra layer of security since it would be unique to the user for the particular account they are logged into.
Any additional thoughts/insight/experience would be appreciated!
I have been trying different techniques while designing this application, which to me is very complicated as there are many solutions to chose from. Deciding which of these solutions is the best has become my full time job for the last few weeks.
Background:
I have a User model which contains some very basic authentication functionality. The application will have three different types of users; admins, buyers, and sellers. The user type will be determined during sign up, where a check box will ask if the user is a seller. If the box is checked, the user is a seller, and if the box is unchecked, it's assumed their just a buyer. I would rather not have a drop down menu to select the user type (Buyer, Seller). Easy so far.
Details:
Sellers have a profile, and users who visit the site will be able to browse through the different sellers and view their profile. Buyers do not have a profile, and should not be listed on the site for users to see. If that's not complicated enough, buyers should have the option to change their account type and become a seller. Similarly, sellers can change their account type and "deactivate" their seller account, removing them from the list of sellers.
Design options:
Single table inheritance:
What I came up with when attempting to implement this using STI was suboptimal. I was faced with two options: a messy controller, which made the decision of what type of user to create based on the check box mentioned above (one controller - UsersController), or two different sign up forms that were identical (two controllers - BuyersController, SellersController).
has_one or "has_none" Profile association:
class User < ActiveRecord::Base
has_one :profile # only if the user_type or role is "seller"
end
class Profile < ActiveRecord::Base
belongs_to :user
end
Here I would use something like CanCan or declarative_authorization, and let the user chose his/her role via the check box mentioned above. This introduces a security risk, as there will be an admin role and I don't want this to be open for mass assignment.
I guess either way you look at it I'll have a messy controller with conditionals on how to create the user. Unless I choose to have two check boxes ("I am a seller," and "I am a buyer"), but this seems redundant. It also seems as though whichever design I choose, I'll be faced with some hackish solutions.
Maybe introduce some model that lies between the User and user type?
Any opinions?
I don't really think you need either STI or Polymorphism. A single user model should suffice. I would add three methods to your user model (administrator?, buyer?, seller?) and also add scopes that will return only buyers, only sellers, or only admins.
In your case, it sounds like you have a real minimal number of roles for users (2 now, expanding to 3 with admins). I would probably use the technique Ryan discusses in the "Embedded Associations" Railscast.
I've done something very similar in my latest project, and then used CanCan (in my case, the 2.0 alpha branch, as I find it simpler) on top of that. Your ability class would look something like this (in 2.0 syntax, but you can do the same with 1.x, I'm sure)
class Ability
include CanCan::Ability
def initialize(user)
if user.seller?
can :create, :profile
else
...
end
end
end
So far it sounds like you have a flag that indicates their user type, or a column with type string, etc.
You haven't indicated any behavior that depends on this--not showing up in listings etc. can be handled with scopes. Admin can be handled with a flag.
I don't see the problem yet, at least not a problem of a few weeks scope.
A 3rd option.
...buyers should have the option to change their account type and become
a seller. Similarly, sellers can change their account type and
"deactivate" their seller account, removing them from the list of
sellers.
Have you considered not allowing switching of accounts? If a buyer wants to become a seller, then they create a new "seller" account. It would work the same for seller to buyer. It would mean having 2 controllers for the signup, etc. but it would keep the separation you're looking for. If the two must be mutually exclusive you could do a rudimentary email check to verify the user doesn't already have an account and if they do, they must de-activate the existing account prior to creating a new one.
Using Rails and am new to it (and RDBMs). Have read lots of posts and articles on modeling and associations, but could really use a reality check on what I'm thinking for my particular case.
I have 3 main models: users, accounts, plans. The accounts are multi-user, with plans worked on by all users attached to the account (with varying privileges). If the account is destroyed I’ll also take down its users and plans.
Looks like the basic associations would be as follows. Is this correct?
users
belongs to - >
< - has many
accounts
has many ->
<- belongs to
plans
Is there any value in associating users with plans with “has many through”? I see that it would allow access like #user.plans and #plan.user[1], but can’t I access each via accounts, as in #user.account.plan?
Is it the case that with “has many through” the middle model simply belongs to the other two? All the examples I’ve seen show that. In my case, that would be inappropriate, since account actually owns the other two.
Is there a better way to model this (multiple users of an organization working on a set of one or more plans)?
Input is very much appreciated.
Your design is correct. The belongs_to terminology can indeed be a bit strange, but is proper. Use "has many through" if it makes your code more readable and obvious. (In other words, if the notion of a user having a plan makes sense, and is needed, go ahead and create the relationship. If it is more clear to conceive of the plan belonging to an account, then stick with user.account.plans.)
Your design should be sufficient so long as you don't need to restrict a user to a subsets of the plans belonging to an account, and so long as a user only belongs to a single account.
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).