there seems to be an issue with parent_class_name

[kdabalos]

my classes look like the following

class User < ApplicationRecord
  include Clearance::User
  ...
  acts_as_follower
  ...
end

class Policy < ApplicationRecord
  include Searchable
  ...
  acts_as_followable
  ...
end

class ApplicationRecord < ActiveRecord::Base
  self.abstract_class = true
end

For some reason when I call this method user.follow(policy), the followable_type is not set to 'Policy' but to 'ApplicationRecord' which makes user.following?(policy) always return false. I looked at the parent_class_name method. the code below executes because the include? method returns false even if obj.class.superclass.name == 'ApplicationRecord'

unless parent_classes.include?(obj.class.superclass)
  return obj.class.superclass.name
end

I use Rails 5 and the master branch as indicated in another issue #79

[PelagicDev]

Did you ever figure this out @kdabalos? I'm using same Rails version and master branch too.

[BrahimDahmani]

i got the same issue, as i understood the code below is used for STI models, so if your class isn't STI model this function will return ApplicationRecord

unless parent_classes.include?(obj.class.superclass)
  return obj.class.superclass.name
end

i solved this by adding all non STI Model to initialiser like this
ActsAsFollower.custom_parent_classes = [ApplicationRecord, Report, Video, Survey, Message]

[BrahimDahmani]

actually this is mentioned in the doc, i didn't see that before now

[PelagicDev]

I did this as well, but I was seeing weird functionality. Sometimes it would create a record with :followable_type attribute set as 'User', and then the next record would be created with followable_type set as 'ApplicationRecord'.

I ended up forking this repo, and changed the code to only using 'User' as the followable_type. This isn't ideal since it isn't reusable for other model types, but I couldn't think of a better/quicker solution since I had beat my head on this for far too long.

[brchristian]

@kdabalos This behavior should be fixed as of the merge of #56. Does that address this issue?

[PelagicDev]

Yeah, I think it does. This should be safe to close.

[brchristian]

I’ll ping @jcoyne here with a heads up that this issue may be good to close, unless @kdabalos objects.