Re: [OPEN-ILS-DEV] How to query coded_value_map via OSRF

[Ken Cox]

Jason and Daniel, that was extremely helpful.  I feel like I learned how to
fish in the permacrud today.  Thank you very much!

I don't feel like I described well enough why I was interested, so here
goes:
* when you search in the app, you can choose a search format, e.g. "All
Books".  This is coded as "book" in the search
(open-ils.search.biblio.multiclass.query).  So I need a mapping from search
display labels to search formats.
* when you look up a record returned from a search, the app needs to
display a label for the format of the specific record, e.g. "E-book" or
"Downloadable ebooks".  So I need a mapping from item formats to item
display labels.
* these mappings are different for different installations, e.g. "E-book"
vs. "Downloadable ebooks"

Thanks again,
Ken

On Thu, Jul 11, 2019 at 4:45 AM Jason Stephenson  wrote:

> I want to follow up on something specific that Ken said, and that I
> forgot to mention.  Dan Wells didn't address this either.
>
> On 7/10/19 10:26 PM, Ken Cox wrote:
> > Jason,
> >
> > Thank you, that is a great hint, but I'm not close enough to get it
> > yet. In the past I've looked at OSRF methods registered in perl
> > modules, and they were wrapped with some decorations that told me how
> > they were supposed to be called (__PACKAGE__->register_method and look
> > at the params array).  In this case (sub init_ro_object_cache) I don't
> > recognize any methods being registered at all.  I tried to
>
> The cstore and pcrud methods are all generated from the IDL at service
> startup.  If you know how cstore works, then you pretty much know how
> pcrud works.  You create, retrieve, update, and delete things in pretty
> much the same way.  The main differences being in the method names
> (pcurd uses the IDL class id, and cstore uses the Fieldmapper class id
> with :: turned into _) and in pcrud pretty much always requiring
> permissions, so therefore an authtoken.  Also, cstore should *never* be
> exposed through the gateway.
>
> The method names are totally predictable when you understand how they
> are generated. For ccvm, we get:
>
> open-ils.pcrud.ccvm.create
> open-ils.pcrud.ccvm.retrieve
> open-ils.pcrud.ccvm.update
> open-ils.pcrud.ccvm.delete
> open-ils.pcrud.ccvm.search
> open-ils.pcrud.ccvm.id_list
>
> create takes a newly made Fieldmapper object
> retrieve takes an integer of the database id
> update takes an existing Fieldmapper object
> delete takes an existing Fieldmapper object
> search takes a JSON object of search parameters
> id_list takes a JSON object of search parameters
>
> The arguments all come after the authtoken.
>
> Create, update, and delete, all have to happen within a pcrud
> transaction or you will get an error message.
>
> If you know C, you can find how this is done, along with a somewhat
> helpful comment beginning around line 51 in
> Evergreen/Open-ILS/src/c-apps/oils_pcrud.c.
>
> >
> > srfsh# introspect open-ils.pcrud "open-ils.pcrud.search.ccvm"
> >
> > but it didn't provide any help.  I tried calling it in a lot of
> > different ways but all I get is
> >
> >
> https://gapines.org/osrf-gateway-v1?service=open-ils.pcrud=open-ils.pcrud.search.ccvm=%22ANONYMOUS%22=*
> > {"payload":[],"debug": "osrfMethodException : Severe query error --
> > see error log for more details","status":500}
> >
> > One more clue please?
> >
> > Thanks,
> > Ken
>


-- 
-Ken

Re: [OPEN-ILS-DEV] How to query coded_value_map via OSRF

[Ken Cox]

Jason,

Thank you, that is a great hint, but I'm not close enough to get it
yet. In the past I've looked at OSRF methods registered in perl
modules, and they were wrapped with some decorations that told me how
they were supposed to be called (__PACKAGE__->register_method and look
at the params array).  In this case (sub init_ro_object_cache) I don't
recognize any methods being registered at all.  I tried to

srfsh# introspect open-ils.pcrud "open-ils.pcrud.search.ccvm"

but it didn't provide any help.  I tried calling it in a lot of
different ways but all I get is

https://gapines.org/osrf-gateway-v1?service=open-ils.pcrud=open-ils.pcrud.search.ccvm=%22ANONYMOUS%22=*
{"payload":[],"debug": "osrfMethodException : Severe query error --
see error log for more details","status":500}

One more clue please?

Thanks,
Ken


On Wed, Jul 10, 2019 at 6:52 AM Jason Stephenson  wrote:
>
> On 7/9/19 8:34 PM, Ken Cox wrote:
> > Is there a way to query the coded_value_map via OSRF?  I want to list
> > the search_format and icon_format values for use in the mobile app.  I
> > see a call to ctx.search_ccvm in coded_value_selector.tt2, but I can't
> > find that code anywhere.  I am swinging wildly using pcrud but haven't
> > hit anything yet, and could use a clue.
>
> ctx.search_ccvm is added, along with a bunch of methods, in a loop
> beginning at line 77 of
> Open-ILS/src/perlmods/lib/OpenILS/WWW/EGcatLoader/Util.pm.  It's doing a
> CStoreEditor search.
>
> Since ccvm has a pcrud controller, you should be able to achieve a
> similar search with open-ils.pcrud.search.ccvm.
>
> HtH,
> Jason
>
> >
> > Thanks,
> > Ken
> >



-- 
-Ken

[OPEN-ILS-DEV] How to query coded_value_map via OSRF

[Ken Cox]

Is there a way to query the coded_value_map via OSRF?  I want to list the
search_format and icon_format values for use in the mobile app.  I see a
call to ctx.search_ccvm in coded_value_selector.tt2, but I can't find that
code anywhere.  I am swinging wildly using pcrud but haven't hit anything
yet, and could use a clue.

Thanks,
Ken

[OPEN-ILS-DEV] Evergreen 3.2.2 OSRF search returns way more data than I need

[Ken Cox]

The 3.2.2 server returns a lot of additional data in the search response,
like "highlight_map".  The mobile apps don't need this data, and it bloats
the response substantially.  Is there a customer for this additional data,
or should I file a ticket to squelch it?  Can I avoid receiving it?

Sample query against 3.0.2, response body is 2470 bytes:

https://bark.cwmars.org/osrf-gateway-v1?service=open-ils.search=open-ils.search.biblio.multiclass.query=%7B%22offset%22:0,%22limit%22:200%7D=%22title:the%20war%20on%20normal%20search_format(book)%22=1


Sample query against 3.2.2, response body is 5714 bytes (+131%):

https://gapines.org/osrf-gateway-v1?service=open-ils.search=open-ils.search.biblio.multiclass.query=%7B%22offset%22:0,%22limit%22:200%7D=%22title:the%20war%20on%20normal%20search_format(book)%22=1


The only thing I really need from the response is the list of ids, the
visible count, and the status; about 100 bytes.

Thanks,
Ken

Re: [OPEN-ILS-DEV] Looking for a way to upgrade my EG 3.0 installation in less than 8 hours

[Ken Cox]

Bill and Jason,

Your advice was extremely helpful and very much appreciated.  It makes
perfect sense now for the ansible scripts to create installs from
scratch, since you might do that every week.  When I slowed down and
paid careful attention to the upgrade SQL, it made more sense and I
was able to take my DB at version 1087 and upgrade it confidently to
3.2.2.

Thank you!

Ken

On Mon, Feb 25, 2019 at 11:40 AM Jason Stephenson  wrote:
>
> Ken, et al.
>
> I think I should add something else to the previous email.
>
> We also upgrade our training server about 6 months prior to when we plan
> to upgrade.  This keeps us about 1 release behind.  Staff get to test
> the upcoming release on the training server with close to recent/real
> data.  I also keep training up to date with recent point releases, so
> that means I'll do a mini-update from 3.2.3 to 3.2.4 later this week.
>
> We used to upgrade twice per year, but I think we're moving to just 1
> per year, which also means skipping releases.  For instance, we're going
> from 3.0.13 to 3.2.[45] at our next upgrade.
>
> And, when I talk about testing, I mean it.  It is imperative that you
> test the database upgrade script with a recent copy of your actual,
> production data.
>
> Upgrades of Evergreen are not something that you just do, they require
> planning and preparation, otherwise you could be facing days of down
> time and unhappy users.
>
> HtH,
> Jason
>
>


-- 
-Ken

[OPEN-ILS-DEV] Looking for a way to upgrade my EG 3.0 installation in less than 8 hours

[Ken Cox]

Perhaps I am exaggerating, but maybe just barely.

I have EG 3.0-ish installed with evergreen-ansible-installer on
ubuntu-16.04.  I want to upgrade it to 3.1 and then to 3.2 so that I
can test the fixes for the iOS app crashes (due to IDL changes, see
other thread).  After many hours of trying, I still don't have a
working server.

I have tried various approaches to upgrading this installation, with
very limited success.  Things I tried:

1. Rerunning evergreen-ansible-installer.  This seemed to break
several things, including my existing user accounts, my certificates,
and the websockets configuration.

2. Running a subset of the evergreen-ansible-installer modeled on the
instructions in
http://docs.evergreen-ils.org/3.1/_upgrading_the_evergreen_server.html.
Things here seemed to work fine, I was able to upgrade to 3.1.9.  Then
I ran the upgrade SQL scripts per
http://docs.evergreen-ils.org/3.1/_upgrade_the_evergreen_database_schema.html.

3. When I tried to upgrade from 3.1.9 to 3.2.3, things went south.
Compiling from source went OK and eg_db_config worked, but then I
couldn't login as my existing user and admin accounts.  I figured I
need to run the upgrade SQL scripts, but here things went poorly.
This part of the upgrade process is confusing because of the fuzziness
in the upgrade documentation: "Only upgrade as far as necessary to
reach the major version upgrade script".   But there is no
3.1.9-to-3.2.0 script, so I tried the 3.1.5-3.2.0-upgrade-db.sql and
every successive one.  Many failed immediately with something like

psql:version-upgrade/3.2.1-3.2.2-upgrade-db.sql:6: ERROR:
duplicate key value violates unique constraint "upgrade_log_pkey"
DETAIL:  Key (version)=(1134) already exists.

So it would seem the patch was already applied.  But later updates
failed due to missing tables, e.g.

psql:version-upgrade/3.2.2-3.2.3-upgrade-db.sql:10: ERROR:
relation "vandelay.session_tracker" does not exist

How do you manage upgrading?  Any help appreciated.

-- 
-Ken

Re: [OPEN-ILS-DEV] IDL is not backward compatible?

[Ken Cox]

Dan Wells: Good suggestion re: opensrf.open-ils.system.ils_version.  I
will think more about it.  For now, disabling caching for the
fm_IDL.xml request will have the same effect as querying the version
on every login. It would help if auth tokens got invalidated during
server upgrades; does anyone know whether that's true?

Dan Scott: Good point about cache-busting params; now that I know to
do it I can avoid caching and save 72KB in the cache for something
useful.  I didn't know about /IDL2js, thanks.  The URL I use is:

http://bark.cwmars.org/reports/fm_IDL.xml?class=ac=acn=acp=ahr=ahtc=aou=aout=au=aua=auact=aum=aus=bmp=cbreb=cbrebi=cbrebin=cbrebn=ccs=circ=csc=cuat=ex=mbt=mbts=mous=mra=mraf=mus=mvr=perm_ex

I'm not sure whose idea adding all the 'class' params was (probably
Dan Wells) but that response is 72KB whereas the full IDL is 820KB,
and since I don't need the reset, it saves a lot of time parsing.

Regards,
Ken

On Mon, Feb 18, 2019 at 10:14 PM Dan Scott  wrote:
>
> Hi Ken:
>
> In addition to the headers you're getting back, it might be helpful to 
> include the exact GET request you're making. If you're referring to /IDL2js, 
> then that's ~400kb of data that's being shipped--a not inconsiderable amount 
> to send over the wire.
>
> Back in 2017, Evergreen's web environment adopted the generally accepted 
> performance approach of setting the cache time as long as possible and 
> relying on cache-busting GET params to only cause browsers to request new 
> versions of files when things actually change. When things change (for 
> example, when a server is upgraded and autogen.sh is run), the GET param 
> changes from ?abc123 to ?def456 (or some other such hash), breaking the cache 
> and forcing a fresh retrieval of the file in question.
>
> Prior to commit 1cb0d8c63c44, the default caching time was 18 hours. So 
> crashes due to IDL mismatches could still occur if the cache-busting GET 
> param wasn't updated; the window was just shorter.
>
> It sounds like in the the iOS app, if you want to force a refetch of the 
> cached file, perhaps you could generate a similar cache-busting token and 
> just append it to your GET URL?
>
> Best,
> Dan
>
> Best,
> Dan
>
> Dan
>
> On Mon, Feb 18, 2019 at 6:12 PM Ken Cox  wrote:
>>
>> I think I know what is going on, but I would like somebody to confirm
>> my understanding.
>>
>> After a server upgrade from 3.0.1 to 3.2.2, I saw a significant spike
>> the iOS app crashes.  It looks like a cached IDL specifies fewer
>> fields than is returned by the /osrf-gateway-v1 endpoint.
>>
>> I fixed the app so that does not cause a crash, reasoning that since
>> the IDL fields must be newly added fields, and because the app didn't
>> require them, I could safely ignore them.  On deeper inspection, it
>> looks as though new fields have been added to the middle of IDL
>> classes.  For instance, the class 'au' had the following new fields
>> added, all in the middle:
>> * Privacy Waiver Entries
>> * Preferred Prefix
>> * Preferred First Name
>> ...
>>
>> Short term, I think a partial fix is to disable caching of the IDL,
>> even though the server indicates it can be cached:
>>
>> HTTP/1.1 200 OK
>> Date: Mon, 18 Feb 2019 09:27:03 GMT
>> Cache-Control: max-age=31536000
>> Expires: Tue, 18 Feb 2020 09:27:03 GMT
>>
>> Long term, I think a better approach would be to add new fields only
>> at the end.  This is a common technique for maintaining binary
>> compatibility in compiled code.  If the app is suspended during a
>> server upgrade, and if fields are added in the middle, then the IDL is
>> out of sync, right?  Or maybe, all sessions are lost during the down
>> time and the next request with an auth token will fail, and the IDL
>> should be loaded on every login?  (Sorry I have been trying to test
>> this hypothesis but I am having trouble upgrading my own EG server).
>>
>> Thanks,
>> Ken



-- 
-Ken

[OPEN-ILS-DEV] IDL is not backward compatible?

[Ken Cox]

I think I know what is going on, but I would like somebody to confirm
my understanding.

After a server upgrade from 3.0.1 to 3.2.2, I saw a significant spike
the iOS app crashes.  It looks like a cached IDL specifies fewer
fields than is returned by the /osrf-gateway-v1 endpoint.

I fixed the app so that does not cause a crash, reasoning that since
the IDL fields must be newly added fields, and because the app didn't
require them, I could safely ignore them.  On deeper inspection, it
looks as though new fields have been added to the middle of IDL
classes.  For instance, the class 'au' had the following new fields
added, all in the middle:
* Privacy Waiver Entries
* Preferred Prefix
* Preferred First Name
...

Short term, I think a partial fix is to disable caching of the IDL,
even though the server indicates it can be cached:

HTTP/1.1 200 OK
Date: Mon, 18 Feb 2019 09:27:03 GMT
Cache-Control: max-age=31536000
Expires: Tue, 18 Feb 2020 09:27:03 GMT

Long term, I think a better approach would be to add new fields only
at the end.  This is a common technique for maintaining binary
compatibility in compiled code.  If the app is suspended during a
server upgrade, and if fields are added in the middle, then the IDL is
out of sync, right?  Or maybe, all sessions are lost during the down
time and the next request with an auth token will fail, and the IDL
should be loaded on every login?  (Sorry I have been trying to test
this hypothesis but I am having trouble upgrading my own EG server).

Thanks,
Ken

Re: [OPEN-ILS-DEV] Removal of OpenSRF and Evergreen Java Libraries

[Ken Cox]

Bill, thanks for mentioning that.  I don't know anything about bundling or
chunking so I am quite certain my fork doesn't have them.  Are these
features required when called via osrf-gateway-v1, and where are they
described?

Ken

On Mon, Feb 11, 2019 at 12:22 PM Bill Erickson  wrote:

> Thanks, Jason.
>
> It's also worth mentioning the Java OpenSRF libs are missing some
> new features (bundling/chunking/etc.), so in addition to updating the
> dependencies, any prospective maintainer would need to port these features
> over to make the Java OpenSRF libs compatible with modern OpenSRF.
>
> -b
>
> On Sat, Feb 9, 2019 at 10:17 AM Ken Cox  wrote:
>
>> Hey Jason and Blake,
>>
>> Hemlock Android uses a fork of the java libraries inside its own repo.
>> Hemlock iOS uses a brand new API implemented in Swift.  As long as the
>> '/osrf-gateway-v1' endpoint doesn't change, I'm all set.
>>
>> Thanks for reaching out,
>> Ken
>>
>> On Sat, Feb 9, 2019 at 12:03 PM Jason Stephenson  wrote:
>> >
>> > Blake,
>> >
>> > I believe that Hemlock has its own implementation.  Some of the files
>> > may have been copied from the OpenSRF code at some point, but the files
>> > in the OpenSRF code are not used to build Hemlock.  I could be mistaken,
>> > but I'm pretty sure that Hemlock does not rely on the actual Java code
>> > from OpenSRF or Evergreen.
>> >
>> > As you said, Ken knows best, so hopefully, he will answer.
>> >
>> > Jason
>>
>>
>>
>> --
>> -Ken
>>
>

-- 
-Ken

Re: [OPEN-ILS-DEV] Removal of OpenSRF and Evergreen Java Libraries

[Ken Cox]

Hey Jason and Blake,

Hemlock Android uses a fork of the java libraries inside its own repo.
Hemlock iOS uses a brand new API implemented in Swift.  As long as the
'/osrf-gateway-v1' endpoint doesn't change, I'm all set.

Thanks for reaching out,
Ken

On Sat, Feb 9, 2019 at 12:03 PM Jason Stephenson  wrote:
>
> Blake,
>
> I believe that Hemlock has its own implementation.  Some of the files
> may have been copied from the OpenSRF code at some point, but the files
> in the OpenSRF code are not used to build Hemlock.  I could be mistaken,
> but I'm pretty sure that Hemlock does not rely on the actual Java code
> from OpenSRF or Evergreen.
>
> As you said, Ken knows best, so hopefully, he will answer.
>
> Jason



-- 
-Ken

Re: [OPEN-ILS-DEV] Hack-A-Way Online

[Ken Cox]

Nevermind, I found the link in the other email you sent:) Cheers,
Ken

