Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Option to enable/disable auto away and configure timer #736

Closed
rockneverdies55 opened this issue Sep 8, 2015 · 28 comments · Fixed by #8029
Closed

Option to enable/disable auto away and configure timer #736

rockneverdies55 opened this issue Sep 8, 2015 · 28 comments · Fixed by #8029

Comments

@rockneverdies55
Copy link

Rocket.Chat keeps user status as Online only if user is actively using chat window or if chat window is hovered via mouse.

Otherwise, user status falls onto Away...

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

@rodrigok
Copy link
Member

rodrigok commented Sep 8, 2015

What is the expected behaviour?

@rockneverdies55
Copy link
Author

User status shouldn't be determined based on the interaction with the chat window.

User is online as long as she/he's logged in to rocket.chat and doing something on the computer. No activity with OS at all for a predefined time (can be set by Admins) should make user Away.

@Maysora
Copy link
Contributor

Maysora commented Sep 8, 2015

probably should add an option to enable/disable auto away?

@rodrigok
Copy link
Member

rodrigok commented Sep 8, 2015

I don't know if we can detect OS inactivity inside the browser.

The auto away is useful to send mentions via push notification.

@geekgonecrazy
Copy link
Contributor

maybe an option to choose how long before auto away. The only place detecting if they are truely away is in the Rocket.Chat desktop app.

@jclabaugh
Copy link

maybe 'Set to Away status in [ ] minutes' defaulting to 10 min.

@geekgonecrazy
Copy link
Contributor

agreed 👍

@jclabaugh
Copy link

might check out https://atmospherejs.com/dpid/user-presence for inspiration (advanced settings stuff)? Since the app is browser-based, it is harder than Slack's desktop client to set user presence accurately but there might be a cludge idea somewhere that gets you closer to replicating that by adding a user-defined delay period.

We have had UX issues currently with people going "I'm at my computer, I am just not typing in the app right this sec, why is it setting me to 'away' already?"

@jclabaugh
Copy link

I think Slack actually does a non-standard implementation of user presence, contrary to the likes of Skype or any IM client... If the app is open, you are 'online', regardless of any of your activity in the app. If the app is not open or your computer is asleep/off, you are 'offline.' You say you are 'away' by manually setting your status by clicking 'Set yourself away'. So its detecting a binary presence state, kind of.

@geekgonecrazy
Copy link
Contributor

https://developers.google.com/web/updates/2015/08/27/using-requestidlecallback

Ran across this during my perusing of the interwebs. Looks like it might be of use here.

@gmsecrieru
Copy link
Contributor

ifvisible.js looks interesting, do you folks think it could be of any use? Demo here

@engelgabriel engelgabriel changed the title Set user status correctly Option to enable/disable auto away and configure timer Feb 22, 2016
@engelgabriel engelgabriel added this to the Nice-to-Have milestone Feb 22, 2016
@klatys
Copy link

klatys commented May 5, 2016

+1 on this. This also causes sending mobile notifications eventhough you are active on a computer (but not in RC window) which is quite annoying.

I found Robot.js's getMousePos which could check/detect mouse position change. Detecting keypresses is (for obvious reasons) probably an issue, but if there wasn't any other way. Mouse might at least partially fix this...

I'm not really fluent with electron, but was wondering - if it was somehow working the same way the cordova does then maybe some sort of plugin might do the trick...

@joergludwig
Copy link

joergludwig commented Apr 24, 2017

We switched to Rocket.Chat for communication in our company. Every user runs the desktop app on his computer. It would be very useful if we could see, who is working at his computer and who is not at his desk. In the past we used Pidgin with an XMPP server, which did this well.

Rocket.Chat should switch a user to "away", if he does not move the mouse for 5 minutes, and switch back to "online", as soon as he is active again. If Rocket.Chat could detect, if the screen is locked, this would work as well.

I just posted a $200 bounty on Bountysource for this issue.

@freddy70
Copy link

Hi all
I'm in the same situation and I have the same need as joergludwig.
I installed the desktop app on several computers in my company. I would like to have a "green" status when user is working on his computer and "orange" status when user stop moving his mouse or screen locked. Do you know if this feature will be implemented ?
Thanks a lot for your feedback.

@StealthMicro
Copy link

+1

@klatys
Copy link

klatys commented Jul 22, 2017

