You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current user status automation has no hierarchy for when a status should be overwritten by the automation, and when not. This leads to behaviour such as the automation overwriting custom status messages even though the users intention is not to show the automation message.
For clarity's sake, the following definitions apply: status or user status: the dot next to the user avatar - green dot, yellow half moon, red circle with white line, none (for invisible):
Status message or message: The combination of emoji and custom text displayed below a users name:
Clean up is_user_defined status field in the code
Currently, this field is not worked with properly and is used inflationary - making this field practically useless. When cleaned up, use this field to determine who set the status message, not the user status.
Decouple the user status and the status message.
Implement the following:
status hierarchy
1. INVISIBLE
3. DND
4. AWAY
5. ONLINE
The new "BUSY" status can be removed / ignored for now. The higher status overwrites the lower status but not in reverse.
Message hierarchy and fixed CONSTs for these messages
1. IN A CALL
2. OUT SICK
3. VACATION
4. OUT OF OFFICE
5. IN A MEETING
6. CUSTOM STATUS
Higher message can overwrite lower ones but not in reverse.
Leave the status to the availability automation and the heartbeat. A user can overwrite their status according to the hierarchy. The availability automation should only ever overwrite an online status. Check if the OOO status needs to adjust the status too after Out-of-office: Update user status #41378 was implemented.
Add a restoration mechanism that allows to restore the custom message if one was set before a message type 1-5 was written. (Or adjust the backup functionality to work this way). A new line in the DB should be written for any new message.
A new user defined message must overwrite any current message, automated or not. For this to work, a timestamp comparison is needed, and that is why we need 4. If the automated message was set before the custom message, the custom message takes precedence.
Extend documentation on how to set up "TRANSPARENT" calendar events to make the automation more accurate, and mention the automation in the Calendar documentation.
The text was updated successfully, but these errors were encountered:
miaulalala
changed the title
feat(user_status): Automation improvements and handling of custom messages
Automation improvements and handling of custom messages fur user status
Apr 26, 2024
Is there a option to disable user status automation ? In my company, we prefer to set up the status manually, and for now it's modified automatically each time we have an event in calendar, but we use events also just to organize ourselves and get a notification not to forget something. It's painfull to set up each event as "not busy" each time we create an event (3 clics on thunderbird, and has to think to do this, impossible for a 30 persons team...).
If it doesn't already exists, it would be great to be able to enable or disable status automation with calendar, and just keep online/offline status as automatic.
Follow up to #31177
Summary
Discussed and approved by @jancborchardt
The current user status automation has no hierarchy for when a status should be overwritten by the automation, and when not. This leads to behaviour such as the automation overwriting custom status messages even though the users intention is not to show the automation message.
For clarity's sake, the following definitions apply:
![image](https://private-user-images.githubusercontent.com/7427347/282524297-df28cac7-1d80-4b21-b779-9b59f864508f.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU5ODMxODQsIm5iZiI6MTcyNTk4Mjg4NCwicGF0aCI6Ii83NDI3MzQ3LzI4MjUyNDI5Ny1kZjI4Y2FjNy0xZDgwLTRiMjEtYjc3OS05YjU5Zjg2NDUwOGYucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTBUMTU0MTI0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9NTkxYjM2NDcyODMyYjQ3MzUxZTU3YjM4YmFhODllNGYyMWNiZmRkNWEzNDRlNGI5NjVlODMwYjFjNjMyOGEyZiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.oj79-WUacXA2gRO1k4aSr6OsgMExE6e828N_N3mZoPU)
status or user status: the dot next to the user avatar - green dot, yellow half moon, red circle with white line, none (for invisible):
Status message or message: The combination of emoji and custom text displayed below a users name:
![image](https://private-user-images.githubusercontent.com/7427347/282524132-2536ffd2-0b03-46a4-b1cf-d1f592829545.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MjU5ODMxODQsIm5iZiI6MTcyNTk4Mjg4NCwicGF0aCI6Ii83NDI3MzQ3LzI4MjUyNDEzMi0yNTM2ZmZkMi0wYjAzLTQ2YTQtYjFjZi1kMWY1OTI4Mjk1NDUucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI0MDkxMCUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNDA5MTBUMTU0MTI0WiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MjY2NmZlZTkzZjViYWIwNGI4NTM2ZjBkNDAwMjkyZGVkMjdiZTI3MDA3YmFiZGU3MDRhY2MyNzg2YjU5OGU4ZiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QmYWN0b3JfaWQ9MCZrZXlfaWQ9MCZyZXBvX2lkPTAifQ.G77zIgYd9qzT6S--F0ydQPG4B7vee7d-OlTg4hQuu90)
Clean up
is_user_defined
status field in the codeCurrently, this field is not worked with properly and is used inflationary - making this field practically useless. When cleaned up, use this field to determine who set the status message, not the user status.
Decouple the user status and the status message.
Implement the following:
The new "BUSY" status can be removed / ignored for now. The higher status overwrites the lower status but not in reverse.
Higher message can overwrite lower ones but not in reverse.
Leave the status to the availability automation and the heartbeat. A user can overwrite their status according to the hierarchy. The availability automation should only ever overwrite an online status. Check if the OOO status needs to adjust the status too after
Out-of-office: Update user status #41378 was implemented.
Add a restoration mechanism that allows to restore the custom message if one was set before a message type 1-5 was written. (Or adjust the backup functionality to work this way). A new line in the DB should be written for any new message.
A new user defined message must overwrite any current message, automated or not. For this to work, a timestamp comparison is needed, and that is why we need 4. If the automated message was set before the custom message, the custom message takes precedence.
Extend documentation on how to set up "TRANSPARENT" calendar events to make the automation more accurate, and mention the automation in the Calendar documentation.
The text was updated successfully, but these errors were encountered: