Hi JC and team,
First of all, thanks for this fantastic project.
We're planning on deploying this and contributing and love the auto-away feature, but it seems to kick in even if the user has set themselves to "Offline".
In other words: user wants to go offline, he/she changes his/her state to offline, but after X minutes the auto-away timer kicks in and puts them back online and set to "Away".
It's perhaps around here:
if (this.auto_away > 0 && this.idle_seconds > this.auto_away && stat !== 'away' && stat !== 'xa') {
We understand there are limitations to "Offline", including propagation, but our users really want it.
It seems that auto-away should only act on the user's state if they are set to a normal "Online" state (not "Busy", and not "Offline"); this is how AIM, ICQ, Google Talk/Hangouts and GAIM/Pidgin behave. Since there's no xmpp "Offline" status, one option might be:
if (this.auto_away > 0 && this.idle_seconds > this.auto_away && stat == 'online') {
The only other feature we miss is the auto-open of a conversation on a page change/reload (this feature apparently went away in the last week or so), and ideally, notification sounds wouldn't play if a conversation is in focus, or would be optional. We can open additional issues for those if you prefer.
Thanks again.
Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.
I think I agree with you @theclifbar that auto_away shouldn't apply to states besides online and chat (which is a special case of online).
However, I'd like to hear what @thierrytiti thinks about it, since he originally contributed this feature. @thierrytiti Can you comment on this?
About the other issues you mention @theclifbar, sounds like you are using the master branch. This is risky because it's undergone lots of refactoring recently, is still under development and not considered stable. Chats should remain open across page loads and notifications shouldn't play if the browser window is in focus. If these problems persist, you can create tickets for them, but I suggest you first double-check again with the latest code from master.
I have to reread the actual code, but the code has to avoid changing status if it hasn't been changed from online to away (or xa) by the code itself.
Normally if the status is changed to 'offline', the status should not be changed by the auto away function.
Maybe it would be safer to change the code this:
if (this.auto_away > 0 && this.idle_seconds > this.auto_away && stat !== 'away' && stat !== 'xa' && stat !== 'offline')
because in your correction, status could change from online to away, but never from away to xa
Normally if the status is changed to 'offline', the status should not be changed by the auto away function.
Agreed. What about 'busy'?
Also, I think there are already some tests for this. Any change here should be accompanied by more to test for regressions and the various permutations that may arise.
It seems to me that if someone set their status to busy/do-not-disturb, then there shouldn't be an automatic override of their setting. Otherwise, after the away idle time, the busy status is changed to away and then when they resume working (no longer idle) they will appear online in chat instead of busy as they previously set. Perhaps the code block should read:
if (this.auto_away > 0 && this.idle_seconds > this.auto_away && stat == 'online') {
this.auto_changed_status = true;
this.xmppstatus.setStatus('away');
} else if (this.auto_xa > 0 && this.idle_seconds > this.auto_xa && (stat == 'online' || stat == 'away')) {
this.auto_changed_status = true;
this.xmppstatus.setStatus('xa');
}
This should satisfy the condition that only online users will be set to auto-away and extended away is operational for online (if auto-away isn't set or fails) or away.
good point @mhchu
Fixed. The user's status won't be set to 'away' or 'xa' if they're in the 'dnd' state.
There is no longer an 'offline' state.
Most helpful comment
I think I agree with you @theclifbar that
auto_awayshouldn't apply to states besidesonlineandchat(which is a special case ofonline).However, I'd like to hear what @thierrytiti thinks about it, since he originally contributed this feature. @thierrytiti Can you comment on this?
About the other issues you mention @theclifbar, sounds like you are using the master branch. This is risky because it's undergone lots of refactoring recently, is still under development and not considered stable. Chats should remain open across page loads and notifications shouldn't play if the browser window is in focus. If these problems persist, you can create tickets for them, but I suggest you first double-check again with the latest code from master.