Re: [OPEN-ILS-GENERAL] OPAC default url

[Holly Brennan]

I'm not the most knowledgeable on this subject, but since it's later in the day 
you might be hanging until tomorrow waiting for the experts

Our OPAC is at ___our hostname__/eg/opac/home

If that helps, great. If not, someone else will get your over this hurdle but 
it might be tomorrow!

-Holly


Holly Brennan
Technology Specialist
Homer Public Library

hbren...@cityofhomer-ak.gov
907-435-3154 (direct)
907-235-3180 (main desk)



-Original Message-
From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Sitalk 
Teres
Sent: Wednesday, April 6, 2016 4:07 PM
To: open-ils-general@list.georgialibraries.org
Subject: [OPEN-ILS-GENERAL] OPAC default url

Hello,

First of all thanks everyone for the support.

The installation of Evergreen 2.10 went smoothly on Debian 8. 

After which the ejabberd services and Evergreen have been started successfully. 

There were not any errors after running the autogen.sh script and after 
restarting apache2. 

Afterwards I logged in successfully into Evergreen through the srfsh console. 

The settings-tester.pl script also did not reveal any errors. 

However I was not able to find any reference to the OPAC url. 
I tried "http://<>/xul/server", but I got the error:

"The requested URL /xul/server was not found on this server."

Could anyone suggest what is the correct url for accessing the OPAC?
How could I troubleshoot any possible errors?

Thanks in advance. 

[OPEN-ILS-GENERAL] OPAC default url

[Sitalk Teres]

Hello,

First of all thanks everyone for the support.

The installation of Evergreen 2.10 went smoothly on Debian 8. 

After which the ejabberd services and Evergreen have been started successfully. 

There were not any errors after running the autogen.sh script and after
restarting apache2. 

Afterwards I logged in successfully into Evergreen through the srfsh console. 

The settings-tester.pl script also did not reveal any errors. 

However I was not able to find any reference to the OPAC url. 
I tried "http://<>/xul/server", but I got the error:

"The requested URL /xul/server was not found on this server."

Could anyone suggest what is the correct url for accessing the OPAC?
How could I troubleshoot any possible errors?

Thanks in advance. 

Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Morgan, Michele]

Josh,

Have you considered using a different status for the ILL items?

We have the library setting "Selfcheck override events list" configured to
automatically override the COPY_NOT_AVAILABLE block. But we also have the
library setting "Block copy checkout status" configured to prevent checkout
of some individual statuses.

You could give these items the ILL status, and block self checkout for that
status using the library settings.

Hope this helps,
Michele

--
Michele M. Morgan, Technical Assistant
North of Boston Library Exchange, Danvers Massachusetts
mmor...@noblenet.org


On Wed, Apr 6, 2016 at 3:27 PM, Thomas Berezansky  wrote:

