Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: Portal frontend19 #127

Merged
merged 7 commits into from
Aug 7, 2024
Merged

fix: Portal frontend19 #127

merged 7 commits into from
Aug 7, 2024

Conversation

SKairinos
Copy link
Contributor

@SKairinos SKairinos commented Aug 2, 2024

This change is Reviewable

Copy link
Contributor

@faucomte97 faucomte97 left a comment

Choose a reason for hiding this comment

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

Reviewed 9 of 9 files at r1, all commit messages.
Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @SKairinos)


codeforlife/user/filters/user.py line 44 at r1 (raw file):

        return queryset.filter(
            first_name__icontains=first_name
        ) | queryset.filter(last_name__icontains=last_name)

Should we do a Q lookup here instead of performing 2 filters? I'm not 100% sure it's better but I have a feeling it is. Something like this:

return queryset.filter(Q(first_name__icontains=first_name) | Q(last_name__icontains=last_name))

Code quote:

        return queryset.filter(
            first_name__icontains=first_name
        ) | queryset.filter(last_name__icontains=last_name)

codeforlife/user/models/teacher.py line 117 at r1 (raw file):

                new_student__isnull=True,
                new_teacher__school=self.school,
            )

Same comment here about the Q lookup

Code quote:

            # student-users
            User.objects.filter(
                new_teacher__isnull=True,
                **(
                    {"new_student__class_field__teacher__school": self.school}
                    if self.is_admin
                    else {"new_student__class_field__teacher": self}
                )
            )
            # school-teacher-users
            | User.objects.filter(
                new_student__isnull=True,
                new_teacher__school=self.school,
            )

codeforlife/user/views/klass_test.py line 119 at r1 (raw file):

        self.client.list(
            models=classes,
            filters={"teacher": str(user.teacher.id)},

This might be a silly question, you probably just need to remind me how this works exactly.

What is the "point" of the this filters arg here exactly, isn't classes already filtered to be just the classes that the teacher owns? (on the second line of this def)

Or, is the point that classes should actually be all the classes in the school first, instead of only the teacher's classes?


codeforlife/user/views/user_test.py line 172 at r1 (raw file):

        self.client.list(
            models=school_teacher_users,
            filters={"only_teachers": str(True)},

why str(True) and not just "True"?

Copy link
Contributor Author

@SKairinos SKairinos left a comment

Choose a reason for hiding this comment

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

Reviewable status: all files reviewed, 4 unresolved discussions (waiting on @faucomte97)


codeforlife/user/filters/user.py line 44 at r1 (raw file):

Previously, faucomte97 (Florian Aucomte) wrote…

Should we do a Q lookup here instead of performing 2 filters? I'm not 100% sure it's better but I have a feeling it is. Something like this:

return queryset.filter(Q(first_name__icontains=first_name) | Q(last_name__icontains=last_name))

functionally equivalent but since it's more compact, I went with your approach


codeforlife/user/models/teacher.py line 117 at r1 (raw file):

Previously, faucomte97 (Florian Aucomte) wrote…

Same comment here about the Q lookup

functionally equivalent but since it's more compact, I went with your approach


codeforlife/user/views/klass_test.py line 119 at r1 (raw file):

Previously, faucomte97 (Florian Aucomte) wrote…

This might be a silly question, you probably just need to remind me how this works exactly.

What is the "point" of the this filters arg here exactly, isn't classes already filtered to be just the classes that the teacher owns? (on the second line of this def)

Or, is the point that classes should actually be all the classes in the school first, instead of only the teacher's classes?

Admin teachers can list all the classes in a school. If the admin wants to get a subset of those classes, where the class teacher = {ID}, they can use this filter.


codeforlife/user/views/user_test.py line 172 at r1 (raw file):

Previously, faucomte97 (Florian Aucomte) wrote…

why str(True) and not just "True"?

Filters are search params. Therefore, we need the string equivalent of True. Search params values are always strings (a url is a string).

GET  .../api/users/?only_teachers=True

This will list only teacher users

Copy link
Contributor

@faucomte97 faucomte97 left a comment

Choose a reason for hiding this comment

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

:lgtm:

Reviewed 2 of 2 files at r2, all commit messages.
Reviewable status: :shipit: complete! all files reviewed, all discussions resolved (waiting on @SKairinos)

@SKairinos SKairinos merged commit 2dc2c72 into main Aug 7, 2024
5 of 6 checks passed
@SKairinos SKairinos deleted the portal-frontend19 branch August 7, 2024 09:42
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.

2 participants