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.
Related
I have the following association between entities in the system:
Store
Vendor
and User
store can have many vendors,
vendor can belong to multiple stores.
A user can have multiple stores, but if its a user who is related to vendor, say a person who works for that vendor, then the behavior of that user changes.
Also, for a store there can be multiple roles.
I tried polymorphic association, but since the behavior of the user changes depending on roles and whether he is a store user or a vendor user, I cannot use that.
STI can also not be used since a vast amount of columns will differ. Any ideas will be helpful.
If I'm understanding your requirements accurately you want to model:
A vendor can have many stores
A store can have many vendors
A vendor can have many users
A store can have many users
That would require a has_and_belongs_to_many relationship between vendor and store. It would also require a polymorphic association between user and vendor/store. You should be able to use a polymorphic association. That way you could manage system behaviour for each user by checking their roles and associations. If you created a polymorphic association named userable for example, you could user user.userable to get either the vendor or the store and vendor.users or store.users to access users for those instances.
For your user model, regarding this line in your question:
"but if its a user who is related to vendor, say a person who works for that vendor, then the behavior of that user changes"
I would add a column to my user table called user_type and create some user types that you can use to filter out and assign privileges to. The user_type column could be a string field and explicitly named something like related and not_related, simply an integer 1 or 2, or more, or even a boolean field if there aren't going to be too many user_types.
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.
I want to setup a work order system in a tree structure like so
so the workorder belongs to a tenant, but also belongs to the property he/she lives in, and belongs to the landlord.
I know I can't have belongs_to :through. I want to be able to see all of the work order submitted by each tenant, and see all work order per property, and per landlord.
so if a landlord click on an work order, it will say which house it is for, and which tenant submitted this order.
So what is the best way to model this? polymorphic? or just straight up, belongs to?
Work orders belong to tenants, properties, and landlords. A work order must have all of those set when it is created. Landlords have many properties. Properties have many tenants, tenants have many work orders.
To see all work orders submitted by a tenant just do tenant.workorders. To see all he work orders per property per landlord you need to get all of the landlord's properties and then get all of the work orders for each of those properties.
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!
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.