Calendar colors for "name-changed" original calendars - problem

As Ward Clerk, I changed the following original calendar names:

"Deacons" --> "YM - Deacons"
"Teachers" --> "YM - Teachers"
"Priests" --> "YM - Priests"
"Beehives" --> "YW - Beehives"
"Mia Maids" -->"YW - Mia Maids"
"Laurels" --> "YW - Laurels"

It's easier this way to group organizations together when subscribing to calendars.

However, the problems is that now the newly named calendars show up in white color with white text in the "Subscribed Calendars" section of the calendar. You can't even see the calendar name until you hover you mouse over it. I can change the colors of these calendars personally, but every other member in the ward will have to do the same. Can't those calendar colors remain the same as the original (before I changed the calendar name)?

Thanks!

-Dan

(see image)

I believe the colors are just how they are assigned to you based on how many you subscribe to. You may want to log out and log back in to see if it changes.

Note: since this was unrelated to the prior posts, I moved this into a new thread.

dbollard99 wrote:However, the problems is that now the newly named calendars show up in white color with white text in the "Subscribed Calendars" section of the calendar. You can't even see the calendar name until you hover you mouse over it.

Having white as a calendar color has been reported here. When the subscribed calendars exceed 42 and each color is only assigned to one calendar it appears that white, which is not on the user selectable pallet of colors, is available to be assigned by the system.

The colors assigned to calendars can be changed by the user. Some choose to use the same color for calendars that could be grouped together and thus free up some colors. If the system assigned color is not changed by the user then it is possible that white can be assigned (at least until the programmers change this) when the number of calendars exceeds 42.

dbollard99 wrote:I can change the colors of these calendars personally, but every other member in the ward will have to do the same.

And those that have decided to use one color for several related calendars may not notice this until all 42 colors are used.

dbollard99 wrote:Can't those calendar colors remain the same as the original (before I changed the calendar name)?

I suspect that when the calendar name is changed it is treated as a new calendar, at least as far as assigning a color to the calendar.

I would expect that since the developers are aware of the white calendar color issue that it has been logged to be fixed. Unless a program team member responds about the suggestion regarding retaining a calendar's color when it is renamed you may want to submit a suggestion through the LDS.org "Submit Feedback" link.

jdlessley wrote:Having white as a calendar color has been reported here. When the subscribed calendars exceed 42 and each color is only assigned to one calendar it appears that white, which is not on the user selectable pallet of colors, is available to be assigned by the system.

The colors assigned to calendars can be changed by the user. Some choose to use the same color for calendars that could be grouped together and thus free up some colors. If the system assigned color is not changed by the user then it is possible that white can be assigned (at least until the programmers change this) when the number of calendars exceeds 42.

And those that have decided to use one color for several related calendars may not notice this until all 42 colors are used.

I suspect that when the calendar name is changed it is treated as a new calendar, at least as far as assigning a color to the calendar.

I would expect that since the developers are aware of the white calendar color issue that it has been logged to be fixed. Unless a program team member responds about the suggestion regarding retaining a calendar's color when it is renamed you may want to submit a suggestion through the LDS.org "Submit Feedback" link.

I just counted my calendars:

• We have 51 calendars.
  • 23 are Stake Calendars
  • 17 are Ward Calendars
  • The rest are misc. calendars (missionary, cleaning, pavillion events, holidays, etc.)

• Currently, I am subscribing to 38 of the calendars.

The only time the app assigns colors to the calendar is when the calendar is first subscribed to (actually, it is the first time the main calendar view loads after subscribing to that calendar).

That means if you change the name of a calendar, but don't unsubscribe/resubscribe to it, the color should not change. However, it should also be the case that the color assignment will not fail until you have over 42 subscribed calendars. This is because the javascript picks a random color to assign that is not already assigned, and then calls out the database to actually assign the color. You can see this happening in the Console tab of Firebug when you first view the calendar after a new subscription. If you have more than the 42 calendars subscribed, you can see the web service calls for the color do not have a color ID included in the url, because the javascript has exhausted the list without finding a color ID that was not already used.

In your case, it sounds like you did not change your subscription status at all, and you are not subscribed to more than 42 calendars. I would be interested to know what is happening when the javascript tries to assign a color. If you're adventuresome and willing to use Firebug, the call you are looking for would be:

lds.org/calendarws/services/lucrs/cal/{CALENDAR_ID}/color/{COLOR_ID}.

To use firebug:
- Install the Firefox add-on Firebug
- Open Firebug, click the Console tab, click the 'Enable' link
- Log in to calendar, or refresh the page if already logged in
- In Firebug, look for the URL above
- Firebug will tell you if the call succeeded (200 ok) or failed (some other number code like 404 or 500)

As far as worrying about other users, their calendar color should not change when you change the name, only if they unsubscribe and resubscribe. So while it's possible you've discovered a new bug that they will also experience, you should be able to expect that they will see no change to their colors.

jdcr256 wrote:The only time the app assigns colors to the calendar is when the calendar is first subscribed to (actually, it is the first time the main calendar view loads after subscribing to that calendar).

That means if you change the name of a calendar, but don't unsubscribe/resubscribe to it, the color should not change. However, it should also be the case that the color assignment will not fail until you have over 42 subscribed calendars. This is because the javascript picks a random color to assign that is not already assigned, and then calls out the database to actually assign the color. You can see this happening in the Console tab of Firebug when you first view the calendar after a new subscription. If you have more than the 42 calendars subscribed, you can see the web service calls for the color do not have a color ID included in the url, because the javascript has exhausted the list without finding a color ID that was not already used.

In your case, it sounds like you did not change your subscription status at all, and you are not subscribed to more than 42 calendars. I would be interested to know what is happening when the javascript tries to assign a color. If you're adventuresome and willing to use Firebug, the call you are looking for would be:

lds.org/calendarws/services/lucrs/cal/{CALENDAR_ID}/color/{COLOR_ID}.

To use firebug:
- Install the Firefox add-on Firebug
- Open Firebug, click the Console tab, click the 'Enable' link
- Log in to calendar, or refresh the page if already logged in
- In Firebug, look for the URL above
- Firebug will tell you if the call succeeded (200 ok) or failed (some other number code like 404 or 500)

As far as worrying about other users, their calendar color should not change when you change the name, only if they unsubscribe and resubscribe. So while it's possible you've discovered a new bug that they will also experience, you should be able to expect that they will see no change to their colors.

I did as you requested, see the image below for the results:
Also, regarding other users, I signed in under my wife's profile to view her subscribed calendars. She was already subscribed to the calendars before I renamed them. And now (after I renamed them) she is still subscribed to those calendars, but they are white in color, with white text. So I fear it is this way for all users, whether they have unsubscribed and resubscribed to them or not.

