Nick-changing messes up gender tracking

[dgw]

Illustrative example first:

<ElimGarak> Kaede: what gender am I?
<Kaede> ElimGarak: Grammatically, I refer to you as androgynous. [snip]
<ElimGarak> Kaede: I am male
<Kaede> Okay, ElimGarak
	ElimGarak changed nick to GLaDOS
<GLaDOS> Kaede: what gender am I?
<Kaede> GLaDOS: Grammatically, I refer to you as male. [snip]
<GLaDOS> ok
<GLaDOS> Kaede: what gender is ElimGarak?
<Kaede> GLaDOS: I don't know how to refer to ElimGarak!

Following someone's /nicks is all well and good, but all too often someone changes nicks, leaves IRC, then comes back on their original nick—at which point Bucket no longer knows their grammatical gender. I was even asked, following the most recent occurrence of this: <DHMO_Mobile> dgw: Why is my gender moved from nick to nick, instead of copied though? Needless to say, I didn't have a good answer except that the current code does what it does.

I traced this to the main body of the irc_on_nick subroutine. Assuming that exists $stats{users}{genders}{lc $who}, that value is deleted and assigned to $stats{users}{genders}{lc $newnick}, and then the database is updated (&sql( "update genders set nick=? where nick=? limit 1", [ $newnick, $who ] );), at which point Bucket has completely forgotten about the old nick. (The old nick is $who and the new nick is $newnick.)

The best solution to Bucket's amnesic tendency isn't really clear, though. While the gender value could be copied to a new row instead of changing the nickname in the existing row, that would lead to having a bunch more rows in the genders table. Updating the grammatical gender for one nickname also wouldn't update any of the others used by the same person—and having the gender "magically" follow someone when they change nicknames wouldn't work then.

In my own work on plugins for the Sopel framework (which supports explicitly grouping nicknames to have them use the same preferences & stored values), I've been toying with the idea of writing a module that automatically merges nicks when users change names. But in my thought process for that concept, I'm hung up in the same place as I am here: Even if Bucket supported nickname groups, how can an automated merging process tell when a grouping should be temporary vs. permanent? When should the new name be ungrouped on PART/QUIT/KICK and when should it be left to persist? That's often a call only a human bot admin can make on a case-by-case basis.

But I've gotten into the weeds a bit. Here, the biggest issue for me is that when users go to the effort of telling Bucket their grammatical gender, that set value should persist no matter what nick-changes occur. Whether the solution is tracking nick-changes only in $stats{users}{genders} and leaving the DB alone, or something more sophisticated, I don't think the current behavior of just forgetting about the original nickname is ideal.

[dgw]

Addendum to the problem description:

1. user sets gender to 'male'
2. user changes nick to resu (Bucket updates DB entry with new name)
3. resu quits IRC
4. user joins IRC (Bucket does not know user's gender at this point)
5. user sets gender to 'male' again
6. user changes nick to resu
7. Bucket outputs a DB error because he has tried to update user's name to resu, but there is already an entry with that nick

So not only does Bucket "forget" stuff he shouldn't, but he also throws out errors because of it. The only way I have found to resolve this is to manually delete the DB entry for either user or resu in the DB. Then it's fine until the next time user forgets to come back using the same nick as when they left…

[zigdon]

Tracking nick changes is really a 'best effort' kind of thing, since unless we only look at registered nicks, we cannot possibly hope to keep up. honestly, not sure what the best solution here is though. Perhaps not saving genders at all, and just tracking them in memory? That, or only save to the database when a user that is identified is setting it?

…

On Wed, Nov 30, 2016 at 4:41 PM dgw ***@***.***> wrote: Addendum to the problem description: 1. user sets gender to 'male' 2. user changes nick to resu (Bucket updates DB entry with new name) 3. resu quits IRC 4. user joins IRC (Bucket does not know user's gender at this point) 5. user sets gender to 'male' again 6. user changes nick to resu 7. Bucket outputs a DB error because he has tried to update user's name to resu, but there is already an entry with that nick So not only does Bucket "forget" stuff he shouldn't, but he also throws out errors because of it. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#92 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AACtVHVGWi_EP7RqlQVlBsR97DeLyyfeks5rDhe2gaJpZM4K83SF> .