id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	size
94	Refactor manage_officers and friends	adehnert		"manage_officers is no longer ""a somewhat intimidating 100+ line long function with up to eight layers of indentation in some places"" (ASA #87). Instead, it's a 250+ line morass of six functions with terrible APIs and uncertain purposes, with up to five layers of indent. Which... is a different problem. Sort of. It still wants to be cleaned up, until the various helper functions actually have a clear purpose in life, instead of being ""lets yoink a chunk of 50 lines and slap the minimal function header that lets it run on"".

Some likely-useful steps:
* the `new_people`/`max_new` code should be split out into a separate utility function as much as possible. In particular, `manage_officers_load_accounts` and `manage_officers_sync_role_people` shouldn't care, ideally...
* `manage_offices_sync_role` should get a set of relevant people (or possibly just old people), a set of people who should still be listed, and various extraneous info, and make them match up. This will make it a much better match for `manager_officers_{table,bulk}_update`, especially the latter.
* `manage_officers_load_accounts` should ideally use some sort of built-in caching for everything using `AthenaMoiraAccount`. Failing that (as certainly might happen), it could at least not need to use `new_people`/`max_new`/`request`
* Better function names might help"	task	new	normal	Sometime	People					medium