> For reference:
>
> I had thoughts about creating a "origin type" like field in the circ
> matrix "Staff", "OPAC", "Selfcheck", etc. Then you could set rules based on
> that to say "Staff can renew this, but you can't OPAC renew this" and "this
> can't be checked out at a selfcheck,". Add in an option on accounts in
> SIPServer for what context to use and you could have that context be
> different across SIP2 users.
>
> The use cases I have heard are all similar to "A game case (with barcode
> on the outside per delivery rules) sits on the shelf, but the
> disk/cartridge/whatever is actually behind the reference desk".
>
>
> Quoting Elaine Hardy :
>
> Josh,
>>
>> I don't think this is ​a problem for a software solution. I think it is
>> best solved by ILL workflow changes and staff education.
>>
>> In PINES, ILL staff are instructed to check the item out to the patron
>> when
>> they create the pre-cat record so that the due date is set correctly. As
>> you mentioned, it doesn't matter when the patron picks up the item, it is
>> still due back to the lending library at their set date. ILL staff are
>> also
>> instructed to renew the item so that it cannot be renewed by the patron.
>> (We don't have a circ modifier expressly for ILLs, since initially, you
>> could not choose a circ modifier for a pre-cat. We should add one but it
>> hasn't been on my radar to do so and PINES libraries haven't asked for
>> one).
>>
>> The item also generally has a book strap that identifies it as an ILL item
>> so that it can be correctly handled on check out and return (provided the
>> patron leaves the strap on).
>>
>> I don't know if self checkout differs, but if I try to check out, in the
>> client, an item already checked out to me, I get an error message telling
>> me that. I still would not want the item to go to the holds shelf since I
>> would want the patron to be verbally told the due date and any other
>> information. Having ILL staff check the item out may solve the self check
>> problem if it does inadvertently get placed there.
>>
>> Elaine
>>
>>
>>
>> J. Elaine Hardy
>> PINES & Collaborative Projects Manager
>> Georgia Public Library Service/PINES
>> 1800 Century Place, Ste. 150
>> Atlanta, GA 30045
>>
>> 404.235.7128 Office
>> 404.548.4241 Cell
>> 404.235.7201 FAX
>>
>> On Wed, Apr 6, 2016 at 2:21 PM, Josh Stompro 
>> wrote:
>>
>> Thanks for the idea been.  I am referring to the web based self check, I
>>> should have clarified that.
>>> Josh
>>>
>>> Josh Stompro - LARL IT Director
>>>
>>>
>>> -Original Message-
>>> From: Open-ils-general [mailto:
>>> open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben
>>> Shum
>>> Sent: Wednesday, April 06, 2016 11:40 AM
>>> To: Evergreen Discussion Group
>>> Subject: Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking
>>> checkout
>>>
>>> Presuming you mean the Evergreen web selfcheck, I could only think of a
>>> workaround approach like follows:
>>>
>>> If you were to designate the workstation for the selfcheck to be a
>>> different org unit (like an opac invisible child unit of the parent
>>> library), then include a circ policy in circ_matrix_matchpoint that says,
>>> don't circ items of a particular copy location (the ILL one) or circ
>>> modifier (if you have an ILL circ mod?), but leave the rest to
>>> fallthrough
>>> back up to the parent org unit rules, then the selfcheck could function
>>> differently with regards to those materials.
>>>
>>> Otherwise, I've found it more common that staff wanted items to be
>>> completely restricted and not allowed for checkout (i.e. circulate =
>>> false
>>> on the item or copy location levels) and to deal with it at the desk as
>>> you
>>> hint would be burdensome.
>>>
>>> Some development required maybe if we want to avoid any crazy workarounds
>>> like the one I posit above.
>>>
>>> And if you're talking about SIP2-based selfchecks, that's a whole other
>>> ball game entirely
>>>
>>> Just thinking aloud, hope some of that might prove helpful.
>>>
>>> -- Ben
>>>
>>> On Wed, Apr 6, 2016 at 12:02 PM, Josh Stompro <
>>> stomp...@exchange.larl.org>
>>> wrote:
>>> > Hello Everyone,
>>> >
>>> >
>>> >
>>> > My coworker is working on an issue with out of state ILL items, that
>>> > we always 

Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Thomas Berezansky]

For reference:

I had thoughts about creating a "origin type" like field in the circ  
matrix "Staff", "OPAC", "Selfcheck", etc. Then you could set rules  
based on that to say "Staff can renew this, but you can't OPAC renew  
this" and "this can't be checked out at a selfcheck,". Add in an  
option on accounts in SIPServer for what context to use and you could  
have that context be different across SIP2 users.


The use cases I have heard are all similar to "A game case (with  
barcode on the outside per delivery rules) sits on the shelf, but the  
disk/cartridge/whatever is actually behind the reference desk".


Quoting Elaine Hardy :


Josh,

I don't think this is ​a problem for a software solution. I think it is
best solved by ILL workflow changes and staff education.

In PINES, ILL staff are instructed to check the item out to the patron when
they create the pre-cat record so that the due date is set correctly. As
you mentioned, it doesn't matter when the patron picks up the item, it is
still due back to the lending library at their set date. ILL staff are also
instructed to renew the item so that it cannot be renewed by the patron.
(We don't have a circ modifier expressly for ILLs, since initially, you
could not choose a circ modifier for a pre-cat. We should add one but it
hasn't been on my radar to do so and PINES libraries haven't asked for one).

