Hi Sue, sorry to hear that the problem isn't resolved yet. I read through the code at that point, and I'm not sure where the behaviour might come from. There are situations when Scheduler sends a cancellation e-mail and then a notification of a new appointment, but as far as I can see in the code, it always happens in this order - cancellation first. As I'm currently without a further clue, can I ask you to look into the log files? First, this would be the Moodle log of the relevant scheduler (see Scheduler administration -> Logs). Look for the relevant time when the problem happened, you can also filter by user. I would be interested whether you see a relevant event "scheduler booking added", " scheduler booking removed", or both, or none; if both, in which order they occur. Then, if you have access to them, look at the web server logs. I'd like to know whether at the relevant time, there appears a URL that has the words "scheduler" and "disengage" in it - and if so, whether this comes from the same ip address as the user that made the booking (cf Moodle log). Sorry for not having something more concrete right now.
Thank you for your time on this.
Looking at the logs they show the booking has been made and then that the booking has been removed, even though I did this booking and know that I did not remove it. The IP address stays the same for all of these entries.
more logs attached - for web logs from scheduler for 15th Sept and Moodle logs for scheduler for 15th Sept. Hope these help
Hello Sue
thanks for the log files. Yes, I think that has indeed helped. It appears the following has happened:
After you clicked "Save my choice", your choice was correctly saved, a "new booking" e-mail generated, and the booking screen was again displayed to you. However, immediately afterwards, the page was then reloaded (but this time as a GET rather than POST request, to mention the details). Why this happened isn't clear to me - I reproduced it by clicking into the address bar of the browser and hitting "Enter", but maybe it's some browser feature unknown to me? In any case, this triggered a bug in Scheduler so that the choice was saved again, but this time with an empty list of slots. Hence your booking was cancelled.
I have made a little change to the 2.7 version of Scheduler so that the problem should no longer occur. It's available from the MOODLE_27_STABLE branch on github. Would you mind installing this on your (test) system in order to see whether it works for you?
This seems to have worked. Have tried it on one that was guaranteed to throw this error every time and so far I have managed to book several appointments.
Thank you