I’m officially verified in Scoutbook as the Pack Religious Emblems Coordinator, but apparently the role does not include any permissions. I am unable to run reports to see who has completed their emblems nor can I enter when a Scout has completed their religious emblem.
You need to be connected to the Scouts in the pack with Edit Advancement in order to record that their religious emblem was completed. Ask a unit admin (2 keys on next to their name on the pack roster) to make the connections for you.
1 Like
For what it’s worth, that’s not a very efficient way of assigning roles-based permissions.
Your unit can use the Feature Assistant Extension for Chrome and Firefox which has a function called “Permissions by Positions”.
Since units operate differently, there is no single set of permissions that would work for all positions for any given unit. For example, in a Troop, the Guide to Advancement gives the Scoutmaster the authority as to who can sign off on advancement. In some troops, this is all Assistant Scoutmasters, in others it is only a few Assistant Scoutmasters, while I’m sure there are some small troops where only the Scoutmaster signs off.
2 Likes
Thanks, I’ll see if I can find someone who is tech savvy who can do that. Despite the fact that this is a Pack, I understand what you’re getting at.
Apparently there are roles within Scoutbook that have certain permissions by default because of the duties and responsibilities of the position. Everything doesn’t have to be customized for every unit. That would be tedious.
Thank you for taking the time to reply.
Yes and no. There are some defaults for access by position, but not a lot of them, and it’s primarily centered around the Unit Key 3 (CM,CC,COR). Also, you can’t assume that every position has default access/permissions to perform a particular activity, just because it falls under the generic duties list that the BSA has propagated. Since Scoutbook started as a non-BSA-owned program, there are some internal structural issues (e.g. granularity of permissions) that make something like that difficult to implement.
I recommend taking a deep-dive in the help files on the way permissions are structured for Scoutbook and IA2, as they are not necessarily intuitive, and don’t “propagate” to new scouts except for certain positions (e.g. Key 3, Unit and Den Admins, and certain functional roles assigned at my.scouting). One spot to start is the article below, but there are a lot of other function-specific help articles that touch on permissions, like who has what level of access to edit and/or approve activity logs at IA2 and who has access to edit calendars, etc.
Thanks Charley, I agree that there are some issues. I hope someone involved in the system development monitors the forums and is open to user feedback.
Unfortunately, the development group does not (at least not officially) monitor the discussion groups. The SUAC folks like @edavignon and others are the conduit for feedback to the folks actually making the decisions and providing direction to the developers. Even they only have an advisory role, and can’t “direct” a change, no matter how much they may agree with or advocate for it.
The permissions structure is a long-known issue, and has been part of the long-term development plan, if I understood prior comments correctly (and BSA priorities haven’t changed). That said, I agree with Ed that not every unit is going to assign tasks as they are in the BSA boilerplate, so having position-based access without customization may not be a feasible approach, except for folks like Unit Key 3 and Key 3 Delegates/admins. However, looking just at how IA2 was initially structured (access limited to Unit Key 3 and those with certain functional roles assigned in my.scouting), it looks like we’re headed for more restrictive, rather than more customizable, access. That might mean that there isn’t even the “work-around” that exists currently in Scoutbook. Since we as users only see the results after they have been released – not a list of what’s coming down the development pipeline – we won’t know what’s actually happening until after it happens. I personally find that a frustrating way to work, but I’m not far enough up the food chain to get a vote. :^)
1 Like
Permissions is not simple if we are to follow BSA Guidance like the GTA.
3 Likes
Okay, I understand. I’ve been doing software development for a couple decades now, so I get the whole prioritized backlog thing. Glad to hear it’s a common complaint and I’m not just missing something obvious. Since this is a volunteer-based organization, I’ll follow the path of least resistance for this one and just shrug. Will keep a spreadsheet for my own use. Much appreciated!
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