The item also generally has a book strap that identifies it as an ILL item
so that it can be correctly handled on check out and return (provided the
patron leaves the strap on).

I don't know if self checkout differs, but if I try to check out, in the
client, an item already checked out to me, I get an error message telling
me that. I still would not want the item to go to the holds shelf since I
would want the patron to be verbally told the due date and any other
information. Having ILL staff check the item out may solve the self check
problem if it does inadvertently get placed there.

Elaine



J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 150
Atlanta, GA 30045

404.235.7128 Office
404.548.4241 Cell
404.235.7201 FAX

On Wed, Apr 6, 2016 at 2:21 PM, Josh Stompro 
wrote:


Thanks for the idea been.  I am referring to the web based self check, I
should have clarified that.
Josh

Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general [mailto:
open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum
Sent: Wednesday, April 06, 2016 11:40 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

Presuming you mean the Evergreen web selfcheck, I could only think of a
workaround approach like follows:

If you were to designate the workstation for the selfcheck to be a
different org unit (like an opac invisible child unit of the parent
library), then include a circ policy in circ_matrix_matchpoint that says,
don't circ items of a particular copy location (the ILL one) or circ
modifier (if you have an ILL circ mod?), but leave the rest to fallthrough
back up to the parent org unit rules, then the selfcheck could function
differently with regards to those materials.

Otherwise, I've found it more common that staff wanted items to be
completely restricted and not allowed for checkout (i.e. circulate = false
on the item or copy location levels) and to deal with it at the desk as you
hint would be burdensome.

Some development required maybe if we want to avoid any crazy workarounds
like the one I posit above.

And if you're talking about SIP2-based selfchecks, that's a whole other
ball game entirely

Just thinking aloud, hope some of that might prove helpful.

-- Ben

On Wed, Apr 6, 2016 at 12:02 PM, Josh Stompro 
wrote:
> Hello Everyone,
>
>
>
> My coworker is working on an issue with out of state ILL items, that
> we always want to have due on a specific date, even when the customer
> doesn’t pickup the item right away.  And she has been trying to figure
> out if there is a way to block a specific item from being checked out
> at the self check, but allow it to be checked out by staff without using
an override.
>
>
>
> With these items we don’t want them to go on the holdshelf, since we
> need staff to read the documentation attached and set a specific due
> date.  But they will accidentally get placed on the hold shelf, so we
> would like the self checks to not process the checkouts.
>
>
>
> I’ve looked at hard due dates documentation, but that doesn’t seem
> like it would since this situation isn’t what it was designed for.  We
> have also looked at using item alerts, but blocking based on the alert
> event would affect too many users negatively in our system since we
> use the alerts for situations that don’t require a checkout to be
blocked.
>
>
>
> We would like to avoid setting the items to 

Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Elaine Hardy]

Josh,

I don't think this is ​a problem for a software solution. I think it is
best solved by ILL workflow changes and staff education.

In PINES, ILL staff are instructed to check the item out to the patron when
they create the pre-cat record so that the due date is set correctly. As
you mentioned, it doesn't matter when the patron picks up the item, it is
still due back to the lending library at their set date. ILL staff are also
instructed to renew the item so that it cannot be renewed by the patron.
(We don't have a circ modifier expressly for ILLs, since initially, you
could not choose a circ modifier for a pre-cat. We should add one but it
hasn't been on my radar to do so and PINES libraries haven't asked for one).

The item also generally has a book strap that identifies it as an ILL item
so that it can be correctly handled on check out and return (provided the
patron leaves the strap on).

I don't know if self checkout differs, but if I try to check out, in the
client, an item already checked out to me, I get an error message telling
me that. I still would not want the item to go to the holds shelf since I
would want the patron to be verbally told the due date and any other
information. Having ILL staff check the item out may solve the self check
problem if it does inadvertently get placed there.

Elaine



J. Elaine Hardy
PINES & Collaborative Projects Manager
Georgia Public Library Service/PINES
1800 Century Place, Ste. 150
Atlanta, GA 30045

