Bernard Siebens
744b623403
members/services/family.py enrolled a parent exactly like the child they were registering, so every parent held a full membership: counted in the member list, in the club and platform KPIs, and in the fee roll, with a fee record of their own. ClubMembership.kind (member | guardian) separates the two. A guardian is attached to the club only through their child. They hold the login, can be contacted and can sit in a Group -- the stated exception -- but they are not a member: no fee (clean() refuses one), absent from the member list, the fee list and every member count, and not eligible for a roster or a staff spot. A parent who also plays or coaches is a member who happens to be a parent; the two facts are independent, which is why this is its own field rather than inferred from FamilyMembership.role. A field on ClubMembership rather than a separate model because everything that answers "is this person attached to this club" already reads through that table -- tenancy, groups, the club-wide event audience -- and a second kind of link would need a parallel path through all of it. What changes is only who counts. Two things that weren't obvious going in: Excluding guardians had to be a subtraction, not a narrower filter. The obvious move -- match only member-kind rows and drop the MEMBER-role branch, since an active membership of any kind grants that role -- also hides someone the club knows but hasn't signed up for a season yet, which is a real state the member edit page supports. Two existing tests caught it. _guardians_only() subtracts instead, so anyone who also plays, is on staff or runs the club stays visible. Their tie to the club isn't seasonal but rides on a per-season row, so it has to be carried forward or a parent silently drops off at the season boundary while their child stays enrolled. Copied from the immediately preceding season only, so a deliberate removal isn't resurrected from an older row. The data migration reclassifies existing parents, deliberately skipping anyone who plays, is on a team's staff or holds an elevated ClubRole -- demoting them would strip them from their own team's roster eligibility. Anything ambiguous stays a member, which an admin can flip; noticing someone quietly vanished is much harder. The import template gains a membership_kind column next to family_role (a child marked guardian is refused), and the review screen shows what each row will join as. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
22 lines
1.0 KiB
Python
22 lines
1.0 KiB
Python
from django.utils import timezone
|
|
|
|
from club.models import ClubMembership, Season
|
|
from members.models import Member
|
|
|
|
|
|
def eligible_roster_members(club):
|
|
"""Members eligible to be added to a team's roster or staff: active (paid) for
|
|
the club this season or next, regardless of which season's roster/staff list is
|
|
currently being edited (the team page's season switcher can point at either)."""
|
|
today = timezone.localdate()
|
|
eligible_seasons = [season for season in (Season.covering(club, today), Season.next_after(club, today)) if season is not None]
|
|
return Member.objects.filter(
|
|
member_of__club=club,
|
|
member_of__season__in=eligible_seasons,
|
|
member_of__status=ClubMembership.StatusChoices.ACTIVE,
|
|
# Guardians are attached to the club only as a parent of a member, so they
|
|
# are not eligible for a roster spot *or* a staff one. A parent who
|
|
# volunteers as a coach is a member of the club and marked as one.
|
|
member_of__kind=ClubMembership.Kind.MEMBER,
|
|
).distinct()
|