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.
Hi, when I copy and paste a calendar url into a calendar program that supports the iCal (.ics) format, all calendars are hardcoded with the same name. This makes it impossible to to determine one calendar from another by the name alone. This seems to be defined as “X-WR-CALNAME” in the (.ics) file. If I have a Pack and a Den calendar in my list they both appear with the same name making difficult to manage multiple calendars.
Didn’t want this to get missed with the rest of your note. This is key. I was going to say “I rename mine after adding”. Well, it looks like that isn’t possible for some!
How many characters are displayed in the systems for which you can’t modify the name?
It seems (at first blush) like a workable solution to this might be to show the unit number and, in lieu of the chartering organization name, the council number. Then, appended den numbers/patrol names/etc likely would be legible (at least in part)
For example, the proposed format for my unit would be
Troop 0750 Council 049
Troop 0750 Council 049 - XYZ Patrol
It seems like there shouldn’t be more than one unit in the same council with the same number. Even if so, they would likely be chartered by the same organization so having the full chartering org name there doesn’t help differentiate them.
Hi, I can confirm that the names are identical and match with the X-WR-CALNAME value in the generated feed. It would be great if it matched with the names of the calendars in the list.
I wasn’t clear if this was a response to this question:
If so, and assuming that the full X-WR-CALNAME value was included in your previous post, it seems like the answer is “49 characters including spaces”.
If that’s the case, then my suggestion probably needs some tweaking to fully-include longer patrol names. That said, if only seeing enough of the den/patrol name to identify it is “good enough”, the proposed change would still work since there are only 25 characters before you start the den/patrol label, which will get you a space plus 23 more characters for the name.
Making the names exactly the same would be pretty challenging for folks active in more than one unit. It would at least need to include the unit number (likely as a prefix) to allow differentiating between units. In addition, including the council number would accommodate folks who are “split” across council boundaries (e.g. closest boys’ troop is in one council and closest girls’ troop is in another). That covers the edge case of one person with two identical unit numbers in different councils.
I totally get where you’re coming from. If someone is involved with multiple Packs or Troops, there’s a chance they might encounter two Lion Dens. But, considering each Den has its own unique number, it seems quite unlikely, doesn’t it?
Also, I noticed the Troop calendar too. The patrol names, like “Rockin croc” and “Deadly cupcake”, are so distinctive and fun! It’s hard to imagine there would be duplicates across different Troops.
By the way, if you’re managing multiple Troops or Packs, hats off to you! That’s quite a task, and I’m here to support you in any way I can. Keep up the great work!
Not necessarily. I know at least four packs in my district that used “Den 1” as the Tiger Den and moved the scouts to “Den 2” in Wolves at least at one point, rather than migrating the den number with the scouts. Considering the size of my district, that’s not terribly uncommon.
Failure to consider the potential for name clashes is kinda the root of the issue you’ve raised. The calendar platforms not permitting display name changes fail to accommodate the potential that more than one calendar will have a sufficiently similar (or overlapping) name that they can’t be differentiated. It’s always easier to consider the boundary cases and accommodate them (if feasible) at the beginning of the programming effort than to kludge it in later.
The use of the full name of the chartering org in the SB+ X-WR-CALNAME creates an “apparent” clash whenever the number of displayed characters is less than the number needed to get to the “unique” part, even if there were a unique part.
Hey Charley, you know, we have seven calendars in our unit, and interestingly, they all share the same name - “Pack 0160 White Meadow Lake Property Owners Assoc”. This is the name you’ll find in the (USERS SUBSCRIBED TO .ics) file. This is generated when a user subscribes to a calendar and they copy and paste their calendar file url in the calendar program that supports the iCal (.ics) format.
Now, here’s the thing. We don’t have any unique names generated for subscription purposes. But when you look at the Scoutbook Plus Calendar UI, it neatly shows unique names grouped by unit, just as we’d like it to.
We seem to agree that unique names are needed in the ics files, and (possibly) disagree as to the form those should be in. It seems like you didn’t understand the questions I was asking and/or I didn’t understand the responses you were providing.
I was trying to figure out whether the name was unique in its source format (i.e. in SB+), but truncated before it was added to the X-WR-CALNAME value in the ics file and/or truncated by the receiving mail handler (since the name you’re showing is clearly truncated). I couldn’t tell from your post (or the other SB+ ics files I had access to on my end) if all that was happening was truncation based on a maximum number of characters (i.e. the data is unique where stored in the system, but only the first N characters are passed to the ics file) because they all truncated the chartering org name. I asked around some units that have a shorter chartering org name than yours and mine to try to differentiate between truncation and subunit data not being included at all. Based on that, it looks like it is getting added to the ics file as Unit # and chartering org only, not truncated from a longer string (stored somewhere) that included the subunits. Again, I concur that the X-WR-CALNAME values should be unique, and it looks like it’s not just a case of truncation but that the system is not assigning unique values at all.
I suspect (but can’t prove since I don’t have access into the guts of the software) that the unique names displayed in SB+ are being generated based on the numeric value of the ics “file name” (i.e. the last part of the URL, likely via a lookup table). That’s probably the “how” there are unique names displayed in SB+, despite not being shown in the ics file. The why and how to fix it sounds like @DonovanMcNeil has passed along to the developers. All I was trying to do was help sort out what the actual problem was, and make sure it wasn’t one problem (i.e. truncation) rather than another (i.e. inadequate data was being served, irrespective of truncation).
Hi, these values are not truncated when I plug them into our web calendar as show in the list below. You can view this live at https://wmlpack160.com/calendar/ to see that each of these selections are a different calendar such as Aol 3, Lion 7, etc.
Frankly I would like to to be abbreviated more. I have the Pack, boys troop and girls troop. I would to see P321, BT321, GT321. This makes it a quick glance to know which unit is which. The naming of dens is easier in SB+ as it forces you to assign a certain way. Found that out when I promoted the dens. I have resorted in remembering which color is assigned to which unit. I have also requested the units start their event names with the unit like above so that the many of us in multiple units can easily pick out what we are looking for with the unit number.
