Onboarding backend #624
Onboarding backend #624
Conversation
…plan into onboarding-backend
There was a problem hiding this comment.
heads up we use yarn, so shouldn't need a package-lock.json since we use yarn
| @@ -0,0 +1,38 @@ | |||
| # Generated by Django 3.2.24 on 2024-03-24 21:30 | |||
There was a problem hiding this comment.
Nit: it's a good idea to merge these migrations into one (you can just roll back to the migration before the ones you added using python manage.py migrate XXXX where XXXX is the last migration not in this PR. You can then delete all the migrations created in this PR and run python manage.py makemigration
|
|
||
|
|
||
| class DegreeProfile(models.Model): | ||
| user_profile = models.OneToOneField( |
There was a problem hiding this comment.
Could we just foreign key directly to the User? is there a reason not to?
| help_text="extending the user profile class", | ||
| ) | ||
|
|
||
| transcript = models.OneToOneField( |
There was a problem hiding this comment.
I don't think we want this field (ie, we shouldn't store the transcript)
| ), | ||
| ) | ||
|
|
||
| transfer_credits = models.ManyToManyField( |
There was a problem hiding this comment.
I think this might need to be an array of full_codes? Courses are only the ones we have in our database, but PDP supports other course codes, e.g., EAS 0091 which is not an official course according to our db
| model = Degree | ||
| fields = "__all__" | ||
|
|
||
| def validate_degrees(self, degrees): |
There was a problem hiding this comment.
Do we need this? I think this check should be handled by the view level (the view defines a get_object that handles this)
| ), | ||
| ) | ||
|
|
||
| degrees = models.ManyToManyField( |
There was a problem hiding this comment.
Why do we store degrees here? How would we display this on the onboarding panel.
| ), | ||
| ) | ||
|
|
||
| def calculate_total_credits(self): |
There was a problem hiding this comment.
Are we planning on using this anywhere?
| user_profile, _ = UserProfile.objects.get_or_create(user=self.request.user) | ||
| return serializer.save(user_profile=user_profile.id) | ||
|
|
||
| def update(self, request, *args, **kwargs): |
There was a problem hiding this comment.
if we have a ModelViewset, the nice part is we don't have to define most of these things. See e.g., the SectionList view. This is because django rest framework ModelViewset already has defaults for these things.
| return super().destroy(request, *args, **kwargs) | ||
|
|
||
| @action(detail=True, methods=["post"], url_path="add-course", url_name="add_course") | ||
| def add_course(self, request, pk=None): |
There was a problem hiding this comment.
This is nice, I like this pattern for adding/removing on manytomany fields
• Added DegreeProfile and CourseTaken models to store onboarding info
• Basic CRUD routes, serializers, and unit tests
• Transcript model and transfer credit attribute are there but not yet implemented