Welcome to the #dominoforever Product Ideas Forum! The place where you can submit product ideas and enhancement request. We encourage you to participate by voting on, commenting on, and creating new ideas. All new ideas will be evaluated by HCL Product Management & Engineering teams, and the next steps will be communicated. While not all submitted ideas will be executed upon, community feedback will play a key role in influencing which ideas are and when they will be implemented.
For more information and upcoming events around #dominoforever, please visit our Destination Domino Page
Thank you for all the feedback. This is a critical feature prioritized and currently in development.
Hello, we also need the function for users to delete chat history while persistent chat is enabled as soon as possible!
Please implement "Delete Specific Chat" when "Persistent Chat is Enabled". We need this function. Thank You.
Some organizations must save the chathistory for 5 years. This is required by law, and needed for security audits afterwards.
GDPR is also telling us to anonymize chat-data and not just deleting it.
Any news yet? We also need this function. Not for users but for admins to remove the entire chathistory per user for GDPR purposes. Otherwise supply the Mongo command to remove it manually.
Please implement this. Its really, really important! Without this function we cannot use Sametime. #GDPR #DSGVO #right of erasure
Would be really nice if this feature would be implemented.
It's possible with the competition, our managers are already thinking about changing.
are there any news? please implement this. its very important.
#GDPR #DSGVO
12 months later .. are there any news ?
I have the feeling that the requirement is not taken seriously enough.
9 months later .. are there any news ?
reducing the chatlogging lifetime makes no sense at all.
This is totally contrary to the concept of Persistent Chats and doesn't solve the problem.
4 months later .. are there any news ?
This is on our roadmap after the November release. There are a lot of implications and policies to consider when we provide this e.g. it'll have to be a setting that can be controlled at org level by the admin due to archival needs by certain orgs. We are looking into how best to provide this option to end users considering all scenarios e.g. does the chat get deleted from the sender and all receivers client? Does it also get deleted from server side or does it get archived and flagged on server so it doesn't show up in user's clients? All this is being considered for the release after November one.
Are there sny news? We urgently need this. Otherwise we cannot upgrade our users to Sametime 11.
Our Sametime Server 11.0FP1 is StandBy since April,
the updates Sametime 11.0FP2 is StandBy since August
But we cannot switch our users to the new server if the users cannot delete its own chat history.
I have worked with another customer today also interested in this enhancement.
Best Regards, Keith Kopanski
Senior Product Support Engineer, HCL Sametime
Are there any news? When can we expect the implementation? Our Sametime Server 11.0FP1 is StandBy since April, but we cannot switch our users to the new server if the users cannot delete its own chat history.
For us having the possibilities for the user to delete themself parts and full chat history is an absolute must. Without that user delete function we will not be able to use Sametime anymore.
Passwords do not belong in a chat - everyone should know that. But there are certainly other examples where trustworthy content may be transmitted, but the sender did not see it that way.
@Thomas
BTW: default for chatlogging lifetime is 90d / see administration guide or chatlogging.ini
CL_MONGO_HISTORY_TTL=90
The thing is: Even if it is GDPR- compliant: Some times I chat with colleagues and they e.g chat me a password for me to test something... and this password now sits there... in their and in my chat... visible for every bypasser without any possibility to be removed before the 30day or even 7day limit...
Nevertheless, the user should always have the possibility to delete it himself. Status changed to Likely to implement. That gives us hope. Thank you.