when original "submitter" moves from unit, phone & email continue to update?

When a calendar editor who submitted an event moves, his name remains as the contact, this I know. But apparently his email and phone continue to update if he changes them after the move. I'm not 100% sure this happens, because other factors may explain it, so perhaps someone else could check it.

I'm not sure what I expected to see happen, but for his new phone and email to apparently "update" to the new ones at his new location surprised me.

I guess if it caused confusion...like ward/stake members still contacting him with questions about the event although he has moved, the new contact for the event (or admin) could call up the event and edit something and save it, which would place their name as the contact...

kisaac wrote:When a calendar editor who submitted an event moves, his name remains as the contact, this I know. But apparently his email and phone continue to update if he changes them after the move. I'm not 100% sure this happens, because other factors may explain it, so perhaps someone else could check it.

I don't have any situation like this that I can check, but this makes a lot of sense to me. What information would the system store in the database about a person? It would clearly be only a user ID (probably an LDS Account ID of some sort). Then when you want to display that person's name and contact information, you look up their current name and contact information based on that ID. You have to do it that way so that if they change their phone number or email address (even while they continue to reside in the same stake and have the same calling), the system will always display the correct current information.

Given that it has to work that way, it's not at all surprising that contact information updates when someone moves and thus the new information is displayed. As explained in the thread Event conflict does not list building scheduler as contact, the event submitter's name is listed, not the current building scheduler (that oddity is the underlying cause of the situation described in this thread). The ID is still valid for the submitter, even if they are no longer in the stake (as long as they are still a member of the Church), so their updated information will clearly be displayed.

Yes, it does make perfect sense, but like I said, I wasn't really sure what I expected. The events he posted are yearly recurring events, so they'll be showing him for quite some time.....

Just something people should be aware of. For example, an admin that has posted many events, often on behalf of others, such as I have now, and then moves, may have his name as a contact on the calendar in an old ward or stake, with no way for him to remove it, for years to come. And now, he could not access the calendar in a previous ward to remove or add a new contact name....
I guess he could unlist his info from his new wards directory, which we are told would "unlist" it from being shown as a submitter. This solution is not common knowledge.....

As has been suggested elsewhere, this does point out that the contact individual for an event, such as an organizational leader, (in case you have a question about the specifics of the event) is not always the original submitter of the calendar event, which may be an admin or building scheduler (which you may need if you have a question about the posting of it or a room reservation associated with it.)

We really must have a submitters name, and I was a huge advocate to see it listed, so I'm not sure of an easy solution here. And, maybe, its not even a real problem.

In developing the calendar (and the directory for that matter), we really hoped to get a rule passed barring all members from changing wards.

What we should do here is if we detect the user has moved, replace them with another calendar editor as the contact. This gets a little tricky, as there are many possible situations we'd have to account for.

Thanks for pointing this out. I'll put something on the backlog and maybe we can figure out a solution in a future release.

jdcr256 wrote:What we should do here is if we detect the user has moved, replace them with another calendar editor as the contact. This gets a little tricky...

Yes that seems like a solution. Or maybe if they are no longer a current editor of that calendar, a current one is listed as the contact? Perhaps you didn't move, but were released and given a new calling in the ward or stake. Again, this removes the "original submitter," info, that still may be needed in case we need to track "who modified what" to the event.

And, you are masters at being TRICKY!

jdcr256 wrote:What we should do here is if we detect the user has moved, replace them with another calendar editor as the contact. This gets a little tricky, as there are many possible situations we'd have to account for.

Suggestion: If the member has access due to their calling, then store the calling as "creator". If the member changes, perhaps note that it was done by a predecessor, and then refer to the person now holding that calling.

The tricky part comes if there's more then one person with that calling.