Improve user signup flow

[mek32390]

Here is the breakdown of the workflow:

1. An intern submits a Class Set (the syllabus and roster HTML for a class)
2. The roster HTML is parsed to make new entries consisting of their name and email (if applicable)
3. If the emails are provided, skip to step 5.
4. If the emails aren't provided, one of two things should happen:
   1. I should be able to download the names without emails and have a script scrape the the school's directory for the emails. I currently have this on my own comp and it takes in CSV and exports CSV. That would also mean that I should be able to import the finished results back into Django's admin.
   2. Instead of scraping the directory manually on my comp, we do it from Django.
5. Associate/enroll each roster entry with their correct course on mchp.
6. The campaign/mailer will check all events that are coming up on mchp within 48 hours, and will send out either a "Request for Study Guide" or "Study Guide" email to all of the students enrolled in the course on mchp, which means it should send out an email to both students that are already signed up on mchp and also those that came from a roster/Class Set submitted by an intern.

A problem occurs because the mailer will only email "enrolled" "student objects" in the course. Our backend makes a one-to-one relationship between each Django "user" to a "student object", and only a "student" can be "enrolled" in a course on mchp. Remember, the mailer checks for the "students" "enrolled" in the course and emails them.

So, how do imported roster entries from an intern become "enrolled" and therefore "student objects" in a course on mchp, even thought they may have never signed up before?

Further, if they do try to sign up, Django will reject their email in the form because to Django, there is already a "user" with that email.

This may be the wrong approach, so I am very open to trying alternative methods to solve this problem.

[merenbach]

My suggested approach, for long-term stability, is to have user Profile objects that have the Foreign Key to a Django User object optional and their school email address stored there. This would allow profiles to be created and students to be attached to those profiles and so on, and so forth, and so the most "logical"-sounding approach would then work.

AllAuth would continue to be associated with User accounts and, when registering, a way would need to be found to check existing Profile email addresses against the registering user's email address.

Challenges in this: the existing system depends upon being able to find a User for many things, including email addresses, so simply making the key optional for existing Profiles wouldn't cut it. Instead, a parallel system could be created to eventually subsume the existing system.

While I consider the above the most robust in terms of not duplicating things and enhancing scalability, I'm not convinced about its viability in terms of timeframe. As such, one thought is to have it create "NewProfile" (call it whatever you like) and "NewEnrollment" (same) objects for all imports, but also set up enrollments for existing users if any are found. Then over time, new features would depend on the NewProfile/NewEnrollment classes and eventually the old ones could be deprecated.

[mek32390]

This is a critical issue that needs a good diagnosis. I'll put it into context:

• We have 300 interns from 40 schools ready for this semester, starting Sept 1
• Each intern is to collect 3 Class Sets per week (about 900 sets in week 1)
• The parser can't parse 40 different CMS's at this time. We'll only be able to add new schema's from new CMS on a one-by-one basis as they come in.
• If emails aren't provided by the CMS > HTML Roster, what should happen?
• We don't have a way to keep track of how many sets are uploaded per intern per week

Given this update, how we should proceed with this? Do I make 300 google Drive folders (one per intern), and have them submit their class sets there (syllabus and html file) in the meantime?