On Tue, Oct 30, 2018, 4:24 PM Ken Cox  wrote:

> Hey Rogan,
>
> I'm interested in the YouTube live stream, but I couldn't find it by
> searching.  Can you send me the link?
>
> Thanks, and I appreciate the work you're doing supporting the
> hack-a-way.  If you feel like hacking on the Evergreen iOS app let me
> know!
>
> Cheers,
> Ken
> On Tue, Oct 30, 2018 at 9:51 AM Rogan Hamby
>  wrote:
> >
> > For those who want to chime into the discussions at the Hack-A-Way
> during the group discussions we will be using Youtube Live on the community
> Evergreen channel for those events but we are not planning on broadcasting
> during non group discussion times.  At this time we don't have a schedule
> for when the discussions will happen but once we do (likely not until
> Monday morning) we will publish it on the WIKI and schedule it on Youtube
> for those subscribed to the channel.
> >
> >
> > Rogan Hamby, MLIS
> >
> > Data and Project Analyst
> >
> > Equinox Open Library Initiative
> >
> > phone:  1-877-OPEN-ILS (673-6457)
> >
> > email:  ro...@equinoxinitiative.org
> >
> > web:  http://EquinoxInitiative.org
>
>
>
> --
> -Ken
>

Re: [OPEN-ILS-DEV] Hack-A-Way Online

