Add an API to set and rollback the user status

[CarlSchwan]

Signed-off-by: Carl Schwan [email protected]

[AndyScherzinger]

@CarlSchwan what's the status on this PR? (as in label)? :)

[CarlSchwan]

@CarlSchwan what's the status on this PR? (as in label)? :)

Mostly waiting on some UX discussion I had this morning with an Jan an Joah. This now needs some small changes.

[ChristophWurst]

After a bit of thinking I come to the conclusion that this might not be the best approach. The way it's currently designed follows a push principle. Anyone who wants to change a status has to actively propagate it. This is great for Talk as in Talk there is some back-end code running when this happens. For other systems like CalDAV there is no such thing to hook in. The system is totally passive and doesn't do anything at the start of an event. So we wouldn't actually be able to update the user status at the beginning of a busy event, nor reset it after.

Moreover the stateful design of the API where you say switch to the busy status now and switch back to the default status won't work well with concurrent status updates. Imagine you have a call that takes place 8 to 10 and a busy event from 9 to 11. At 8 Talk would set the status to busy, at 10 Caldav would set it to busy, but wouldn't change anything. At 10 Talk would reset the status, although it should stay busy until 11. You could keep a counter that increments with every time someone pushes a busy state and decrements when it ends, but this is prone to errors. As soon as the counter isn't updated just one time, the user might stay in busy state forever.

With a pull design you would ask x registered apps about their busy state. If at least one tells you the user is currently busy then you switch status. As soon as no one reports busy you switch back. The pull works for Talk (AFAIK sessions of current calls are in the DB and can be queried) and CalDAV. This info can be cached so we don't ask all apps for every user status query and possibly only do this like once per minute. The concurrent busy states also do not cause a problem here. In the worst case one of the apps with busy status doesn't work and the user is shown as available. But the status wouldn't remain in an undefined state.

Hope this makes sense.

[CarlSchwan]

Hope this makes sense.

Yes, it makes sense. I didn't think about the concurrent busy state and this is something that would actually happen a lot in real life (the same meeting is both in calendar and in the talk application). So I guess each app could provide a IUserStatusProvider interface. The normal user status apps would provide the existing one, and both talk and calendar would also provide one and a Manager class would merge the results.

One thing I'm still not sure how do we handle the case of a user wanting to revert a status change. With the current push model, we can just let them submit a request to get back to the previous status, but with a pull model, we would need to store that the user doesn't want to change their status for a specific talk meeting or calendar event. I guess this should also be something that the IUserStatusProvider allows to do with e.g. function revertCurrentStatusChanges(IUser $user);?

[ChristophWurst]

With the current push model, we can just let them submit a request to get back to the previous status, but with a pull model, we would need to store that the user doesn't want to change their status for a specific talk meeting or calendar event. I guess this should also be something that the IUserStatusProvider allows to do with e.g. function revertCurrentStatusChanges(IUser $user);?

What's the semantic of resetting the status manually? Is this permanent? Is this based on a specific task? Is this based on a specific time range?

[CarlSchwan]

With the current push model, we can just let them submit a request to get back to the previous status, but with a pull model, we would need to store that the user doesn't want to change their status for a specific talk meeting or calendar event. I guess this should also be something that the IUserStatusProvider allows to do with e.g. function revertCurrentStatusChanges(IUser $user);?

What's the semantic of resetting the status manually? Is this permanent? Is this based on a specific task? Is this based on a specific time range?

It's based on certain tasks. For example, it should be possible when for a user in a call to switch back to the previous message in case for example they aren't really away.

[ChristophWurst]

The exemption from the automated status is indeed a tricky problem, possibly in both approaches. Even with push approach you could have some scenario like where a user schedules a meeting. They join a minute earlier and see that their status changed to busy. They revert this, and the "backup" status is shown. Then the calendar app will again push the status to busy a minute later.

I think the status is either automatic and the system toggles between free and busy or fully manual.

For comparison Teams/O365 doesn't let you even change this. They always set your status by the info from the calendar. If you don't want to be seen as busy during an event you have to change the event busy property.

[CarlSchwan]

Error unrelated: git clone failed :/