404.235.7128 Office
404.548.4241 Cell
404.235.7201 FAX

On Wed, Apr 6, 2016 at 2:21 PM, Josh Stompro 
wrote:

> Thanks for the idea been.  I am referring to the web based self check, I
> should have clarified that.
> Josh
>
> Josh Stompro - LARL IT Director
>
>
> -Original Message-
> From: Open-ils-general [mailto:
> open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben Shum
> Sent: Wednesday, April 06, 2016 11:40 AM
> To: Evergreen Discussion Group
> Subject: Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout
>
> Presuming you mean the Evergreen web selfcheck, I could only think of a
> workaround approach like follows:
>
> If you were to designate the workstation for the selfcheck to be a
> different org unit (like an opac invisible child unit of the parent
> library), then include a circ policy in circ_matrix_matchpoint that says,
> don't circ items of a particular copy location (the ILL one) or circ
> modifier (if you have an ILL circ mod?), but leave the rest to fallthrough
> back up to the parent org unit rules, then the selfcheck could function
> differently with regards to those materials.
>
> Otherwise, I've found it more common that staff wanted items to be
> completely restricted and not allowed for checkout (i.e. circulate = false
> on the item or copy location levels) and to deal with it at the desk as you
> hint would be burdensome.
>
> Some development required maybe if we want to avoid any crazy workarounds
> like the one I posit above.
>
> And if you're talking about SIP2-based selfchecks, that's a whole other
> ball game entirely
>
> Just thinking aloud, hope some of that might prove helpful.
>
> -- Ben
>
> On Wed, Apr 6, 2016 at 12:02 PM, Josh Stompro 
> wrote:
> > Hello Everyone,
> >
> >
> >
> > My coworker is working on an issue with out of state ILL items, that
> > we always want to have due on a specific date, even when the customer
> > doesn’t pickup the item right away.  And she has been trying to figure
> > out if there is a way to block a specific item from being checked out
> > at the self check, but allow it to be checked out by staff without using
> an override.
> >
> >
> >
> > With these items we don’t want them to go on the holdshelf, since we
> > need staff to read the documentation attached and set a specific due
> > date.  But they will accidentally get placed on the hold shelf, so we
> > would like the self checks to not process the checkouts.
> >
> >
> >
> > I’ve looked at hard due dates documentation, but that doesn’t seem
> > like it would since this situation isn’t what it was designed for.  We
> > have also looked at using item alerts, but blocking based on the alert
> > event would affect too many users negatively in our system since we
> > use the alerts for situations that don’t require a checkout to be
> blocked.
> >
> >
> >
> > We would like to avoid setting the items to non-circulate since that
> > would require staff to override, which we don’t want to be a common
> > occurrence that staff get used to.
> >
> >
> >
> > If something to address this doesn’t already exist, would anyone else
> > find it useful to be able to block checkouts at the self check for
> > specific items, but allow the checkout for staff users without an
> > override?  Maybe the self check could block based on a list of
> > circ_modifiers?  If something like this may be useful to more than one
> > location, it might make a good enhancement.
> >

Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Josh Stompro]

Thanks for the idea been.  I am referring to the web based self check, I should 
have clarified that.
Josh

Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Ben 
Shum
Sent: Wednesday, April 06, 2016 11:40 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

Presuming you mean the Evergreen web selfcheck, I could only think of a 
workaround approach like follows:

If you were to designate the workstation for the selfcheck to be a different 
org unit (like an opac invisible child unit of the parent library), then 
include a circ policy in circ_matrix_matchpoint that says, don't circ items of 
a particular copy location (the ILL one) or circ modifier (if you have an ILL 
circ mod?), but leave the rest to fallthrough back up to the parent org unit 
rules, then the selfcheck could function differently with regards to those 
materials.

Otherwise, I've found it more common that staff wanted items to be completely 
restricted and not allowed for checkout (i.e. circulate = false on the item or 
copy location levels) and to deal with it at the desk as you hint would be 
burdensome.

