A new feature that could be added is a “Parent View” option that allows leaders with den/unit admin access to be able to view a Scout as if they only had Parent access without having the parent actually log in to show (and possibly forgetting their username/password).
Unfortunately the way Scoutbook is architected, a change like that would rip up just about every page and function. I doubt we will see anything like this unless/until the BSA rewrites all of Scoutbook.
A hack’ish idea would be to create in the background (not shown to users) a Mock Parent user for each unit. Then when a leader checks a box on sign in, instead of showing the normal leader’s interface, it really logs the person in as the Mock Parent for that unit.
Or while the leader is signed in, they can chose a “view as parent” and it replaces their view with the Mock Parent’s view. It uses the current mechanics by having this hidden user as the real permissions.
This works well. I did it when we started using Scoutbook for the troop and parents would ask a question. I would try to talk them through a process and they would get lost. I soon realized some of my screens look completely different than theirs. Running Feature Assistant didn’t help things.
I created “Test Parent” and attached him to my son using a different email address. Now if I need to talk a parent through something I just log on in IE and have the same screens they have.
1 Like
My suggestion is that the developers add this as a feature. They could add a checkbox that toggles between your real admin account and a “hidden” reduces account.
Your idea is a fine work around, I am just saying need it up and make it a default feature.
@Matt.Johnson - I would suggest that it would be more than just a check box involved. There are rights that would need to be masked. The global database holds the keys to what is seen and not seen, so taking a full rights unit user to a full rights parent might be involved. Just my thought unless you have global database design expertise.
Yes, yes, not “just” a checkbox.
Well, I picture it where it does really “make” you that user with lower rights.
Basically toggle a control that puts your session to the side, logs you in as the weaker user (seamlessly), toggle it back, logs you back in as your normal rights. Masking could be done, but I guess what I am thinking it would be easier to use a hidden real
user vs having to mask all of the rights and then unmask them. Maybe too much of a hack?
You may say “sure, no re-architecting, but a whole mechanism to bounce between users”. Ok, yes, pick your poison.
Ok, I have another hack idea. Each unit gets a user that can still be used, but acts like a deleted user (doesn’t show up in the interface). Basically Un-delete and redeleted each use.
Or, each unit can choose to creates a test Scout and test adult and tells everyone they aren’t real, so ignore them. Current work around. 
My area of expertise is process control and industrial automation software, networking, and devices. I have done tiny direct database design (30-100 users).
…and maybe the effort for my ideas are more trouble, risk, and pain than the benefit of the feature.
Matt
@Matt.Johnson - I do totally understand what your concept is and as an outflow of having migrated from another application some six years ago I happen to have a few “parent” accounts that I use to test things with. But certainly, having to off load issues with those accounts to BSA support is not fair. That is what prompted my question about your database background as the concept introduces risks and issues that will tax already limited staff. Again I get it but your best bet is to work with what I have. Create a parent that is far more flexible and forgiving than your real parents.
Out of curiosity, what do you gain by having a “parent view” of a Scout? Especially considering that a “generic parent” and a Scout’s parent are going to be two different things…
As stated in the OP, a way to better help parents through Scoutbook use, better troubleshooting, the ability to see what they see vs what I see.
As I said previously, this is unlikely to happen due to the way Scoutbook is architected.
I got around the need for this feature by creating an account for my wife. If I need to know what a parent would see, I log in to my wife’s account.
Ed,
My suggestions were how to use the current architecture and not rearchitect.
We will continue to use the work arounds.
Matt
Matt,
The underlying architecture of Scoutbook (not what you as a user sees) is what makes your suggestion unlikely to be implemented. Unfortunately, Scoutbook was not coded in a way that makes such a feature easy to implement.
Still the problem remains that what your wife’s account see for a random Scout in the unit is not what that Scout’s parent would see…
@SteveCagigas - I understand what you are saying or at least I think so. Most often we make parent connections for a scout and their parents and guardians. Generally the connection is limited to only that scout. In it’s raw state that is the parent view. That being said there are units that expand the parent view to view only on the rest of the unit. I noted that I have some legacy parent accounts from our migration from troop/packmaster so I use those for any glimpse into a parent view. The concept of a toggle view would involve time and effort better served on the enhanced service to scouts,scouters and units.
I have test accounts for both Adult/parent and youth. I used these to grab screen shots and send to parents when trying to assist them in a variety of steps.
If so many people are using this workaround, is there any chance we could get the ability to flag accounts as “mock users” to exclude them from reports?
Or a broader “inactive” label that could be used for this and also those families who have disappeared, but are still on our charters.
If an account’s membership is “not approved”, I believe the scout is excluded from all reports, and is totally invisible to all non-admins. Just make sure you disapprove the membership when you’re not using the account for something.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
