resolution_fixed type_defect | by rjsparks@nostrum.com
Currently, GroupInfo has an ad field (ForeignKey to Person).
This is a holdover from how Groups worked in older code.
The groups that have ADs, should have a Role record indicating the AD instead.
With the current models, there are groups where a responsible AD doesn't make sense, and the field is either artifically populated or left blank. They also don't allow the notion of more than one AD for a group.
These results are not the most intuitive:
In 0a679b7ff24d8f94560634185d6eca4ea97d90a4: Group.objects.get(acronym='rai').ad
In a00b1631f4c7a6372fdbfd5dbf1bd54853a82bc4: Group.objects.get(acronym='iesg').ad
Outa00b1631f4c7a6372fdbfd5dbf1bd54853a82bc4: <Person: Jari Arkko>
Note that we're already using the Role idea for Areas:
In 98165ab39945f8c997b48d6ecebf5ed05c8d1f90: Group.objects.get(acronym='rai').role_set.all()
Out98165ab39945f8c997b48d6ecebf5ed05c8d1f90: [<Role: Richard Barnes is Area Director in rai>, <Role: Alissa Cooper is Area Director in rai>]
There is code in the views that would be drastically simplified by this change. See, for instance, the view that displays a WG or RG charter.
See also #1555
Issue migrated from trac:1557 at 2022-03-04 03:57:27 +0000
resolution_fixedtype_defect| by rjsparks@nostrum.comCurrently, GroupInfo has an ad field (ForeignKey to Person).
This is a holdover from how Groups worked in older code.
The groups that have ADs, should have a Role record indicating the AD instead.
With the current models, there are groups where a responsible AD doesn't make sense, and the field is either artifically populated or left blank. They also don't allow the notion of more than one AD for a group.
These results are not the most intuitive:
Note that we're already using the Role idea for Areas:
There is code in the views that would be drastically simplified by this change. See, for instance, the view that displays a WG or RG charter.
See also #1555
Issue migrated from trac:1557 at 2022-03-04 03:57:27 +0000