What we’ve done is prepended a character string (ZZ_DISBANDED) to our now-unused patrols so that the scouts in our current database who had leadership or memberships in those patrols retain the information, but the patrols are stuck on the end of the patrol listings, more or less out of the way.
This workaround is clunky at best, and I’m hoping that “future Scoutbook” has a better way to handle this so that units which have a high turnover rate in patrols/patrol names don’t end up with a laundry list of “dead” patrols in the indices. It seems like, from a programming POV, the leadership role should be a property of the scout object, and that it only needs to have the patrol name with which it is associated verified against a list of “current” patrol objects when the dates of leadership are current. Consider, for example, the case of a scout who changes units after having occupied a patrol-level leadership role in that unit. Do those scout’s patrol leadership roles get “transferred” to the patrol into which he or she has transferred, since the patrol name from the prior troop would no longer be valid in the new one? I haven’t been able to test this case, since most of our new scouts are transferred in from Webelos dens, but depending on exactly how the code is written, it could be an interesting test case. Consider the scout who has occupied a leadership position in a patrol which is no longer extant. The “ease” of picking a patrol name from a dropdown list is sometimes outweighed by the
I would suggest that a free text option be added for patrol names that would permit entry of “past” patrols, and which would throw a warning that the patrol name entered does not match a current patrol. If it does match, then it will link the role to that patrol in the manner that the current codebase appears to.