[Ken Cox]

Hey Rogan,

I'm interested in the YouTube live stream, but I couldn't find it by
searching.  Can you send me the link?

Thanks, and I appreciate the work you're doing supporting the
hack-a-way.  If you feel like hacking on the Evergreen iOS app let me
know!

Cheers,
Ken
On Tue, Oct 30, 2018 at 9:51 AM Rogan Hamby
 wrote:
>
> For those who want to chime into the discussions at the Hack-A-Way during the 
> group discussions we will be using Youtube Live on the community Evergreen 
> channel for those events but we are not planning on broadcasting during non 
> group discussion times.  At this time we don't have a schedule for when the 
> discussions will happen but once we do (likely not until Monday morning) we 
> will publish it on the WIKI and schedule it on Youtube for those subscribed 
> to the channel.
>
>
> Rogan Hamby, MLIS
>
> Data and Project Analyst
>
> Equinox Open Library Initiative
>
> phone:  1-877-OPEN-ILS (673-6457)
>
> email:  ro...@equinoxinitiative.org
>
> web:  http://EquinoxInitiative.org



-- 
-Ken

Re: [OPEN-ILS-DEV] After upgrade to 3.0.2, OSRF query fails to limit items by org_unit

[Ken Cox]

After a lot of debugging, I figured out how to get search working
again in the Android app.

This query works in 2.12 but not in 3.0.2:

method = open-ils.search.biblio.multiclass.query
param = {org_unit=7, default_class=title, offset=0, limit=200, depth=2}
param = "harry Potter chamber of secrets"
param = 1

This query works in both:

method = open-ils.search.biblio.multiclass.query
param = {offset=0, limit=200}
param = "title:harry Potter chamber of secrets site(ARL-ATH)"
param = 1

I got a clue after seeing this comment in Biblio.pm:

> sub multiclass_query {
># arghash only really supports limit/offset anymore
>my($self, $conn, $arghash, $query, $docache) = @_;

The funny thing is, that comment existed in 2.12 as well, and the
query worked there.

I kind of used 
https://wiki.evergreen-ils.org/doku.php?id=documentation:technical:search_grammar
as a guide though it's clearly not authoritative.  For instance,
site(7) should work according to the wiki but it doesn't, and
site(ARL-ATH) does.

Ken

[OPEN-ILS-DEV] After upgrade to 3.0.2, OSRF query fails to limit items by org_unit

[Ken Cox]

After a recent upgrade to 3.0.2, the behavior of the query method
open-ils.search.biblio.multiclass.query made by the Android app
changed.  It used to limit results to those matching the org_unit
specified in the query; now it seems to return all copies.  Running
the same query against an older Evergreen 2.12.8 works as expected,
returning only the ids of copies owned by the specified org_unit.

Does the query need to change for newer Evergreen installs, or is this
a server bug?

Thanks in advance for any pointers.

Sample OSRF call
-
method = open-ils.search.biblio.multiclass.query
param = {org_unit=7, default_class=title, offset=0, limit=200, depth=2}
param = "harry Potter chamber of secrets"
param = 1

Full URL: 
https://gapines.org/osrf-gateway-v1?service=open-ils.search=open-ils.search.biblio.multiclass.query=%7B%22org_unit%22:7,%22default_class%22:%22title%22,%22offset%22:0,%22limit%22:200,%22depth%22:2%7D=%22harry%20Potter%20chamber%20of%20secrets%22=1

Results: 96 items

Expected results: 6 items


-- 
-Ken

Re: [OPEN-ILS-DEV] Everyone should have an Evergreen server and you can too!

[Ken Cox]

Wow, that sounds like quite a useful contribution indeed!  On many
occasions I wished I could easily stand up a test server and this seems to
fit the bill.  I could run this on my NAS.

++blake
++ansible


On Mon, Apr 10, 2017 at 5:20 PM, Blake Henderson  wrote:

> All,
>
> After this conference, it dawned on me that I could easily convert some of
> the docker work into a helpful community asset. I have committed a docker
> image to the public docker repository that will launch an Evergreen server
> on your computer with just a couple of commands!
>
> It's probably worth sharing with the general list, but I thought I would
> share it on the dev list first for some feedback.
>
> After you have installed the docker engine for your linux distribution,
> you can get an Evergreen server running with a single command:
> docker run -it -p 80:80 -p 210:210 -p 443:443 -p 32:22 -p 7680:7680 -p
> 7682:7682 -p 6001:6001 mobiusoffice/evergreen-ils:2.12.0
>
> If it doesn't automatically download the docker image, you might have to
> manually download it with:
> docker pull mobiusoffice/evergreen-ils:2.12.0
>
>
>
> Once you see that, the server is setup and ready for connections. Keep in
> mind if you press CTRL+C - the server will die. Please use CTRL+pq instead
> to leave it running.
>
> Once you see this screen above, the container has finished booting, and
> the OPAC should be available from your machine's IP address:
> http://127.0.0.1
> http://localhost
>
> XUL staff client is precompiled and included:
> http://localhost/updates/manualupdate.html
>
> The SSL certificates are self signed, therefore you will need to add an
> exception
>
> The global admin account is:
> admin / demo123
>
> The postgres database contains the concerto set (--load-all-sample).
>
> You can SSH into the container if you map the ssh port. The shell login
> creds:
> user/password
>
>
>
> I posted the code that creates this image to github:
> https://github.com/mcoia/eg-docker/tree/master/docker_
> builds/generic-dockerhub
>
>
> Any feedback would be much appreciated!
>
> --
> -Blake-
> Conducting Magic
> MOBIUS573-234-4513 <(573)%20234-4513>877-312-3517 <(877)%20312-3517>
>
>


-- 
-Ken

Re: [OPEN-ILS-DEV] Android: how to determine (quickly) which libraries are hold pickup locations

[Ken Cox]

Josh, Bill -- good news, thanks!  I'm optimistic for the future.  In
the meanwhile, I found that calling
open-ils.actor.ou_setting.ancestor_default.batch with just the setting
I want is significantly less expensive.  I can make 339 calls in
~5600ms cold, and 750-850ms cached.  This is probably workable.

Ken

On Tue, Feb 14, 2017 at 4:14 PM, Bill Erickson <beric...@gmail.com> wrote:
> Thanks for mentioning that, Josh.  The code I added would make the multi-org
> setting look-ups a lot faster.  It would need a couple of Perl layers (one
> for view_perm checks, plus a public API access point) before it could be
> used by a remote client.  I'd say it's more than halfway there, though.
>
> -b
>
> On Tue, Feb 14, 2017 at 11:59 AM, Josh Stompro <stomp...@exchange.larl.org>
> wrote:
>>
>> Ken, I don't know if this is completely applicable, but as part of the new
>> holds targeter, Bill created a way to pull org unit settings in batch for
>> multiple orgs at once.
>>
>> https://bugs.launchpad.net/evergreen/+bug/1596595/comments/20
>>
>> That might help in the future.
>>
>> Josh Stompro - LARL IT Director
>>
>>
>> -Original Message-
>> From: Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org]
>> On Behalf Of Ken Cox
>> Sent: Tuesday, February 14, 2017 7:39 AM
>> To: Evergreen Development Discussion List
>> Subject: [OPEN-ILS-DEV] Android: how to determine (quickly) which
>> libraries are hold pickup locations
>>
>> I want to determine via OSRF which organizations cannot be hold pickup
>> locations, and prevent the user from selecting those locations when placing
>> a hold.  The only reliable way I have found is to call
>> open-ils.actor.org_unit_setting.values.ranged.retrieve and look for
>> "opac.holds.org_unit_not_pickup_lib":true.  Calling that 339 times takes 54
>> seconds, even in release mode with a pool of 4 threads.
>>
>> Can you help me find a better way?
>>
>> Many thanks,
>> Ken
>
>



-- 
-Ken

[OPEN-ILS-DEV] Android: how to determine (quickly) which libraries are hold pickup locations

[Ken Cox]

I want to determine via OSRF which organizations cannot be hold pickup
locations, and prevent the user from selecting those locations when
placing a hold.  The only reliable way I have found is to call
open-ils.actor.org_unit_setting.values.ranged.retrieve and look for
"opac.holds.org_unit_not_pickup_lib":true.  Calling that 339 times
takes 54 seconds, even in release mode with a pool of 4 threads.

Can you help me find a better way?

Many thanks,
Ken

Re: [OPEN-ILS-DEV] Different OSRF response format from different servers?

[Ken Cox]

Mike: +1 very helpful, thanks.  I will try it.

Jason: I prefer "artisinal code".  I started with an old OSRF Java library
made it work in the Android runtime.  If you want to dig deeper shoot on
over to
https://github.com/kenstir/hemlock/tree/master/opensrf/src/org/opensrf

On Thu, Jan 26, 2017 at 9:58 AM, Mike Rylander <mrylan...@gmail.com> wrote:

