acts_as_follower icon indicating copy to clipboard operation
acts_as_follower copied to clipboard

Unblock should not delete record

Open ychaker opened this issue 13 years ago • 5 comments

Hey, I just spent an hour trying to figure out why the records had been disappearing until i finally got across this line

Unblocking deletes all records of that follow, instead of just the :blocked attribute => false the follow is deleted. So, a user would need to try and follow the book again. I would like to hear thoughts on this, I may change this to make the follow as :blocked => false instead of deleting the record.

i feel like an idiot now, but then again, it's 1130pm and i've been working since 9am!

This is definitely not the intuitive way to do it. is there any particular reason you went this route vs just setting the field to false?

ychaker avatar Jan 30 '12 21:01 ychaker

I sort of agree with unblocking shouldn't delete. However, I think the thought process on this was for pre-emptive blocking. Say you block a user, before they try to follow you, right now that creates a record for a follow and marks it as blocked. Now, when you unblock it just deletes that record. If we change it to just mark that record as unblocked, now that user would be following you. This would mean that you could block people and then just unblock them and all of a sudden they would be following you. I don't think this is good at all. This would be a great way to spam people.

So, that is where we were coming from with the original 'unblock' deleting the record. I think if we were going to move to a :blocked => false setup we would need to know who originally initiated the follow. So if the follower initiated the follow and then you blocked, and then unblocked it should just get marked as false. However if you preemptively blocked a user and then unblocked, it should delete that record. Otherwise we would be opening up a big SPAM problem with follows.

Maybe we should be add a 'preemptive' boolean flag to track these preemptive blocks so we can track when to delete and when to mark blocked => false?

Any thoughts here? Glad you brought this issue up to trigger this conversation. Hope you are finding the rest of the lib easy to use.

~ Tom

tcocca avatar Feb 05 '12 13:02 tcocca

what about the case when you had originally blocked someone but decided to unblock them because they turned out to be not a spammer (or whatever reason you might imagine). or what about scenario when you block the wrong person, and then unblock them?

i see those as more probable scenarios, at least in my case, then the scenario where you unblock someone and they become spammers. because if that person is a spammer, you just either block them again or don't unblock them in the first place because you don't trust them.

this definitely changes depending on the application. and what's right for one might be wrong for the other. is it possible to have a config option and if it's set to true, you delete the record, set to false you just mark the blocked field as 0? this way you accomodate both cases, and you don't have to go through the complicated path you were explaining.

does that make sense?

ychaker avatar Feb 05 '12 13:02 ychaker

Hi Youssef,

I think both of your cases would probably be in response to somebody trying to follow you correct? The the 'preemptive' boolean would be false so if you unblocked somebody it would just do blocked false instead of deleting.

However, a setting might not be a bad idea. Maybe something in the generated Follow model?

Would you want to take a stab at this? The default should be that the records get deleted to maintain backwards compatibility.

~ Tom

tcocca avatar Feb 05 '12 13:02 tcocca

I just had the same issue where I was trying to figure out why records were disappearing. In my case, a simple unblocking makes much more sense also, because in normal usage there will be no pre-emptive blocking behaviour by users.

If we could get a config setting for this, it would certainly help out my case.

Unfortunately, I won't have time to make the changes myself for at least a month or so. In the meantime, I'm just going to use the current behaviour (it won't be critical to change it until the application is launched).

trentclowater avatar Apr 08 '12 08:04 trentclowater

Hello @tcocca

Can we add unblock! method into model generator like block! method for unblocking purpose, so that users who does not want to delete record they can use this method.

 def unblock!
     self.update_attribute(:blocked, false)
 end

Thank you.

amoludage avatar Nov 04 '15 05:11 amoludage