jhuopensource / semesterly Goto Github PK

Steps to reproduce:

Suppose there are no students in student_student.

1. Log in with Facebook
2. Log out
3. Log in with Google/JHU
4. Click on Continue with Facebook
5. Log in with the same Facebook account
6. AuthAlreadyAssociated exception is raised

Potential solution:

• Extend the social pipeline to catch this error
• Create a modal informing users to delete their existing account
• Redirect users to this modal

Advisors imported from SIS are kept even if the student has swapped advisors. Should there be a limit to how many advisors they can have and how should we remove them if so?

Ties with #252

This should be discussed further (post-MVP for advisor dashboard).

Right now, Semester.ly’s analytics page is very plain. We were thinking we could look into outsourcing some of our data-visualization, improving the metrics we track, and updating the overall look of the page.

In order to get student data from SIS, we need to have students log-in using Hopkins authentication.

This involves:

• Configuring Django Microsoft Azure authentication
• Creating a Hopkins Login button on initial login modal that triggers Hopkins auth
• Connecting existing accounts to Hopkins accounts (if users have existing Facebook Semester.ly accounts)
  • Not exactly sure how this will work, but we want to avoid having users with existing Facebook accounts create new accounts
  • I think we do this type of "connection" with Google+Facebook accounts so taking a look at how that works might help!

Tests todo-list:

• AdvisorSerializer
• AdvisingView GET redirects a non-JHU-authenticated student to Microsoft Azure login
• StudentSisView
  • GET returns appropriate semesters in reverse-sorted order
  • POST properly populates data that mocks SIS' request
  • POST invalid tokens are properly handled
  • POST 404's when the data is improper (should it only save if everything is successful?)
  • POST If a course is invalid, what should we send in response? #226
• RegisteredCoursesView
  • GET returns the correct courses for a student
  • GET correctly verifies sections against the current timetable
  • GET denies an advisor that isn't an advisor
  • GET denies an advisor that isn't an advisor on the student's transcript
  • GET returns the correct courses for an advisor requesting student data

#193 has a TODO for this in the top_bar_advising.jsx file

This should be reconsidered post-MVP.

Only have Spring and Fall 2021 ingested/digested at the moment.

The typical Semester.ly user at JHU searches for some or all of their courses using SIS's Advanced Search feature. Typically, Semester.ly comes in when students are decided which courses (of those found through SIS) will fit together in a nice schedule. This feature aims to completely eliminate the need for users to use SIS's Advanced Search feature. We want Semester.ly's search to be just as good if not BETTER than SIS's search.

Should adjust the UI/UX as well the backend for advanced search feature. The reviews section is outdated and needs to be replaced with a sufficient, sustainable API.

What components will we need to write?
What components can we re-use?
Is the UI intuitive for advisors? Do they want to see all of their students and pick their students first or do they want to see all of the chats?

We know what we want out of our chat system on the advising dashboard.
We want:

• the entire chat history to be saved and tied to the student
• advisors and students to both see the chat
• all advisors to have access to the same chat (as in it should be a group chat with all the student's advisors)
• the chat to look and function in a way that is familiar and user friendly

However, we haven't yet had a discussion about how we will design all of this in the backend.

• What models do we need?
• What will the models look like?
• What is the most efficient way to store this transcript?

We need to design this backend! The best way I find to do this is to draw diagrams and write out what fields each model will have and how they will connect.

#193 has a TODO for this in the top_bar_advising.jsx file

Ex: #329

Per James's notes:
have 4 text inputs for things like first name, last name, email address, and jhed

if we go with the modal, the flow would be
click on link -> open modal -> input first name, last name, jhed, email -> backend adds advisor to student -> refresh -> new advisor should appear in the dropdown -> invite

As it stands, there isn’t a simple way for users to suggest new features they would like for Semester.ly. Every once in a while, the team sends out surveys and that is how we currently get feedback from users. However, something that would be really cool is a place on the Semester.ly homepage for users to submit feature requests or suggestions for improvement!

For example, my course MI.841.200 (01) Game/Play doesn't exist. For now it's just ignored, but maybe we should let the user know that it doesn't exist in the DB.

Right now the text just goes off the bubble

Depending on what this entails - it may be a semester-long project?

At the moment, the course review data on Semester.ly is really outdated (think 2014 and 2015 data… yikes!). With this project, your task would be to figure out how the original course review data was ingested and processed on Semester.ly, and either apply that process to more current course review data or figure out a better way to sustainably ingest the new data

In order to create an advising dashboard with an official schedule, we need the be able to see a student's official semester data.

This will involve:

• Designing and API with @alihacks
• Creating a few mock json files for testing/creating features with this data

We have mocks created for an advanced version of the Advising Dashboard - but we know that we need to first create an MVP version.

First, we need to decide:

• Where will the initial advising dashboard button be / what will it look like?
• What will the UI of the MVP look like? We need some versions of this paired down mock that only include:
  • a 'return to semester.ly' button
  • a chat
  • courses a student is currently registered for OR
  • courses a student has in their cart (if they aren't registered for any courses AKA it is before registration date)
  • courses a student is currently waitlisted for? <-- should we include this? is this necessary?
• Once we decide on how it will look for students - i think it will look the same for advisors (just with minor tweeks) so we can then create a mock of the advisor side of things!

As of Jan 2020, Python 2.7 reached its EOL as noted here.

It's crucial to upgrade to the latest stable release of Python3.

Previous Attempts to upgrade to Python 3
Best reference (since it was resolved at ITCR)

noahpresler#1021
noahpresler#1014
noahpresler#1033

What im thinking:

When an advisor logs in for the first time, we check the "Advisor" table and see if their JHED (is this reliable?) exists in that table.
If it doesn't exist, we assume they aren't an advisor for any students who have imported their SIS data (what if a student imports their SIS data after the advisor already has an account?).

If it does exist, a student has them as an advisor - so a social auth User and Student object is created for the advisor and it is somehow indicated in that object that they are an advisor (maybe a boolean is_advisor in the Student model?).

Anyway, when it comes to rendering the advising dashboard - we need to check whether the user and an advisor or not. If they are an advisor, their dashboard will be slightly different (we will need to conditionally render components based on some is_advisor boolean in the frontend i believe).

Anyway - those are my initial thoughts.

This past year, Hopkins students have been working and attending their courses from all over the world! So now, more than ever, there exists a demand among users to incorporate an option for students to change their time zone.

Semester.ly plans to offer 3 ways of authentication: Google, Facebook, and JHED. We are currently working on getting Google authentication to work again.

We want to test that the following sequences of authentication work:

• Facebook -> JHED -> Google
• Facebook -> Google -> JHED
• JHED -> Facebook -> Google
• JHED -> Google -> Facebook
• Google -> Facebook -> JHED
• Google -> JHED -> Facebook

When a user doesn't login with FB, they don't have a profile pic for semester.ly. We should give them an icon instead of a grey circle.

Refer to this file, which will likely be where something like this fontawesome favicon can be inserted in place of the gray color.

/advising/testadd/ and its associated view are currently only used for testing purposes. In the future, we may allow students to add other students as their advisors.

#313
#334
#335
#340
#342
#358
#361