> Ken,
>
> The open-ils.pcrud service is written in C. The attrs column on the
> view behind that is an hstore, which is a key-value data type
> available in Postgres.  What you're getting there is what is actually
> in the database.  You might want to use mraf
> (metabib.record_attr_flat) instead.
>
> HTH,
>
> --
> Mike Rylander
>  | President
>  | Equinox Software, Inc. / Open Your Library
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  mi...@esilibrary.com
>  | web:  http://www.esilibrary.com
>
>
> On Thu, Jan 26, 2017 at 8:00 AM, Ken Cox <kens...@gmail.com> wrote:
> > Thank you, that helps.  I implemented a generic string-or-int-to-integer
> > method, and will be on the lookout for other places where it might be
> > needed.  I guess it goes without saying that it feels a bit awkward to be
> > dealing with Perl vagaries when consuming the API from a different
> language.
> > (I'm looking at you, open-ils.pcrud.retrieve.mra, and your devilish
> > perlishness)
> >
> > Ken
> >
> > On Wed, Jan 25, 2017 at 12:21 PM, Mike Rylander <mrylan...@gmail.com>
> wrote:
> >>
> >> Ken,
> >>
> >> Any time a variable is used as a string (or a number), perl starts
> >> treating it that way for stringification purposes.  As the code
> >> changes version to version, and even as different code paths are taken
> >> within one version depending on settings, perl may change the variable
> >> type.  Like Bill says, if you expect a number it's best to just use,
> >> say, parseInt() from JS or it's equiv.
> >>
> >> HTH,
> >>
> >> --
> >> Mike Rylander
> >>  | President
> >>  | Equinox Software, Inc. / Open Your Library
> >>  | phone:  1-877-OPEN-ILS (673-6457)
> >>  | email:  mi...@esilibrary.com
> >>  | web:  http://www.esilibrary.com
> >>
> >>
> >> On Wed, Jan 25, 2017 at 10:38 AM, Bill Erickson <beric...@gmail.com>
> >> wrote:
> >> > Hi Ken,
> >> >
> >> > I can't say why they vary in this specific case, but it's not uncommon
> >> > for
> >> > numbers to be packaged as JSON strings throughout Evergreen / OpenSRF.
> >> > Generally, Perl and JavaScript don't care and the OpenSRF JSON C
> library
> >> > is
> >> > well-equipped to handle it.  It's probably best to assume that any
> >> > number
> >> > might be delivered as a JSON number or a JSON string.
> >> >
> >> > -b
> >> >
> >> >
> >> >
> >> >
> >> > On Tue, Jan 24, 2017 at 5:03 PM, Ken Cox <kens...@gmail.com> wrote:
> >> >>
> >> >> I have a bug report that searching the Missouri Evergreen catalog
> >> >> crashes
> >> >> the Android Hemlock App.  I tracked it down to different results from
> >> >> the
> >> >> open-ils.search.biblio.multiclass.query .  The server at
> >> >> issourievergreen.org returns an "ids" list containing integers, and
> the
> >> >> other servers I tried return an "ids" list containing strings.
> >> >>
> >> >> Is this expected?  Handling this one mismatch is straightforward, but
> >> >> I'm
> >> >> wondering how many similar issues lurk behind this one.
> >> >>
> >> >> Sample search queries and excerpted results for "pride and
> prejudice":
> >> >>
> >> >> missourievergreen, version 2-11-0
> >> >>
> >> >>
> >> >>
> >> >> https://missourievergreen.org/osrf-gateway-v1?service=open-
> ils.search=open-ils.search.biblio.multiclass.
> query=%7B%22org_unit%22:1,%22default_class%22:%
> 22keyword%22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D&
> param=%22pride%20and%20prejudice%22=1
> >> >> ...
> >> >> "ids":[[32673,null,"0.0"],[886843,null,"0.0"]]
> >> >>
> >> >> gapines, version 2-11-1
> >> >>
> >> >>
> >> >>
> >> >> https://gapines.org/osrf-gateway-v1?service=open-ils.
> search=open-ils.search.biblio.multiclass.query=
> %7B%22org_unit%22:1,%22default_class%22:%22keyword%
> 22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%
> 22pride%20and%20prejudice%22=1
> >> >> ...
> >> >> "ids":[["503610",null,"0.0"],["502717",null,"0.0"]]
> >> >>
> >> >> cwmars, version 2-10-7
> >> >>
> >> >>
> >> >>
> >> >> http://bark.cwmars.org/osrf-gateway-v1?service=open-ils.
> search=open-ils.search.biblio.multiclass.query=
> %7B%22org_unit%22:1,%22default_class%22:%22keyword%
> 22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%
> 22pride%20and%20prejudice%22=1
> >> >> ...
> >> >> "ids":[["1805532"],["2385399"]]
> >> >>
> >> >>
> >> >>
> >> >> --
> >> >> -Ken
> >> >
> >> >
> >
> >
> >
> >
> > --
> > -Ken
>



-- 
-Ken

Re: [OPEN-ILS-DEV] Different OSRF response format from different servers?

[Ken Cox]

Thank you, that helps.  I implemented a generic string-or-int-to-integer
method, and will be on the lookout for other places where it might be
needed.  I guess it goes without saying that it feels a bit awkward to be
dealing with Perl vagaries when consuming the API from a different
language.  (I'm looking at you, open-ils.pcrud.retrieve.mra, and your
devilish perlishness)

Ken

On Wed, Jan 25, 2017 at 12:21 PM, Mike Rylander <mrylan...@gmail.com> wrote:

> Ken,
>
> Any time a variable is used as a string (or a number), perl starts
> treating it that way for stringification purposes.  As the code
> changes version to version, and even as different code paths are taken
> within one version depending on settings, perl may change the variable
> type.  Like Bill says, if you expect a number it's best to just use,
> say, parseInt() from JS or it's equiv.
>
> HTH,
>
> --
> Mike Rylander
>  | President
>  | Equinox Software, Inc. / Open Your Library
>  | phone:  1-877-OPEN-ILS (673-6457)
>  | email:  mi...@esilibrary.com
>  | web:  http://www.esilibrary.com
>
>
> On Wed, Jan 25, 2017 at 10:38 AM, Bill Erickson <beric...@gmail.com>
> wrote:
> > Hi Ken,
> >
> > I can't say why they vary in this specific case, but it's not uncommon
> for
> > numbers to be packaged as JSON strings throughout Evergreen / OpenSRF.
> > Generally, Perl and JavaScript don't care and the OpenSRF JSON C library
> is
> > well-equipped to handle it.  It's probably best to assume that any number
> > might be delivered as a JSON number or a JSON string.
> >
> > -b
> >
> >
> >
> >
> > On Tue, Jan 24, 2017 at 5:03 PM, Ken Cox <kens...@gmail.com> wrote:
> >>
> >> I have a bug report that searching the Missouri Evergreen catalog
> crashes
> >> the Android Hemlock App.  I tracked it down to different results from
> the
> >> open-ils.search.biblio.multiclass.query .  The server at
> >> issourievergreen.org returns an "ids" list containing integers, and the
> >> other servers I tried return an "ids" list containing strings.
> >>
> >> Is this expected?  Handling this one mismatch is straightforward, but
> I'm
> >> wondering how many similar issues lurk behind this one.
> >>
> >> Sample search queries and excerpted results for "pride and prejudice":
> >>
> >> missourievergreen, version 2-11-0
> >>
> >>
> >> https://missourievergreen.org/osrf-gateway-v1?service=open-
> ils.search=open-ils.search.biblio.multiclass.
> query=%7B%22org_unit%22:1,%22default_class%22:%
> 22keyword%22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D&
> param=%22pride%20and%20prejudice%22=1
> >> ...
> >> "ids":[[32673,null,"0.0"],[886843,null,"0.0"]]
> >>
> >> gapines, version 2-11-1
> >>
> >>
> >> https://gapines.org/osrf-gateway-v1?service=open-ils.
> search=open-ils.search.biblio.multiclass.query=
> %7B%22org_unit%22:1,%22default_class%22:%22keyword%
> 22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%
> 22pride%20and%20prejudice%22=1
> >> ...
> >> "ids":[["503610",null,"0.0"],["502717",null,"0.0"]]
> >>
> >> cwmars, version 2-10-7
> >>
> >>
> >> http://bark.cwmars.org/osrf-gateway-v1?service=open-ils.
> search=open-ils.search.biblio.multiclass.query=
> %7B%22org_unit%22:1,%22default_class%22:%22keyword%
> 22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%
> 22pride%20and%20prejudice%22=1
> >> ...
> >> "ids":[["1805532"],["2385399"]]
> >>
> >>
> >>
> >> --
> >> -Ken
> >
> >
>



