When attempting to perform batch check-ins in Koha's circulation module, Envisionware's Staff Link software is automatically paused when it detects a change in page title. After submitting a check-in the page title changes to reflect the title of the item you're checking in. For example: Expected window: Check in › Circulation › Koha Actual window: Check in The killer department : › Circulation › Koha If the page title were to stay "Check in > Circulation > Koha" the Staff Link software would successfully check in multiple items (according to Envisionware). We've been able to successfully perform batch check outs because the page title stays static. Possibly related to bug #31512, but that bug didn't mention page titles, so I'm bringing it to the community's attention here.
Hi Eliana, have you checked with your support provider if you maybe can use a wildcard/truncation in the software settings? If you could tell the software to look or a page title of "Check in > Circulation*" that could solve your issue.
I submitted this on behalf of another institution, but I can have them pass that question onto Envisionware! I'm guessing they probably would have suggested that if it was an option, but it doesn't hurt to check. Thank you for the suggestion. (In reply to Katrin Fischer from comment #1) > Hi Eliana, have you checked with your support provider if you maybe can use > a wildcard/truncation in the software settings? If you could tell the > software to look or a page title of "Check in > Circulation*" that could > solve your issue.
Created attachment 164776 [details] [review] Patch that keeps check in page title static
I test checked in a non-checked out item and a checked out item and both times the page's title stayed static. Mission accomplished!
I'm skeptical about sacrificing some human usability to make the page work with automation. I would prefer that some development be done towards making batch check-in a feature on its own.
(In reply to Owen Leonard from comment #5) > I'm skeptical about sacrificing some human usability to make the page work > with automation. I would prefer that some development be done towards making > batch check-in a feature on its own. Hi Owen, If we wait for a batch check-in feature that could take much longer than this patch which only involves editing a single line. I'm not sure enough people rely on the title of the browser tab for the current setup to be that significant to the user experience. The checkout function in Koha actually does not change the browser title and so we're able to perform batch checkouts using RFID without issue. I think increasing Koha's interoperability outweighs preserving something so minor.
Ironically, this patch will break Tech Logic's CircIt integration. CircIt uses regular expressions to match the page title and relies on the title changing.
(In reply to Kyle M Hall from comment #7) > Ironically, this patch will break Tech Logic's CircIt integration. CircIt > uses regular expressions to match the page title and relies on the title > changing. Thx for weighing in, Kyle. I believe this needs a little more thought.
Is it possible to get an alternative to the current inconsistent behavior with regards to check-in and check-out? Does Tech Logic work for check-out? If so, that means their regex must work in that case without the page title changing, so I'm not sure why check-in would be an issue. I'm not sure why either company requires it.
(In reply to Joe Sikowitz from comment #9) > Is it possible to get an alternative to the current inconsistent behavior > with regards to check-in and check-out? Does Tech Logic work for check-out? > If so, that means their regex must work in that case without the page title > changing, so I'm not sure why check-in would be an issue. I'm not sure why > either company requires it. https://github.com/bywatersolutions/koha-plugin-rfid lets CircIt work without the need for reading browser titles. However, the version of CircIt that is compatible with it is so new that it's not widely available yet afaik. Given time this will be a non-issue for users of CircIt
Can that plug-in be modified to work with Envisionware? It sounds like in the long-run we can probably apply this patch, but how will we know when that time comes?
(In reply to Joe Sikowitz from comment #11) > Can that plug-in be modified to work with Envisionware? It sounds like in > the long-run we can probably apply this patch, but how will we know when > that time comes? That is my hope! We would need to get a hold of someone at Envisionware to see if their RFID desktop application exposes a rest api on a local port. That appears to be when all the kids are doing these days.
I can ask MassMaritime to ask Envisionware since they are currently using Koha and Envisionware together. I believe Envisionware exposes an API because other ILSs seem to use it.
Hello, Envisionware exposes their API on port 10081. I've also uploaded their API documentation. Thanks!
Created attachment 170915 [details] Envisionware API Documentation
(In reply to Kyle M Hall from comment #12) > (In reply to Joe Sikowitz from comment #11) > > Can that plug-in be modified to work with Envisionware? It sounds like in > > the long-run we can probably apply this patch, but how will we know when > > that time comes? > > That is my hope! We would need to get a hold of someone at Envisionware to > see if their RFID desktop application exposes a rest api on a local port. > That appears to be when all the kids are doing these days. Hi Kyle, Could we please get some follow-up on this one?