Rocket.Chat
Rocket.Chat copied to clipboard
RocketChat
[New] Show non-online time on users
[New]
Closes #14893
This allows showing of the away/offline/busy time on both direct messages and on the member list so that you can tell how long a user has been in a non-online status.
Note, you will need the currently under review PR #47 from Konecty/meteor-user-presence to test/use this
OK both of these failed tests for mongo are with a field that user.presence isn't returning (and that I didn't alter).
I suspect once the latest user.presence is pr #47 is accepted and referenced by the build package, this error will go away.
Revised Ok I was wrong, I needed to ensure the utcOffset was populated to something during user creation to pass the test.
Any news on getting this reviewed and adding into the release branch?
I think this raises a privacy issue, ~I'd say this calls for some user settings on if they want to share this kind of info or not, as other chat platforms have.~
[edit] previous wording could be confusing - I meant the user should have a setting to choose wether or not they allow other users to see their "Last seen" time. And, if they choose not to "share" that with other users, then they wouldn't be able to see other users' "Last seen" as well
@RocketChat/core thoughts on this?
I think if the user can turn it off... Would be ok privacy wise. Because we already have last login which is already kind of a clue that someone has connected from some sort of client.
I think telegram and a few other clients have this and it can be disabled kinda like the read receipt thing being something they can set too.
Let me revise my previous answer, I want to propose ONE property for now (due to time constraints) for the admin to enable/disable the feature completely.
In a later PR/release, I can come back and add the ability for a user to opt out of their status showing to non-admin users (add a permission to the normal permissions table with admins having it default)
I think that would satisfy all concerns of privacy at that point.
Also, lots of platforms don't allow turning it off by the end user at all (FB, lync, etc)
Let me revise my previous answer, I want to propose ONE property for now (due to time constraints) for the admin to enable/disable the feature completely.
Just make it default to off for all users in that case.
In a later PR/release, I can come back and add the ability for a user to opt out of their status showing to non-admin users (add a permission to the normal permissions table with admins having it default)
I think that would satisfy all concerns of privacy at that point.
No it certainly won't - because for those of us who live under GDPR you have to consider users opting out for privacy. Defaulting to 'on' with no way to change that is not good.
My employees don’t necessarily want anyone knowing what time they were last online if they are at home out of office hours. Etc, etc etc
Also, lots of platforms don't allow turning it off by the end user at all (FB, lync, etc)
Rocket is NOT FB. It is why some of us chose it. It is why some of us do not have a FB account because we are sick to the back teeth of their spying.
You have to think privacy first, even if you live elsewhere on the planet. Some of us face large fines otherwise.
So, if there is only one switch (which is extremely bad IMHO) then it has to be off by default from the outset.
Thanks.
The admin could maybe default it on for new accounts... but the user always gets final say? I agree we have to make it possible to opt out for our European users. Also I would want to be able to turn this off and I don't live in europe. But I can see some cases people might like this functionality. Especially like family and friends and such
Sorry if there was confusion on the intent there. My focus is on the corporate users, hence that is the main user story I was focused on.
I also agree that it needs the ability to be turned off per user for GRPR users
And I also agree, that if initially, I only have a global property, that it default to off. If turned on, it would apply to all users. This has use cases such as corporate environments where I don't think GDPR applies quite the same way? (Please correct me if I'm wrong on that)
- For example,. I work for a company with people across 3 continents, and it is important to know if someone "just logged out" or has been gone for hours for the sake of coordinating work between the different teams and time zones.
I was then suggesting, due to time constraints on my part, that as a next round of revisions I then add the features that make it more GDPR friendly so for people using it in public/non-corporate/GDPR compliant scenarios, there is the opt out. feature per user.
I'm not sure we will be able to merge this before there is a way for each user to configure wether they want others to see their "Last seen" or not, unfortunately. But I really feel this will be a great addition once they do!
We are currently in a feature freeze period until the release candidate is released, so it would not be possible to merge this right away. It can make it in the next cycle (for v1.4.0), though, if you (or any other contributor, really) can get the user setting in!
Until I get at least the global disable/enable features in, I wasn't expecting a merge.
What is the time frame for the v1.4.0 release cycle?
We have monthly releases, with the feature cut starting on the 20th every month. So to include it on the 1.4 release it needs to be merged by August 20th.
Sorry if there was confusion on the intent there. My focus is on the corporate users, hence that is the main user story I was focused on.
That still affect individuals..... think about workers going home with the their phone with their Rocket app. Do they want their boss knowing they were still up at 4 am??
And I also agree, that if initially, I only have a global property, that it default to off. If turned on, it would apply to all users.
That's fine if the default is off to start with (no one forced to do it) and companies can then choose to turn it on.
So the Global should be Off and Individual is Off to start with. It's only a click to enable it if required, and if anyone chooses too.
This has use cases such as corporate environments where I don't think GDPR applies quite the same way? (Please correct me if I'm wrong on that)
Happy to correct you then :-) GDPR applies regardless. If you control/process personal data, that's it. Corporate, charity, or whatever. And it applies both internally and externally. So I have to think of both my employees, and my clients.
For example,. I work for a company with people across 3 continents, and it is important to know if someone "just logged out" or has been gone for hours for the sake of coordinating work between the different teams and time zones.
You may want to check with your lawyers in the relevant jurisdictions.... tricky, but doesn't necessarily absolve you from GDPR if any of those continents include Europe.
I was then suggesting, due to time constraints on my part, that as a next round of revisions I then add the features that make it more GDPR friendly so for people using it in public/non-corporate/GDPR compliant scenarios, there is the opt out. feature per user.
It has to be GDPR friendly out of the box. Because there are lots using it in GDPR countries, so the minute you roll out a change, the law applies. Better late than sorry IMHO.
You have to totally rethink how you do privacy. It has to be on by default and you have to get permission to use and store data before you process it. Not after.
(N.B. I am not actually against what you are doing - just pointing out the legal ramifications that many of us have to consider. There is still a lot of debate about what will or won't apply that will be settled by court cases in due course. In the meantime is is better to be safe than sorry)
Just to be clear, this is on hold until I have time make this privacy compliant.
Unfortunately, I'm going to need to pull this PR. I won't have time to complete this work as a few other outstanding PRs (some well over a year old) have cause my boss to have us stop the experiment with Rocket.Chat
@ChristineBoersen can you please this PR open?
We think this is very important and will appreciate having your code merged once we manage to add the privacy setting needed.
Managing all the PRs is always a challenge, but the company is growing and our team is expanding, so we will be able to do it better.
No problem on the reopening. Unfortunately, this needs hours more work to be made GDPR compiant which was why I closed it.. That and I would implement it slightly differently with that goal in mind.