Skip to content

Conversation

@flxffy
Copy link
Contributor

@flxffy flxffy commented Jul 2, 2019

Backend to supplement the usage of ChatKit. API can be found here.

What's new:

  1. lib/cadet/chat/token.ex: generate tokens for connection to Chatkit's services
  2. lib/cadet/chat/room.ex: logic for creating rooms using Chatkit's API and storing room id in the db
    2.1 Updated router to enable frontend retrieval of a token - for Chatkit's TokenProvider in the frontend
  3. mix/tasks/users/chat.ex: logic for creating users on Chatkit

Current Implementation:

  • Rooms are currently being created at three points - when answers are created, when students edit their answers and when cadets access answer in the grading view. In the event Chatkit crashes, the last two points serve as failsafes to ensure comments get to the students.
    • Alternative: a script to create all chatrooms after Chatkit restores its services, if it crashes
  • Making use of comment column in the Answer table to store room ids

Tests for Chatkit will be included by the end of the week once I figure out how ExVCR works 👯

@flxffy flxffy requested review from geshuming and jiachen247 July 2, 2019 15:23
@coveralls
Copy link

coveralls commented Jul 2, 2019

Pull Request Test Coverage Report for Build 2513

  • 27 of 39 (69.23%) changed or added relevant lines in 7 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage decreased (-1.2%) to 95.829%

Changes Missing Coverage Covered Lines Changed/Added Lines %
lib/cadet/chat/room.ex 19 20 95.0%
lib/cadet_web/router.ex 0 1 0.0%
lib/cadet_web/views/chat_view.ex 0 1 0.0%
lib/cadet/chat/token.ex 4 6 66.67%
lib/cadet_web/controllers/chat_controller.ex 0 7 0.0%
Totals Coverage Status
Change from base Build 2512: -1.2%
Covered Lines: 850
Relevant Lines: 887

💛 - Coveralls

Copy link
Contributor

@geshuming geshuming left a comment

Choose a reason for hiding this comment

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

Hi, first thing I noticed is that there isn't a lot of tests...

Can we get some tests written so we can at least understand how to approach and use your features.

@flxffy
Copy link
Contributor Author

flxffy commented Jul 2, 2019

Hi, first thing I noticed is that there isn't a lot of tests...

Can we get some tests written so we can at least understand how to approach and use your features.

@geshuming There are no tests at the moment! They will be included once I figure out how ExVCR works. I'll ping the group once they are complete and ready for merging!

Copy link
Contributor

@geshuming geshuming left a comment

Choose a reason for hiding this comment

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

Some preliminary comments.

I realised that you are reusing the comment field from answer. Can we deprecate the comment field instead, and add a new field for the chat room token.

Since the frontend no longer requires avengers to write grading comments, the frontend should send null or empty string for the comment, and we can further guard the field here by having it default to empty string, or be nullable in the database. Regardless, we can keep the comment field but mark it as deprecated.

Copy link
Contributor

@geshuming geshuming left a comment

Choose a reason for hiding this comment

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

Ok, looks better! We need a couple more optimizations, otherwise it will be good to go.

Copy link
Contributor

@geshuming geshuming left a comment

Choose a reason for hiding this comment

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

Is there any way to check if a room key is valid? Currently it seems that we assume that comment is either nil or VALID_KEY


if answer.comment == "" or answer.comment == nil do
Room.create_rooms(submission, answer, user)
end
Copy link
Contributor

Choose a reason for hiding this comment

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

Actually, can this be placed where a submission occurs?

Copy link
Contributor Author

@flxffy flxffy Jul 6, 2019

Choose a reason for hiding this comment

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

May I clarify what you mean? Do you mean when a submission is being finalised?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes. I think it is fine to leave the function here for now. But ultimately room creation should be done when a submission is submitted right?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sure. I'll place it here then? Since this is where all submissions flow through, whether it's submitted early or submitted by the autograder. Quite ugly tho :/

Copy link
Contributor

@rrtheonlyone rrtheonlyone left a comment

Choose a reason for hiding this comment

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

Sorry for spam, I just have some other comments here:

  1. "admin" seems to be hardcoded for get_superuser_token -> possible to make it a constant/variable (minor nit)

  2. It is interesting that you are tagging each user with their user_id when creating. This is the primary key in the database. This means that the user ids will just be ["1", "2", "3"] and so on.

I believe this is brittle and can lead to errors. Consider a scenario in which the import script adds half of the users and breaks after that. Or if there is a change to one/two users in between. We then have to manually go into chatkit and cleanup the ids. However, this is unlikely to happen as the User table does not usually change over the semester and remains constant (its more of a what if..)

I prefer to use the NUS ID instead to create Users. This is just a suggestion/concern. @geshuming @flxffy do see if you want to change or not!

@geshuming
Copy link
Contributor

I prefer to use the NUS ID instead to create Users. This is just a suggestion/concern. @geshuming @flxffy do see if you want to change or not!

@rrtheonlyone It should be fine. Many other core components also use user_id. Normally user rows should be preserved, if a user drops out of the course for example we can just delete their authorization, and not the user row.

@flxffy
Copy link
Contributor Author

flxffy commented Jul 6, 2019

Is there any way to check if a room key is valid? Currently it seems that we assume that comment is either nil or VALID_KEY

@geshuming The only way to verify a room id's validity is through a GET request to Chatkit to fetch room info. There's no documentation on how the room ids are being generated either.

@flxffy
Copy link
Contributor Author

flxffy commented Jul 6, 2019

I prefer to use the NUS ID instead to create Users. This is just a suggestion/concern. @geshuming @flxffy do see if you want to change or not!

@rrtheonlyone I used user_id because it's a unique identifier and a compulsory field. There's no NOT NULL constraint on the nusnet_id column so I'm going with user_id instead!

@flxffy
Copy link
Contributor Author

flxffy commented Jul 6, 2019

Tests have been added for room creation.

Copy link
Contributor

@geshuming geshuming left a comment

Choose a reason for hiding this comment

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

Looks ok. I will log issues from this PR

@geshuming geshuming merged commit 0007377 into source-academy:master Jul 7, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

6 participants