How should I structure this model?

I have an application that is used by several different organizations.
(each organization runs their own copy)

In the application, there are users, and each user can have a number of
specialties. The specialties vary from organization to organization.
Also,
the possible specialties may change from time to time, according to the
wishes of that particular organization.

Normally, I would think that I would create a specialties table with a
has
and belongs to many relationship with users. But I don’t want to be
building different tables for each organization, and I want them to be
able
to add and delete specialties at will.

At the moment, I have a constant defined in my environment.rb that holds
an
array of the specialties (an array of strings). Then in each user, I
have a
serialized field that holds an array of the specialties appropriate to
that
user. But of course, the constant can’t be changed by the organization,
and
the whole thing is awkward for checkboxes, etc.

There has to be a better way, and I would me most grateful for any
advice.

Shelby

If a user belongs to an organization, go ahead and do what you
suggested (habtm). The organization would only see their users’
specialties because specialties would be related to users.

If a user can belong to multiple organizations, look into using
_with_scope on your find statements.

-Kyle

Sounds like you want to be able to drive this particular part of the
application from a model, not from the environment.rb. Make that puppy
data-driven for the specialties allowed within each organization.
There’s no reason that data shouldn’t reside in a table. Even a basic
scaffolded interface would let the right person (the organization’s
admin user) create new specialties, etc, etc.

By “(each organization runs their own copy)”, do you mean that each
organization has their own database? If not, the specialties just need
an organization tag assigned to them to keep them separate in the
processing, re: Kyle’s _with_scope suggestion.

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs