Changing a calendar's unit type (Ward/Stake)

Hello. I was just discussing an issue with one of our developers for the calendar and we came up with a question we don't have an answer for: Why change a calendar from a ward calendar to a stake or vice versa? We couldn't really come up with a use case for this functionality. Can anyone provide some examples of when they've changed a calendar from a ward calendar to a stake calendar or back the other way? What prompted the move? Did you have any problems with getting the calendar converted?

kyleq wrote:Why change a calendar from a ward calendar to a stake or vice versa? We couldn't really come up with a use case for this functionality.

I haven't done it myself, but I can see where it would be useful:

• Someone created a calendar at the wrong level and now it needs to be moved
• A ward created a calendar for a shared groups, such as a merged scouts group. Once everyone realized that a single ward-level calendar wasn't going to work, it was moved to a stake-level to allow both wards to see it.

In both cases, while it's possible to delete and re-create the calender, that would require rescheduling everything. While an export/import might help, they'd still have to fix the location for each event taking place in a church building.

That said, I think we've seen a couple of cases here in the forum where someone might have moved a calendar by accident. So it shouldn't be something that's too easy to do.

One strange thing about this feature is that it's not really bidirectional. Any ward administrator can change a ward-level calendar to be a stake calendar. But a stake administrator can only change a stake calendar to be a ward-level calendar for his own ward. That's odd, because a stake administrator probably has no rights for his home ward's calendars. If a stake administrator does need to change a stake calendar to be a ward calendar (about the only case I could see this being needed is to undo an inadvertent change someone made from a ward calendar to a stake calendar), it would be relatively unlikely that the desired ward just happened to be the stake administrator's home ward.

And that was the crux of our problem...we couldn't really see a good use for this. In fact we could see it causing more problems than solving. Converting from ward to stake is easy enough but converting back to ward from stake will rarely be done correctly. Right now we are working on solving a long standing bug related to calendar conversions. One of the more simple solutions is to disable this functionality and provide for a bulk import/export that is easier to use. This would lock a calendar type (ward or stake) for the life of the calendar. I'm all for flexibility within an app but this flexibility seems to really not serve a useful purpose.

Before we make a change like this though we'd like a bit more input. What do you think about calendar conversion to other types being removed?

kyleq wrote:What do you think about calendar conversion to other types being removed?

From a user standpoint, as long as there is a export/import that includes dealing with booking the locations, I don't see a problem.

However, from a programming standpoint, I suspect getting a working import that can deal with location conflicts (including reservations that were overridden) is going raise more issues and be more problematic then migrating existing events to a new calender. For example, how do you insure that nothing has changed since the export? How do you prevent someone from using the import from overriding existing events? Seems like this would eat up far more development resources for the benefit it creates.

kyleq wrote:What do you think about calendar conversion to other types being removed?

I can certainly conceive of situations where it could be useful to change a ward calendar to a stake calendar. RussellHltn mentioned a couple in his first post in this topic.

However, in the entire time our stake has used the new Calendar, this feature has only been used twice, and both were mistakes. The ward admin who made the change didn't understand what he was doing and so we had to try to undo it. In both cases, we happened to have a stake admin who was in the ward, so we could undo it.

I know that's not a statistically significant sample, but still I have to think that this feature just isn't all that useful, and it certainly creates the possibility of misuse -- a possibility that could be more likely than proper use. So I wouldn't mind if the feature were removed.

On a whole, while I have argued for keeping it: I think that as a function of user benefit vs. developer time, this probably doesn't make the cut. There are other features that are more pressing.

And since I'd think most units would be on the new calendar by now, any need has largely passed. All the scenarios I can come up with are all part of getting things set up properly, not ongoing usage.

So if you can't fix it in a short amount of time, I say drop it. It's not like there isn't a work-around (manually re-creating). I can't imagine anyone having hundreds of events that they have to move.

I concur with the others here that this function could be removed without much grief from us as users. Our stake has never used the functionality in either direction.

I'll point out, or maybe just reiterate, that for anyone that mistakenly creates a calendar at the wrong level, this isn't a big deal, re-create a new one at the right level and delete (or get assistance deleting) the wrong one. At this point in the calendar's existence there are no events on it, so nothing lost here.

Maybe for the few case where this functionality could be a useful, you help to alleviate that by clarifying or reiterating in the help pages the differences, maybe including something like: "any calendar that will need to be accessed by members of more than one ward, even if it's just 2 wards and not the whole stake, the calendar will need to be a stake calendar"

On the other hand...

I will point out that a work around for getting a stake calendar back to a ward calendar could be as easy as temporarily assigning a stake administrator from the ward in question... maybe I'm missing something, and I realize it's not the ideal solution, but seems like that would work easy enough.