Welcome! This forum has a treasure trove of great info – Scouters helping Scouters! Just a heads up, though - all content, information, and opinions shared on this forum are those of the author, not the BSA.

Scouting Forums

Report for permissions within administrator role

I would like to respectfully request that at least administrators have the ability to create a report that contains permissions for all users within the My Dashboard -> Reports Menu section of Scoutbook.

I feel this report could be extremely helpful to administrators trying to navigate medium to large troops.

Thanks, and have a great day!

Dallas Ivanko

Could you explain this a little more? What would this report contain that is not in the Connections Manager?

The report would contain everything the Connections Manger dictates; however would be easier for searching purposes and would not involve navigating the GUI that can become cumbersome in large troops.

Export to PDF or CSV would be awesome.


Dallas Ivanko

It would be helpful if you produced a mock up of what you are thinking.

Sounds great, I will work on that.



scoutbook-permission-report.xlsx (9.1 KB)

Here is a rough example of what I would like to see.

For combined troops a person could export each permission report in CSV format, easily merge them and have everything in one spreadsheet . So, if an administrator has access to both a Girls and Boys troop information they can see all permissions, and why I placed a “troop number” field.



That could easily be thousands of rows to see every combination of adult leader and scout. Is that what you want?

That’s interesting. Should probably include the other connection types as well – Adult leader, Parent/Guardian, MBC, or Other Family Member, since these can modify the position-based permissions.

Yea … that would be extremely useful.

Well, I’m not sure of what other combinations would result in the same output. I’m open to suggestions, just would like to have everything visible all at once for all leaders / parents and scouts. It would be easier to sort through an excel spreadsheet than traverse the GUI to the far right and up / down to verify all settings that are necessary for permissions.




I wonder if this might make more sense after a revision of the permissions structures. What I mean by that is:

  1. I think that a report on permissions would be useful for debugging on the unit admin side why some people seem to be able to do things and why other can’t.
  2. I think that more granular permissions settings/data would be more useful, but doesn’t really exist right now. For example, as @SteveCagigas pointed out indirectly, the meaning of Full Control changes depending on whether or not the individual is a parent or a leader.

It seems like a hypothetical more granular permissions structure (which I assume is somewhere in the to-do list) would allow directly setting (and therefore investigating) who can execute tasks like:

  • mark Completed (Currently anyone with Edit Advancement or Full Control)
  • mark Leader Approved (Currently any Leader with Edit Advancement or Full Control)
  • mark Awarded (Currently any Leader with Edit Advancement or Full Control)
  • edit connections (Anyone with Full Control? Just parents and unit admins?)
  • edit profile data (Anyone with Edit Profile or Full Control, except certain data which is only editable by support)

The potential complexity of this brings to mind the *nix permissions structure with some combination of r/w/x for each of the User-Group-All entities. If each type of data belonged to some (sub)class of data (e.g. HomeAddress is part of the PersonalData subclass which is part of the Profile class, BSAID would be part of the Profile class but not considered PersonalData, Rank would be part of the Advancement class, etc), and each class and/or subclass of data had variable permissions for access akin to the rwx system (although I’m not sure how in this context “r” and “x” would differ), you might theoretically have some people with read and write access to all of the Profile class, some with read access for all of the Profile class except for the PersonalData subclass,…

I would be curious to see what the developers are thinking about trying to do before it goes forward, just because I’d hope that, if there’s a lot of development effort being invested, there could be some user feedback on whether or not the effort will address the concern, or if a different (easier) structure might be adequate. On the other-other hand, I’m not paying the developers directly, so…

1 Like

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.