-- 
-Ken

[OPEN-ILS-DEV] Different OSRF response format from different servers?

[Ken Cox]

I have a bug report that searching the Missouri Evergreen catalog crashes
the Android Hemlock App
.
I tracked it down to different results from the open-ils.search.biblio.
multiclass.query .  The server at issourievergreen.org returns an "ids"
list containing integers, and the other servers I tried return an "ids"
list containing strings.

Is this expected?  Handling this one mismatch is straightforward, but I'm
wondering how many similar issues lurk behind this one.

Sample search queries and excerpted results for "pride and prejudice":

*missourievergreen, version 2-11-0*

https://missourievergreen.org/osrf-gateway-v1?service=open-i
ls.search=open-ils.search.biblio.multiclass.query&
param=%7B%22org_unit%22:1,%22default_class%22:%22keyword%
22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%
22pride%20and%20prejudice%22=1
...
"ids":[[32673,null,"0.0"],[886843,null,"0.0"]]

*gapines**, version **2-11-1*

https://gapines.org/osrf-gateway-v1?service=open-ils.search;
method=open-ils.search.biblio.multiclass.query=%7B%
22org_unit%22:1,%22default_class%22:%22keyword%22,%
22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%22pride
%20and%20prejudice%22=1
...
"ids":[["503610",null,"0.0"],["502717",null,"0.0"]]

*cwmars**, version **2-10-7*

http://bark.cwmars.org/osrf-gateway-v1?service=open-ils.search=open-ils.search.biblio.multiclass.query=%7B%22org_unit%22:1,%22default_class%22:%22keyword%22,%22offset%22:0,%22limit%22:2,%22depth%22:0%7D=%22pride%20and%20prejudice%22=1...
"ids":[["1805532"],["2385399"]]



-- 
-Ken

[OPEN-ILS-DEV] Android app

[Ken Cox]

Jason Stephenson made the suggestion that to facilitate collaboration, I
pull the Evergreen Android app out of the dark corner of the working repo
and into the light. He even provided a filter-branches incantation to do
it.  Thank you, Jason.

The code is now and for the indefinite future available at
https://github.com/kenstir/hemlock/.  I would now consider the sources in
the Evergreen repo to be abandoned.

In the README.md I have included a section "History of this app".  If you
notice inaccuracies or think someone else deserves a mention, let me know.

Cheers,
Ken

[OPEN-ILS-DEV] Library card number via OSRF gateway?

[Ken Cox]

I login to the android app (using OSRF via the gateway) using my username.
How can I get my library card number?  Is there a PCRUD interface for
that?  Having that number would make it easier for me to login to axis360
after I have found an e-book.

Thanks,
-- 
-Ken

Re: [OPEN-ILS-DEV] Beta App Feedback

[Ken Cox]

Thanks, Ben, that was really helpful!

The app used to look for images by isbn but when that didn't work I
floundered a bit.  Looking up /small/r/ID and /medium/r/ID seems to work
well across the board.

Ken

On Mon, Nov 30, 2015 at 10:48 AM, Ben Shum <bs...@biblio.org> wrote:

> Hi Ken,
>
> Without knowing too much else about the innards of these commands and
> calls... I can tell you that the usual suspect for an item jacket
> image uses the bib record ID in Evergreen for the link.  As of
> Evergreen 2.7 and up at least.  Prior to that, it used to be ISBN or
> something.  But nobody should be using Evergreen versions that old
> anymore, or at least, this community no longer supports versions that
> old.
>
> So, if there had been an image for that bib record 1558155 in NTLC's
> catalog, the URL would have been what you used except instead of
> "tcn", you'd use the ID itself as the ending.
>
> Course that's a bad example and doesn't seem to show anything for the
> image.
>
> From ours as a separate example:
>
> https://acorn.biblio.org/eg/opac/record/699851
>
> has
>
> https://acorn.biblio.org/opac/extras/ac/jacket/large/r/699851
> https://acorn.biblio.org/opac/extras/ac/jacket/small/r/699851
>
> Those are the two versions of the image for us.
>
> So I think that if one were to use the bib record ID instead of TCN,
> that would be a good start.
>
> -- Ben
>
> On Fri, Nov 27, 2015 at 6:55 PM, Ken Cox <kens...@gmail.com> wrote:
> > Geoff, thanks for the feedback. I am totally with you on the OU level
> > stuff and will deal with that soon.
> >
> > Re: jacket images.  Definitely could be a bug here.  Devs, please help
> > me understand what is supposed to happen.  Here's what happens in the
> > app:
> >
> > 1. App queries "sorcerer's stone" via
> https://catalog.northtexaslibraries.org/
> >
> > This returns a list of ids [1558155, 814731, 1341211, 1317697,
> 327359]
> >
> > [ for each result ]
> >
> > 2. App calls
> https://catalog.northtexaslibraries.org/osrf-gateway-v1?service=open-ils.search=open-ils.search.biblio.record.mods_slim.retrieve=1558155
> >
> >This returns the payload (converted)
> >
> > [
> >   {
> > "online_loc": [
> >
> > ],
> > "types_of_resource": [
> >   "text"
> > ],
> > "isbn": "9780545790352 (hardcover) ",
> > "toc": null,
> > "publisher": null,
> > "pubdate": "2015",
> > "edition": "First illustrated edition.",
> > "title": "Harry Potter and the sorcerer's stone ",
> > "copy_count": null,
> > "call_numbers": [
> >
> > ],
> > "physical_description": "print 246 pages : color illustrations ; 28
> cm. ",
> > "doc_id": 1558155,
> > "series": [
> >
> > ],
> > "subject": {
> >   "Magic": 1,
> >   "England": 1,
> >   "Schools": 1,
> >   "Wizards": 1,
> >   "Potter, Harry (Fictitious character)": 1
> > },
> > "tcn": "  2015009929",
> > "doc_type": null,
> > "synopsis": "Rescued from the outrageous neglect of his aunt and
> > uncle, a young boy with a great destiny proves his worth while
> > attending Hogwarts School for Witchcraft and Wizardry.",
> > "author": "Rowling, J. K."
> >   }
> > ]
> >
> > 3. App constructs a record info with the tcn above: "  2015009929"
> >
> > 4. App tries to load jacket image from
> > https://catalog.northtexaslibraries.org/opac/extras/ac/jacket/small/r/
> >  2015009929
> >
> > What is the proper algorithm for constructing the jacket image URL
> > across different libraries?
> >
> > Ken
> >
> >
> > On Fri, Nov 27, 2015 at 2:16 PM, Geoff Sams <gs...@roanoketexas.com>
> wrote:
> >> Now that I've had a chance to really use the app, I figured I post some
> feedback here as well.
> >>
> >> First off, wow!  The app look and feel are really nice.  Each interface
> is snappy and seems to work pretty smoothly.  From a design stand point, I
> think this is pretty solid.
> >>
> >> A possible bug: Jacket Images do not seem to appear for me when there
> are available images in the catalog.  It doesn't appear that eit

Re: [OPEN-ILS-DEV] Beta App Feedback

[Ken Cox]

Geoff, thanks for the feedback. I am totally with you on the OU level
stuff and will deal with that soon.

Re: jacket images.  Definitely could be a bug here.  Devs, please help
me understand what is supposed to happen.  Here's what happens in the
app:

