Shepherding AD for WG can be from a different area

[ietf-svn-bot]

resolution_fixed type_enhancement | by resnick@episteme.net

---

The IESG, in discussing it's re-organization of areas, would like it to be possible to assign a Shepherding AD for a WG that does not come from the area in which the WG is chartered. This appears to be possible in theory (i.e., on the "Edit Group" page, those are two separate drop-downs that can be set independently), but if you do so, the Shepherding AD does not appear on the charter page for some reason. This may simply be a bug in the views, but after speaking to Robert, it sounds like there may be a presumption in several places that the Shepherding AD is an AD for the area in which the WG lives. We'd like to eliminate that presumption.

---

Issue migrated from trac:1555 at 2022-03-04 03:57:15 +0000

[ietf-svn-bot]

@resnick@episteme.net commented

---

I was asked to check with the IESG regarding priority. Ted and Brian's answers are representative:

On 12/11/14 1:18 PM, Ted Lemon wrote:

It seems to me that we can operate informally until the late January timeframe. There is no reason to have a fire drill.

On 12/11/14 4:49 PM, Brian Haberman wrote:

Seeing as I am one of the perpetrators of this game, I am happy doing
this informally until the Jan/Feb timeframe.

From chatting with the ladies at AMS, some of the issues are due to the
way the tools automatically extract certain information from the DB
based on the area tag of the WG. I would feel more comfortable if we
gave Robert/Henrik/Ole a good runway to work this and we take the hit of
doing things informally/manually until they are confident in the code.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From 4c9db8f:

This is the first step towards using Role to represent Area directors. It

• Migrates the information captured in GroupInfo.ad to Role objects.
• Renames GroupInfo.ad to GroupInfo._ad (retaining the current column name) to prepare for deletion of that field.
• Provides ad property accessor and setter methods implemented using the group's role_set (so that the existing view code continues to work with minimal changes)
• Improved selection in many querysets that assumed only groups of type 'area' would have area directors.

Related to #1557 and #1555.

Commit ready to merge.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From 65804be:

This is the second step towards ADs out of GroupInfo into Role.

The use of group.ad has been scrubbed from the code and templates.

• Those places that set group.ad have been directly manipulate Role objects instead
• Most places that read group.ad now use a new group.ad_role() that returns a Role object, simplifing some views.

Related to #1555 and #1557.

Commit ready for merge.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From 65804be:

This is the second step towards ADs out of GroupInfo into Role.

The use of group.ad has been scrubbed from the code and templates.

• Those places that set group.ad have been directly manipulate Role objects instead
• Most places that read group.ad now use a new group.ad_role() that returns a Role object, simplifing some views.

Related to #1555 and #1557.

Commit ready for merge.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From 65804be:

This is the second step towards ADs out of GroupInfo into Role.

The use of group.ad has been scrubbed from the code and templates.

• Those places that set group.ad have been directly manipulate Role objects instead
• Most places that read group.ad now use a new group.ad_role() that returns a Role object, simplifing some views.

Related to #1555 and #1557.

Commit ready for merge.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

From 65804be:

This is the second step towards ADs out of GroupInfo into Role.

The use of group.ad has been scrubbed from the code and templates.

• Those places that set group.ad have been directly manipulate Role objects instead
• Most places that read group.ad now use a new group.ad_role() that returns a Role object, simplifing some views.

Related to #1555 and #1557.

Commit ready for merge.

[ietf-svn-bot]

@rjsparks@nostrum.com changed status from new to closed

[ietf-svn-bot]

@rjsparks@nostrum.com changed resolution from `` to fixed

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

Fixed in 56f9260:

Show out-of-area ads on /wg/. Fixes #1555. Related to #1557. Commit ready for merge.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

From edc4cba:

Merged in 4c9db8f from rjsparks@nostrum.com:\n This is the first step towards using Role to represent Area directors. It

• Migrates the information captured in GroupInfo.ad to Role objects.
• Renames GroupInfo.ad to GroupInfo._ad (retaining the current column name) to prepare for deletion of that field.
• Provides ad property accessor and setter methods implemented using the group's role_set (so that the existing view code continues to work with minimal changes)
• Improved selection in many querysets that assumed only groups of type 'area' would have area directors.
  Related to AD should be a role for groups, not a property of GroupInfo #1557 and Shepherding AD for WG can be from a different area #1555.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

From be1c255:

Merged in 65804be from rjsparks@nostrum.com:
This is the second step towards ADs out of GroupInfo into Role.
The use of group.ad has been scrubbed from the code and templates.

• Those places that set group.ad have been directly manipulate Role objects instead
• Most places that read group.ad now use a new group.ad_role() that returns a Role object, simplifing some views.
  Related to Shepherding AD for WG can be from a different area #1555 and AD should be a role for groups, not a property of GroupInfo #1557.

[ietf-svn-bot]

@henrik@levkowetz.com commented

---

Fixed in 56f979b:

Merged in 56f9260 from rjsparks@nostrum.com:
Show out-of-area ads on /wg/. Fixes #1555. Related to #1557.