Use custom status for "In a meeting" user state

[mickmister]

At the moment we give the user two options to have their status automatically set to "Away" or "Do not Disturb". Ideally we incorporate the new Custom Status feature that allows us to use a Calendar emoji and message to note that the user is in a meeting.

We can incorporate the meeting end time in the custom status message, something like "In a meeting until 10:00AM EDT", using whatever timezone the user that is in the meeting. This can't be adapted to the user that is viewing the status, because this message is constructed once, to set the custom status.

[mickmister]

@aaronrothschild @matthewbirtch Can I have some of your thoughts on this before I open the ticket for development?

[matthewbirtch]

@mickmister love the idea! One suggestion: instead of showing when the meeting ends as part of the custom status text (which won't match the reader's time zone anyway), I think we should use the expiry feature of custom statuses and automatically set the expiry time to match the end of the meeting. So the status will automatically be removed at the same time when the meeting ends

[mickmister]

I think we should use the expiry feature of custom statuses and automatically set the expiry time to match the end of the meeting. So the status will automatically be removed at the same time when the meeting ends

@matthewbirtch This plugin already manages the user's expiry time by monitoring the meeting's status:

• If the meeting is cancelled, the user's status will be adjusted accordingly
• If the meeting's end time is extended, the user's status will not be adjusted until it has ultimately ended

We could use the custom status expiry time as well, but then we would be using two different time tracking systems for this, and the plugin is already using this time monitoring for other operations. We may be able to use both time tracking systems (internally in the plugin and through the custom status expiry) simultaneously, though the only benefit would be to have that meeting time displayed to other users, and potentially cause issues with trying to change the status at the same time. The plugin also allows the user the choice of Away or DND for the meetings, so there is also this difference.

@larkox What do you think about whether or not we should incorporate the custom status expiry here? The main benefit of using the custom status expiry in this case is that the meeting's remaining duration will be shown to other users, though we will need to adjust the expiry if the meeting's times change.

[aaronrothschild]

I would err on the side of predictable. If we can leverage the "expiry" on custom status, the end-user will know when the status is going to change, otherwise it is effectively unknown to them when a status will change. I think this is more important in the other case, where a meeting ends early and the user doesn't understand why they are set to "in a meeting till 10:30".... with the expiry, it becomes visible to the user and they can change it at their will.

The edge case is actually extending the meeting....I find that rarely happens in real life, but you get out of meetings early relatively often.

[mickmister]

The edge case is actually extending the meeting....I find that rarely happens in real life, but you get out of meetings early relatively often.

@aaronrothschild This makes sense. And if the meeting does run long, the plugin has no way of knowing that it is still going. If the meeting length actually changes, the plugin can pick up on that and readjust the expiry to reflect that.

In the event that the meeting ends early, but the calendar event is not updated (idk if anyone ever does that), the user would probably manually change their status back to online manually. When the plugin notices that the user has manually changed their status during the meeting, the plugin knows not to mess with their status anymore.

I propose the following logic for the expiry:

• When the meeting starts, set the expiry to the end of the meeting
• If the meeting length changes, re-adjust the expiry appropriately

[mickmister]

Blocked on mattermost/mattermost#20851

[lh1022]

This would be a great feature to have - is it still blocked waiting on something?

[fmartingr]

We have been discussing this recently, the problems we tried to face are:

1. The meeting can end sooner or be modified while running, meaning that the custom status expiration wont match the modification.
2. The Mattermost Plugin API expose methods to change the user custom status, but not to revert to a custom status if they already have it.
   • This requires some testing with: SetUserStatusTimedDND(userId string, endtime int64): Check if the ExpiresAt is respected (documentation ignores that field) and if it does, what it does when the custom status expires (probably clear the custom status).

From my perspective, (1) is a completely non-issue. If the meeting ends sooner users can just remove the DND/Custom status themselves, and I have never been on a meeting that gets altered while we are on it. (2) is trickier, since I only use custom statuses for absences (like meetings) but there are other uses to it. So for me it's a non-issue as well, but I understand the concern for others.

The two possible scenarios are:

• Have a new Plugin API method that would let us set the custom status and away/dnd with an expiration, and the server would take care of resetting the custom status to the previous one (if there was one).
  • Alternatively, we could have a new PluginAPI method similar to RemoveUserCustomStatus but instead of removing it would reset it to the previous one.
  • This approach requires server changes so it would need to wait for a release and older Mattermost versions could not use it until upgraded.
