Opened 9 years ago

Last modified 9 years ago

#10650 new enhancement

Handle roster modification errors better, specifically translate group move into secondary group addition

Reported by: mbateman Owned by: deryni
Milestone: Component: XMPP
Version: 2.6.3 Keywords:
Cc:

Description

I have buddies with muliple accounts that I group using the expand and drag method. One of their accounts is Jabber where they are part of some group that is named on the Jabber server. I drag them out of that group and into the expanded buddy in a group that I created locally. That works fine until I restart Pidgin. At that point, they are no longer grouped and the Jabber contact is back in the group defined on the Jabber server.

Change History (7)

comment:1 Changed 9 years ago by darkrain42

  • Component changed from unclassified to XMPP
  • Status changed from new to pending

Are these buddies that are added to your list by a corporate server?

Those groups are forced upon clients by the server and there's no way to override that (there's an argument to be made that Pidgin should notice that the move fails on the server and move the buddy back locally, although that's pretty terrible behavior also).

What you can do is go to Buddies->Add a Buddy and add the buddy into another group on the buddy list; the buddy will then be in two groups and should probably remain after a disconnect/connect to the server.

comment:2 Changed 9 years ago by mbateman

  • Status changed from pending to new

Yes, these are buddies that are added by a group on the server. In Trillian, I can just move them into a meta contact and put the meta contacts in any local group that I want. With Pidgin, they do not stay in their meta contact if the meta contact is moved out of the group that was created by the server. I was able to add the same buddy manually and put it in the meta contact I want and it stayed there. I was also able to delete the group created by the server, so I end up with the result I want. But it seems like a lot of steps compared to the intuitive way that Trillian does it.

comment:3 Changed 9 years ago by darkrain42

  • Status changed from new to pending

Are you saying that you deleted the group the buddy was in originally and it did not' return when you restarted Pidgin?

If so, please get debug logs (Help->Debug Window) for each of the operations you've performed (when it both did and did not work).

comment:4 Changed 9 years ago by mbateman

  • Status changed from pending to new

Sorry, the group did come back. It put it in a different place in my buddy list, so I did not notice it at first. Bummer. At least the one I added manually did stay grouped with the other accounts for that Buddy.

comment:5 Changed 9 years ago by deryni

If trillian behaves the way you are saying it does then it means that trillian is "remembering" your local changes that did not work on the server and re-applying them the next time you receive your roster from the server (which will have them in the "wrong" group). I don't like the sound of that from a data standpoint, it means you can never be certain that the list you are seeing is the list on the server which means data may just "go missing" under the right circumstances. pidgin assumes the server list is correct and its local list is not when they disagree (this allows for changes made from other clients to display correctly in pidgin).

The best pidgin could do to handle this would be to detect that the move failed and convert it to the addition of the buddy to a second group (or prompt for whether an extra group addition is the desired result), which is something I think we reasonably should do.

comment:6 Changed 9 years ago by deryni

  • Owner changed from rekkanoryo to deryni
  • Summary changed from Buddies do not stay grouped to Handle roster modification errors better, specifically translate group move into secondary group addition
  • Type changed from defect to enhancement

comment:7 Changed 9 years ago by darkrain42

Related: #5778

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!