Skip to content
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

[MM-188] Add feature to update custom status and status of the user during meeting #355

Closed
wants to merge 6 commits into from

Conversation

ayusht2810
Copy link
Contributor

@ayusht2810 ayusht2810 commented Feb 6, 2024

Summary

  • Added feature to update custom status of the user during meeting
  • Added feature to set status of the user from the options provided in the dropdown during the meeting

Ticket Link

#228

Screenshots

image
image

What to test?

  • Custom status gets updated during a meeting.
  • User status gets updated to the selected value during a meeting.
  • No change in user status during overlapping meetings or when there are no attendees.
  • No change of user custom status during overlapping meetings, when there are no attendees, or when there is already a custom status set.

How to test?

  • Create a meeting in the MS Calendar.
  • Run slash command /mscalendar settings, select an option from the Update Status setting, and check the updated status on the Mattermost.
  • Run slash command /mscalendar settings, set the Set Custom Status setting to yes, and check the updated custom status on the Mattermost.

@ayusht2810 ayusht2810 self-assigned this Feb 6, 2024
@ayusht2810 ayusht2810 linked an issue Feb 6, 2024 that may be closed by this pull request
@codecov-commenter
Copy link

codecov-commenter commented Feb 6, 2024

Codecov Report

Attention: Patch coverage is 42.85714% with 68 lines in your changes are missing coverage. Please review.

Project coverage is 24.72%. Comparing base (b1bcb7b) to head (0ceffcd).

Files Patch % Lines
server/mscalendar/availability.go 53.68% 33 Missing and 11 partials ⚠️
server/mscalendar/welcome_flow.go 0.00% 13 Missing ⚠️
server/mscalendar/settings.go 0.00% 9 Missing ⚠️
server/mscalendar/welcomer.go 0.00% 2 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master     #355      +/-   ##
==========================================
+ Coverage   23.71%   24.72%   +1.01%     
==========================================
  Files          62       62              
  Lines        3087     3163      +76     
==========================================
+ Hits          732      782      +50     
- Misses       2274     2292      +18     
- Partials       81       89       +8     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Contributor

@fmartingr fmartingr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hey @ayusht2810, thanks for taking care of this! I just added some minor comments, will defer to @mickmister & @matthewbirtch on flow logic.

I've pointed out some minor things.

Also some screenshots with the changes to easily see the changes without a cloud/local env would be awesome. (I'm talking here about the settings, specifically).

server/mscalendar/notification.go Outdated Show resolved Hide resolved
server/mscalendar/availability.go Outdated Show resolved Hide resolved
server/mscalendar/availability.go Show resolved Hide resolved
server/mscalendar/availability.go Show resolved Hide resolved
@mickmister mickmister added 2: Dev Review Requires review by a core committer 3: QA Review Requires review by a QA tester labels Feb 20, 2024
Copy link
Contributor

@mickmister mickmister left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work on this @ayusht2810 👍 This feature is pretty complicated in general

I have some comments for discussion before approving. I'd also like to get QA eyes on this before approval as well

@@ -157,7 +159,7 @@ func (m *mscalendar) setUserStatuses(users []*store.User, calendarViews []*remot
numberOfLogs, numberOfUserStatusChange, numberOfUserErrorInStatusChange := 0, 0, 0
toUpdate := []*store.User{}
for _, u := range users {
if u.Settings.UpdateStatus {
if u.Settings.UpdateStatusFromOptions != NotSetStatusOption || u.Settings.SetCustomStatus {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What about the existing UpdateStatus setting? Can we still respect that setting? Also, it's probably good to lump this check into a method on the u.Settings struct. We can factor in the legacy UpdateStatus setting there if needed as well

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mickmister I think there is some confusion here.

  • There were two settings before:

    1. If a user needs to change their status or not.
    2. If yes, it should be away or DND.
  • In the new flow we have s single setting for this. The user gets three options in a single setting.

    1. Away
    2. DND
    3. Do not set

Because of the new flow the UpdateStatus field does not exist anymore

server/mscalendar/welcomer.go Outdated Show resolved Hide resolved
Comment on lines 23 to 24
user.Settings.UpdateStatusFromOptions = value.(string)
s.Tracker.TrackAutomaticStatusUpdate(userID, value.(string), "flow")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same here to avoid panic. We pretty much never want to do the syntax .(type) without the double return value syntax

Suggested change
user.Settings.UpdateStatusFromOptions = value.(string)
s.Tracker.TrackAutomaticStatusUpdate(userID, value.(string), "flow")
stringValue, _ := value.(string)
user.Settings.UpdateStatusFromOptions = stringValue
s.Tracker.TrackAutomaticStatusUpdate(userID, stringValue, "flow")

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wondering why this didn't panic when value is checked as a bool above. Maybe a change in the behavior of Go in some release, though that's highly doubtful. @hanzei Curious what you think about this

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Type assertions with a check variable do not panic if the type doesn't match.

The value of ok is true if the assertion holds. Otherwise it is false and the value of v is the zero value for type T. No run-time panic occurs in this case.

https://go.dev/ref/spec#Type_assertions

See https://goplay.tools/snippet/ETzO-4sgImZ as an example. Only L8 panics, not L6.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@hanzei Yes but there was no check variable on this before

server/store/flow_store.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
Comment on lines +274 to +275
if checkOverlappingEvents(events) {
return "Overlapping events, not setting a custom status", isStatusChanged, nil
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reasoning for never setting status if the events overlap? Does this check ever occur before the first event?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What's the reasoning for never setting status if the events overlap?

It was mentioned in the issue here: #228 (comment)

Does this check ever occur before the first event?

@mickmister Not sure what you are asking here. Can you please provide some details?

Comment on lines 278 to 280
if events[0].IsCancelled {
return "Event cancelled, not setting custom status", isStatusChanged, nil
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume the events are sorted by start time? Edit: This is implicitly being done in the call to checkOverlappingEvents above. Note that if the order of operations changes, this will result in a bug here

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Updating the logic to filter out the canceled event in the filterBusyEvents function.

Comment on lines 554 to 556
sort.Slice(events, func(i, j int) bool {
return events[i].Start.Time().UnixMicro() < events[j].Start.Time().UnixMicro()
})
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This pattern is a little dangerous - implicitly sorting these events in this function. This will have side effects as other piece of code relying on the original order will have the incorrect assumption. Maybe that's not an issue, but something to keep in mind

})

for i := 1; i < len(events); i++ {
if events[i-1].End.Time().UnixMicro() > events[i].Start.Time().UnixMicro() {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be >=?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@mickmister I think what we have is fine as an event can end at 6:30 and another can start at 6:30. I don't think we should consider this as overlapping. Please let me know your opinions on this.

server/mscalendar/availability_test.go Show resolved Hide resolved
@mickmister
Copy link
Contributor

mickmister commented Feb 20, 2024

@cwarnermm Can you please take a look at the user-facing strings in this PR? Thanks 🙂

These are primarily in server/mscalendar/welcome_flow.go

Copy link
Member

@cwarnermm cwarnermm left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Provided editorial feedback inline for in-product messages.

server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
server/mscalendar/welcome_flow.go Outdated Show resolved Hide resolved
@raghavaggarwal2308
Copy link
Contributor

raghavaggarwal2308 commented Mar 4, 2024

@mickmister @cwarnermm @hanzei @fmartingr Because of a lot of conflicts on this PR after merging #267 PR. We are creating a separate PR by creating a new branch from the master and cherry-picking the commits of this PR there so that the changes on the master branch are not affected by mistake.

All the review fixes mentioned in this PR are fixed there

New PR link: #359

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2: Dev Review Requires review by a core committer 3: QA Review Requires review by a QA tester
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Use custom status for "In a meeting" user state
7 participants