Hi, like I suggested earlier, I tried tinkering with robot.js, since it's for a electron apps (or if I get it correctly requires actual app - means it won't work in browser) I used it in Rocket.Chat.Electron and it seems to work:
inactive window logging mouse pos
Now I'm not that fluent in how the client works with rocket.chat instance, I suppose it might send some sort of info regarding user status to server which would process that. Could someone from @RocketChatApp point me in the right direction?

@ghost
Copy link

ghost commented Aug 23, 2017

+1 Need this very badly to make chat more useful in business environment.

@armand1m
Copy link
Contributor

armand1m commented Sep 2, 2017

Hi, I've started implementing this feature, but I'm in doubt in certain situations:

This feature involves not only the actual online/away user but the whole team that this user belongs, so I'm in doubt if this must be in the "My Account" preferences for each user to configure its own Idle Time Limit, or in another place.

screenshot_27

. @rockneverdies55 has said:

No activity with OS at all for a predefined time (can be set by Admins) should make user Away.

For me, it should be configured per User in the "My Account" preferences, and each user should use this responsibly, but what @rockneverdies55 sad also makes sense to me, even more if some companies are running this as the main communication channel and needs this kind of control.

Just want to know most people's opinion about this. By now, I'm creating it as the screenshot shows.

@armand1m
Copy link
Contributor

armand1m commented Sep 2, 2017

For now, I'm not willing to change the way Rocket Chat handles User Presence, I'm just creating the option to enable the auto away and change the Idle Time Limit if enabled.

@armand1m
Copy link
Contributor

armand1m commented Dec 5, 2017

Hey, I've updated the PR #8029.

Know the tests are all passing, and we have the feature implemented in 4 languages:

  • English (default)
    captura de tela 2017-12-04 as 23 04 00

  • Portuguese
    captura de tela 2017-12-04 as 23 04 12

  • Brazilian Portuguese
    captura de tela 2017-12-05 as 00 42 34

  • Dutch (Nederlands)
    captura de tela 2017-12-05 as 00 42 23

Here is a GIF demonstrating the feature.

enableautoaway

@joergludwig
Copy link

Thank you for your work. Unfortunately I think, the actual problem is not solved:

rockneverdies55 commented on 8 Sep 2015
User status shouldn't be determined based on the interaction with the chat window.
User is online as long as she/he's logged in to rocket.chat and doing something on the computer. No activity with OS at all for a predefined time (can be set by Admins) should make user Away.

@rodrigok
Copy link
Member

rodrigok commented Dec 7, 2017

@joergludwig Unfortunately there is no way to get the OS activity from inside the browser.

@armand1m
Copy link
Contributor

armand1m commented Dec 7, 2017

@joergludwig can you be more clear? you just copy pasted the message from @rockneverdies55 but didn't explained anything at all. If you want me to detect no activity with OS at all, I must say that I'm sorry because this is actually impossible without a chrome extension or something like that. But the PR was merged, the issue was closed and the desired functionality was delivered, I think I deserve the bounty. If you want to know if the user is interacting with the OS, I would recommend you to use another kind of monitoring tool in your company such as Hubstaff.

@armand1m
Copy link
Contributor

armand1m commented Dec 8, 2017

@joergludwig I've also asked for some feedback before starting to implement this feature, and no one even took the time to respond to some of my questions before I took the liberty to make the decisions about this feature myself. I think it is really not fair.

@rodrigok
Copy link
Member

rodrigok commented Dec 8, 2017

@armand1m Your solution was a good solution, thanks.

@joergludwig We already have some improvements to get the OS activity when using the Desktop/Electron app, we can improve, please open an issue at https://github.com/RocketChat/Rocket.Chat.Electron/issues if you have suggestions.

Thank you guys.

@armand1m
Copy link
Contributor

armand1m commented Dec 8, 2017

@joergludwig can you accept the claim in bountysource please?

@joergludwig
Copy link

Sorry for the misunderstanding. I thought this issue was about detecting OS activity. We only use the desktop and mobile apps. I was not aware that there are different issue trackers for browser and app usage.

I accepted your claim in bountysource anyway to support further development of Rocket Chat.

@armand1m
Copy link
Contributor

armand1m commented Dec 8, 2017

thanks @joergludwig 🙂

@engelgabriel can you take a look and accept the bounty? 😄

HappyTobi pushed a commit to HappyTobi/Rocket.Chat that referenced this issue Jul 10, 2018
@theorenck theorenck removed this from the Long-term milestone Dec 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.