Reuse Guard Time

Reuse Guard Time

by Henning Bostelmann -
Number of replies: 5
Picture of Core developers Picture of Plugin developers

Dear Scheduler users,

I'm considering to make the following non-backwards-compatible change in future versions of Scheduler.

At the moment, Scheduler has a feature called "Volatile slots". When a slot is marked as volatile, and the student booked into the slot cancels their appointment, the slot will be deleted so that it is no longer available to other students. However, this deletion happens only if the slot is within the "Reuse guard time" of the current time (the "reuse guard time" is a setting at the scheduler level).

This feature is somewhat difficult to use and in a sense incomplete (e.g., it means that students can't sign up for new individual appointments shortly before the slot, but they can cancel their appointment, or sign up for a group slot).

I'm planning to remove the "Volatile slots" feature entirely, and replace it with the following: At the level of an individual scheduler, you will be able to configure a "guard time". If a slot is closer than the "guard time" to the current time, then students can no longer change their booking on it in any way (they can't make an appointment, or cancel an existing one). There will be no option to configure this on a per-slot level. See also CONTRIB-4862.

However, before I do that, I'd like to ask whether anyone is using the "volatile slots" feature at the moment, and if so, for which purpose, so that I'm not removing functionality that is actually required widely.

Henning

 

 

Average of ratings: -
In reply to Henning Bostelmann

Re: Reuse Guard Time

by Willy Lee -

I'm not convinced that volatile slots ever worked. I went through a few rounds of testing and and it seemed that a volatile slot was deleted any time the appointment was cancelled regardless of reuse guard time. A colleague at York University asked me about it not too long ago and neither of us could get it to work as advertised.

I think your plan makes a lot more sense. It also allows a faculty member to know that no one signed up for an appointment and might save them a trip to campus.

In reply to Henning Bostelmann

Re: Reuse Guard Time

by Gaël Mifsud -
Picture of Core developers
I know it's a bit late but there is some thoughts from teachers who are using Scheduler in my University.
They wonder if the changes in Scheduler 2.7 will have a big impact on their usage.

This is exactly what they have to say :
"

We use the feature 'Scheduler' with the possibility of 12 people (up to 20 people in certain cases) registering in the session (but with certain limitations...)

*A new registration IN the session (or OUT of the session) must not have any impact on the other registrations in the session.( The only change to be seen is in the number of registrations available .)

* people are allowed to unsubscribe (if needed) and therefore it will alter immediately the number of registrations available. This will offer a new opportunity for a new subscriber.

* Somebody registration in a session in the 'Scheduler' implies that he/she will not be allowed to register in a new session of the same activity, unless the session is passed. If so, he/she will be allowed to register in a new session



These features are very important for the activity we have set up and should remain the same ....



Possible evolution :

We would appreciate if we could have the following opportunity for the inscription list:

So far, the list is 'frozen' at the O Hour: (the exact time chosen for the session)

It could be very interesting for us to have the possibility of freezing the list at Hour minus1 or Hour minus 2 in order to print it and keep the list unchanged till the session of the activity.

"

Can we have your thougth ?
Thank you.
In reply to Gaël Mifsud

Re: Reuse Guard Time

by Henning Bostelmann -
Picture of Core developers Picture of Plugin developers

Hello Gaël

Regarding the first three features that you mention: There is no (intended) change in these in Scheduler 2.7. For this to work, you need to set the configuration option "Students can register 1 appointment at a time". This means that students will be able to book a new appointment once the they have been marked as "Seen" in the previous one.

Since I rewrote a substantial part of the code, however, it may well be that I introduced some change unintentionally, which is why I appreciate your help in testing (see below).

Regarding the "frozen" slots, this is exactly what I intend with the new "guard time" feature: If you set the "guard time" to 2 hours, then students will not be able to book slots in the last 2 hours before the session, nor will they be able to remove their booking in the last 2 hours.

Since these features are, as you say, very important to you, it would be best if you could try whether they do actually work in your particular setup. That is, you should best set up a Moodle 2.7 site (a test site, not your actual production site) and simulate exactly the steps that you need for your activity. If you encounter any errors, let me know via the Tracker.

Best wishes
Henning

In reply to Henning Bostelmann

Re: Reuse Guard Time

by Gaël Mifsud -
Picture of Core developers

Thank you very much, Henning.

I forward your answer to my teachers but it seems very positive already.


We will do some tests on a 2.7 Moodle and let you know what we find, and think.