-
Notifications
You must be signed in to change notification settings - Fork 69
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
Create new meeting instead of using PMI #147
Conversation
Codecov Report
@@ Coverage Diff @@
## master #147 +/- ##
======================================
Coverage 0.00% 0.00%
======================================
Files 8 8
Lines 860 882 +22
======================================
- Misses 860 882 +22
Continue to review full report at Codecov.
|
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.
Awesome improvement @larkox! Just a few requests
server/http.go
Outdated
meeting, err := client.CreateMeeting(user.Email) | ||
if err != nil { | ||
p.API.LogWarn("Error creating the meeting", "err", err) | ||
return | ||
} |
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.
Does the Mattermost user's email have to match the Zoom user's email? If so, can we communicate that to the user 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.
No, there is no need on OAuth. I will make some changes to properly handle this.
server/zoom/jwt.go
Outdated
var ret Meeting | ||
meetingRequest := CreateMeetingRequest{ | ||
Topic: "Meeting created on Mattermost", | ||
Type: 1, |
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.
Can we have a constant for this, and also a NewCreateMeetingRequest
function?
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.
The constant will be done. Regarding the function, I am not sure how useful will be. We may eventually add more different kinds of meetings, and this approach seems good for the time being. Also, this definition is only repeated on the jwt and oauth code, but the jwt code will be removed for the next release.
server/zoom/meeting.go
Outdated
// Recurrence struct { | ||
// Type int `json:"type"` | ||
// RepeatInterval int `json:"repeat_interval"` | ||
// WeeklyDays string `json:"weekly_days,omitempty"` | ||
// MonthlyDay int `json:"monthly_day,omitempty"` | ||
// MonthlyWeekDay int `json:"monthly_week_day,omitempty"` | ||
// EndTimes int `json:"end_times,omitempty"` | ||
// EndDateTime int `json:"end_date_time,omitempty"` | ||
// } `json:"recurrence,omitempty"` |
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.
Any reason we would want to have this commented out, rather than uncomment or remove 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.
I would like to keep it as reference. Right now removing the comments is not an option because it will send the "recurrence" field in the payload, and will create errors on zoom side.
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.
Can you do *Recurrence
with omitempty
?
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.
Indeed I can and I will. 😅
server/zoom/jwt.go
Outdated
func (c *JWTClient) CreateMeeting(userEmail string) (*Meeting, error) { | ||
var ret Meeting | ||
meetingRequest := CreateMeetingRequest{ | ||
Topic: "Meeting created on Mattermost", |
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.
Can we let the user specify a meeting topic via /zoom start Let's have some fun!
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.
That can be done, but I think it would be a great HW ticket, if you are willing to write it down.
server/zoom/oauth.go
Outdated
meetingRequest := CreateMeetingRequest{ | ||
Topic: "Meeting created on Mattermost", | ||
Type: 1, | ||
} |
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 comments mentioned in jwt.go
… for meeting types.
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.
LGTM, one non-blocking request to prefix MeetingType
constants with the data type
server/zoom/meeting.go
Outdated
Instant MeetingType = 1 | ||
// Scheduled meeting | ||
Scheduled MeetingType = 2 | ||
// RecurringWithNoFixedTime meeting | ||
RecurringWithNoFixedTime MeetingType = 3 | ||
// RecurringWithFixedTime meeting | ||
RecurringWithFixedTime MeetingType = 8 |
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.
Can we have these prefixed with MeetingType
? In other parts of the code, reading Instant
is not easy to know that it is a meeting type
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.
LGTM
Does this also fix #199? |
Got it. Then let's keep #199 open. |
Waiting for #184 to be merged and cut |
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.
@Hanze i when i deploy this PR code then first time when i use /zoom start command then still for the first time i can see that the PMI number is same, and some time the issue was not regenerated, after testing this again and again in the server & in the Private window, i did not found the issue so its LGTM
Should i remove the do not merge tag? @hanzei |
I merged master into this, and should be ready to merge. I leave up to you if some smoke test is needed in case the merge went wrong. |
@hanzei pls see this video, i was talking about this issue at.the.First.time.the.while.creating.the.meeting.link.should.be.the.random.mp4 |
@larkox ☝️ |
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.
@larkox pls see the video, i reported a issue.
@dipak-demansol I was missing that particular case. It should be solved now. Let me know if you find any other issue. |
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.
LGTM, Tested with the below Scenario.
- Manually Disconnected The zoom account and connected again and tested that PMI number is different or not.
- after 1 hour automatically the zoom account disconnect then connected zoom account and tested the same thing.
- many times Created the zoom meeting and every time its generating the different PMI number.
This reverts commit 65af542.
Summary
Create new meetings instead of using the user PMI at the meeting creation
Ticket Link
Fix #81
Fix #106