If one creates a custom status and marks it to be saved for future use, at this first time it will set that status message and other client will see it (say Online - Working..). But if next time this user will select this status from the saved statuses drop down menu, other client will see only Online status without the custom message, though for this user it will show Online - Working.. on the top of the roster window. Same with other custom statuses (Away, DND). It sets the default status message when status message is selected from the list.
It's even worse now. It only sends correct presence update when you set a custom message manually. But now it doesn't send presence update even when you select default Away, DND, etc. It always shows Online. And the issue when you select saved status message is still there.
I don't know how Slava is testing. This should be done with two Spark clients at least.
Update. The issue is only happening when i'm logged into one of the gateways (Gtalk, ICQ, etc.) via Kraken plugin. If i logout form all transports then Spark is correctly sending presence to Openfire and saved custom messages work ok.
Wonder if this is an easy fix and can be solved in this ticket or should we close this and file another one related to gateways?
I reviewed Slava's patch and tested before committing using two Spark clients, no transports and our IM server (openfire) - worked fine for me too.
So I think, yes it is Gateway related
Not sure now if is easy fix or not, but we will try to reproduce/fix given your scenario
It looks it now works even with gateways enabled. But a minor issue is that it always prepends the default status text to the saved one.
When you first set a custom status, say for Away and name it Busy. It will show only Busy in your window and the other client will show: Away icon "You name - Busy". But if you select this saved status from the list, it will show like: Away icon "Your name - Away - Busy". Inconsistent behavior and prepending default status text is not needed, especially if custom status is long.
Actually the last minor issue is an older issue, already reported by me