Similar, but not relevant to this topic. Both links you provide deal exclusively with Blocked reservations. This topic deals specifically with reservations assigned to a unit.
I took a look at the thread, but couldn't tell if you were able to successfully "work around" the problem. Were you able to get it to work? If so, How? I haven't been able to get anything to work.
How would I go about slightly uncorrupting my unit's database? It seems like at least one other user was experiencing the exact same problem. This is making our stake building coordinator's calling much more time consuming than it needs to be. Could it be user specific and not unit specific?aebrown wrote:So whatever you're experiencing does not sound like a universal problem. It may have something to do with your data (either some slight corruption in your unit's database, or a particular combination of factors that don't exist in my scenario),...
Sorry...for the lack of explanation. Workaround was to manually find the conflicts for the ward reservation and add them individually. Luckily we only have a few reservations for each location, but it was a pain.chris.m.cook wrote: I took a look at the thread, but couldn't tell if you were able to successfully "work around" the problem. Were you able to get it to work? If so, How? I haven't been able to get anything to work.
I have experienced the same behavior on unit reservations. But your are correct, those posts did deal with blocks. My apologies potentially leading off topic. I was honestly trying to help.aebrown wrote: Similar, but not relevant to this topic. Both links you provide deal exclusively with Blocked reservations. This topic deals specifically with reservations assigned to a unit.
I also tested this and newly created reservations don't cause an issue as aebrown confirmed. I did find that when I tried to extend some long standing unit reservations that have been around for a couple revisions of the calendar, I did run into the eternal spinner. That said, it wasn't consistent. So I think aebrown is correct in his conclusion that it is an isolated data problem that isn't pervasive. I would be curious if your issue was on newer reservations or if you were extending/modifying older existing reservations that may have underwent some "migrations". If it occurred on new ones...you got me.aebrown wrote: As far as I can tell, I am the only one who has tried to reproduce the problem reported in this topic, and was unable to. So I have to think it is data related, not a general bug.
No apology necessary; your posts are very helpful. Even the links that might not be entirely relevant might have some tidbits of information that could be helpful. I've been in situations like chris.m.cook is, and in mild desperation you're happy to have any information that might provide a key to a solution.dshepher wrote:I have experienced the same behavior on unit reservations. But your are correct, those posts did deal with blocks. My apologies potentially leading off topic. I was honestly trying to help.aebrown wrote: Similar, but not relevant to this topic. Both links you provide deal exclusively with Blocked reservations. This topic deals specifically with reservations assigned to a unit.
That is indeed one option. For the case where an existing reservation is causing a problem when you try to edit its repeating rules, another possible workaround is to delete that reservation and start over, or to create a new reservation that covers the new dates and leave the existing reservation in place.dshepher wrote:Workaround was to manually find the conflicts for the ward reservation and add them individually. Luckily we only have a few reservations for each location, but it was a pain.
I tried, but couldn't duplicate it either. I tried to do it with an event that was schedule by another ward so I wouldn't have rights to the calendar. I tried both a standard room and a custom room. I think I even tried "all day" reservation, but didn't try it against a all day event.aebrown wrote:As far as I can tell, I am the only one who has tried to reproduce the problem reported in this topic, and was unable to.