can_manage_group can have better semantics

[ietf-svn-bot]

resolution_fixed type_defect | by [email protected]

---

Right now ietf.group.utils.can_manage_group (and can_manage_group_type) have the surprising result that chairs can't manage their own group.

This leads to code that checks can_manage_group that immediately also checks to see if the user is a chair (or secretary, or lead, or whatever other role would let them, well, manage the group).

I suspect the code overall would be simpler if can_manage_group answered yes for roles like chair.

Also, can_manage_group_type and can_manage_group currently have separate (and disagreeing) implementations. One should be implemented in terms of the other.

---

Issue migrated from trac:2155 at 2022-03-04 05:40:48 +0000

[ietf-svn-bot]

@[email protected] changed status from new to closed

[ietf-svn-bot]

@[email protected] changed resolution from `` to fixed

[ietf-svn-bot]

@[email protected] commented

---

Fixed in e2640f3:

Changed semantics for can_manage_group() to include chairs etc, and changed calls with the old semantics to use can_manage_group_type(). Rewrote can_manage_group() in terms of can_manage_group_type() and additional checks. Fixes issue #2155.