Just discovered that several parents are not receiving event reminders. If I go in an specifically send a message, then they get it, but they aren’t getting the scheduled event reminders. Is there an email log so I can deduce who is missing out?
If parents are receiving messages from Scoutbook but not reminders, the parents or their Scouts are not on the invitation list for the event. You can use the Feature Assistant for Chrome and Firefox to quickly update the invitation list for multiple events.
As Scouts join the unit, invitation lists need to be updated to include the new Scouts. They are not automatically added.
1 Like
@edavignon : “Invitations lists need to be updated to include the new Scouts”. That is frustrating and tedious. How can we change this?
This has been on the backlog for a long time. We do not know if or when the BSA will update the calendar to automatically add new Scouts/Parents/Leaders to calendar entries.
1 Like
To put things in perspective, using the Feature Assistant yesterday evening, I added two new scouts to every event in our calendar in about 2 minutes, including logging in. It’s pretty darn fast.
1 Like
I guess I better figure out how to use the Feature Assistant. The bare Scoutbook makes this a real chore.
The help doc for that particular feature is here: 8c. Extending Calendar Invites to New Scouts Extension for Scoutbook.pdf - Google Drive
1 Like
If anyone is looking for specific instructions, they are here: 8c. Extending Calendar Invites to New Scouts Extension for Scoutbook.pdf - Google Drive
By the way, I’m only on my first calendar, and I’ve been waiting for “updating” for 5 minutes already, so I still think this is more tedious that it should be. But the real harm here is how I had no idea people were missing invites. If we can’t fix, can we at least include some kind of “email report” to the unit admin when reminders are (not) sent?
How would that be implemented, though? What I mean is, how does Scoutbook determine who was intended to be invited to any given event so it can “report” the missing people (and not people who were intentionally omitted)? Doing that would require the same sort of logic as determining who to “add” to any given event.
For our troop, for example, we have OA events from the lodge/chapter listed, to which only OA arrowmen are invited (i.e. so the rest of the troop doesn’t think it’s a troop-wide event). There are PLC meetings, to which only youth holding positions of responsibility (and relevant scouters) are invited. Troop scouter (aka committee + SM/ASM) meetings to which only the adult scouters are invited. Plus occasional ad hoc meetings of folks who are doing “subcommittee” work, which have a limited invitee list.
It might be relatively easy to define for some events (e.g. troop/pack or patrol/den meetings), but for others. I suspect it would just give the impression that the problem is being resolved, when it’s only being handled for some cases, but not others. Really addressing the issue would involve some sort of dynamic definition of invitees (e.g. “all youth who hold a current position of responsibility”, “all youth”, “all scouters”, etc). In principle it can be done, but I suspect that the underlying database isn’t structured to handle that kind of dynamic list, and would need a separate process to run periodically to make the updates. I’ve had enough issues with automated scripts in Scoutbook breaking stuff that was working fine that I’m rather reluctant to get too much “help” with invitee lists.
1 Like
My unit has multiple “calendars” (pack, each den…) Scoutbook also maintains a roster for each unit, den/patrol, etc. I don’t understand why there should be an independent mapping between calendars and people. In your example, it seems to me you should have a calendar for OA and a calendar for PLC… everyone enrolled to that group should automatically receive calendar reminders.
I guess another way of asking: Scoutbook obviously can do this because when new events are created it defaults the invite list perfectly well. It’s just skipping that mapping when a scout is added AFTER the event.
Yes, Scoutbook’s calendar system creates separate calendars for units (troops, packs) and sub-units (patrols, dens). Anyone in the unit can be invited to a unit-calendar event, but only folks on the sub0unit roster can be invited to the sub-unit-calendar events.
Scoutbook does not permit creating custom “calendars”, nor custom “groupings”, only manually altering invitee lists within the parameters noted above. Custom groups and/or additional user-defined calendars would be nice, and have both been requested, but neither has been implemented or publicly scheduled for implementation.
Kinda right, kinda wrong. When the event is created, a process is run (once), and a Scoutbook-defined default (not custom) set of invitees is added based on the event type, which may not match with the unit’s intended invitee group. The invitee list can be manually edited during or after event creation. Once the event is saved, the invitee list is static (unless manually edited again). There is no ongoing background process continually querying or updating the invitee list. I would argue that such process would be a bug more than a feature, at least as long as the invitee groups being used for “updating” are defaults, and not customizable by each unit.
For example, the default PLC meeting group only includes SPL & PLs, not any adults, nor any of the other youth PoRs. Some units may only invite their SPL and PLs to a PLC, but many cast a wider net (e.g. ASPLs, APLs, SM & one or more ASMs, etc). Having Scoutbook auto-populate those groups is already a bit of a mess for many units. Having it re-populate the invitee list on an ongoing (or even periodic) basis using the default list would be a disaster (i.e. potentially uninviting folks who were previously manually invited). Even with custom groups, I would argue that there should be a toggle to turn off any auto-updating, as there might be reasons not to update the list (e.g. a joint PLC between the outgoing and incoming groups).
I get the desire, and I’ve lobbied for ways to create custom dynamic groups and invite those dynamic groups to a calendar event, as well as offering the ability to create additional “custom” calendars for various subgroupings. I can see a lot of different ways to (theoretically) implement these, but no part of it is really “easy” from the implementation perspective. It’s also not necessarily cheap computationally in terms of running an ongoing/periodic process for however many events (on average) per unit for however many units there are in Scoutbook. I can understand why it’s not already done, though, given the various ways that it could become complex and/or resource intensive.
1 Like
@MichaelNewman1 - In short the calendar entries are a flat entry. They are not dynamic. In the absence of the feature assistant I go to each event and update the invitees. Now if your calendar has only a few months of forward entries it is somewhat manageable. The feature assistant does the keystrokes to make quick work of the process.
1 Like
Look, I’m a software developer too. I’ve been in your situation where a customer wants to oversimplify something, but the actual implementation makes it much more difficult than it sounds. Nevertheless, the “experience” is broken here: a system which quietly excludes newest members is undesirable. You’ve probably heard the joke about UI designs that require so much explanation…
@CharleyHamilton : I’m not advocating for an “ongoing background process”. I’m saying, when someone is added to a den, a one-shot process can add them to the invite list of future events on that den calendar. Likewise with the unit. This isn’t computationally expensive.
If there are no other groups/calendars supported by Scoutbook, then that is another complaint I would have.
1 Like
It still seems like Scoutbook would need some way (like customizable dynamic groups) to determine to which events new members should be added. Not every event on a unit calendar is something to which every unit member is invited. Defaulting to adding new scouts/parents/leaders to every event would be a significant new bug that would require a lot of manual work to “fix”.
I can see a somewhat clearer path for subunits, since those events are typically subunit wide. Even then, I can also think of instances where they might not be patrol-wide, like a patrol calendar that has a meeting only for folks in the patrol participating a particular patrol event like a campout.
The more I think about it, the more it seems like manual intervention at some level is unavoidable. At the least, units would need the ability to disable/enable the auto-update functionality for individual events to avoid the system adding unintended invitees. In practice, any “custom” groups would require manual definition of membership of some type (e.g. which youth/adult roles belong in the PLC invitations).
I’m not sure how much more/less effort would come from automating the system. It might work for events like pack/troop and den/patrol meetings, to which everyone in the list is invited, but that would still leave all of the other event types “manual”. I’m not sure if a “partial” implementation would be more or less confusing.
I think we’re just disagreeing on rule vs exception, over-communicating vs under-communicating
Could be. Wouldn’t be the first time I’ve “violently agreed” with someone. :^)
I don’t think it’s properly classified as “over-communicating” to invite someone to an event which they are not actually expected to attend, but again that could be classified as a matter of definition, too.
I suppose if we ever want the development team to have a chance at implementing this “correctly”, we ultimately need a clear user story, however it goes.
I’ll propose that whatever the implementation ultimately is should (IMHO) handle:
- youth/adults who are completely new to a unit (add to “relevant” unit & subunit events)
- youth/adults who leave a unit (remove from all future unit events and reminder emails)
- youth/adults who move from one “subunit” to another within the same unit (e.g. stripping them from the prior subunit calendar events and adding them to events in the new subunit)
- distinguishing between events that “everyone” in the unit/subunit should be invited to vs events with limited attendance (maybe an event-level flag to disable auto-updates at the minimum, preferably via support for custom dynamic and static groups)
- an event-level flag to prevent automatic updating of invitee lists
- ideally unit-definable/customizable dynamic groups that can, but don’t have to, rely on Scoutbook account properties to define group members, and can be “nestable” so that super-groups could be made up of defined groups plus others who are not part of a particular definable subgroup.
- ideally, the ability to define the custom dynamic groups based on database characteristics of each person record. For example, some activities may have age restrictions (e.g. high adventure) which might limit who should be getting invitations/reminders to participate. Activities like PLC meetings will only want to youth who hold a position of responsibility.
- a bunch of stuff I haven’t thought of yet. :^)
1 Like
I support everything you just iterated, but my guess is that you also have them generally in easiest-to-hardest order… obviously I would be on cloud 9 if I got #1 and #3.
I know how to bulk import events… is it possible to bulk delete events? (For example, can I just recreate all my calendar events when I want to “fix” invite lists?) This would also be useful in cases where we have a permanent location change.
This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.