Some development required maybe if we want to avoid any crazy workarounds like 
the one I posit above.

And if you're talking about SIP2-based selfchecks, that's a whole other ball 
game entirely

Just thinking aloud, hope some of that might prove helpful.

-- Ben

On Wed, Apr 6, 2016 at 12:02 PM, Josh Stompro  
wrote:
> Hello Everyone,
>
>
>
> My coworker is working on an issue with out of state ILL items, that 
> we always want to have due on a specific date, even when the customer 
> doesn’t pickup the item right away.  And she has been trying to figure 
> out if there is a way to block a specific item from being checked out 
> at the self check, but allow it to be checked out by staff without using an 
> override.
>
>
>
> With these items we don’t want them to go on the holdshelf, since we 
> need staff to read the documentation attached and set a specific due 
> date.  But they will accidentally get placed on the hold shelf, so we 
> would like the self checks to not process the checkouts.
>
>
>
> I’ve looked at hard due dates documentation, but that doesn’t seem 
> like it would since this situation isn’t what it was designed for.  We 
> have also looked at using item alerts, but blocking based on the alert 
> event would affect too many users negatively in our system since we 
> use the alerts for situations that don’t require a checkout to be blocked.
>
>
>
> We would like to avoid setting the items to non-circulate since that 
> would require staff to override, which we don’t want to be a common 
> occurrence that staff get used to.
>
>
>
> If something to address this doesn’t already exist, would anyone else 
> find it useful to be able to block checkouts at the self check for 
> specific items, but allow the checkout for staff users without an 
> override?  Maybe the self check could block based on a list of 
> circ_modifiers?  If something like this may be useful to more than one 
> location, it might make a good enhancement.
>
>
>
> Thanks
>
> Josh
>
>
>
> Lake Agassiz Regional Library - Moorhead MN larl.org
>
> Josh Stompro | Office 218.233.3757 EXT-139
>
> LARL IT Director | Cell 218.790.2110
>
>

Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Jason Stephenson]

Josh,

As far as I know that feature does not exist.

We (MVLC) would welcome it as we've had a request for this capability in 
the past but have had the tuits to implement it.


The trick would be making this work with SIP2 self check clients as well 
as Evergreen's own self check.


Cheers,
Jason

--
Jason Stephenson
Assistant Director for Technology Services
Merrimack Valley Library Consortium
4 High ST, Suite 175
North Andover, MA 01845
Phone: 978-557-5891
Email: jstephen...@mvlcstaff.org

Please note my new email address.

Re: [OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Ben Shum]

Presuming you mean the Evergreen web selfcheck, I could only think of
a workaround approach like follows:

If you were to designate the workstation for the selfcheck to be a
different org unit (like an opac invisible child unit of the parent
library), then include a circ policy in circ_matrix_matchpoint that
says, don't circ items of a particular copy location (the ILL one) or
circ modifier (if you have an ILL circ mod?), but leave the rest to
fallthrough back up to the parent org unit rules, then the selfcheck
could function differently with regards to those materials.

Otherwise, I've found it more common that staff wanted items to be
completely restricted and not allowed for checkout (i.e. circulate =
false on the item or copy location levels) and to deal with it at the
desk as you hint would be burdensome.

Some development required maybe if we want to avoid any crazy
workarounds like the one I posit above.

And if you're talking about SIP2-based selfchecks, that's a whole
other ball game entirely

Just thinking aloud, hope some of that might prove helpful.

-- Ben

On Wed, Apr 6, 2016 at 12:02 PM, Josh Stompro
 wrote:
