Android app for Evergreen

Adding a note here that the current branch appears to be using old jspac calls to place holds and, as a result, completely bypassing the initial hold rules check. Patrons are therefore able to place holds using the app when they otherwise would be unable to place those holds in the catalog.

Many thanks to the folks at ESI for helping us track down this issue.

I'm hoping somebody else here can provide some direction on which calls should be used.

Sorry I don't know anything about JSPAC. The app uses OSRF via the gateway
to place holds using the code below. Hopefully this is enough of a clue.

OSRFObject ahr = new OSRFObject("ahr");

ahr.put("target", recordID);
ahr.put("usr", userID);
ahr.put("requestor", userID);
ahr.put("hold_type", "T");
ahr.put("pickup_lib", pickup_lib);
ahr.put("phone_notify", phone);
ahr.put("email_notify", email_notify);
ahr.put("expire_time", expire_time);
ahr.put("frozen", suspendHold);
ahr.put("thaw_date", thaw_date);

Object response = Utils.doRequest(conn(), *"*open-ils.circ",
"open-ils.circ.holds.create",
authToken, new Object[] { authToken, ahr });

Hi Ken,

I've been doing a bit of digging since I added this comment today. I think what you need to do is replace

open-ils.circ.holds.create

with

open-ils.circ.holds.test_and_create.batch

I see at least one wiki page that still references the older call. I'll update it and see if I can find other references to update.

Thanks Ken!

I have tried a couple things, but no luck yet.

First, the method open-ils.circ.holds.test_and_create.batch takes different parameters than open-ils.circ.holds.create. So far when I call it I get an empty payload. I'm calling it like so:

POST https://catalog.cwmars.org/osrf-gateway-v1?service=open-ils.circ&method=open-ils.circ.holds.test_and_create.batch&param=%22authtoken%22&param=%7B%22pickup_lib%22:69,%22patronid%22:409071%7D&param=[772444]

received:{"payload":[],"status":200}

I tried various forms of the URL above to no avail.

From reading the code in Holds.pm, it appears that calling open-ils.circ.holds.test_and_create.batch is the same as calling open-ils.circ.title_hold.is_possible followed by open-ils.circ.holds.create . In other words, I can call title_hold.is_possible myself before calling holds.create and it will have the same effect. Would that be satisfactory?

On 02/21/2016 07:08 PM, Ken Cox wrote:
> I tried various forms of the URL above to no avail.
>
> >From reading the code in Holds.pm, it appears that calling open-
> ils.circ.holds.test_and_create.batch is the same as calling open-
> ils.circ.title_hold.is_possible followed by open-ils.circ.holds.create .
> In other words, I can call title_hold.is_possible myself before calling
> holds.create and it will have the same effect. Would that be
> satisfactory?

I haven't kept up with the code, but I was looking at this a bit. I
noticed in the source for
core/src/org/evergreen_ils/accountAccess/holds/PlaceHold.java:176

                 // TODO verify hold possible

                 // accountAccess.getHoldPreCreateInfo(record_id, 4);
                 // accountAccess.isHoldPossible(4, record_id);

It looks like someone had started down this path at some point.

One thing missing from your test_and_create_batch trials is the hold_type. Try adding "hold_type":"T" (for a title hold) to the end of your params hash and see if that gets you further.

As for doing the steps separately, those separate API calls are not likely to be supported in future version of Evergreen. It would be a reasonable band aid, though.

As an aside, Evergreen has (for those methods that provide documentation) a web interface for exploring the full API. You can install it on any instance, but for convenience here is a link to some relevant API docs published on Equinox's web client demo server:

https://webby.evergreencatalog.com/opac/extras/docgen.xsl?service=open-ils.circ&param=%22test_and_create%7Ctitle_hold%22&offset=0&limit=25

HTH.

Dan, thanks! hold_type=T was all that was missing.

Mike, thanks! That public link is much easier for me than starting my VM and srfsh.

Kathy, I will package up a release of the CW/MARS app soon and close this bug when I do.

Ken, glad to see you got it sorted out.

You might want to look at bug 1017990 for what Dan Wells refers to in comment #7 about the API calls disappearing in a future release.

Kathy, if you have a beta tester willing to test the CW/MARS app, I have a Beta in the Play Store.

Thanks, Jason, that was exactly the background I was looking for.

Ken

On Tue, Feb 23, 2016 at 9:49 PM, Jason Stephenson <
<email address hidden>> wrote:

> Ken, glad to see you got it sorted out.
>
> You might want to look at bug 1017990 for what Dan Wells refers to in
> comment #7 about the API calls disappearing in a future release.
>
> --
> You received this bug notification because you are a bug assignee.
> https://bugs.launchpad.net/bugs/1506207
>
> Title:
> Android app for Evergreen
>
> Status in Evergreen:
> New
>
> Bug description:
> From the open-ils-general mailing list message at
> http://georgialibraries.markmail.org/thread/sks2fjuqbjwt4ofm , Ken Cox
> has developed an Android app that works with the C/W MARS Evergreen
> System.
>
> The code is based on code previously done by drizea as part of a GSoC
> project.
>
> With Ken's permission, I am posting his working branch here in the
> hopes that more work can be done to make a more generic Evergreen app
> that can be used by other Evergreen sites.
>
> The working branch is available at
>
> http://git.evergreen-
> ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/kenstir
> /android-master
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/evergreen/+bug/1506207/+subscriptions
>

--
-Ken

Released CW/MARS to the play store that uses test_and_create.batch
Version code 27
Version name 2.3.3

I don't see any way to close this bug.

I will set the status of this bug to fix committed.

If we start getting a lot of bug reports for the Android app here, it might be worth while to do two things:

1. Setup a new launchpad for the Android app.

2. Split the android code into its own repo.

#2 might be worth doing if others start contributing to it.

Err, make that fix released...... Esprit de l'apres-clique.....