I am currently building an application where part of it is an invitation / enrollment system. Currently there are "courses" and "classrooms" in the system. A "course" is thus some course, and a "classroom" is a specific instance of a course. F.ex. there might be 1 course, but 3 classroom instances of that course, having different start/end dates, slightly different/updated materials, etc. Now, an "employee" can be invited to participate in a "course", but the "employees" themselves, has to choose a specific "classroom" to enroll in. So, the employee goes to his/hers profile page, where the invitations show up. Now the employee clicks an invitation, and can then choose a specific classroom to enroll in. This should obviously create an enrollment. But, it should also get rid of the invitation, since it has been "accepted". Currently i have it set so that "employees" has many "classrooms" through "enrollments". Also, an "employee" has many "courses" through "invitations". This doesn't seem right though, since when an employee clicks some invitation, they will be taken to an enrollment page(enrollment controller), where an enrollment will be created. As the enrollment is created, the invitation should be deleted though. So right now i guess the enrollment controller should be able to create enrollments and delete invitations. This seems like bad design. I am pretty happy with the relation between classrooms and employees, but the relation between employees and invitations seems bad. How would you do it?
Why don't you use simply a status attribute in your model to managed the invitation procedure?
I'll use the following models:
Employee, the user of the app;Course, the course to be followed;Classroom, belonging to a Course (a course having many classrooms).Participation, making the link between the employee, the course and the classroom. This model would have a status depending on the evolution of the participation to the course: invited when the employee has been invited, enrolled when the employee has chosen a classroom, etc.A skeleton of the Participationmodel would be:
class Participation < ActiveRecord::Base
attr_accessible :status
belongs_to :employee
belongs_to :course
belongs_to :classroom
#...
validates_uniqueness_of :employee_id, :scope => [course_id, :classroom_id]
end
With a uniqueness requirement for the employee given the course and the classroom. And may be only for course itself without considering the classroom depending on your choice.
I'll add a unique index on Participations table:
add_index :participation, [employee_id, course_id, classroom_id], unique => true
At the invitation the participation instance would be created (status invited) with the corresponding employee_id and the course_id, classroom_id being left empty. At the enrollement, the participation would be updated with the classroom_id and status enrolled.
Does it fit your needs?