• Handle it directly in the plugin. If the user didn't have a custom status set, we would set a custom status with expiration set to the meeting end time. If it has one, we will store the custom status on the plugin storage, and when we remove the DND/Away flag we would restore the custom status to the previous one as well.
  • In this case no server release would be required so this change will just be released with the plugin life cycle.

[mickmister]

@matthewbirtch: @fmartingr and I discussed this, and we are thinking we want the plugin to delegate the management of the custom status entirely to the core custom status feature if possible. This would mean the core custom status feature would need to be able to support "the time is up, so I'm going to set your custom status back to what you had it set to before, rather than just clearing the status".

What are your thoughts on introducing this to the custom status feature? Outside of the calendar/zoom plugin use case (as an aside, wondering about potential conflict of plugins fighting over custom status if we implement in multiple plugins), this would allow users to say "I'm OOO today so I'm setting my custom status to reflect that, but tomorrow I will automatically have my personalized custom status set again, without manually changing it back to that".

[matthewbirtch]

@mickmister I'm wondering if we could/should simplify this so that we don't have to worry about resetting their custom status after a meeting at all. If the user has their status already set manually, then maybe we assume they wouldn't want it changed programmatically at all. If they don't have their status set at all, then we can automatically set it for meetings. Thoughts? As a reference point, this is what Slack appears to do.

cc: @asaadmahmood for his thoughts on this too

[mickmister]

I'd like to get some feedback from customers requesting this. I can reach out to them

[fmartingr]

@mickmister I'm wondering if we could/should simplify this so that we don't have to worry about resetting their custom status after a meeting at all. If the user has their status already set manually, then maybe we assume they wouldn't want it changed programmatically at all. If they don't have their status set at all, then we can automatically set it for meetings. Thoughts? As a reference point, this is what Slack appears to do.

cc: @asaadmahmood for his thoughts on this too

Those were my thoughts exactly, this may be a non issue if we treat a custom status as what it is and avoid to override custom statuses if the user already have one set up. This will mean that people that use custom statuses for fun things (like having one always enabled) wont benefit from this feature, but that's ok for me.

[mickmister]

I'm fine with going forward with the approach of "if the user has a custom status set, do not automatically change it to 'in a meeting'". @esethna Do you have any thoughts on this?

[esethna]

@mickmister +1. Thanks!

[mickmister]

@matthewbirtch @esethna There is also the case of "this event is not actually a meeting". Like if you're going to lunch or running an errand. This applies not just to the custom status, but also to automated away/DND as well.

AFAIK there's no way for us to know if an event is actually a meeting. In the case of MSTeams, they may be able to handle this because they have their own system to recognize if an event is a meeting, though it's possible they too treat every "busy" event as a meeting.

An excerpt from MSTeams docs https://support.microsoft.com/en-us/office/change-your-status-in-microsoft-teams-ce36ed14-6bc9-4775-a33e-6629ba4ff78e:

If you’re in a meeting or call, Teams will automatically change your status to In a meeting or In a call (Busy) when not set to Do not disturb.

[matthewbirtch]

@mickmister I wondered about this. One way to assume it's not a meeting is if you are the only attendee. I wonder if we were to look at the attendees and see that you are the only one in the calendar event, we could treat it differently (e.g. not change your status).

[fmartingr]

@mickmister I wondered about this. One way to assume it's not a meeting is if you are the only attendee. I wonder if we were to look at the attendees and see that you are the only one in the calendar event, we could treat it differently (e.g. not change your status).

Maybe not for the custom status, but I want to be set DND on my lunch/errand events. In my personal case I would just not enable the custom status and would let DND do its job.

[mickmister]

@matthewbirtch @fmartingr @esethna I'd like to nail down the requirements before development starts on this. Should we give the user different options for what should change (DND and/or custom status), and how it should change (allow the user to configure to only affect DND if the event only has one person, and change custom status when we can infer that it's a meeting)

[fmartingr]

Now that I see all the different approaches we have with this one, I'm wondering if the "in a meeting" custom status should be handled by the calendar plugin or by another more specific plugin (zoom, teams, etc).

[matthewbirtch]

Now that I see all the different approaches we have with this one, I'm wondering if the "in a meeting" custom status should be handled by the calendar plugin or by another more specific plugin (zoom, teams, etc).

