Looks like Evergreen is getting this feature:
Maybe something for Koha too? :-)
This would be super helpful.
Good idea. Especially with the current health emergency.
I'm interested in trying to get a specification for this together.. starting with something simple hopefully that we can implement as a quick phase one.
I can see challenges around notification of when items are available for pickup and what items are available for request and when... nothing unsolvable but it would be interesting to get peoples thoughts around the topic.
I know Lucas at Bywater put together some JQ that replaces the "notes" section on the OPAC with a very basic curbside scheduler. It works well for single-branch libraries (or libraries where you can only put on holds from your branch) but I'm not sure you can limit how many patrons at a time are doing curbside so you don't get flooded with curbside appointments.
For us as a consortium with multi-branch libraries within the consortium, we would want to schedule pickup once the hold is available and be able to limit how many people are doing curbside at a time, as well as setting times and limits on each branch. We are doing a 15 minute window with up to 10 pickups at a time at our branch. Currently our branch is using a paid service to facilitate this.
Ideally in Koha we could do a link/have them go to the OPAC login and could schedule from there once holds were in.
It would be helpful if we could check out all waiting holds with a button press so when we are prepping the materials we can say 'these are the 15 holds for this patrons, check them all out' to speed up the process and reduce how much staff is handling the items. I know we could copy the barcodes into batch checkout, but it would be much smoother if there was a button.
For the long run, having it be something you could turn on and off/branch would be ideal, although if you could set pickup times for each branch those that aren't using it could just not set up times.
I think I saw that Evergreen's plan was to have a check in option when they arrived and I think that would be helpful as well.
The biggest hurdle I see on this excellent idea is the notification to staff. Being web based, how would staff be notified that a patron is waiting? Seems like each library would have to have some kind of dashboard that could be updated instantly, like many fast food places have. Relying on e-mail would be tricky if someone isn't monitoring the e-mail account.
Some kind of dashboard would be nice though, because I could see this as a way of letting staff know of other holds that are being queued up to be picked off shelves, or of cancelled holds, and so forth.
Equinox proposes to add support for curbside pickup functionality along similar lines to what we wrote for Evergreen.
The specifications we propose to follow can be found at:
The workflow that this feature would support is diagrammed here:
As noted in the specs, we are planning to initially write this as a plugin for the sake of development, but we'll code it in such a way that it could be submitted as a core Koha feature if there turns out to be a long-term need for curbside pickup management.
We are seeking cosponsors to help fund the work; if you might be interested in helping out, please Andrea Neiman at email@example.com.
I've completed the initial development of a curbside plugin based on Galen's specs! Thanks Galen!
I've done what I can to make it possible to convert it into a Koha patch. The OPAC side would need a pretty heavy rewrite. It would make sense to keep the feature as a plugin while we shake it out. I expect we'll find many libraries requesting the same missing features which we haven't thought of yet :)
The only oddity is the need for bug 26163. Part of the patchability was to use Koha objects and DBIC in the code. That bug is needed to load the plugin's schema files whenever plack restarts. I'm open to other possibilities as well!
Galen, I've also got to ask what software you all used to make the interface mockups. I love it!
(In reply to Kyle M Hall from comment #7)
> The only oddity is the need for bug 26163. Part of the patchability was to
> use Koha objects and DBIC in the code. That bug is needed to load the
> plugin's schema files whenever plack restarts. I'm open to other
> possibilities as well!
Kyle, I'll try to look at Bug 26163 tonight. To accelerate things it would be helpful if you QAed Bug 25778.
It would also be great if you included the URL to your plugin here :D.
(In reply to David Cook from comment #9)
> It would also be great if you included the URL to your plugin here :D.
Oops. Looks like you already did.
By the way, if you look at Bug 26163, it looks like the Curbside Pickup plugin may no longer need to depend on a Koha change. Hurray!
Equionx talk about a "Koha Curbside Pickup plugin" here:
As far as I can see they do not mention Bywater. But there is no link to any code either. So I'm confused, do we have one or two "Curbside Pickup" plugins now?
(In reply to Magnus Enger from comment #12)
> Equionx talk about a "Koha Curbside Pickup plugin" here:
> As far as I can see they do not mention Bywater. But there is no link to any
> code either. So I'm confused, do we have one or two "Curbside Pickup"
> plugins now?
I read the article, and I think it is referring to this pull request from Galen:
Again, i have to give props to Galen for it because it's so much better than my solution was, and provides a blueprint for future plugins to implement their own DBIC and objects as well!
Ah cool, that makes sense! Thanks for clarifying!
That Equinox news item was a bit confusing, although it makes more sense when read after the previous news item at https://www.equinoxinitiative.org/fe_highlightitem.php?sid=10155f3ecfef0033d446 which actually references this bug report and how Kyle (of Bywater) started the plugin.
I am also really pumped for Galen's contribution to that plugin. Lack of DBIC integration in plugins has been a pain when I've been writing them, so this offers a nice change. (Although we might want to create some Koha::Plugin::* code to make it easier for any plugin to use the functionality without copying the boiler plate if possible.)
(In reply to David Cook from comment #15)
> That Equinox news item was a bit confusing, although it makes more sense
> when read after the previous news item at
> php?sid=10155f3ecfef0033d446 which actually references this bug report and
> how Kyle (of Bywater) started the plugin.
> I am also really pumped for Galen's contribution to that plugin. Lack of
> DBIC integration in plugins has been a pain when I've been writing them, so
> this offers a nice change. (Although we might want to create some
> Koha::Plugin::* code to make it easier for any plugin to use the
> functionality without copying the boiler plate if possible.)
Agreed. It would certainly be reasonable to have the plugin base to look for a 'lib' directory in the bundle directory, locate all pm files, require the files, and run register_class for all modules starting with Koha::Schema::Result.