sergeknystautas / relationships-googlecal-ktor Goto Github PK

This is a function of the Google calendar API, but often for whatever factors I can't determine, the display_name field is not on the event data, so it falls back to the email address.

We are also getting access to the google people data to show the names in all cases. This would likely be hard to do some caching so we avoid slamming the people API.

We nicely detect the feature gap in KTor because OAuth config needs more options.

But the error page still shows a stack trace. We should handle that nicer on the error page.

I'm thinking that I don't generally want or desires recurrent 1:1s as a way to refresh social ties, but the idea "you have not been in a meeting with X in Y time" is interesting. I think when there are more than 8 people on VC it's broadcasting.

Can you create additional tabs for building and aging relationships based on meetings with 8 people (or fewer)?

The current KTOR OAuth2 implementation does not specify the URL parameters that Google wants to provide a refresh token. In OAuth2, in addition to an access token, an authorization provider can supply a refresh token to get a new access token after a certain amount of time has passed.

This is currently blocked by https://youtrack.jetbrains.com/issue/KTOR-2128. When this is fixed, we can incorporate this new version and then we can make changes to our code base to support refreshing the token if it expired. In addition to knowing to refresh if the time has expired, we will likely want to persist the access token and refresh token so restarting the application does not require yet another login.

There should be instructions for how to set up a new machine, and also a new person to develop locally. This should be comparable to the README in the old version of this service.

Also do more documentation on the code so people can open the KT files and know what's up.

I hit an issue today where I typed in the URL, and it defaulted to http://riot-1on1s-staging.herokuapp.com/. That won't work because of OAuth and is likely something we should use anyway.

Figure out how in KTor to redirect from http to https (or in Heroku)outside of development.

Depending on how we are going to get data about Rioters in the future (whether directory or sheets or whatever), it would be nice to use Google's service accounts (https://developers.google.com/identity/protocols/oauth2/service-account) to access this data. The main benefits of this are:

• The application can download the directory or sheets information on app start-up (if cached in memory) and refreshed whenever necessary.
• The above means the first user will load their report faster because we do not need to scan and process the Rioter metadata.
• All users will be able to use the site with providing future scopes, as in, they will just need to provide their calendar data rather than the other major scopes we ask for when you sign in.

At 16:57 in California, went to the report and it said:

Prepared Feb 19, 2021 12:56 AM

That's UTC, not California. I should look at the calendar time zone and use that to set the right time zone for "now" so that "today" is correctly defined.

Right now I have no idea what users have accessed this. Either send an email each time someone uses it as a super dumb/start, or ideally create a database that stores who has signed in, and when the last time they signed in, and maybe track how many times they've signed in. I guess an authentication log might be better if that's the use case.

Anyway, see who is using it.

Right now if someone else uses the website, we have no idea if it crashed for whatever reason. Install Sentry (or whatever library) and confirm error reports go back to there. Create a test page to manually verify crash reports.