[Bug]: User status automation sets status to *Away* despite activity

[ChristophWurst]

⚠️ This issue respects the following points: ⚠️

• This is a bug, not a question or a configuration/webserver/proxy issue.
• This issue is not already reported on Github OR Nextcloud Community Forum (I've searched it).
• Nextcloud Server is up to date. See Maintenance and Release Schedule for supported versions.
• I agree to follow Nextcloud's Code of Conduct.

Bug description

#31177 should set user status to busy/in a meeting when there is an event and leave it untouched otherwise. But the online status is now always Away outside of events.

Steps to reproduce

0. Ensure the test user has calendars but opening the Calendar app once
1. Ensure the user has an email address set
2. Have no ongoing events
3. Set personal availability so you are current out of office
4. Clear oc_user_status
5. Reload the page twice

Expected behavior

Show as Online

Installation method

None

Nextcloud Server version

28

Operating system

None

PHP engine version

None

Web server

None

Database engine version

None

Is this bug present after an update or on a fresh install?

None

Are you using the Nextcloud Server Encryption module?

None

What user-backends are you using?

• Default user-backend (database)
• LDAP/ Active Directory
• SSO - SAML
• Other

Configuration report

No response

List of activated Apps

No response

Nextcloud Signing status

No response

Nextcloud Logs

No response

Additional info

No response

[miaulalala]

\OCA\UserStatus\Listener\UserLiveStatusListener::handle needs to be modified to update just the status to ONLINE if the user is online.

[nickvergessen]

Btw for me the availability DND also does not happen anymore. Not sure if that is the same cause, my assumption from the DB is yes:

MariaDB [oc]> SELECT * FROM oc_user_status WHERE user_id IN ('myname', '_myname');
+-------+---------+---------+------------------+-----------------+--------------+-------------+--------------------+----------+-----------+--------------------------+
| id    | user_id | status  | status_timestamp | is_user_defined | message_id   | custom_icon | custom_message     | clear_at | is_backup | status_message_timestamp |
+-------+---------+---------+------------------+-----------------+--------------+-------------+--------------------+----------+-----------+--------------------------+
| 63140 | _myname | offline |       1700113209 |               0 | NULL         | ?️           | Dragons are back   |     NULL |         1 |               1700112273 |
| 63882 | myname  | away    |       1700199400 |               1 | availability | NULL        |                    |     NULL |         0 |                        0 |
+-------+---------+---------+------------------+-----------------+--------------+-------------+--------------------+----------+-----------+--------------------------+
``

[ChristophWurst]

Cleared my local status and set a conditional breakpoint for status=away. First trigger was at

server/apps/user_status/lib/Service/StatusService.php

Line 166 in 158aedb

$calendarStatus->getStatus(),

.

[ChristophWurst]

Btw for me the availability DND also does not happen anymore

It is related. #40615 set the status and creates a backup, but never reverts. There can only be one backup. If the availability DND automation tries to backup as well it fails.

#41570 improves this bit so that calendar automation does revert again, so there is a backup slot for the availability DND automation. There is still a conflict if a user has an event happening into or inside unavailable times. Then either one or the other automation wins.

@nickvergessen says this problem was also there for calls. That is why the availability DND automation resets call automation. We can do the same if availability DND is of higher priority than calendar automation.

[ChristophWurst]

The Away bug is not reproducible if a user has no email set because \OCA\DAV\CalDAV\Status\StatusService::processCalendarAvailability has an early return for that condition.

Same thing happens if the user has no calendars.

Steps to reproduce adjusted.

[nickvergessen]

Same thing happens if the user has no calendars.

This was it for me.

Now I can reproduce locally and your PR fixes this angle at least.