1. App queries "sorcerer's stone" via https://catalog.northtexaslibraries.org/

This returns a list of ids [1558155, 814731, 1341211, 1317697, 327359]

[ for each result ]

2. App calls 
https://catalog.northtexaslibraries.org/osrf-gateway-v1?service=open-ils.search=open-ils.search.biblio.record.mods_slim.retrieve=1558155

   This returns the payload (converted)

[
  {
"online_loc": [

],
"types_of_resource": [
  "text"
],
"isbn": "9780545790352 (hardcover) ",
"toc": null,
"publisher": null,
"pubdate": "2015",
"edition": "First illustrated edition.",
"title": "Harry Potter and the sorcerer's stone ",
"copy_count": null,
"call_numbers": [

],
"physical_description": "print 246 pages : color illustrations ; 28 cm. ",
"doc_id": 1558155,
"series": [

],
"subject": {
  "Magic": 1,
  "England": 1,
  "Schools": 1,
  "Wizards": 1,
  "Potter, Harry (Fictitious character)": 1
},
"tcn": "  2015009929",
"doc_type": null,
"synopsis": "Rescued from the outrageous neglect of his aunt and
uncle, a young boy with a great destiny proves his worth while
attending Hogwarts School for Witchcraft and Wizardry.",
"author": "Rowling, J. K."
  }
]

3. App constructs a record info with the tcn above: "  2015009929"

4. App tries to load jacket image from
https://catalog.northtexaslibraries.org/opac/extras/ac/jacket/small/r/
 2015009929

What is the proper algorithm for constructing the jacket image URL
across different libraries?

Ken


On Fri, Nov 27, 2015 at 2:16 PM, Geoff Sams  wrote:
> Now that I've had a chance to really use the app, I figured I post some 
> feedback here as well.
>
> First off, wow!  The app look and feel are really nice.  Each interface is 
> snappy and seems to work pretty smoothly.  From a design stand point, I think 
> this is pretty solid.
>
> A possible bug: Jacket Images do not seem to appear for me when there are 
> available images in the catalog.  It doesn't appear that either images 
> entered into the system manually, or OpenLibrary.org images are appearing.
>
> A visual preference:  When there is no image, the space for the image shows 
> up white, which is at odds with the rest of the app's design elements and is 
> a little jarring.  This is more opinion than anything else, take it or leave 
> it, won't bother me a bit.  I'm not even sure if this one is possible to 
> change in any case without changing the blank image that is used everywhere.
>
> I think that utilizing the same sorting for OUs as the TPAC does would be 
> ideal for the app as well.  As far as I can tell that is by OU-level, then by 
> alpha within a level.  Currently in the app, the consortium level is at the 
> top, then everything else is below that in alpha for my consortium.  We have 
> 3 levels in our group: Consortium, Geographic Area, Library.  So all of the 
> Geographic Areas are in the list with the Libraries and is likely going to be 
> a source of confusion if it remains that way.
>
> Everything else I feel works how I would expect it to work, and I can't 
> really think of anything that I'd make a change to right off.  I'm going to 
> keep toying around with things in any case.
>
> As for Justin's comments, I tend to agree with his assessment for the most 
> part.  -7 in particular would be great to have.  Some of our libraries have 
> features specific to their subdomain that would be great to see included for 
> their patrons.  I'm not sure what all bleeds through to the app, but if 
> anything does they'd want to keep it available.  Electronic Resources are 
> definitely a must, series/subject headings being links would be fantastic, 
> and yes please to barcode searching.
>
> Overall, I like the app, and I'm looking forward to being able to show it off 
> to the rest of my consortium. I really appreciate all of the work that you 
> have put into this app, and I look forward to continue helping test it.
>
> Thanks,
> Geoff Sams
> Library Manager
> Roanoke Public Library
>
>
> -Original Message-
> From: Open-ils-dev [mailto:open-ils-dev-boun...@list.georgialibraries.org] On 
> Behalf Of Justin Hopkins ??
> Sent: Tuesday, November 24, 2015 7:40 PM
> To: Evergreen Development Discussion List 
> 
> Subject: [OPEN-ILS-DEV] Beta App Feedback
>
> Ken,
>
> So awesome. It feels cool just to log in and use the app. I know I speak for 
> everyone when I say how much we appreciate your hard work on this.
>
> From my limited experience so far I'd offer the following:
>
> [-7]: Perhaps we could use another, or expand on the .json file so that we 
> could include all libraries in a given 

Re: [OPEN-ILS-DEV] Beta App Feedback

[Ken Cox]

Geoff,

Please update the app and make it crash again.  I messed up and lost the
data file that would let me de-obfuscate the stack traces.

Is there any sort of view-only account you could give me on GAPINES?  Of
course the turnaround would be quicker if I could reproduce it myself.

Thanks,
Ken

On Wed, Nov 25, 2015 at 4:43 PM, Geoff Sams <gs...@roanoketexas.com> wrote:

> Well, I fixed the issue with our SSL, turns out I has missed a step last
> time.
>
>
>
> Now I can log in through the app, but unfortunately not much else.
>
>
>
> I tried the Items Checked Out section first, and the app crashed after I
> pressed the button.
>
>
>
> I tried to run a search, but after initiating the search the app crashed.
>
>
>
> I could pull up the holds screen without issue, though I had no holds.
> After placing a hold, I checked again and the app crashed.
>
>
>
> The fines screen appears to work as intended though, even after adding a
> fine as a test.
>
>
>
> If I hadn’t already let you know, I’m running this on a Nexus 6 with
> Android 6.0.
>
>
>
> I’ll keep tinkering with things, but it seems like it simply doesn’t like
> working with me when items are involved.
>
>
>
> Thanks,
>
> Geoff Sams
>
> Library Manager
>
> Roanoke Public Library
>
>
>
> *From:* Open-ils-dev [mailto:
> open-ils-dev-boun...@list.georgialibraries.org] *On Behalf Of *Ken Cox
> *Sent:* Tuesday, November 24, 2015 9:19 PM
> *To:* Evergreen Development Discussion List <
> open-ils-dev@list.georgialibraries.org>
> *Subject:* Re: [OPEN-ILS-DEV] Beta App Feedback
>
>
>
> Geoff,
>
>
>
> What library are you trying to login to, GAPINES?  That error indicates
> some problem with SSL, either the CA or an intermediate are not trusted by
> Android.  I had this problem with https://mlnc4.mvlcstaff.org/eg/opac/home;
> Windows seems to trust its CAs but Android does not.  Only short term fix
> is not to use SSL (he said invitingly).  Longer term fix may be a trust
> chain fix to the site certs or custom code to accept those specific CAs*.
>
>
>
> Ken
>
>
>
> * see http://developer.android.com/training/articles/security-ssl.html
>
>
>
>
>
> On Tue, Nov 24, 2015 at 8:47 PM, Geoff Sams <gs...@roanoketexas.com>
> wrote:
>
> I'm at home so I haven't had a chance to really look into things closely,
> but I did pull up the app and attempt to login, but keep getting an error
> "Unable to contact login service."
>
> Thanks,
> Geoff Sams
> Library Manager
> Roanoke Public Library
> 817-491-2691
>
> 
> From: Open-ils-dev [open-ils-dev-boun...@list.georgialibraries.org] on
> behalf of Justin Hopkins  [jus...@mobiusconsortium.org]
> Sent: Tuesday, November 24, 2015 7:40 PM
> To: Evergreen Development Discussion List
> Subject: [OPEN-ILS-DEV] Beta App Feedback
>
>
> Ken,
>
> So awesome. It feels cool just to log in and use the app. I know I
> speak for everyone when I say how much we appreciate your hard work on
> this.
>
> From my limited experience so far I'd offer the following:
>
> [-7]: Perhaps we could use another, or expand on the .json file so
> that we could include all libraries in a given consortium/system for a
> more fine grained GPS based library suggestion
> [-6]: Add the consortium level as an option for search scope
> [-5]: Along the same lines, make user preferences already stored in
> Evergreen accessible/applicable (default locations, etc) or store new
> preferences for the app
> [-4]: Show some indication of consortium/system/branch levels in
> location dropdowns. It's not clear what is a system and what is a
> branch, and could make it too easy to set a system as the pickup
> location. I'm not sure how that would resolve.
> [-3]: Electronic resources don't display their 856 links
> [-2]: Subject and series information on the record pages could be links
> [-1]: A common feature among library apps, or apps where searching for
> books is a likely operation, is a barcode search - I think that would
> be a nice addition.
>
> Thanks again! I'm looking forward to playing around with this and
> putting it more to use.
>
> --
> Regards,
> Justin
>
>
>
>
>
> --
>
> -Ken
>



