This post was prompted by a discussion in another thread about the technical difficulties associated with tracking of leader positions, but it . I recognize it’s almost a philosophical digression on the architecture of Scoutbook (and one being posted by a non-professional programmer at that!), but I wanted to see what other folks (particularly those more qualified than I am) thought about the ideas. This is the proximal post that prompted my mental excursion:
@Stephen_Hornak’s comment about the data tracking challenges touches on one of the issues I have with what seems to be the way that Scoutbook is architected. It seems to me (as a strictly amateur programmer who’s never seen any of the Scoutbook code) that, if we’re tracking people as Objects (in a coding sense, not in a philosophical sense), then a leader position is a property of the person object. An individual person could accumulate a large number of such positions, coming from various councils and various units within any given council.
If the long-term goal is to ensure that we have a one-for-one correspondence between BSA records and actual people, then it seems to me that creating architecture flexible enough to accommodate multiple BSA IDs from multiple councils is a necessity, unless BSA thinks that (unlike every other piece of software every written) this will somehow outlast the issue of multiple BSA IDs for a single person. There is apparently a structure in the database accessed by my.scouting that permits the assignment of a BSA ID as primary vs secondary (or perhaps primary vs non-primary is more accurate). It seems a bit like this is a beginning step along the path to single record tracking of individuals. However, it doesn’t address what I think is an important use case, and has implications for how I believe Scoutbook is (at least currently) implementing this use case.
Consider an individual who is actively registered on more than one council (for argument’s sake, say with a troop in one council and a crew in another). At present, that individual has (at least!) two different BSA IDs, because of the structure of how BSA IDs are distributed. Since Scoutbook only permits for one BSA ID for each person record, two different person records (“Troop Leader” and “Crew Leader”) must exist for the same actual person (one for each BSA ID/council). As a result of Scoutbook’s requirement that leader accounts be accessed using SSO, it appears (at least on the face of things) that an individual registered in two councils would need to maintain two different my.scouting accounts (with unique BSA IDs and email addresses) in order to access the two different Scoutbook accounts.
It seems like a solution to this would be to rearchitect the person record portion to allow for multiple simultaneous BSA IDs, which are neither “primary” nor “secondary”, but are rather marked as “active” or “inactive”. For example, an adult who has a BSA ID from their youth registration in Council 1 would mark that BSA ID “inactive”, since they are no longer a youth. However, that same leader who is registered as a crew leader in Council 2 and a troop leader in Council 3 would mark the BSA IDs for each of those councils as “active”. I think that this would leave space for the BSA to eventually “merge” all of these person records into a single national BSA ID, without the need to replace the existing records. I think this could also solve the problem of proliferating BSA IDs, since it would permit multiple BSA IDs to be assigned to the same person.
I haven’t thought this all the way through (obviously) and I’m sure there are other issues that the concept raises. I’m curious what folks who do this for a living think of the idea. I know it breaks the “one person one database ID” paradigm, assuming that BSA ID is the unique identifier. That said, the paradigm is obviously already broken as it is, so why not take advantage of the existing breakage to set up the conditions to be able to merge the multiple person-records some folks have into a single person-record?