> Hello Everyone,
>
>
>
> My coworker is working on an issue with out of state ILL items, that we
> always want to have due on a specific date, even when the customer doesn’t
> pickup the item right away.  And she has been trying to figure out if there
> is a way to block a specific item from being checked out at the self check,
> but allow it to be checked out by staff without using an override.
>
>
>
> With these items we don’t want them to go on the holdshelf, since we need
> staff to read the documentation attached and set a specific due date.  But
> they will accidentally get placed on the hold shelf, so we would like the
> self checks to not process the checkouts.
>
>
>
> I’ve looked at hard due dates documentation, but that doesn’t seem like it
> would since this situation isn’t what it was designed for.  We have also
> looked at using item alerts, but blocking based on the alert event would
> affect too many users negatively in our system since we use the alerts for
> situations that don’t require a checkout to be blocked.
>
>
>
> We would like to avoid setting the items to non-circulate since that would
> require staff to override, which we don’t want to be a common occurrence
> that staff get used to.
>
>
>
> If something to address this doesn’t already exist, would anyone else find
> it useful to be able to block checkouts at the self check for specific
> items, but allow the checkout for staff users without an override?  Maybe
> the self check could block based on a list of circ_modifiers?  If something
> like this may be useful to more than one location, it might make a good
> enhancement.
>
>
>
> Thanks
>
> Josh
>
>
>
> Lake Agassiz Regional Library - Moorhead MN larl.org
>
> Josh Stompro | Office 218.233.3757 EXT-139
>
> LARL IT Director | Cell 218.790.2110
>
>

[OPEN-ILS-GENERAL] Self Check / ILL issue - Blocking checkout

[Josh Stompro]

Hello Everyone,

My coworker is working on an issue with out of state ILL items, that we always 
want to have due on a specific date, even when the customer doesn't pickup the 
item right away.  And she has been trying to figure out if there is a way to 
block a specific item from being checked out at the self check, but allow it to 
be checked out by staff without using an override.

With these items we don't want them to go on the holdshelf, since we need staff 
to read the documentation attached and set a specific due date.  But they will 
accidentally get placed on the hold shelf, so we would like the self checks to 
not process the checkouts.

I've looked at hard due dates documentation, but that doesn't seem like it 
would since this situation isn't what it was designed for.  We have also looked 
at using item alerts, but blocking based on the alert event would affect too 
many users negatively in our system since we use the alerts for situations that 
don't require a checkout to be blocked.

We would like to avoid setting the items to non-circulate since that would 
require staff to override, which we don't want to be a common occurrence that 
staff get used to.

If something to address this doesn't already exist, would anyone else find it 
useful to be able to block checkouts at the self check for specific items, but 
allow the checkout for staff users without an override?  Maybe the self check 
could block based on a list of circ_modifiers?  If something like this may be 
useful to more than one location, it might make a good enhancement.

Thanks
Josh

Lake Agassiz Regional Library - Moorhead MN larl.org
Josh Stompro | Office 218.233.3757 EXT-139
LARL IT Director | Cell 218.790.2110

[OPEN-ILS-GENERAL] Call for Release Manager Nominations - Evergreen 2.11

[Galen Charlton]

Hi,

It is time to elect the Release Manager for the next Evergreen release.

The Release Manager does not have to be a core committer, but does
need to be familiar with Git and have contributed something to the
Evergreen project whether it be code or documentation.

Nominations (including self-nominations) are due by 11:59 PM EDT on
Friday, April 15. Nominations should be made by email
toopen-ils-...@list.georgialibraries.org with a Cc: to
open-ils-general@list.georgialibraries.org. Replying to all on this
email will also work.

Nominees should send an email to both of the above mailing lists with
some statements about their relationship to the Evergreen community
and their goals for the next release. The elected release manager will
be expected to adhere to the established schedule for the release
milestones.

The election will be held in the Evergreen IRC channel on freenode.net
during the week of April 18th (i.e., the week of the Evergreen
Conference).  Later this week, I will circulate a poll for setting the
specific date and time.

Everyone is invited to participate in the voting. Evergreen core
committers who cannot make the meeting may submit their vote via email
to the open-ils-dev mailing list.

BTW, it is perfectly OK to nominate yourself.

Regards,

Galen
-- 
Galen Charlton
Infrastructure and Added Services Manager
Equinox Software, Inc. / Open Your Library
email:  g...@esilibrary.com
direct: +1 770-709-5581
cell:   +1 404-984-4366
skype:  gmcharlt
web:http://www.esilibrary.com/
Supporting Koha and Evergreen: http://koha-community.org &
http://evergreen-ils.org