[sip-comm-dev] Remove a contact which was not requested for authorization


#1

Hi Damian,

I have more information about this problem.

The contact stays in the contact list only localy, it could not be removed except by deleting the contactlist.xml file. May be the contacts awaiting authorization should be added in an Awaiting authorization group and there removeContact method should have a different behavior..

Yana

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

I think that if we create them as volatile (non-persistent) it should also be ok. Once we've received the authorization however, the protocol provider would have to fire a subscription created event to indicate that the contact has been moved to a persistent group, and fire a subscription removed event for the non-persistent contact.

Emil

Yana Stamcheva wrote:

···

Hi Damian,

I have more information about this problem.

The contact stays in the contact list only localy, it could not be removed except by deleting the contactlist.xml file. May be the contacts awaiting authorization should be added in an Awaiting authorization group and there removeContact method should have a different behavior..

Yana

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Hi,
I've tested the situation and its not actually as describe. The buddy is not added as awaiting in this situation. Its just created and is VolatileBuddy.
The actual exception is :
Caused by: java.lang.IllegalArgumentException: can't delete buddy net.java.sip.communicator.impl.protocol.icq.VolatileBuddy@1ee5bed : wrong type
          at net.kano.joustsim.oscar.oscar.service.ssi.SsiTools.getBuddiesToDelete(SsiTools.java:52)
          at net.kano.joustsim.oscar.oscar.service.ssi.SsiBuddyGroup.deleteBuddies(SsiBuddyGroup.java:175)
          at net.kano.joustsim.oscar.oscar.service.ssi.SsiBuddyGroup.deleteBuddy(SsiBuddyGroup.java:171)
          at net.java.sip.communicator.impl.protocol.icq.OperationSetPersistentPresenceIcqImpl.unsubscribe(OperationSetPersistentPresenceIcqImpl.java:564)

May be we must add to the unsubscribe method a check for volatile contact and just remove it and fire an event
What you think ?

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Sounds ok to me.

Emil

Damian Minkov wrote:

···

Hi,
I've tested the situation and its not actually as describe. The buddy is not added as awaiting in this situation. Its just created and is VolatileBuddy.
The actual exception is :
Caused by: java.lang.IllegalArgumentException: can't delete buddy net.java.sip.communicator.impl.protocol.icq.VolatileBuddy@1ee5bed : wrong type
          at net.kano.joustsim.oscar.oscar.service.ssi.SsiTools.getBuddiesToDelete(SsiTools.java:52)
          at net.kano.joustsim.oscar.oscar.service.ssi.SsiBuddyGroup.deleteBuddies(SsiBuddyGroup.java:175)
          at net.kano.joustsim.oscar.oscar.service.ssi.SsiBuddyGroup.deleteBuddy(SsiBuddyGroup.java:171)
          at net.java.sip.communicator.impl.protocol.icq.OperationSetPersistentPresenceIcqImpl.unsubscribe(OperationSetPersistentPresenceIcqImpl.java:564)

May be we must add to the unsubscribe method a check for volatile contact and just remove it and fire an event
What you think ?

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net