Sung
Sung
@lmiller1990 thanks, it works. any idea why that fixes it?
+1 but not enough time to do PR atm
I am seeing this issue as well, using Rails 4.2.1, pry-byebug 3.1.0, pry-remote 0.1.8 on OSX Yosemite.
Why are the views within `app/views/public_activity/` using different `current_user` helper? Should they not use the one defined in your `ApplicationController` because they are within the same app?
You're right. We don't need both `blocker_id` and `blockee_id`. Plus, they sound funny. Maybe the new table `blocked_friendships` could have `friendship_id` foreign key and `blocker_id`, and `blocker_type` to make the...
What convention do you mean? Do you mean that we keep the current structure?
That's a reasonable approach. We could add statuses like `was_blocked` and `did_block`. I think this is not an urgent feature because current setup works just fine. This is something to...
By the way your PR was very helpful. Would you like to be a collaborator for this gem?
Yes. I think a solution would be to make the `friend_type` column in the `friendship` table. Currently we only have `friend_id`. Any thoughts?
When we first implemented block_friend, it was for blocking someone from making a friend request. That is why `unblock_friend` just destroys the existing friendship ([see here](https://github.com/sungwoncho/has_friendship/blob/ccd15c017e32c4cbd590542895086a27a0af9093/lib/has_friendship/friendable.rb#L75)). But I see that...