@fmartingr I would say it makes sense to be handled by the calendar plugin right now. There may be a case for video conferencing plugins to do this as well, but I think more meetings are likely scheduled in the users' calendar app rather than their video conferencing tool of choice.

I'd like to nail down the requirements before development starts on this. Should we give the user different options for what should change (DND and/or custom status), and how it should change (allow the user to configure to only affect DND if the event only has one person, and change custom status when we can infer that it's a meeting)

@mickmister when is development supposed to start on this?

Based on the conversation and based on other apps behave, Here's my stab at the requirements. We could certainly simplify if these are too complex, but these are my thoughts. Let me know what you guys think.

• Setting: "Update user presence automatically during meetings" [Away, Do Not Disturb, Don't change status]
  • If calendar event has other invitees, set to chosen status
  • Otherwise, don't set status automatically
  • If there are overlapping events, don't set the status.
• Setting: "Set custom status automatically during meetings" [Yes, No]
  • If calendar event has other invitees, set to "📆 In a meeting"
  • If calendar event contains "Vacation" in the title, set to "🌴 On vacation"
  • If calendar event contains "Lunch" in the title, set to "🍔 Lunch break"
  • If calendar event contains "OOO, PTO, or Out of office" in the event title, set the custom status to "⛔️ Out of Office"
  • Otherwise, don't set custom status
  • If there are overlapping events, don't set the custom status.
  • If a custom status is currently set, don't automatically set the custom status

[fmartingr]

@fmartingr I would say it makes sense to be handled by the calendar plugin right now. There may be a case for video conferencing plugins to do this as well, but I think more meetings are likely scheduled in the users' calendar app rather than their video conferencing tool of choice.

But the video conferencing tool actually knows if the user is currently on a meeting or not, so the "On a meeting" custom status is actually accurate. It doesn't need to be scheduled in the tool for this to work.

[matthewbirtch]

But the video conferencing tool actually knows if the user is currently on a meeting or not, so the "On a meeting" custom status is actually accurate. It doesn't need to be scheduled in the tool for this to work.

That's true, but what about in-person meetings? In an in-person office setting, there may not be a video conference link at all. In that case the calendar is the source of truth for scheduled meetings. For that reason, I think the calendar is going to be more reliable across use cases

[fmartingr]

That's true, but what about in-person meetings? In an in-person office setting, there may not be a video conference link at all. In that case the calendar is the source of truth for scheduled meetings. For that reason, I think the calendar is going to be more reliable across use cases

You are right on that one, I just don't like the if..else approach of getting event titles and match that to statuses. We are assuming things in there, or making people use English, for example.

That said, it may be a good first iteration and I don't have any other options to offer :)

[matthewbirtch]

You are right on that one, I just don't like the if..else approach of getting event titles and match that to statuses. We are assuming things in there, or making people use English, for example.

Fair point on the language. Maybe there is a smart way to handle it based on the user's language setting and providing translations for these.

We could start with simpler logic:

Setting: "Update user presence automatically during meetings" [Away, Do Not Disturb, Don't set status for me]

• If the calendar event has other invitees, set to the chosen status
• Otherwise, don't set status automatically
• If there are overlapping events, don't set the status.

Setting: "Set custom status automatically during meetings" [Yes, No]

• If the calendar event has other invitees, set to "📆 In a meeting" (ideally translate to chosen language)
• Otherwise, don't set custom status
• If there are overlapping events, don't set the custom status.
• If a custom status is currently set, don't automatically set the custom status

[fmartingr]

You are right on that one, I just don't like the if..else approach of getting event titles and match that to statuses. We are assuming things in there, or making people use English, for example.

Fair point on the language. Maybe there is a smart way to handle it based on the user's language setting and providing translations for these.

We could start with simpler logic:

Setting: "Update user presence automatically during meetings" [Away, Do Not Disturb, Don't set status for me]

• If the calendar event has other invitees, set to the chosen status
• Otherwise, don't set status automatically
• If there are overlapping events, don't set the status.

Setting: "Set custom status automatically during meetings" [Yes, No]

• If the calendar event has other invitees, set to "📆 In a meeting" (ideally translate to chosen language)
• Otherwise, don't set custom status
• If there are overlapping events, don't set the custom status.
• If a custom status is currently set, don't automatically set the custom status

I like this approach a lot more, with some good help text hopefully is shouldn't be confusing to the user and we avoid guessing what the meeting is for.

[mickmister]

@fmartingr @matthewbirtch Do you know where we landed on the "keep user's custom status intact when we change it back to normal"?

As in, I hypothetically have my own custom status on by default, and the plugin changes it to "in a meeting". After the meeting, should the plugin then change it back to the previous one I had it set to? @fmartingr and I were thinking maybe this should be in the main product, where the user can set a temporary status change, and the system will set it back to the previous status when the time is finished. I thought we had a thread on this but not sure where now

[mickmister]

I'm asking ☝️ because that's an important piece to decide what code should go where

[matthewbirtch]

I'm asking ☝️ because that's an important piece to decide what code should go where

@mickmister, yep, we decided that if the user has their own custom status already set, we simply will not automatically override their customer status for them.

[mickmister]

@matthewbirtch Hmm that's unfortunate as it limits user to choose which feature they want to use (custom status, or having automatic meeting statuses). Do you mind if we take a poll on this from users on the community server?

[matthewbirtch]

@matthewbirtch Hmm that's unfortunate as it limits user to choose which feature they want to use (custom status, or having automatic meeting statuses). Do you mind if we take a poll on this from users on the community server?

I'm totally fine with a poll on this topic if you'd prefer. I guess I thought we were good to move forward though based on the consensus back in December.

I'm fine with going forward with the approach of "if the user has a custom status set, do not automatically change it to 'in a meeting'".

One other thing to note, if users are expecting it to behave similarly to Slack, the Google calendar app for Slack also does this: "the Google Calendar app won't override any status you've set yourself"

[mickmister]

One other thing to note, if users are expecting it to behave similarly to Slack, the Google calendar app for Slack also does this: "the Google Calendar app won't override any status you've set yourself"

@matthewbirtch I think that's enough validation of the approach. Thanks for the link 👍

[mickmister]

@raghavaggarwal2308 This ticket's requirements have been solidified now. Please take a look when you have the chance, or delegate accordingly. Essentially, when we change the user's status to DND/Away, we want to:

• If the user does not have a custom status set, then set their custom status to "In a meeting" with the calendar emoji. We will set the expiry of the custom status to the end of the meeting, so other users can see when the meeting will end.
• When the meeting ends, we should probably explicitly change it back, just in case there is some conflict with setting it again with another meeting coming up. This case needs to be taken into account either way.
• Along with details from this comment Use custom status for "In a meeting" user state #228 (comment)

cc @matthewbirtch @fmartingr Please let me know if I misunderstood or forgot something

[mickmister]

or making people use English

@matthewbirtch Should the "In a meeting" string be translated to other languages? That will be difficult as that string is put into the status itself, so it wouldn't be translatable to the viewer of the status. This is coming up because we need a way for the plugin to know that itself had set the custom status, by doing something like

if status.Status == "In a meeting" && status.Emoji == ":calendar:" {
    // handle the case where the plugin set this value
}

Also this plugin currently doesn't have translations so maybe that's out of scope for that reason too. I wonder how localization has been taken into account into the custom status suggestions already?

[matthewbirtch]

@matthewbirtch Should the "In a meeting" string be translated to other languages? That will be difficult as that string is put into the status itself, so it wouldn't be translatable to the viewer of the status.

Also this plugin currently doesn't have translations so maybe that's out of scope for that reason too. I wonder how localization has been taken into account into the custom status suggestions already?

@mickmister Custom status suggestions do support translations and they translate to the user's selected language, but it will display in that language for everyone else who sees their status regardless of their own personal language preference.

In light of all this, the options are:

1. 'In a meeting' is translated to the user's language preference, but all other users see it in that language regardless of their own personal language preference
2. No translation at all and we leave this out of the requirements for this first iteration

I think I'm more of an advocate for option 1 since it's reasonable to assume the user is communicating with others in the language they have set as their preferred language in MM. Thoughts?

[mickmister]

I think I'm more of an advocate for option 1 since it's reasonable to assume the user is communicating with others in the language they have set as their preferred language in MM. Thoughts?

@matthewbirtch Since we currently don't have a way to translate strings in the plugin, I'm not sure how/where this translation would be accessed by the plugin. I'm thinking we will have to support just English for the first iteration. Getting translations into the plugin projects is on our roadmap but currently no ETA

[matthewbirtch]

I'm thinking we will have to support just English for the first iteration. Getting translations into the plugin projects is on our roadmap but currently no ETA

Makes sense @mickmister. Can we track this as a later improvement?

[mickmister]

@matthewbirtch Yep captured it here #354

[ayusht2810]

@mickmister I started working on and exploring the above issue and have some clarifications. Please let me know your thoughts on the below points. Also, please let me know if I am missing something here.

1. The below existing settings are present in the plugin.

   • Do you want to update your status on Mattermost when you are in a meeting?
   • Do you want to get a confirmation before automatically updating your status?
   • Do you want to still receive Mattermost notifications while you are on a meeting?\nIf you want notifications, you will be set as "Away" during meetings. If not, you will be set as "Do Not Disturb".  

   They will be updated to a single setting. Let's say, Do you want to update your status automatically on Mattermost when you are in a meeting? having three options: Away, Do not disturb, and Don't set status for me.
   Also, we will be adding a new setting in the plugin to set custom status. Let's say, Do you want to set custom status automatically on Mattermost when you are in a meeting?
     

2. If the user does not have a custom status set, then set their custom status to "In a meeting" with the calendar emoji. We will set the expiry of the custom status to the end of the meeting, so other users can see when the meeting will end.

   I checked the documentation of plugin APIs and found there was no plugin API present to get the user's current custom status. I also checked the code of the Mattermost server, and I think we don't have the plugin API exposed in the code for GetUserCustomStatus. How do you think we should approach the above use case, or am I missing something here?
    

3. AFAIK about the current feature, the plugin updates the current status of the user through a runSyncJob. Even if the meeting has not started (but is about to start), we update the status of the user when the job runs, and it gets removed when the meeting ends (the status doesn't get updated as soon as the meeting ends, rather, it gets updated when the job re-runs). Do we need to follow the same behaviour for the updated feature?

4. Also, if we update our status while being in the meeting to something other than Busy, the status gets updated to the previous status of the user, even if the user is still in the meeting. Should we follow this same behaviour in the new feature?
   

[fmartingr]

2. > If the user does not have a custom status set, then set their custom status to "In a meeting" with the calendar emoji. We will set the expiry of the custom status to the end of the meeting, so other users can see when the meeting will end.

I checked the [documentation](https://developers.mattermost.com/integrate/reference/server/server-reference/#API.UpdateUserCustomStatus) of plugin APIs and found there was no plugin API present to get the user's current custom status. I also checked the code of the Mattermost server, and I think we don't have the plugin API exposed in the code for [GetUserCustomStatus](https://github.com/mattermost/mattermost/blob/60df49652eda8cdc582b68e6a2de6de620fe529c/server/public/plugin/api.go#L291). How do you think we should approach the above use case, or am I missing something here?

IIRC we can use the GetUser API. The resulting user should have a CustomStatus method.

[mickmister]

The below existing settings are present in the plugin.
Do you want to get a confirmation before automatically updating your status?

@ayusht2810 I think we'll still want this "confirmation" option

AFAIK about the current feature, the plugin updates the current status of the user through a runSyncJob. Even if the meeting has not started (but is about to start), we update the status of the user when the job runs, and it gets removed when the meeting ends (the status doesn't get updated as soon as the meeting ends, rather, it gets updated when the job re-runs). Do we need to follow the same behaviour for the updated feature?

I'm not sure I understand. In general this feature should work the same way and use the same mechanisms for timing etc. There is a slight difference in that the custom status supports stating how long the user will have their status set, so other users can see how long the user will be in the meeting.

Also, if we update our status while being in the meeting to something other than Busy, the status gets updated to the previous status of the user, even if the user is still in the meeting. Should we follow this same behaviour in the new feature?

In general we should follow the same patterns as currently done in the plugin. Do you see risk in how it's currently implemented?

[ayusht2810]

In general we should follow the same patterns as currently done in the plugin. Do you see risk in how it's currently implemented?

@mickmister No, I think we can start on the development of the above feature.

[mickmister]

If there are overlapping events, don't set the custom status.

@matthewbirtch I'm not sure I understand this. If I'm in a meeting, the plugin should set my status accordingly. But according to this comment if there is another meeting I'm invited to that's going on at the same time, then it shouldn't change my status?

[matthewbirtch]

If there are overlapping events, don't set the custom status.

@matthewbirtch I'm not sure I understand this. If I'm in a meeting, the plugin should set my status accordingly. But according to this comment if there is another meeting I'm invited to that's going on at the same time, then it shouldn't change my status?

@mickmister I can't honestly quite recall why we wanted this requirement. We can probably skip it.