WIP: Change Outlook frame to use MS Graph API#218
Open
itsalexjones wants to merge 8 commits intofuel9:masterfrom
Open
WIP: Change Outlook frame to use MS Graph API#218itsalexjones wants to merge 8 commits intofuel9:masterfrom
itsalexjones wants to merge 8 commits intofuel9:masterfrom
Conversation
This reverts commit fc725ab.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Following the deprecation of basic auth in the Exchange Web Services API, a solution is required for accessing calendar information using modern auth.
This pull request completes that using the Microsoft Graph API.
In making these changes I have been focussed on our use case @global-broadcast-engineering, but have tried to keep existing behaviour intact, but it has not been tested yet.
I am happy to take feedback on the code, and suggestions of minor changes over at #214 - but note that my scope is purely enabling our use case of meeting room booking and free/busy display. Anything requiring significant work that doesn't further that use case may be tricky to get completed.
Notable changes for operators of DisplayMonkey are:
Creating an Azure AD Application for Calendar Access
In order to authenticate users via Azure AD, we must register DisplayMonkey in our tenant. To do this:
You will also need to provide consent for the accounts you have previously registered (or will register) for the scopes
"User.Read", "Calendars.ReadWrite", "Calendars.ReadWrite.Shared", "MailboxSettings.Read". The application does not (currently) provide UI to do this, and the easiest way it to grant admin consent.Things not explicitly tested - but theoretically working
The management UI still has fields for EWS, these still store the data, but it's no longer used.