UnacknowledgedEventCount > 0 is only partly useful as a session group selector
UnacknowledgedEventCount > 0 indeed creates a group, but if you want to read the messages before connecting you must go find the session in the other hierarchy, and the moment one clicks the messages button in the interface (6.x for sure), the messages for that session are marked read, and the session is dropped from the list, and because messages is now the flagged function this will repeat until the group is empty or one manages to click another section (hey it could happen if you have enough unacknowledged messages).
Obviously awesome response to have sessions that no longer meet the criteria dropped from most group (I use tbd.msi as my "go to" download that puts the client in "New Sessions" for Access, then I edit, obviously once I change CustomProperty1 it should and does disappear from that group and appear in the right group.
So perhaps this should be addressed in some other manner, but I have session group names that are a little "too long" such that I can't see the green dot after it, so the special group for unack was exciting at the first of the week, then I found the "catch".
Customer support service by UserEcho
Hey Josh,
We fixed the issue w/ the notification dot not being visible due to long session names in 6.5, see
https://control.product.connectwise.com/communities/6/topics/1361-red-dot-chat-message-indicator-is-hidden-if-host-page-not-wide-enough
Were you also asking for a way to group chats received within a period of time? Something similar to https://control.product.connectwise.com/communities/1/topics/143-make-a-group-by-the-session-groups-with-all-pcs-that-have-a-chat-in-the-last-24-hours-etc
Kristen,
I think the "period of time" fix would address the issue, though in a roundabout way. While we don't use chat, I have a group setup like Silas below. It just shows machines with the notification dot. Clicking on the chat dialog marks the chat as "Acknowledged", then immediately makes the machine disappear from the group.
We are sitting in the same boat.
We have about 1000 clients, and the only thing to figure out from which client the unread messages came from, is with this filter:
But unfortunately, you have to keep in mind which client it was, because it falls out as soon as you click on the clients chat tab.
There definitely needs to be a better solution than that. This filter group is not even a solution..
Thanks for implementing that soon.
We have over 1100 clients connected now so similarly thought of creating a "Chat Requests" group with the code:
We can confirm that switching to the chat tab will quickly clear the entire group. The only real answer from a user perspective is to take a screen shot or clip first so you retain the information. But that doesn't fix the issue of having to then search your inventory to find the requester.
It seems like one solution would be to have to either reply or manually acknowledge the event (preferably NOT a pop-up) instead of having it clear automatically.
This was working fine until now, after the update to 22.9.10231.8343 the problem resurfaced
A new product change is affecting how the dots show up/disappear, please see below and have a look at the Version 2022.9 section
Red dot indicating new message in chat not disappearing after reading a message - ConnectWise