[ICQ/AIM] Possibly fix for broken privacy lists in some accounts (tickets #9034, #12549)

[dustin]

Hello,

dustin wrote:
> Mark Doliner wrote:
>> Ahhh, I see now.  So you're saying that this broken entry doesn't
>> appear in OscarData->ssi.official or OscarData->ssi.local?  I wonder
>> if that's a server bug (they fail to send us an entry for that
>> gid+bid), or a client bug (we receive the entry for that gid+bid, but
>> we discard it for some reason).
>>
[..]

>>> [..]
>>> This seems to be a rare bug, and having an automatic correction for this
>>> may have harmful side effects (possibly deleting legitimate entries in a
>>> different situation...).
>>>
>>> So I thought keeping a manual fix for this, and preferably far away
>>> from libpurple's normal functioning, would be better.
>> Hrm.  Good point.  I guess we should determine if this is a client bug
>> (make sure we're not discarding the entry for some reason).  If it's
>> not a client bug, then I'd argue that we SHOULD include code to
>> automatically correct the problem.  I think it happens frequently
>> enough, and the downside of possibly deleting a single item is minor
>> enough to justify it.
> 
> Maybe this could be done in purple_ssi_parseack() [oscar.c] as part of
> error handling?
> e.g.
> in aim_ssi_sync(): save the last addition to the item list in some place if
> gid == 0.
> in purple_ssi_parseack(): if error is 0x0003 and item does not exist in the
> itemlist => delete (or give a special dialog window?)

Or maybe the entries are some server data after all, only lacking the ssi
itemlist reference .
I've just written some hack to automatically delete those entries, and I
found several of those on my regular and a test account.

For a start it may be sufficient to consider lower bids as reserved and
have aim_ssi_itemlist_add() generate only bids from 0x0100 upward or something.

If that doesn't work and the errors keep coming back one could still
include an automatic delete for weird entries.


Regards,

Dustin