All I did was rename an existing calendar. (i.e. - "Deacons --> "YM - Deacons"). Ideally, this should not affect users subscriptions and/or the calendar colors, or require users to unsubscribe and resubscribe.

dbollard99 wrote:All I did was rename an existing calendar. (i.e. - "Deacons --> "YM - Deacons"). Ideally, this should not affect users subscriptions and/or the calendar colors, or require users to unsubscribe and resubscribe.

To offer a contrasting experience, I created enough calendars to cross the 42 calendar mark. I do see the problem with newly subscribed calendars being white, with the accompanying webservice error reported in Firebug. But repeated experiments with renaming calendars shows that the calendar color never changes. Any calendar that had an assigned color remains that color.

So that makes me wonder if there is some other factor going on with the calendars you mentioned. In particular, have you tried a controlled experiment since then? By that I mean, have you looked carefully at the color of one calendar, renamed that calendar, and observed the calendar after the rename? If you repeat that experiment, do you get consistent results -- the color always changes or never changes? That would help us understand if it is a problem that always occurs for you, or if the initial problem you reported was actually the exception.

I second aebrown's question. Is this something you can repeat again? The only other reason I can think of for losing the existing color would be if the calendar ID changed. But that would cause much bigger problems than just losing the color (e.g. any subscriptions to that calendar, or events on that calendar, would also be lost).

Also, can you re-confirm exactly how many calendars you are subscribed to?

Incidentally, I just fixed the issue of not getting colors past the 42 calendar mark, so that will be in the next release. But for now it looks like this is a separate issue.

dbollard99 wrote: We have 51 calendars.

• 23 are Stake Calendars
• 17 are Ward Calendars
• The rest are misc. calendars (missionary, cleaning, pavillion events, holidays, etc.)

I doubt that it is particularly relevant to the problem at hand, but that count can't really be correct. Every calendar is either a ward or stake calendar -- there is no category of "misc. calendars." So the 11 calendars not categorized as ward or stake calendars must surely be either a ward or stake calendar.

dbollard99 wrote:Currently, I am subscribing to 38 of the calendars.

Is there any chance your count of 38 is not accurate? Are you counting all ward and stake calendars that you are subscribed to? I was unable to duplicate any issues with calendars having a white background until I crossed the 42 calendar limit. And then I duplicated it easily.

It appears that the Calendar system keeps trying to assign a color to those white calendars. So in my testing, if I ever dropped my subscribed calendar count down to 42 or less, the white calendars were assigned a color as soon as I went to the main calendar view. I am unable to see any white calendars unless my subscribed calendar count is currently more than 42.

Omigosh!!! Fixed it!

So, apparently, I misunderstood the difference between 'subscribing' to a calendar, and check-boxing the calendar to view it. They are independent variables. I thought I was unsubscribing to a calendar by unchecking it in the main Calendar view.

I went to Settings-->Subscriptions, and actually 'unsubscribed' to most of our several Stake Calendars that don't pertain to me. (There are 51 calendars total!).

After unsubscribing to several, I am now down to 32 subscribed calendars, and they all have colors!

So, problem solved for me. Although, most users in my ward will not know to do this I'm guessing, as i think the default is for them to be subscribed to all 51 calendars! And if they don't know about the 42 calendar limit, they will be confused as I.

I would still suggest that there be more than 42 colors available for those of us with many calendars. Or some other solution that I'm not thinking of. Maybe you could set the default for STAKE CALENDARS as not automatically subscribing every member. (We have 34 Stake Calendars alone!). Or is it just not recommended for the Stake to have that many calendars?

Thanks guys for all your help!



To be more clear, aebrown, you are right, here is my breakdown of calendars:

• We have 51 calendars.
  • 34 are Stake Calendars
  • 17 are Ward Calendars

• Currently, I am subscribing to 32 of the calendars.

Man, 34 stake calendars! We have five. What are we missing?

dbollard99 wrote:Omigosh!!! Fixed it!

That's good news!

dbollard99 wrote:So, problem solved for me. Although, most users in my ward will not know to do this I'm guessing, as i think the default is for them to be subscribed to all 51 calendars! And if they don't know about the 42 calendar limit, they will be confused as I.

That's certainly true for most users -- they either don't know about changing the auto-subscribe setting, or they leave it on, so they will be subscribed to all calendars.

dbollard99 wrote:I would still suggest that there be more than 42 colors available for those of us with many calendars. Or some other solution that I'm not thinking of.

It's tough enough to distinguish among the 42 colors, so I don't think adding more colors would help very much. But reusing some colors automatically when there are more than 42 colors, instead of using the white background, would be a big help.

dbollard99 wrote:Or is it just not recommended for the Stake to have that many calendars?

It's tough to say what the optimal number of calendars is. Certainly having more calendars allows you to have finer control in administration. But when you have a large number of calendars, you are asking your members to sift through a lot of calendars in order to decide what calendars are important to them. Just sifting through all those calendars can be a bit overwhelming to some members.

To take one example, I saw from your first post that you have a separate calendar for each of the 6 youth classes. I don't know, but you might also have a YW calendar, a YM calendar, and a combined Youth calendar. That would be 9 calendars. Such an approach lets you give specific control over the Deacons calendar to the Deacons Quorum Adviser, the Deacons Quorum President, and perhaps others. Then a Laurel wouldn't subscribe to that calendar and thus wouldn't see any of those events. There are advantages to that, but you have 9 calendars just for the youth.

An alternative approach is to have one combined Youth calendar, or perhaps Youth, YM, and YW calendars. Then you have 1 or 3 calendars instead of 9, which is a great simplification. You would then have to name events on that calendar in a way that makes it clear that this event is a Deacons event, and that event is a combined YM event, and another is a Laurels event. Subscribers to the calendar would see events they may not be interested in. But with this kind of approach, you might be able to run a stake with half a dozen calendars (our stake has only 8 public calendars, one of which is a Holidays calendar and another is used for reserving resources that are not associated with calendar events).

There are obviously pros and cons to either approach, and different wards and stakes will make different decisions, but 51 calendars does seem like it might be a bit daunting for your regular users.

dshepher wrote:Man, 34 stake calendars! We have five. What are we missing?

To me, there's two criteria for splitting calendars:

1) Do people want to subscribe/unsubscribe from a given category of events? For example, members without youth at home are not likely to be interested in the youth activities. Placing those events in the "General Events" calendar may prompt many of them to see it as "event spam" and not sync events to their personal calendars. That could affect their attendance on events that does apply to them.

2) Administration Different calendars can have different access controls. For example allowing YM to control one calendar and the YW another.

Obviously one can go overboard on the number of calendars. One general rule I use is if an event only happens once a year, it's not worth a separate calendar.

Here is a list of our 34 Stake Calendars:

[font=&quot]1. Activities/Events @ Maryland Pavilion
2. Activities/Events @ Topaz Pavilion
3. Baptism
4. CCSD Holidays & Staff Days
5. Facility Cleaning Schedule, etc.
6. Las Vegas Temple Schedule & Mtgs.
7. Liberty Building Other Units Activities/Events
8. Maryland Bldg - Other Units Activities/Events
9. Missionary Firesides & Meetings
10. Stake Activities
11. Stake Conf; Mtgs; HC Sun; etc.
12. Stake Ctr - Other Units Activities/Events
13. Stake Emergency Communications (hams)
14. Stake Music and Cultural Arts
15. Stake Primary
16. Stake Relief Society
17. Stake Single Adults
18. Stake Welfare Assignments
19. Stake YM/YW Combined Activities
20. Stake Young Men
21. Stake Young Women
22. Stake-BE
23. Stake-DB
24. Stake-HA
25. Stake-LP
26. Stake-PA
27. Stake-RB
28. Stake-SE
29. Stake-SI
30. Stake-ST
31. Stake-SU
32. Stake-WS
33. Topaz Building Other Units Activities/Events
34. US Holidays [/font]

What does yours look like?