-
-
Notifications
You must be signed in to change notification settings - Fork 4k
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
User status not resetting correctly after a call #31532
Comments
Some more debugging seems to reveal, even while being in a call, the status is already:
|
The update seems to come from the heartbeat. If I keep the call open for some time and then toggle between tabs it will update to "online" at some point |
The online which comes from the event is more important than the "away" from the in call status: server/apps/user_status/lib/Listener/UserLiveStatusListener.php Lines 98 to 102 in 215aef3
Potential fix would be to check the messageId in the UserLiveStatusListener as well. |
Found it
this was isUserDefined true
I combined it to false as I followed
but well the status exists because the line before created it: server/apps/user_status/lib/Connector/UserStatusProvider.php Lines 66 to 67 in 2cb48f4
And therefor server/apps/user_status/lib/Listener/UserLiveStatusListener.php Lines 83 to 88 in 215aef3
does not exit anymore puh, that was a bit.... |
Bug description
Could be related to #31192 but not really sure. The way the deletion works seems unchanged.
When the bug happens, there are 2 status set for the user:
The problem is that on the call row the status is already "Online" and not away" as expected, which is why the deletion in
server/apps/user_status/lib/Service/StatusService.php
Line 516 in 9292834
doesn't work anymore.
But this was also the case before #31192
server/apps/user_status/lib/Service/StatusService.php
Lines 473 to 476 in 17db07c
The question is why the status is not away but online already. Any ideas when this would be updated?
Steps to reproduce
Expected behavior
Status is reset back to "Online"
Installation method
Manual installation
Operating system
Debian/Ubuntu
PHP engine version
PHP 7.4
Web server
Apache (supported)
Database engine version
MariaDB
Is this bug present after an update or on a fresh install?
Updated from a minor version (ex. 22.2.3 to 22.2.4)
Are you using the Nextcloud Server Encryption module?
Encryption is Disabled
What user-backends are you using?
Configuration report
No response
List of activated Apps
Nextcloud Signing status
No response
Nextcloud Logs
No response
Additional info
No response
The text was updated successfully, but these errors were encountered: