-
Notifications
You must be signed in to change notification settings - Fork 24
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
Conversation
Codecov ReportAttention: Patch coverage is
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. |
There was a problem hiding this 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).
…move extra condition
There was a problem hiding this 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 { |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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:
- If a user needs to change their status or not.
- 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.
- Away
- DND
- Do not set
Because of the new flow the UpdateStatus
field does not exist anymore
server/store/flow_store.go
Outdated
user.Settings.UpdateStatusFromOptions = value.(string) | ||
s.Tracker.TrackAutomaticStatusUpdate(userID, value.(string), "flow") |
There was a problem hiding this comment.
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
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") |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
if checkOverlappingEvents(events) { | ||
return "Overlapping events, not setting a custom status", isStatusChanged, nil |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
server/mscalendar/availability.go
Outdated
if events[0].IsCancelled { | ||
return "Event cancelled, not setting custom status", isStatusChanged, nil | ||
} |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
server/mscalendar/availability.go
Outdated
sort.Slice(events, func(i, j int) bool { | ||
return events[i].Start.Time().UnixMicro() < events[j].Start.Time().UnixMicro() | ||
}) |
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this be >=
?
There was a problem hiding this comment.
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.
@cwarnermm Can you please take a look at the user-facing strings in this PR? Thanks 🙂 These are primarily in |
There was a problem hiding this 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.
@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 |
Summary
Ticket Link
#228
Screenshots
What to test?
How to test?
/mscalendar settings
, select an option from theUpdate Status
setting, and check the updated status on the Mattermost./mscalendar settings
, set theSet Custom Status
setting to yes, and check the updated custom status on the Mattermost.