Duplicate location name showing up for event scheduling

[aebrown]

We've asked the other Stake to delete the extra location so we can share the location with them (we are the agent stake), but they said they can't because it is the FM database. I don't have access to any of the stake screens, so I don't know what to do to "make it right".

Locations created through FMAT cannot be deleted, but they can be effectively disabled. To do that, the other stake needs to:

1. Go into Settings > Locations & Rooms
2. Edit that shared location
3. Uncheck the box labeled "This location can be scheduled by Wards and Stakes"
4. Save their changes

I'm not 100% certain, but pretty confident that doing this will cause that location to no longer appear as a duplicate on your list of locations when you go to schedule events.

How can we tell if a location is in the FMAT database vs if it was created through the calendaring system?

Perhaps locations created through FMAT cannot be deleted and locations created through the calendaring system (outside of FMAT) can be deleted?

Yes, that's the reliable way to tell if a location was created through FMAT -- it cannot be deleted. If the location was manually created, there will be a Remove button (see screen shot below). If it was created through FMAT, there will be no Remove button.

RemoveLoc.png

[nathangg]

aebrown, and RusselHtn, THANK YOU!

Here is what we figured out:

* We first had to figure out which stake was the agent stake for all three of the shared buildings (yes, our stake shares three buildings with the stake south of us)
* Once we figured out which stake was the agent stake, we decided to use that stake's location [1].
* Once we knew which locations we were going to use, we had to disable all the extra locations (by going into the non-agent stake's admin screens)

Now comes a huge cleanup effort to put all the events back on the right locations.

[1] Note: some of the locations must be set up wrongly in the FM database because the remove button does NOT show up for some shared locations even though the OTHER stake is the agent stake. (Wow, that's a mouthful).

For example, there is a location "Bayou Gulch Building" in the Parker stake admin screens, but the Parker South Stake is the agent stake. There is no "Remove" button when viewing this location on the Parker Stake's admin screens. This makes me wonder that perhaps the FM database has the Parker Stake as the agent stake for this building when in fact the agent stake should be the Parker South Stake.

Should we get this fixed in the FM database FIRST, before changing all of our events around? Or does it matter? Is there any way I can see if the FM database is right/wrong?

Thanks~!

[aebrown]

* We first had to figure out which stake was the agent stake for all three of the shared buildings (yes, our stake shares three buildings with the stake south of us)
* Once we figured out which stake was the agent stake, we decided to use that stake's location [1].
* Once we knew which locations we were going to use, we had to disable all the extra locations (by going into the non-agent stake's admin screens)

That's good that you figured out first who was the agent stake. I had incorrectly assumed that your stake was the agent stake. Indeed, the best practice is for the agent stake to define the "official" location, and share it with all other units who share that building.

Note: some of the locations must be set up wrongly in the FM database because the remove button does NOT show up for some shared locations even though the OTHER stake is the agent stake.

There have been some communications that lead me to believe that the FMAT database will link that building to all the stakes that use the building, even those stakes that are not the agent stake. Early versions of the calendar documentation indicated that buildings shared among stakes would only be shareable on the calendar if all the stakes involved were connected to the building in FMAT. If I recall correctly, that was before the feature for assigning a unit to a location was created. But in any case, that seems to imply that in FMAT all the stakes are linked to the building. If that theory is correct, all the stakes will end up seeing that location in their list of locations, and the only option they would have is to disable that building from being scheduled.

It would be much better, in my opinion, if the building only showed up in the location list for the agent stake. That would require an adjustment in the linkage between FMAT and the calendar system. But as you have learned by painful experience, it really only makes sense for that location to appear in one stake's list of locations, and that would of course have to be the agent stake.

Should we get this fixed in the FM database FIRST, before changing all of our events around? Or does it matter? Is there any way I can see if the FM database is right/wrong?

If my theory is correct, the FM database itself is correct; it's just that the calendar system puts that building in the list of locations for all stakes involved. Fixing that would require a code change, which I don't think you want to wait for. You could (through your stake's PFR) ask the FM Group manager to verify that FMAT is set up correctly for this building.

But in the meantime, I think you've got the right strategy for sorting out events in this shared building: the agent stake shares the location, and the other stakes use that location. For existing events that are on the duplicate locations, move all the events over to the official shared location, and disable the duplicate locations from being available for scheduling.

[nathangg]

If my theory is correct, the FM database itself is correct; it's just that the calendar system puts that building in the list of locations for all stakes involved. Fixing that would require a code change, which I don't think you want to wait for. You could (through your stake's PFR) ask the FM Group manager to verify that FMAT is set up correctly for this building.

Hmm, I'm not so sure that the FM database is correct right now for our stakes because I just got an email from a stake clerk mentioning that the FM Group Manager had found that the wrong wards were assigned to the wrong buildings for these shared locations. Since the Parker South Stake split from the Parker Stake just 10 months ago (and 2 ward splits occurred at the same time, along with some wards going to different buildings) it is possible that some things didn't get updated in the FM database.

I'll suggest that the FM Group Manager verify that the agent stake is setup properly also (via the stake clerk).

But in the meantime, I think you've got the right strategy for sorting out events in this shared building: the agent stake shares the location, and the other stakes use that location. For existing events that are on the duplicate locations, move all the events over to the official shared location, and disable the duplicate locations from being available for scheduling.

Great. I'm glad this plan seems to make sense in how things should be done. Now comes the hard part: getting ALL of our 2012 events on the right locations for three shared locations.

[russellhltn]

Since the Parker South Stake split from the Parker Stake just 10 months ago (and 2 ward splits occurred at the same time, along with some wards going to different buildings) it is possible that some things didn't get updated in the FM database.

I was just going to suggest that possibility.

Until this calender system came about, I'm not sure what, if any problems would be created by having an out of date database. As such, keeping it up to date may not have been one of their higher priorities. I'm not putting anyone down, I'm just looking at organizational behavior.

[nathangg]

I was just going to suggest that possibility.

So, let's guess for a minute. What if a building in the FMAT database has the wrong agent stake AND it gets fixed. Is that going to mess with our calendar events?

For example: the "Bayou Gulch" building originally belonged to the Parker Stake (before the split). After the split, if the FM database wasn't updated, then the Bayou Gulch building still belonged to the Parker Stake, even though it should belong to to the Parker South Stake.

Fast forward 10 months and both stakes have done a lot of their 2012 planning with "Bayou Gulch" being setup wrong (Parker Stake is sharing Bayou Gulch with Parker South instead of vice-versa). Now we are trying to fix all of this... if it is wrong in the FMAT database AND then they change it, are all of the events at the "Bayou Gulch" location going to get wiped out and need to be re-saved?

[aebrown]

Fast forward 10 months and both stakes have done a lot of their 2012 planning with "Bayou Gulch" being setup wrong (Parker Stake is sharing Bayou Gulch with Parker South instead of vice-versa). Now we are trying to fix all of this... if it is wrong in the FMAT database AND then they change it, are all of the events at the "Bayou Gulch" location going to get wiped out and need to be re-saved?

The events would definitely not get wiped out; the worst that would happen (and it's bad enough) is that all the events that use that location would suddenly be listed as using "No Location." That happened during the v2 beta a couple of times.

[nathangg]

The events would definitely not get wiped out; the worst that would happen (and it's bad enough) is that all the events that use that location would suddenly be listed as using "No Location." That happened during the v2 beta a couple of times.

So perhaps the only way to be 100% sure of what will happen is to 1) see if FMAT is wrong and 2) fix FMAT and see if the events lose the locations? (I'm not upset, just trying to gauge the potential for having to change a bunch of events).

I wonder how often the sync between FMAT and the calendar database happens. Hopefully within 24 hours after the change?