I have the following models:
Account
has_many :libraries
Library
has_many :topics
belongs_to :account
Topic
has_many :functions
belongs_to :library
Function
has_one :example
belongs_to :topic
Example
belongs_to :function
I would like to be able to able to do things such as:
some_account.libraries
some_account.topics
some_account.functions
some_account.examples
In addition, I would like to be able to assign an account to a descendant, i.e
some_example.account = some_account
some_function.account = some_account
some_topic.account = some_account
some_library.account = some_account
To give some context:
I am letting a user (Account) create each Library, Topic, Function, Example. record separately. Then a user is free to change how the records are associated: Change the topic of a Function, move a Topic to a different Library, add an example to a function, and so on.
To my understanding no matter what record is created, I would need to assign it to a user (account) so that I can have a list of each Model records that a user has created, as well as prevent other users from seeing stuff that doesn't belong to them
Although I might be overcomplicating, I really don't know :(
Thanks in advance.
Just put
belongs_to :account
on each entity a user can make... and add a foreign key, and
Account
has_many :libraries
has_many :topics
has_many :functions
has_many :examples
(Note: I use the hobo_fields gem to make migrations easier)
That way.. if they change which functions are in which topics etc.. you can't loose who created it.
If you want to make sure users cannot add their topics to someone else's library just put validation on the record to prevent it.
Related
Using RailsAdmin with this example:
class Product < ActiveRecord::Base
has_many :comments, as: :commentable, inverse_of: :commentable
has_paper_trail
end
class Comment < ActiveRecord::Base
belongs_to :commentable, polymorphic: true, inverse_of: :comments
has_paper_trail
end
When I am viewing a Product, the has_many associated Comments is a comma separated list of the Comment names. I'd like instead to have a table with various attributes the the Comment model in columns.
Further, the default edit view on Product gives me a list of Comments that might be related to other Products, and allows the user to "steal" the Comment and assign it to the current one in view. I guess that might be useful in a Manager/Employee type of association - it would allow a user to switch a Employee from one Manager to another. It's really not what I want though. Instead, I'd like to present a list of existing Comments associated, ability to delete one of these, and ability to add one.
So I'm looking for a starting point on this type of customisation (assuming it's beyond the realm of configuration). I have seem some tips on field customisation but this is something different (isn't it?) I haven't been able to find anything on the web so I'm hoping someone here can get me started...
Thanks,
RailsAdmin does not currently allow for custom partials for the Show action.
I have two models with the following associations:
organization.rb
class Organization < ActiveRecord::Base
has_one :user, as: :identifiable
has_many :speakers
#has_many :cast_items
end
speaker.rb
class Speaker < ActiveRecord::Base
has_one :user, as: :identifiable
#has_many :cast_items
end
As you can see, I've commented out an association with the CastItem model.
I want a Speaker to add multiple CastItems. Also, an Organization must be able to add multiple CastItems. When an Organization adds a CastItem, it does not necessarily belongs to a Speaker who is associated with an Organization. In other words an organization must be able to add a CastItem to itself or to a Speaker who is associated with him.
Will it be completely valid to put the has_many :cast_items in both models, or are there more practical design options?
Yes, you can do that. Remember to add organization_id and speaker_id to your cast_items model.
You can check out this link, http://guides.rubyonrails.org/association_basics.html , some useful information regarding many to many and one to many associations.
Personally, in your case, I will use has_many :through
You can definitely do that. I can't think of any reason that would be bad and it's often necessary.
You may want to look up the 'delegate' method for when you're creating CastItems, and have them always created by Organizations.
Also, make sure that if you have a :speaker_id on your CastItem that it can accept nil or false.
So I have an application with users/user-profiles. Presently, users can view others profiles, send messages, and favorite user profiles. I'd like to also add the feature to allow users to 'hide-user' profiles so that they won't see the user ever again in search, or anything. And provide the option in 'settings' to 'un-hide' the user as well.
How might I do this? I haven't a clue as to where to begin with this feature.
(If you need any code examples, models, controllers please ask and I will happily provide)
Kind regards,
Sonny
There are probably a couple of ways to do this, the first approach that comes to mind would be to establish a self-referencing many to many relationship.
You will need to create the join table (I shall call it suppressed_users). I will show the rails model, as the migration wouldn't have anything other than the foreign keys.
class SuppressedUser < ActiveRecord::Base
belongs_to :user
belongs_to :suppressed_user, :class_name => "User", :foreign_key=>"suppressed_user_id"
end
And in the User model, in order to help DRY up your code, you can use a scope to easily filter all the users that this target user has decided to suppress (or hide):
class User < ActiveRecord::Base
has_many :suppressed_users // Optional
scope :without_hidden_users, -> (target_user) do
where.not("exists (?)",
SuppressedUser.select("1")
.where("users.id = suppressed_users.suppressed_user_id AND suppressed_users.user_id = ?", target_user))
end
end
Note about the scope: What I'm doing here is creating a dependent (or correlated) subquery, in which I check whether the target user has suppressed (or hidden) the user we're looking at at the moment. In other words, the dependent subquery is executed for each row in the users result set (those not filtered by other where or join conditions and such). With proper indexing, this should not have an impact on performance.
Note about has_many :suppressed_users: This is technically not needed for the query I've shown, so if it is not relevant for anything in your system, you should be safe to remove it.
So, if I am presently logged in, and I want to search for a list of users meeting some condition, in your controller you would do something like this:
User.without_hidden_users(#current_user.id)...other conditions and such as needed
Assuming #current_user represents the currently logged in user.
I believe one approach would be to create a many_to_many relationship via the has_many :through association between users and hidden users. And likewise another many_to_many relationship between users and hiders (i.e. users who are hiding the user). In the end, you should be able to do something like this:
some_user.hidden_users and some_user.hiders (i.e. all the users that are hiding some user). You probably won't need the second one most of the time.
So the first thing to do would be to create a join table called hiders_hidden_users (or whatever you want) which would contain only two fields: hider_id and hidden_user_id.
Note, that in reality, those ids will both refer to a User record. Your HidersHiddenUser model will look something like this:
class HidersHiddenUsers < ActiveRecord::Base
belongs_to :hidden_user, class_name: "User", foreign_key: "hidden_user_id"
belongs_to :hider, class_name: "User", foreign_key: "hider_id"
end
Then, you need to set up the relationships in the User class:
class User < ActiveRecord::Base
has_many :hiders_join, class_name: "HidersHiddenUser", foreign_key: "hider_id"
has_many :hidden_users_join, class_name: "HidersHiddenUser", foreign_key: "hidden_user_id"
has_many :hiders, through: :hiders_join
has_many :hidden_users, through: :hidden_users_join
end
Note, that you have to specify the class name and foreign key when writing the has_many relationship with the join table. Note, also that you have to specify the relationship twice with the same model.
Then, say some_user wants to hide user1 and user2. All you would need to do is something like this:
some_user.hidden_users << user1
some_user.hidden_users << user2
Although I have not tested this, I believe it should work.
A person can compete in various events, but they must enter a partner's name for that event. This association is stored in an entry, which contains a field for the partner's name.
class Person < ActiveRecord::Base
has_many :entries
has_many :events, :through => :entries
validates_presence_of :name
end
class Event < ActiveRecord::Base
end
class Entry < ActiveRecord::Base
belongs_to :person
belongs_to :event
validates_presence_of :partner_name
end
The question is: How do you create a single page form that allows a person to enter themselves in multiple events and input their partners' names? I've tried to implement an all_entries method in the person model that will return an array of entry objects for all the available events, and an all_entries_attributes method that will update, create, and delete entry objects, but I can't seem to find a good, clean way to do this. I know this is a rather open ended question, but this must be a pattern that someone else in the rails community has encountered before, so I'm hoping there is a good solution to it.
If you are still looking for the answer you might want to check out my question and answer that I found.
So you want a page in which you can create events for a user, and add people to those events
I won't give you a plain solution because there's some work to an implementation for this, but I will recommend checking out these railscasts about nested model forms
part1 and part2
Rails has a has_one :through association that helps set up a one-to-one association with a third model by going through a second model. What is the real use of that besides making a shortcut association, that would otherwise be an extra step away.
Taking this example from the Rails guide:
class Supplier < ActiveRecord::Base
has_one :account
has_one :account_history, :through => :account
end
class Account < ActiveRecord::Base
belongs_to :supplier
has_one :account_history
end
class AccountHistory < ActiveRecord::Base
belongs_to :account
end
might allow us to do something like:
supplier.account_history
which would otherwise be reached as:
supplier.account.history
If it's only for simpler access then technically there could be a one-to-one association that connects a model with some nth model going through n-1 models for easier access. Is there anything else to it that I am missing besides the shortcut?
Logic, OK it might sound a bit weak for this but it would be logical to say that "I have a supplier who has an account with me, I want to see the entire account history of this supplier", so it makes sense for me to be able to access account history from supplier directly.
Efficiency, this for me is the main reason I would use :through, simply because this issues a join statement rather than calling supplier, and then account, and then account_history. noticed the number of database calls?
using :through, 1 call to get the supplier, 1 call to get account_history (rails automatically uses :join to retrieve through account)
using normal association, 1 call to get supplier, 1 call to get account, and 1 call to get account_history
That's what I think =) hope it helps!
I'm surprised no one has touched on Association Objects.
A has_many (or has_one) :through relationship facilitates the use of the association object pattern which is when you have two things related to each other, and that relation itself has attributes (ie a date when the association was made or when it expires).
This is considered by some to be a good alternative to the has_and_belongs_to_many ActiveRecord helper. The reasoning behind this is that it is very likely that you will need to change the nature of the association or add to it, and when you are a couple months into a project, this can be very painful if the relationship were initially set up as a has_and_belongs_to_many (the second link goes into some detail). If it is set up initially using a has_many :through relationship, then a couple months into the project it's easy to rename the join model or add attributes to it, making it easier for devs to respond to changing requirements. Plan for change.
Inverse association: consider the classic situation user-membership-group. If a user can be a member in many groups, then a group has many members or users, and a user has many groups. But if the user can only be a member in one group, the group still has many members: class User has_one :group, :through => :membership but class Group has_many :members, :through => memberships. The intermediate model membership is useful to keep track of the inverse relationship.
Expandability: a has_one :through relationship can easy be expanded and extended to a has_many :through relationship