-- 
-Ken

Re: [OPEN-ILS-DEV] Beta App Feedback

[Ken Cox]

Justin,

Thanks for the quick feedback!   I will probably come back around to
you on your other suggestions but let me hit wh

> [-7]: Perhaps we could use another, or expand on the .json file so
> that we could include all libraries in a given consortium/system for a
> more fine grained GPS based library suggestion

As you noted, the GPS is just used to suggest a consortium.  That's
where the account is, so why would we need to include all libraries?

> [-6]: Add the consortium level as an option for search scope

In the CW/MARS apps this works by scrolling all the way to the top to
"All C/W MARS Libraries".

> [-5]: Along the same lines, make user preferences already stored in
> Evergreen accessible/applicable (default locations, etc) or store new
> preferences for the app
> [-4]: Show some indication of consortium/system/branch levels in
> location dropdowns. It's not clear what is a system and what is a
> branch, and could make it too easy to set a system as the pickup
> location. I'm not sure how that would resolve.

noted, this requires more learning on my part.  The org tree is
especially baffling, and appears to be only visible in OrgTree.js.
Teach me.

> [-3]: Electronic resources don't display their 856 links
> [-2]: Subject and series information on the record pages could be links
> [-1]: A common feature among library apps, or apps where searching for
> books is a likely operation, is a barcode search - I think that would
> be a nice addition.

noted.

Thanks,
-- 
-Ken

Re: [OPEN-ILS-DEV] Android app: want to be a Beta tester?

[Ken Cox]

Hey there, sorry I forgot to mention:


   - Users need a Google Account (@gmail.com) or a Google Apps account to
   join a test.

Best idea: send me the google account you use on your android phone.

Cheers,
Ken

On Fri, Nov 20, 2015 at 7:32 AM, Forrest, Stuart <sforr...@bcgov.net> wrote:

> Ken
>
> I'd love to try out the beta app. I am SysAdmin at one of the member
> libraries of SCLENDS.
>
> Thanks
> Stuart Forrest
> Beaufort Libray
> South Carolina
>
> Sent from my iPad
>
> On Nov 19, 2015, at 9:28 PM, Ken Cox <kens...@gmail.com kens...@gmail.com>> wrote:
>
> Hello,
>
> The android app is nearly ready to be used with any Evergreen library!  At
> least, any Evergreen library running /osrf-gateway-v1 and which is also
> listed in the directory at
> https://evergreen-ils.org/testing/libraries.json
>
> If you would like to be a Beta tester, please send me an email.  The
> process works like this:
> * I add your email to a list of approved Beta testers
> * You opt in to this by responding to the email
> * You can install an early version of the Evergreen app
> * You optionally provide me feedback omitting any curses in languages I do
> not understand
>
> If you would like to be a Beta tester but your library is not listed in
> the above JSON document, then please email me and cc: somebody with creds
> to fix it, e.g. Galen.
>
> Regards,
> --
> -Ken
>



-- 
-Ken

Re: [OPEN-ILS-DEV] Android app: want to be a Beta tester?

[Ken Cox]

Thanks for your interest, you're in the beta!

 I expect to have a Beta app ready next week. You will probably get an
opt-in invite from the Google Play Store this weekend.

Cheers,
Ken


On Fri, Nov 20, 2015 at 9:54 AM, Justin Hopkins  <
jus...@mobiusconsortium.org> wrote:

> I'm wondering if Missouri Evergreen can be added to the libraries.json
> file.
>
> { "short_name": "Missouri Evergreen", "directory_name": "Missouri
> Evergreen", "url":"https://missourievergreen.org;, "latitude":
> 38.951928, "longitude": -92.335655 }
>
> Then if we could add hopkin...@gmail.com that'd be great!
>
> Justin
>
> On Fri, Nov 20, 2015 at 8:07 AM, Josh Stompro
> <stomp...@exchange.larl.org> wrote:
> > Count us in also, Lake Agassiz Regional Library System and Northwest
> > Regional Library System in Minnesota.
> >
> > Running EG 2.8.4
> >
> > https://egcatalog.larl.org – LARL – Google Maps - Homepage
> >
> > https://egcatalog.nwrlib.org – NWRL – Google Maps - Homepage
> >
> >
> >
> > CC’ing Galen since we are not in the JSON document.
> >
> >
> >
> > Josh Stompro - LARL IT Director
> >
> >
> >
> > From: Open-ils-dev [mailto:
> open-ils-dev-boun...@list.georgialibraries.org]
> > On Behalf Of Ken Cox
> > Sent: Thursday, November 19, 2015 8:28 PM
> > To: open-ils-dev@list.georgialibraries.org
> > Subject: [OPEN-ILS-DEV] Android app: want to be a Beta tester?
> >
> >
> >
> > Hello,
> >
> >
> >
> > The android app is nearly ready to be used with any Evergreen library!
> At
> > least, any Evergreen library running /osrf-gateway-v1 and which is also
> > listed in the directory at
> https://evergreen-ils.org/testing/libraries.json
> >
> >
> >
> > If you would like to be a Beta tester, please send me an email.  The
> process
> > works like this:
> >
> > * I add your email to a list of approved Beta testers
> >
> > * You opt in to this by responding to the email
> >
> > * You can install an early version of the Evergreen app
> >
> > * You optionally provide me feedback omitting any curses in languages I
> do
> > not understand
> >
> >
> >
> > If you would like to be a Beta tester but your library is not listed in
> the
> > above JSON document, then please email me and cc: somebody with creds to
> fix
> > it, e.g. Galen.
> >
> >
> >
> > Regards,
> >
> > --
> >
> > -Ken
>
>
>
> --
> Regards,
> Justin
>



-- 
-Ken

[OPEN-ILS-DEV] Android app: want to be a Beta tester?

[Ken Cox]

Hello,

The android app is nearly ready to be used with any Evergreen library!  At
least, any Evergreen library running /osrf-gateway-v1 and which is also
listed in the directory at https://evergreen-ils.org/testing/libraries.json

If you would like to be a Beta tester, please send me an email.  The
process works like this:
* I add your email to a list of approved Beta testers
* You opt in to this by responding to the email
* You can install an early version of the Evergreen app
* You optionally provide me feedback omitting any curses in languages I do
not understand

If you would like to be a Beta tester but your library is not listed in the
above JSON document, then please email me and cc: somebody with creds to
fix it, e.g. Galen.

Regards,
-- 
-Ken