Allow assigning pre-ads to documents

[ietf-svn-bot]

owner:jennifer@painless-security.com resolution_fixed type_defect | by magnus.westerlund@ericsson.com

---

Allow pre-ads to be attached to documents and groups. Give them the ability to modify things as much, say, chairs for the document, and as much as is reasonable, ads.

---

Issue migrated from trac:3229 at 2022-03-04 08:13:55 +0000

[ietf-svn-bot]

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

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

The ticket here is primarily about pre-AD powers when operating on documents.

Pre-ADs should not be able to ballot, and should not be part of the calculation of number of positions needed to pass.

Pre-ADs should not be able to issue ballots.

The ticket is not asking for permissions with groups, but if interaction with group permissions becomes unavoidable, Pre-ADs should not be able to modify a group's state directly. Specifically, they should not be able to close groups.

Adding pre-ad to docman_roles for a group's groupfeatures might be 90%. The rest would inspecting places that explicitly use the "Area Director" role token from ietfauth, and possibly creating one that is "Pre AD" and adding that as an token in the places it makes sense.

[ietf-svn-bot]

@jennifer@painless-security.com commented

---

For the "attaching" part of the request, would that be in parallel to the responsible AD, or is it expanding the responsible AD options to include pre-AD as well as current AD?

If it's in parallel, it seems a little redundant to have Document.ad, Document.shepherd, and Document.pre_ad all pointing at the Person model (by way of Email for the shepherd). Would it be sensible to add a more general "document role" type M2M relationship between Document and Person and implement the pre-ad link in terms of that?

[ietf-svn-bot]

@jennifer@painless-security.com commented

---

Also, it seems that 'pre-ad' is already included in the 'Area Director' ietfauth token:

        role_qs = {
            "Area Director": Q(person=person, name__in=("pre-ad", "ad"), group__type="area", group__state="active"),

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

Ok... So, maybe this is obe.

(Looking at other places the token is already used, I see that at least the not-balloting part in my note above is already taken care of).

I'll ask the IESG if there's anything they've noticed that is still missing.

[ietf-svn-bot]

@jennifer@painless-security.com commented

---

Ok - the pre-ADs don't show up as options for the responsible AD. Perhaps they should?

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

btw (and this is out of sequence - I had an unsaved buffer for a bit):

a Role model on document is something that keeps coming up - there are several tickets exploring it, but it's a big step to take, and we would want a pretty big discussion on its impact (including its interaction with Group role) before taking that step.

[ietf-svn-bot]

@jennifer@painless-security.com changed status from accepted to assigned

[ietf-svn-bot]

@jennifer@painless-security.com set owner to jennifer@painless-security.com

[ietf-svn-bot]

@jennifer@painless-security.com changed status from assigned to closed

[ietf-svn-bot]

@jennifer@painless-security.com set resolution to fixed

[ietf-svn-bot]

@jennifer@painless-security.com commented

---

Fixed in fc98641:

Allow pre-ADs to be assigned as responsible for document. Fixes #3229. Commit ready for merge.

[ietf-svn-bot]

@rjsparks@nostrum.com commented

---

Fixed in 5238d1c:

Merged in fc98641 from jennifer@painless-security.com:
Allow pre-ADs to be assigned as responsible for document. Fixes #3229.