-
Notifications
You must be signed in to change notification settings - Fork 8
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
Team page #149
base: main
Are you sure you want to change the base?
Team page #149
Conversation
… Members. Also added proper sequential loading of Core Members
This reverts commit 4cd43dd.
Co-authored-by: Nishant Nayak <[email protected]>
Co-authored-by: Nishant Nayak <[email protected]>
This reverts commit 61aba1f.
Your Render PR Server URL is https://corpus-dev-pr-149.onrender.com. Follow its progress at https://dashboard.render.com/web/srv-cotsbsgl6cac73cj0rng. |
corpus/accounts/migrations/0004_alter_executivemember_date_joined.py
Outdated
Show resolved
Hide resolved
corpus/accounts/migrations/0005_alter_executivemember_date_joined_and_more.py
Outdated
Show resolved
Hide resolved
corpus/accounts/models.py
Outdated
|
||
class Core(models.Model): | ||
|
||
POST_CHOICES = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As discussed on call, any reason for this? I think it'll be better to make another model or something called Post
and have a ForeignKey
linking to that table.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
right, would the mapping remain the same for the core posts then? Like rn I'm having a POST_CHOICES which maps every core post to a number, according to which the core posts are fetched and displayed. So can I move this exact logic to the Post model when I create it?
corpus/accounts/models.py
Outdated
class Meta: | ||
verbose_name_plural = "faculties" | ||
|
||
FACULTY_POSTS = ( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This could also go into the Post
model. Then no need to differentiate by like faculty posts and stuff
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nope. I would like Faculty to be in a different model. Core members have to be Executive Members, Faculty will only be Users. The foreign key references will be different.
Also, access control in the future will be much easier if we have these models separate.
corpus/pages/views.py
Outdated
|
||
def team(request): | ||
compsoc_members = ExecutiveMember.objects.filter( | ||
(Q(core__isnull=True) | Q(core=None)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think you've made ExecutiveMember.core
as an association right? I think this is what this query does?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have made a Core.executivemember relation. Again since every Core member has a user model associated, i'm just checking that we do not fetch such users
corpus/pages/views.py
Outdated
def team(request): | ||
compsoc_members = ExecutiveMember.objects.filter( | ||
(Q(core__isnull=True) | Q(core=None)) | ||
& (Q(user__faculty__isnull=True) | Q(user__faculty=None)) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
User
does not have faculty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No but faculty can have a user, right? So I'm just checking that the user I'm fetching does not have a faculty linked to it
corpus/pages/views.py
Outdated
& (Q(user__faculty__isnull=True) | Q(user__faculty=None)) | ||
& Q(sig__name="Piston") | ||
) | ||
ieee_core = Core.objects.filter(sig__name="ExeCom").order_by("post") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We can't add ExeCom as a SIG, it is both wrong logically, and will mess up both current and future code
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not really sure how else to identify ExeCom members then.
As Executive Members, their SIG will only be one of CompSoc/Diode/Piston.
As Core Members, they can only be part of CompSoc/Diode/Piston/SAC/ExeCom. All these 5 categories have to be displayed separately.
Maybe sig
isn't the best name for the attribute in the Core model, but this is logically correct.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What I have done in the newest changes is include 2 attributes. is_execom
and is_sac
which helps us pick out executive committee and sac members without compromising their actual sigs
corpus/pages/views.py
Outdated
& (Q(user__faculty__isnull=True) | Q(user__faculty=None)) | ||
& Q(sig__name="CompSoc") | ||
) | ||
diode_members = ExecutiveMember.objects.filter( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two things you can do to solve this:
- Duplicate core members in the members list. This is fine, as although they are in core, they are still members, so should be okay.
- Get all the core posts, and then remove those from all the members in that SIG.
Also, you'll have to make sure that you query for this particular year. You can probably make a configuration where you define what the current academic year is, and then use that for queries to get "current" people.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can I like check if their term_end is null or not? If term_end is null, then display, otherwise don't?
I think we'll have to sit and rewrite the team page view function to make sure we cover all edge cases and stuff. |
Description
Add Team Page
(Closed PR for reference - #134)
(Closed PR for reference - #141)
Fixes #139
Type of Change
What types of changes does your code introduce?
Put an
x
in the boxes that apply