Yeah, I should have been clearer about that in my comments. Thanks for clarifying that, @JenniferOlinger.
1 Like
First problem is that’s a terrible system (requiring unique email).
Second problem is, these aren’t users, they are MB counselors. Granted that they MIGHT become users, but they aren’t being added through the ‘user’ process but instead through an upload.
Third problem is, there’s zero error reporting about this.
Fourth problem is, there’s no way to contact these people because they only contact point is their email address which you have now obfuscated. So I now have a MB counselor in the system that can’t be contacted. What use is that?
[side note] I’ve typed about five different things here about the advisory board, project management, lack of forethought, unintended consequences, etc. but I’ve deleted all of them because I don’t want to hear the complaints about how I’m just not understanding.
I’d love a seat on the advisory board if anyone is interested.
So someone made a poor choice years ago and the solution is to continue to propagate the consequences of that bad decision forever?
Can I “politely” suggest that this get changed immediately or perhaps sooner? At the very least, don’t impose this rule on MBC imports from scoutnet. Or, at the very, very, very least give us an error message (say in the council MBC upload / management page) telling us who they are, what their REAL email address is, and who they conflict with.
I’m not defending the design decision, just pointing it out. I didn’t do the design.
Er…the upload process was (presumably) developed to avoid councils having to use the user creation process manually to create the accounts. Every MBC has a Scoutbook account, with an associated identity. That’s why it causes issues when the emails/other data don’t match. That’s how we as adult leaders are able to connect the scouts to their MBCs in Scoutbook. It’s because they have an account, whether they know it or not, unless I’m missing something.
I agree that the MBCs amy not be users, in the sense that they may not be using their accounts, but the coding a separate “merit badge counselor” object as opposed to using an instance of an already existing “person object” seems like a strange design decision, particularly if MBCs can be both an MBC and another type of person (e.g. unit leader, committee member, etc). Why include them twice in the database, and implement/maintain two different types of programming objects? It seems more straightforward to populate (or not) certain properties/fields with data based on their registered roles.
I’m a big proponent of verbose error reporting (or at the very least granular error codes with a table clearly defining what the code means). I don’t know exactly what error reporting does or doesn’t exist, not having used the upload process itself. To the extent that it’s not throwing a usable error when an error occurs, I would agree that fixing that seems valuable. However, difficulties associated with that might be the reason that the BSA decided to push for adding all MBCs and their badges to ScoutNet/its successor rather than continuing to use the upload files. I don’t know what’s going on there, since I’m not involved in the development at all, just peeking in through the fence.
I’m interpreting “you” to mean Scoutbook, not me personally (since I didn’t do any of the coding or design on this system). With that clarification, I’m confused as to why the council can’t figure out how to contact the MBCs. Was the contact info not provided to council? I get that you aren’t able to extract the email from Scoutbook if it was buried as “changemyemail”, but the initial upload data file should be somewhere. The contact info should be in that, and searchable by BSA ID (I assume). Presumably the MBCs are in ScoutNet, at least as far as their registered position and contact information. Again, I’m not defending what I think is a potentially bad decision with regard to throwing errors on the upload file. I’ve never done the upload myself, but to the extent that the process does not throw an error identifying which records generated a “changemyemail@scoutbook.com”, it seems like that’s a defect that (I would think) can be corrected. Again, I’ve never seen the upload process from the inside, so I can’t really comment on the quality of error messaging from person experience.
I don’t know the process by which SUAC membership is selected. There was a request at some point in the past, since I recall seeing it. I don’t know whether the intent is to periodically request new volunteers or to only replace those who un-volunteer, as it were. @suacinformation might know more about that topic.
1 Like
Agreed. Didn’t mean to imply it was your design. I’m just pointing out that it’s a bad design.
Re: MBCs as SB users
- I can’t login with my email, I HAVE to use my scoutnet user ID. So the entire “email = account” argument is moot.
- I have 16 people in my MBC download from scoutbook that have a blank email address. Clearly they don’t detect this as either an error nor as a ‘duplicate’ of another account that also doesn’t have an email. And clearly these people can’t be using their email to login or otherwise identify themselves.
Me too, and there is no error reporting because there is no longer an upload process. It’s done “automagically” every night by a background process. There is, however a screen in SB where you can DL the current MBC list as well as upload (though I don’t know why, since it’s now automatic). That screen would be the ideal place to put such errors.
Yes, I meant “SB obfuscated their email address”. The challenge is to find the people who have been obfuscated (guessing maybe any @scoutbook.com email); then map that back to a user record in scoutnet to get the contact info; then go back to the SB dump and figure out who the ‘other’ person is (assuming they are even in your council) with the same email; then determine if this is a duplicate of that person or really another person using the same email; then contact one or both of them to figure out the right email for each.
Or, SB could just tell us this information in an error message since they have all of it in hand at the moment they detect a conflict. Seems much simpler to me, but what do I know.
And what happens if there’s already someone in SB that happens to be using your email (typo or malicious, or whatever) … I guess you just don’t ever get to be a SB user or an MBC?
I don’t either, but it doesn’t seem like they have a lot of folks who actually do this stuff on a daily basis. Love to see some unit serving volunteers, district volunteers, council volunteers, etc. on the committee who actively work with SB, ScoutNET / Akela, etc. on a daily basis. I’d especially like to see some like myself who are both “in the trenches” and are software developers. I think we could contribute significantly to the functionality of the product.
I’m pretty confident I’ll never be considered since I have this terrible habit of pointing out problems and solutions and that’s apparently not what they are looking for. Seems they prefer those who have the “go along to get along” gene fully expressed (just my personal experience mind you).
1 Like
I know that there are some who are active unit volunteers, and some I suspect are volunteering at “higher” levels either within the district or council, the latter based on some offhand comments that have been passed over the years in the forums.
I think a lot of that is what I understand to be a requirement that the SUAC air their “dirty laundry”, as it were, internally to the BSA development group, rather than with all of us out here. At the end of the day, though, SUAC is only advisory. If their opinion is ignored/overruled, they get to lump it like the rest of us.
I know that at least some folks who have historically been critical of how things work have gotten involved in SUAC. Since then, they are more…restrained in their comments. I expect that their “We should do X” and “This is broken because…” comments are now directly development group and BSA-facing, since that’s the audience for getting a change made. Since I’m not on the inside, I can’t be sure (and I probably couldn’t say anything about what’s going on if I were on the inside).
1 Like
I do recall a comment that SUAC input helped change the planned requirement that all unit leaders in Scoutbook had to be registered in their unit on My.Scouting to all unit leaders had to be registered somewhere on My.Scouting.
2 Likes
Scouting is replete with these types and that is yet another problem that we as an institution refuse to address.
If one is not part of the solution they are - by every measure - a part of the problem and those people enjoy my disdain of them.
2 Likes
I wonder how involved these volunteers are on a daily basis. I question it because I see so many obvious things that are not being done that would be high priority for daily users of the product. For example, the complete lack of support, and in fact going out of their way to not support, any district or council level folks such as myself as well as basic unit-level features that get a “what’s the user story for that” response when proposed. We are talking very basic stuff here like search and filter and yet the SUAC members need someone to explain to them why this is needed. That tells me that they don’t use this in a real environment. If they did, the reason for such features would be immediately obvious.
These are actually things I’d attempt to address on day 1 if I were on the SUAC. Transparency is highly beneficial (in my opinion, an absolute requirement). They SHOULD be talking to “us” here on the forums. They should be airing that dirty laundry here so we can be more understanding of what’s going on and their constraints. And at the same time, they need to be squarely “on our side” rather than cold to out right adversarial with the forum users and our requests.
The SUAC should function in the same way as the SM and SPL do between the PLC and the committee. They “represent the group” when talking to the other group. When the SPL is at PLC he’s helping the PLC understand the needs / decisions of the committee. When he’s at committee meeting he’s helping the committee understand the needs / decisions of the PLC. An SPL who simply says “they said no” isn’t doing his job. He’s not representing the group because he’s not providing context. He needs to say “they felt it was unwise because we only have two adults available for the campout and 10 of the 15 scouts who plan to attend are non-swimmers.” Further, they need to offer options or other context to decisions. “If we reschedule the campout for the following weekend four adults can go and they’d be comfortable with that.”
We need ScoutBook / BSA to be more open with us about their plans. In turn, we need to provide quality feedback on the development direction, decisions, etc. That feedback should then drive what’s on the backlog as well as the ordering / priorities. We are, after all, the “stakeholders” for this product since it supposedly is only for units. If that’s true, then there’s literally no one at the district, council, and certainly not national level who should be prioritizing the backlog because IT’S NOT FOR THEM. Yet, we have the exact opposite. The advisory board has, apparently, no power and very little influence, and the people who have literally no stake in the product are making all the decisions.
Again, just my $0.02 and likely yet another reason that they’ll keep me as far away from the SUAC as humanly possible. 
1 Like
BTW, I also have 68 people in the Scoutbook download who have NO merit badges listed so that’s apparently not a criteria to not be uploaded.
Our council has notice that Scoutnet is having issues were one day merit badges donot show and the next day they do.
We also notice that MBC can load from Scoutnet to ScoutBook without badges. The MBC was not showing if the deans were no badges.
1 Like
BTW, I do find it somewhat amusing that to “solve” the supposed “problem” of two users with the same email, they change the email so that it collides with literally EVERY OTHER USER who also shared an email with someone else.
So now, instead of 2 users with the same email, we now have thousands and thousands of users with the same email (all set to “changeyouremail@scoutbook.com”). How did that “fix” the problem exactly?
I wonder what would happen if I set my email to “changeyouremail@scoutbook.com” in scoutnet. Would it go into some infinite loop trying to change my email to what it already is because it collides with thousands and thousands of other accounts?
1 Like
We have asked IT to make the change* e-mail addresses unique by adding a sequence number at the end of each one.
How about just leave it alone; don’t change the address at all. There obviously isn’t a problem with having multiple entries with the same email address. SB creates this problem every time they “fix” someone.
And, how about generating a useful error message so we know when there’s a problem instead of, as usual, intentionally making it harder to find a fix issues.
A functional role push needed to be done, and it looks as if the parent and scout use same email. I know that 2 MBC with an email can cause a problem. Like in my case my son will never have his own email as I Read them to him anyway.
Many e-mail systems allow you to create an alias. If you use gmail, this is done by simply adding + before the @. Other system you need to follow a procedure to create the alias before it can be used.
Using an alias allows e-mail to be sent to the primary account but Scoutbook and other systems to think they are unique. This could be a solution to give your son a unique address while still controlling access.
1 Like
Thank you… I have not had the issue, but as MBC dean it could be a suggestion to parents…
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
