Re: [OPEN-ILS-GENERAL] Processing hooks for action triggers in Evergreen 3.2 and crontab configuration

[Linda Jansova]

Thank you very much, Jason!

Linda

On 5/4/20 3:38 AM, Jason Stephenson wrote:

Linda,

The short answer is yes. You need the --process-hooks and --run-pending
for events with no granularity to work.

Josh is correct about the current example crontab does not work for
these events.

That said, I think there is an expectation that passive events will have
a granularity, though I do not believe that this is documented anywhere.

Hope that helps,
Jason

On 5/3/20 1:23 PM, Linda Jansova wrote:

Hi,

We are trying to set up additional action triggers (and make some of the
default ones work) that send emails in Evergreen 3.2. However, it seems
that while some triggers work okay, some do not without a clear pattern.

We currently use the default crontab configuration:

# Action/Trigger entries 

# Runs all pending A/T events every half hour
*/5 * * * * . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --run-pending

# Passive A/T event generation.
# Note: push these back to 3am so they will run after the fine generator
and spread out the start minute to reduce dogpiling
0 * * * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --process-hooks --granularity hourly
5 3 * * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --process-hooks --granularity daily
10 3 * * 1-5 . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --process-hooks --granularity weekdays
15 3 * * 0   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --process-hooks --granularity weekly
20 3 1 * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --process-hooks --granularity monthly
25 3 1 1 *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl
--osrf-config $SRF_CORE --process-hooks --granularity yearly

# Purge old A/T events
15 1  * * *   . ~/.bashrc && $EG_BIN_DIR/purge_at_events.srfsh

This means that triggers without any granularity value are processed using:

action_trigger_runner.pl –run-pending

without the --process-hooks parameter.

The documentation
(http://docs.evergreen-ils.org/reorg/3.2/command_line_admin/_processing_action_triggers.html)
mentions both

perl action_trigger_runner.pl --run-pending

and

/openils/bin/action_trigger_runner.pl --process-hooks --run-pending

Is it a good idea to add the --process-hooks to the default crontab
configuration as Josh suggested some time ago in the following Launchpad
bug:

„Hello, I think that the current example crontab file included with
evergreen is incorrect when it comes to running pending action trigger
events, and it doesn't try to process hooks for events without a
granularity set at all.“ (https://bugs.launchpad.net/evergreen/+bug/1468096)

?

The thing is that we have our test environment set up in such a way that
it does not send any emails to users and it is a bit of a challenge to
figure out what might be wrong with the particular action triggers
without actually seeing the emails sent.

Thank you in advance for sharing your views on this!

Linda

[OPEN-ILS-GENERAL] Processing hooks for action triggers in Evergreen 3.2 and crontab configuration

[Linda Jansova]

Hi,

We are trying to set up additional action triggers (and make some of the 
default ones work) that send emails in Evergreen 3.2. However, it seems 
that while some triggers work okay, some do not without a clear pattern.


We currently use the default crontab configuration:

# Action/Trigger entries 

# Runs all pending A/T events every half hour
*/5 * * * * . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --run-pending


# Passive A/T event generation.
# Note: push these back to 3am so they will run after the fine generator 
and spread out the start minute to reduce dogpiling
0 * * * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --process-hooks --granularity hourly
5 3 * * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --process-hooks --granularity daily
10 3 * * 1-5 . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --process-hooks --granularity weekdays
15 3 * * 0   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --process-hooks --granularity weekly
20 3 1 * *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --process-hooks --granularity monthly
25 3 1 1 *   . ~/.bashrc && $EG_BIN_DIR/action_trigger_runner.pl 
--osrf-config $SRF_CORE --process-hooks --granularity yearly


# Purge old A/T events
15 1  * * *   . ~/.bashrc && $EG_BIN_DIR/purge_at_events.srfsh

This means that triggers without any granularity value are processed using:

action_trigger_runner.pl –run-pending

without the --process-hooks parameter.

The documentation 
(http://docs.evergreen-ils.org/reorg/3.2/command_line_admin/_processing_action_triggers.html) 
mentions both


perl action_trigger_runner.pl --run-pending

and

/openils/bin/action_trigger_runner.pl --process-hooks --run-pending

Is it a good idea to add the --process-hooks to the default crontab 
configuration as Josh suggested some time ago in the following Launchpad 
bug:


„Hello, I think that the current example crontab file included with 
evergreen is incorrect when it comes to running pending action trigger 
events, and it doesn't try to process hooks for events without a 
granularity set at all.“ (https://bugs.launchpad.net/evergreen/+bug/1468096)


?

The thing is that we have our test environment set up in such a way that 
it does not send any emails to users and it is a bit of a challenge to 
figure out what might be wrong with the particular action triggers 
without actually seeing the emails sent.


Thank you in advance for sharing your views on this!

Linda

Re: [OPEN-ILS-GENERAL] Marc field change script

[Linda Jansova]

Hi Glen,

In some cases MarcEdit can be a good solution: 
https://marcedit.reeset.net/ (but it involves exporting and importing 
the records in question - if the records are already loaded in 
Evergreen; if not, then MarcEdit can be the best option).


Linda

On 4/6/20 6:20 PM, Glen Modell wrote:
Hello, I would like to know if anyone has a script which changes or 
eliminates a given MARC subfield for a given list of bibliographic 
records.


In particular, we have about 10,000 records with contents in the 100-e 
subfield which we would like to eliminate.  In those cases, the 100-a 
ends in a comma, which we would like to eliminate (or change to a 
period) as well.


Thanks.  --  Glen.

*
Glen Modell
Library Automation Specialist
Ann Arbor District Library
mode...@aadl.org
734-327-8322

Re: [OPEN-ILS-GENERAL] 2019 new Evergreen Libraries

[Linda Jansova]

Hi Rogan,

I hope it's not too late by now but I'll try anyway:

In 2019 our Evergreen Common Catalog welcomed three new member libraries:

 * Varianty Educational Programme Library - this library started using
   Evergreen as its first ever ILS. The educational programme is
   operated by a Czech nonprofit organization People in Need, widely
   known for its humanitarian work in a number of countries around the
   world. The library has about 5,000 volumes.
 * Evangelical Theological Seminary Library - this library previously
   used its own Evergreen installation but switched to using Evergreen
   in the Common Catalog format in 2019. The library is operated by a
   vocational school focusing on theology, social and pastoral work. It
   has about 17,000 volumes.
 * Montessori Library - this library started using Evergreen as its
   first ever ILS. The library is operated by a Czech nonprofit
   organization Montessori Czech Republic which focuses on promoting
   and supporting Montessori method of education. It has about 2,000
   volumes.

The Common Catalog is described in detail in the 2015 community annual 
report: 
https://evergreen-ils.org/wp-content/uploads/2016/04/Evergreen%20Annual%20Report%202015%20Max%20Resolution.pdf. 
Currently, it serves as a shared Evergreen installation for seven 
independent libraries based in the Czech Republic.


Also in 2019, the Security Services Archive Library started using 
Evergreen by joining an installation operated by the Institute for the 
Study of Totalitarian Regimes, thus creating a second cluster of 
Evergreen libraries in the Czech Republic. The Security Services Archive 
Library - as its name suggests - is operated by the Security Services 
Archive. This archive is a governmental organization which focuses on 
archival materials resulting from the security services activities 
during the communist era. It has about 4,000 volumes.


Thank you in advance for including some of the above mentioned 
information in the annual report!


Linda

On 12/12/19 6:05 PM, Rogan Hamby wrote:

Good afternoon on behalf of the Outreach Committee,

One thing we are doing in the community annual report this year is 
dedicating space to discussing the growth of Evergreen during 2019 in 
terms of those who have moved to Evergreen.  Obviously, various 
institutions can migrate into Evergreen without any kind of fanfare or 
announcement but I'm hoping to create as strong a list of possible.  
So, if you know of an institution that has moved to Evergreen this 
year please let me know.  A few stats like bib collection size would 
be great but I'll take as little as a name and location!



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

[OPEN-ILS-GENERAL] Untranslated web staff client in Evergreen 3.3.4 and 3.3.5

[Linda Jansova]

Hi all,

We are just testing Evergreen 3.3.4 and 3.3.5 and – surprisingly – it 
seems that although we are able to switch from English to Czech 
interface in the web staff client, with the exception of several strings 
(apparently those also used in the OPAC), the staff client remains 
untranslated.

In Evergreen 3.3.2 the web client localization works okay.

eg-navbar-template script in 3.3.2 seems to load the localization as it 
contains the strings necessary for the translated interface. But the 
same script in 3.3.5 only contains a handful of translated strings (such 
as Domů for Home) and most strings are missing.


An example from web client page source from 3.3.2:

  
    
  
  Hledat čtenáře
    
  

The same piece from 3.3.5:
 
  
    
  
  Search for Patrons
    
  

In both cases the page begins with:


(Just for the record – all the steps that usually work to make sure the 
complete language switch takes place - like clearing the browser cache - 
have been performed.)


Does anybody have any idea about what might have happened between 3.3.2 
and 3.4.4 that results in the untranslated interface? And, most 
importantly, how to make the localization work again?


Thank you in advance for any hints!

Linda

[OPEN-ILS-GENERAL] Longer text in added content in OPAC fails to show

[Linda Jansova]

Hi,

We have encountered a strange behavior in Evergreen 3.3 (maybe it is 
also valid for Evergreen 3.2 while our experience proves that in 3.1 it 
is okay):


When longer text should be shown as added content (e.g., summary but 
also textual TOCs) in the online catalog, it actually fails to load.


Our developer Jakub Kotrla, author of ObalkyKnih.pm module for pulling 
added content from the Czech provider, has made a number of tests and 
has found out that a text composed of 766 letters "a" is visible but 767 
letters of "a" are not.


A more elaborate description can be found at 
https://bugs.launchpad.net/evergreen/+bug/1843884.


Does anyone have any idea what might have changed in 3.2 or 3.3 that 
could be causing this?


Thank you!

Linda

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Problem loading report inteface

[Linda Jansova]

Thank you, Galen!

Linda

On 9/23/19 11:51 PM, Galen Charlton wrote:

Hi,

I may have finally tracked this down. I've written up some details and 
put out a work-in-progress patch for testing in bug 
https://bugs.launchpad.net/evergreen/+bug/1845050.


Regards,

Galen

On Sat, Jun 8, 2019 at 10:45 AM Linda Jansova <mailto:skolk...@chello.cz>> wrote:


Hi,,

We have eventually tried Evergreen 3.3.1 with Ubuntu 16.04 LTS
(end of life April 2021) and the interface loads okay (as the
attached screenshot confirms).

So to avoid seeing a broken interface we will probably go for
Ubuntu 16.04 LTS (instead of Debian 9 or Ubuntu 18 as originally
planned) on our production server - unless there is a (hopefully
simple) change to configuration which would make the reports
interface usable in Debian 9 or Ubuntu 18 (?).

Linda

On 6/6/19 6:41 AM, Linda Jansova wrote:


Hi Galen,

have you managed to sum up your findings to Launchpad yet?

Or could you recommend a particular Ubuntu or Debian version
which works fine with the report interface and is recommended for
the current Evergreen version?

Thank you!

Linda

On 5/30/19 6:51 AM, Linda Jansova wrote:


One more thing - we have also tested Evergreen 3.3.0 on Debian 9
(Stretch), getting the same results (but this testing was
performed using our own database data and localized Evergreen,
making it difficult to tell whether either of the two aren't to
blame).

Linda

On 5/30/19 6:43 AM, Linda Jansova wrote:


Hi Galen,

Thank you very much for looking into this!

Linda

On 5/30/19 12:14 AM, Galen Charlton wrote:

Hi Linda,

On Wed, May 29, 2019 at 2:48 PM Linda Jansova
mailto:skolk...@chello.cz>> wrote:

So the question is - has anyone tried 3.3.1 and tried to
create a report template folder? Or does anyone have any
idea what could be wrong? (We use the concerto database
without localization at this moment. Also, we keep
reloading the interface and clearing the browser cache.)

Thank you in advance for any ideas!


In my own testing I'm seeing cases where on Debian Stretch the
combination of the Apache mod_include and mod_xmlent modules,
which are used to render the reports interface, are no longer
returning the full page. Enough of it gets returned so that
you see an apparently complete interface, but not enough of it
for it to be fully functional. I am working on a writeup for
Launchpad and and hope it post it tomorrow.

Regards,

Galen
-- 
Galen Charlton

Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email: g...@equinoxinitiative.org
<mailto:g...@equinoxinitiative.org>
web: https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366




--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email:  g...@equinoxinitiative.org
web: https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366

Re: [OPEN-ILS-GENERAL] Authority fields list in Evergreen 3.3 web client?

[Linda Jansova]

Hi James,

Thank you very much for the link - we have just tried it in our test 
environment and it seems to work fine :-)!


Obviously, it would be great if a direct link made its way back to the 
current web client interface - thank you for submitting a bug for it!


Linda

On 7/26/19 10:22 PM, James Fournie wrote:
Hi!  It looks to me like the interface was rewritten but this 
functionality was missed in the rewrite.


Because it auto-generates some of these screens, there is a hidden 
screen for this:
https://EVERGREEN>/eg2/en-US/staff/admin/server/authority/control_set_authority_field 
<https://bugsquash.missourievergreen.org/eg2/en-US/staff/admin/server/authority/control_set_authority_field> 



However this isn't very usable in my testing.

If you know the ID of your control set, you might be able to use a URL 
like this to get at it (where 1 is the ID of your control set)


https://EVERGREEN>/eg/conify/global/cat/authority/control_set_authority_field?acs=1 
<https://dev1.catalogue.libraries.coop/eg/conify/global/cat/authority/control_set_authority_field?acs=1> 



I'm not sure how will this will work though, your mileage may vary.

I've filed a bug here:
https://bugs.launchpad.net/evergreen/+bug/1838102



On Fri, Jul 26, 2019 at 2:28 AM Linda Jansova <mailto:skolk...@chello.cz>> wrote:


Hi,

Does anyone have any idea where is the authority fields list that
used
to be available in 3.2
(http://docs.evergreen-ils.org/3.2/_authority_fields.html - please
see
the first image) now - in 3.3 - located? There used to be a link from
Authority Control Sets (under Server Administration) but I cannot
see it
in 3.3.

The reason why I'm searching for it is that I would like to have our
subfield 7 (contained in authority records) automatically inserted
into
authority-controlled fields in bib records. (The subfield in
question is
used by our national library to store permanent authority record
ID and
so we use it basically in all authority-controlled fields in bib
records
in order to have it included in bib records sent to our union
catalog.)

Thank you for pointing me in the right direction!

Linda

[OPEN-ILS-GENERAL] Authority fields list in Evergreen 3.3 web client?

[Linda Jansova]

Hi,

Does anyone have any idea where is the authority fields list that used 
to be available in 3.2 
(http://docs.evergreen-ils.org/3.2/_authority_fields.html - please see 
the first image) now - in 3.3 - located? There used to be a link from 
Authority Control Sets (under Server Administration) but I cannot see it 
in 3.3.


The reason why I'm searching for it is that I would like to have our 
subfield 7 (contained in authority records) automatically inserted into 
authority-controlled fields in bib records. (The subfield in question is 
used by our national library to store permanent authority record ID and 
so we use it basically in all authority-controlled fields in bib records 
in order to have it included in bib records sent to our union catalog.)


Thank you for pointing me in the right direction!

Linda

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Problem loading report inteface

[Linda Jansova]

Hi,,

We have eventually tried Evergreen 3.3.1 with Ubuntu 16.04 LTS (end of 
life April 2021) and the interface loads okay (as the attached 
screenshot confirms).


So to avoid seeing a broken interface we will probably go for Ubuntu 
16.04 LTS (instead of Debian 9 or Ubuntu 18 as originally planned) on 
our production server - unless there is a (hopefully simple) change to 
configuration which would make the reports interface usable in Debian 9 
or Ubuntu 18 (?).


Linda

On 6/6/19 6:41 AM, Linda Jansova wrote:


Hi Galen,

have you managed to sum up your findings to Launchpad yet?

Or could you recommend a particular Ubuntu or Debian version which 
works fine with the report interface and is recommended for the 
current Evergreen version?


Thank you!

Linda

On 5/30/19 6:51 AM, Linda Jansova wrote:


One more thing - we have also tested Evergreen 3.3.0 on Debian 9 
(Stretch), getting the same results (but this testing was performed 
using our own database data and localized Evergreen, making it 
difficult to tell whether either of the two aren't to blame).


Linda

On 5/30/19 6:43 AM, Linda Jansova wrote:


Hi Galen,

Thank you very much for looking into this!

Linda

On 5/30/19 12:14 AM, Galen Charlton wrote:

Hi Linda,

On Wed, May 29, 2019 at 2:48 PM Linda Jansova <mailto:skolk...@chello.cz>> wrote:


So the question is - has anyone tried 3.3.1 and tried to create
a report template folder? Or does anyone have any idea what
could be wrong? (We use the concerto database without
localization at this moment. Also, we keep reloading the
interface and clearing the browser cache.)

Thank you in advance for any ideas!


In my own testing I'm seeing cases where on Debian Stretch the 
combination of the Apache mod_include and mod_xmlent modules, which 
are used to render the reports interface, are no longer returning 
the full page. Enough of it gets returned so that you see an 
apparently complete interface, but not enough of it for it to be 
fully functional. I am working on a writeup for Launchpad and and 
hope it post it tomorrow.


Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email: g...@equinoxinitiative.org
web: https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Problem loading report inteface

[Linda Jansova]

Hi Galen,

have you managed to sum up your findings to Launchpad yet?

Or could you recommend a particular Ubuntu or Debian version which works 
fine with the report interface and is recommended for the current 
Evergreen version?


Thank you!

Linda

On 5/30/19 6:51 AM, Linda Jansova wrote:


One more thing - we have also tested Evergreen 3.3.0 on Debian 9 
(Stretch), getting the same results (but this testing was performed 
using our own database data and localized Evergreen, making it 
difficult to tell whether either of the two aren't to blame).


Linda

On 5/30/19 6:43 AM, Linda Jansova wrote:


Hi Galen,

Thank you very much for looking into this!

Linda

On 5/30/19 12:14 AM, Galen Charlton wrote:

Hi Linda,

On Wed, May 29, 2019 at 2:48 PM Linda Jansova <mailto:skolk...@chello.cz>> wrote:


So the question is - has anyone tried 3.3.1 and tried to create
a report template folder? Or does anyone have any idea what
could be wrong? (We use the concerto database without
localization at this moment. Also, we keep reloading the
interface and clearing the browser cache.)

Thank you in advance for any ideas!


In my own testing I'm seeing cases where on Debian Stretch the 
combination of the Apache mod_include and mod_xmlent modules, which 
are used to render the reports interface, are no longer returning 
the full page. Enough of it gets returned so that you see an 
apparently complete interface, but not enough of it for it to be 
fully functional. I am working on a writeup for Launchpad and and 
hope it post it tomorrow.


Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email: g...@equinoxinitiative.org
web: https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Problem loading report inteface

[Linda Jansova]

One more thing - we have also tested Evergreen 3.3.0 on Debian 9 
(Stretch), getting the same results (but this testing was performed 
using our own database data and localized Evergreen, making it difficult 
to tell whether either of the two aren't to blame).


Linda

On 5/30/19 6:43 AM, Linda Jansova wrote:


Hi Galen,

Thank you very much for looking into this!

Linda

On 5/30/19 12:14 AM, Galen Charlton wrote:

Hi Linda,

On Wed, May 29, 2019 at 2:48 PM Linda Jansova <mailto:skolk...@chello.cz>> wrote:


So the question is - has anyone tried 3.3.1 and tried to create a
report template folder? Or does anyone have any idea what could
be wrong? (We use the concerto database without localization at
this moment. Also, we keep reloading the interface and clearing
the browser cache.)

Thank you in advance for any ideas!


In my own testing I'm seeing cases where on Debian Stretch the 
combination of the Apache mod_include and mod_xmlent modules, which 
are used to render the reports interface, are no longer returning the 
full page. Enough of it gets returned so that you see an apparently 
complete interface, but not enough of it for it to be fully 
functional. I am working on a writeup for Launchpad and and hope it 
post it tomorrow.


Regards,

Galen
--
Galen Charlton
Implementation and Services Manager
Equinox Open Library Initiative
phone:  1-877-OPEN-ILS (673-6457)
email: g...@equinoxinitiative.org
web: https://equinoxInitiative.org
direct: +1 770-709-5581
cell:   +1 404-984-4366

Re: [OPEN-ILS-GENERAL] Problem loading report inteface

[Linda Jansova]

Hi,

We have been trying to figure out what is wrong with the reporter 
interface in 3.3.1 (using a fresh install of Ubuntu 18.04 LTS and a 
concerto database), yet when one is logged in as admin, there still does 
not seem to be any option to create a new folder for report templates 
(as can be seen in the attached file). It has been tested both in Chrome 
and Firefox.


When the same interface is loaded in 3.3.0 
(https://bugsquash.missourievergreen.org/eg/staff/ has been used for 
this purpose), it is possible to create a subfolder after clicking on 
Templates.


So the question is - has anyone tried 3.3.1 and tried to create a report 
template folder? Or does anyone have any idea what could be wrong? (We 
use the concerto database without localization at this moment. Also, we 
keep reloading the interface and clearing the browser cache.)


Thank you in advance for any ideas!

Linda

On 5/24/19 10:50 PM, Cerninakova Eva wrote:

Hi,

thanks a lot for the hint. The fm_IDL.xml files seem to be the right 
track: Both files are really different - however, I don't' think the 
differences are related to localization (in a fact, I don't see any 
signs of localization).


Eva





---
Mgr. Eva Cerniňáková
cer...@jabok.cz 
Tel. +420 211 222 409

Knihovna Jabok
http:/knihovna.jabok.cz 
Tel.  +420 211 222 410
Jabok - Vyšší odborná škola sociálně pedagogická a teologická
Salmovská 8, 120 00 Praha 2



pá 24. 5. 2019 v 16:49 odesílatel Jason Stephenson > napsal:


Hi, all!

I want to make a correction to Jason's comments below.  If you're
using
a localization other than English, then the reporter's copy of
fm_IDL.xml will not be identical to the main one in /openils/conf.  It
should be localized to your language.

The autogen.sh script is supposed to take care of this.

Jason

On 5/24/19 9:13 AM, Boyer, Jason A wrote:
> Hi Eva, I and a couple other folks have run into this same issue
> recently. In the end you're at least required to use the Clear
Cache and
> Hard Reload option in Chrome. If that doesn't fix it alone
you'll need
> to make sure that the layout of the 2 fm_IDL.xml files
(/openils/conf/
> and /openils/var/web/reports/) are the same. I don't know if (or
how)
> both end up being localized so that may or may not be an issue to be
> aware of. After they match you may need to restart some services and
> re-run autogen.sh just in case. After all of that, do a hard reload
> again in Chrome on the reporter page and it should finally let
you get
> back to it.
>
> Jason
>
> --
>
> Jason Boyer
>
> Indiana State Library
>
> 315 W. Ohio St.
>
> Indianapolis, IN 46202
>
> http://library.in.gov/
>
>
>

> *From:* Open-ils-general
> mailto:open-ils-general-boun...@list.georgialibraries.org>> on
behalf of
> Cerninakova Eva mailto:cer...@jabok.cz>>
> *Sent:* Friday, May 24, 2019 8:07 AM
> *To:* Evergreen Discussion Group
> *Subject:* [OPEN-ILS-GENERAL] Problem loading report inteface
>
>  This is an EXTERNAL email. Exercise caution. DO NOT open
> attachments or click links from unknown senders or unexpected
email. 
>

>
> Hi,
>
> I wonted to test some  localization bugs and problems related to
> reports using our  Evergreen test server environment (3.3.0, Czech
> localization). However, I came across a problem, that the web client
> report interface can be loaded only partially (see the
attachment) and
> templates search and folder links don't work at all (in production
> environment using Evergreen 3.1.4 the report interface is loaded
> normally  - there are, however, other problems that I just
wanted to test).
> I compared the report interface with Blake's sandbox -
everything works
> fine there.
>
> I'm not sure if it's a localization problem or if it can be
caused by
> some specific settings.
>
> Don't you have an experience with similar behavior of reporter
interface
> (or idea, what could cause the problem)?
>
> Thank you in advance for any hint.
> Eva
>
>
> ---
> Mgr. Eva Cerniňáková
> cer...@jabok.cz  >
> Tel. +420 211 222 409
>
> Knihovna Jabok
> http:/knihovna.jabok.cz 

> Tel.  +420 211 222 410
> Jabok - Vyšší odborná škola sociálně pedagogická a teologická
> Salmovská 8, 120 00 Praha 2
>

Re: [OPEN-ILS-GENERAL] Setting the currency in the patron billing interface

[Linda Jansova]

Hi Dan,

It really seems there is no easy way in Angular to change default 
currency parameters across the application as mentioned in Angular Wiki 
(https://www.angularjswiki.com/angular/angular-currency-pipe-formatting-currency-in-angular/) 
and further elaborated in a GitHub discussion 
(https://github.com/angular/angular/issues/25461).


However, the Angular Wiki page cited above mentions a workaround (with a 
code example):


"we can define our own custom Angular currency Pipe to do the same.

Create a new file called custom.currencypipe.ts file and add the below 
code to it. You can change the paramters as per your requirements."


If implemented in Evergreen, maybe the currency parameters could be 
changed in a single place?


Linda

On 5/20/19 9:38 PM, Daniel Wells wrote:

Hello Eva,

The AngularJS interfaces are using the built-in currency filter, which 
supplies a dollar sign by default.  More here:


https://docs.angularjs.org/api/ng/filter/currency

It does appear that the filter can specify a different symbol; it is 
fairly limited otherwise.  The newer Angular looks to be more robust 
in allowing locale-specific currency formatting options.


If you care mainly about the symbol, you should be able to change that 
by modifying each place that filter is used, but that doesn't seem 
very practical.  If that doesn't seem viable for you, we probably need 
to look at expanding how that filter is processed to allow for better 
optional behavior.  Tacking on a root variable similar to date 
formatting doesn't seem too terrible.


Hopefully someone with more direct knowledge will chime in and let us 
know there is already an easier way.


Sincerely,
Dan


On Mon, May 20, 2019 at 3:06 PM Cerninakova Eva > wrote:



Hi,

The Czech Evergreen community hopes that during the summer we will
be possible to move our libraries to the web client using
Evergreen version 3.3. Therefore, we are currently working on
testing and removing potential localization problems.

Currently, we are dealing with currency setting in the web staff
client patron billing interface.

There was no currency symbol used in the patron billing interface
in the XUL staff client.  This has changed with the new web
client:  There is the "$" symbol  shown in the patron billing
interface for each payment amount. However, we use the Czech
currency, and the dollar symbol shown in the interface is quite
confusing and does not provide an easy survey of the money summary
to staff. Even greater complication is that the dollar symbol is
also used on patron payment receipts (see the attachments). We
need the currency symbol to be changed (or at least removed).

From the receipt template
(Open-ILS/src/templates/staff/share/print_templates/t_bills_current.tt2),
as well as from the billing interface, it is obvious, that a
specific currency (particularly USD) is automatically inserted
into the receipt or into the billing interface. E.g. "Total owed:
{{xact.summary.total_owed | currency}}" is interpreted as
something like "Total owed: $1.50". However, unfortunately It is
not clear to us, where the USD currency comes from.

We suppose there should be probably a similar setting for the
currency as it is for the date + time format (which is possible to
set in the Library settings editor and which occurs in the receipt
template as {{xact.xact_start | date:$root.egDateAndTimeFormat}} )???

Does anyone please have an idea how to set the currency value?
(The fact that we can't use our own currency is a real web staff
blocker for us )

Thanks for any hint
Eva








---
Mgr. Eva Cerniňáková
cer...@jabok.cz 
Tel. +420 211 222 409

Knihovna Jabok
http:/knihovna.jabok.cz 
Tel.  +420 211 222 410
Jabok - Vyšší odborná škola sociálně pedagogická a teologická
Salmovská 8, 120 00 Praha 2

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] AddedContent.pm produces garbled encoding for application/json

[Linda Jansova]

Hi,

Just letting you know that our developer has eventually changed the 
encoding of the data blob coming from Obalkyknih.cz from UTF-8 to Perl's 
internal representation:


utf8::decode($response_content);

Adding this step before further data processing takes place has 
successfully solved the problem of seeing gibberish characters in our 
catalog :-).


Linda

On 11/25/18 4:56 PM, Linda Jansova wrote:

Hi,

We have encountered a problem in AddedContent.pm's get_url function 
(both in Evergreen 3.1.4 and 2.12.6) - letters with diacritics from 
Czech added content provider Obalkyknih.cz have started being 
corrupted in our TPACs. Our added content provider has reported a 
switch to application/json MIME type.


After the switch we seem to be getting strange chars in summary (and 
table of contents if available as text, not as an image). We have 
tried to locate the problem in a separate Perl program and have come 
to a conclusion that data only get corrupted when fetched by the 
get_url function from AddedContent.pm.


We have added additional logging to the following part of 
AddedContent.pm:


# returns an HTPP::Response object
sub get_url {
    my( $self, $url ) = @_;

    $logger->info("added content getting [timeout=$net_timeout, 
errors_remaining=$error_countdown] URL = $url");

    my $agent = LWP::UserAgent->new(timeout => $net_timeout);

    my $res = $agent->get($url);
    $logger->info("added content request returned with code " . 
$res->code);


    #VJ
    $logger->info("added contet res is: " . $res->content);

    die "added content request failed: " . $res->status_line ."\n" 
unless $res->is_success;


    return $res;
}

And a corresponding sample log looks like this:

[2018-11-24 22:22:58] /usr/sbin/apache2 
[INFO:32231:AddedContent.pm:296:1543094555322319] added contet res is: 
[{"_id":"5bf904c905509b06182848ac","succ_toc_count":"0","cover_preview510_url":"https://cache.obalkyknih.cz/file/cover/1830989/preview510","ean":"9788026203667","uuid":["uuid:6ec863b0-055e-11e6-a611-005056827e51"],"cooperating_with":"https://www.cbdb.cz|CBDB.cz","succ_cover_count":"0","flag_bare_record":0,"csn_iso_690_source":"Národní 
knihovna Äeské Republiky 
18.11.2018","rating_url":"https://www.obalkyknih.cz/stars?value=100","rating_sum":200,"cover_thumbnail_url":"https://cache.obalkyknih.cz/file/cover/1830989/thumbnail","oclc_other":[],"reviews":[],"part_root":1,"orig_height":"510","backlink_url":"https://www.obalkyknih.cz/view?isbn=9788026203667","toc_thumbnail_url":"https://cache.obalkyknih.cz/file/toc/362647/thumbnail","cover_medium_url":"https://cache.obalkyknih.cz/file/cover/1830989/medium","annotation":{"source":"Web 
obalkyknih.cz","html":"Encyklopedie sociální práce (ESP) 
pÅináší pÅes 200 hesel ze vÅ¡ech oblastí 
sociální práce. ESP je postavena na interakÄním pojetí 
sociální práce. JedineÄnost sociální práce spoÄ
ívá v tom, že operuje v poli mezi klientem a jeho 
sociálním prostÅedím; pracovník je v obecném smyslu 
mediátorem mezi jednotlivcem a spoleÄností. Jeho úkolem je 
napomáhat sociálnímu fungování klientů a pomáhat 
spoleÄnosti, aby citlivÄ reagovala na potÅeby 
svých Älenů. Tato dvojitá mediaÄní role je role 
angažovaná. Je zakotvená hodnotovÄ v náboženství nebo v 
huma
[2018-11-24 22:22:58] /usr/sbin/apache2 
[INFO:32231:ObalkyKnih.pm:228:1543094555322319] ObalkyKnih.cz for 
books?isbn=9788026203667 response was 
[{"_id":"5bf904c905509b06182848ac","succ_toc_count":"0","cover_preview510_url":"https://cache.obalkyknih.cz/file/cover/1830989/preview510","ean":"9788026203667","uuid":["uuid:6ec863b0-055e-11e6-a611-005056827e51"],"cooperating_with":"https://www.cbdb.cz|CBDB.cz","succ_cover_count":"0","flag_bare_record":0,"csn_iso_690_source":"Národní 
knihovna Äeské Republiky 
18.11.2018","rating_url":"https://www.obalkyknih.cz/stars?value=100","rating_sum":200,"cover_thumbnail_url":"https://cache.obalkyknih.cz/file/cover/1830989/thumbnail","oclc_other":[],"reviews":[],"part_root":1,"orig_height":"510","backlink_url":"https://www.obalkyknih.cz/view?isbn=9788026203667","toc_thumbnail_url":"https://cache.obalkyknih.cz/file/toc/362647/thumbnail","cover_medium_url":"https

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

[Linda Jansova]

Hi,

The LC official file has already been updated - the link to the file is 
included in my comment at https://bugs.launchpad.net/evergreen/+bug/1800871.


Linda

On 11/11/18 7:54 PM, Linda Jansova wrote:
A little update if someone else needs to perform the upgrade with the 
changed XSLT - the lines also have to be swapped in the following file:


http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/version-upgrade/2.12.6-3.0.0-upgrade-db.sql;h=7a865a89db22c333e8da9e3e7750bc9d1fc8bb95;hb=HEAD 



Linda

On 11/8/18 6:20 AM, Linda Jansova wrote:

Hi,

a little update - Nate Trail from the LC has promised to fix it:

https://listserv.loc.gov/cgi-bin/wa?A2=MODS;692400d8.1811

:-)

Linda

On 11/7/18 11:11 AM, Linda Jansova wrote:

Dear all,

We have updated the XSLT (with swapped lines 1084 and 1085 as Josh 
suggested) using the following command: 
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/955.data.MADS21-xsl.sql. 
Then we performed all steps that the upgrade from 2.12.6 to 3.1.4 
requires. Everything (including the reingest) has been completed 
successfully :-).


On Monday November 5th, I sent a message to MODS (MADS) mailing list 
regarding the troublesome lines in the XSLT file:


https://listserv.loc.gov/cgi-bin/wa?A2=MODS;fd3eba0f.1811

There is no response yet but I do hope that someone from the LC will 
eventually respond.


Linda

On 11/1/18 7:29 AM, Linda Jansova wrote:

Thank you, Josh!

We shall try and go through the reingest of all records and if no 
other XSLT-related issues appear, I can get in touch with MADS 
folks through their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:
Hello Mike, I've created a bug for this issue to get it in the 
queue.  LP#1800871


Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
 On Behalf Of 
Mike Rylander

Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 

Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save 
authority record with a 155 field


Hi Linda and Josh,

Great work figuring that out! We should definitely report this 
upstream to the MODS/MADS folks, but we maintain a local copy of 
the XSLT (altered to work without external file or network access 
for xml
includes) and can fix it locally.  I don't have time right now to 
jump on it, but both the file on the filesystem and the version in 
the config.xml_transform table in the db should be corrected.


Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro 
 wrote:
Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The 
error

message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element 
attribute


xsl:attribute: Cannot add attributes to an element if children 
have been already added to the element.




I agree that it looks like the problem is when the xslt is 
processing the 755 and trying to set the authority source.




I think the bug may be that when processing the 755 tag on line 
1081, the genre template is called before the setAuthority 
template.  The Genre template adds child elements, then the 
setAuthority tries to set attributes, which is where the error 
pops up.




If I swap lines 1084 and 1085 then the error goes away and both 
the genre(155) and related genre(755) show up in the transformed 
xml.




I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all 
that confident that this is the issue though. I would be happy to 
report this to the MODS listserv if it seems to make sense to 
someone that is more familiar with mods/mads/xml/authorities.




Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that 
it is not actually a 155 field which causes the problem but a 755 
field. If it has any value in second indicator, xsltproc fails to 
process it. When the indicator does not have any value (or, to be 
more precise, there is just a space), it is okay.


So far, it seems that we will have to get rid either of the 
values of indicators in 755s, or of the following part of the XSL 
file:


 test="(700 = 
ancestor-or-self::marc:datafield/@tag and 
ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

 
 select="marc

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

[Linda Jansova]

A little update if someone else needs to perform the upgrade with the 
changed XSLT - the lines also have to be swapped in the following file:


http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/version-upgrade/2.12.6-3.0.0-upgrade-db.sql;h=7a865a89db22c333e8da9e3e7750bc9d1fc8bb95;hb=HEAD

Linda

On 11/8/18 6:20 AM, Linda Jansova wrote:

Hi,

a little update - Nate Trail from the LC has promised to fix it:

https://listserv.loc.gov/cgi-bin/wa?A2=MODS;692400d8.1811

:-)

Linda

On 11/7/18 11:11 AM, Linda Jansova wrote:

Dear all,

We have updated the XSLT (with swapped lines 1084 and 1085 as Josh 
suggested) using the following command: 
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/955.data.MADS21-xsl.sql. 
Then we performed all steps that the upgrade from 2.12.6 to 3.1.4 
requires. Everything (including the reingest) has been completed 
successfully :-).


On Monday November 5th, I sent a message to MODS (MADS) mailing list 
regarding the troublesome lines in the XSLT file:


https://listserv.loc.gov/cgi-bin/wa?A2=MODS;fd3eba0f.1811

There is no response yet but I do hope that someone from the LC will 
eventually respond.


Linda

On 11/1/18 7:29 AM, Linda Jansova wrote:

Thank you, Josh!

We shall try and go through the reingest of all records and if no 
other XSLT-related issues appear, I can get in touch with MADS folks 
through their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:
Hello Mike, I've created a bug for this issue to get it in the 
queue.  LP#1800871


Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
 On Behalf Of 
Mike Rylander

Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 

Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save 
authority record with a 155 field


Hi Linda and Josh,

Great work figuring that out! We should definitely report this 
upstream to the MODS/MADS folks, but we maintain a local copy of 
the XSLT (altered to work without external file or network access 
for xml
includes) and can fix it locally.  I don't have time right now to 
jump on it, but both the file on the filesystem and the version in 
the config.xml_transform table in the db should be corrected.


Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro 
 wrote:
Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The 
error

message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children 
have been already added to the element.




I agree that it looks like the problem is when the xslt is 
processing the 755 and trying to set the authority source.




I think the bug may be that when processing the 755 tag on line 
1081, the genre template is called before the setAuthority 
template.  The Genre template adds child elements, then the 
setAuthority tries to set attributes, which is where the error 
pops up.




If I swap lines 1084 and 1085 then the error goes away and both 
the genre(155) and related genre(755) show up in the transformed xml.




I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all 
that confident that this is the issue though.  I would be happy to 
report this to the MODS listserv if it seems to make sense to 
someone that is more familiar with mods/mads/xml/authorities.




Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it 
is not actually a 155 field which causes the problem but a 755 
field. If it has any value in second indicator, xsltproc fails to 
process it. When the indicator does not have any value (or, to be 
more precise, there is just a space), it is okay.


So far, it seems that we will have to get rid either of the values 
of indicators in 755s, or of the following part of the XSL file:


 test="(700 = 
ancestor-or-self::marc:datafield/@tag and 
ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

 
 select="marc:subfield[@code='2']"/>

 
 

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

[Linda Jansova]

Hi,

a little update - Nate Trail from the LC has promised to fix it:

https://listserv.loc.gov/cgi-bin/wa?A2=MODS;692400d8.1811

:-)

Linda

On 11/7/18 11:11 AM, Linda Jansova wrote:

Dear all,

We have updated the XSLT (with swapped lines 1084 and 1085 as Josh 
suggested) using the following command: 
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/955.data.MADS21-xsl.sql. 
Then we performed all steps that the upgrade from 2.12.6 to 3.1.4 
requires. Everything (including the reingest) has been completed 
successfully :-).


On Monday November 5th, I sent a message to MODS (MADS) mailing list 
regarding the troublesome lines in the XSLT file:


https://listserv.loc.gov/cgi-bin/wa?A2=MODS;fd3eba0f.1811

There is no response yet but I do hope that someone from the LC will 
eventually respond.


Linda

On 11/1/18 7:29 AM, Linda Jansova wrote:

Thank you, Josh!

We shall try and go through the reingest of all records and if no 
other XSLT-related issues appear, I can get in touch with MADS folks 
through their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:
Hello Mike, I've created a bug for this issue to get it in the 
queue.  LP#1800871


Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
 On Behalf Of 
Mike Rylander

Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 

Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority 
record with a 155 field


Hi Linda and Josh,

Great work figuring that out! We should definitely report this 
upstream to the MODS/MADS folks, but we maintain a local copy of the 
XSLT (altered to work without external file or network access for xml
includes) and can fix it locally.  I don't have time right now to 
jump on it, but both the file on the filesystem and the version in 
the config.xml_transform table in the db should be corrected.


Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro 
 wrote:

Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The error
message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children have 
been already added to the element.




I agree that it looks like the problem is when the xslt is 
processing the 755 and trying to set the authority source.




I think the bug may be that when processing the 755 tag on line 
1081, the genre template is called before the setAuthority 
template.  The Genre template adds child elements, then the 
setAuthority tries to set attributes, which is where the error pops 
up.




If I swap lines 1084 and 1085 then the error goes away and both the 
genre(155) and related genre(755) show up in the transformed xml.




I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all 
that confident that this is the issue though.  I would be happy to 
report this to the MODS listserv if it seems to make sense to 
someone that is more familiar with mods/mads/xml/authorities.




Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it 
is not actually a 155 field which causes the problem but a 755 
field. If it has any value in second indicator, xsltproc fails to 
process it. When the indicator does not have any value (or, to be 
more precise, there is just a space), it is okay.


So far, it seems that we will have to get rid either of the values 
of indicators in 755s, or of the following part of the XSL file:


 test="(700 = 
ancestor-or-self::marc:datafield/@tag and 
ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

 
 
 
 

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think the Authority ingest uses the 
MARC21slim2MADS.xsl transform file to convert the authority data 
into MADS format.  Could you try manually processing your problem 
authority record using the MADS file instead of the MODS and see 
what you get.




The MADS xsl does look like it references tag 155.



Josh Stompro - LARL IT Director



From: Open-ils-general
 On Behalf Of
Linda Jansova
Sent: Friday, October 26, 2018 5:29 AM
To: Evergre

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

[Linda Jansova]

Dear all,

We have updated the XSLT (with swapped lines 1084 and 1085 as Josh 
suggested) using the following command: 
http://git.evergreen-ils.org/?p=Evergreen.git;a=blob;f=Open-ILS/src/sql/Pg/955.data.MADS21-xsl.sql. 
Then we performed all steps that the upgrade from 2.12.6 to 3.1.4 
requires. Everything (including the reingest) has been completed 
successfully :-).


On Monday November 5th, I sent a message to MODS (MADS) mailing list 
regarding the troublesome lines in the XSLT file:


https://listserv.loc.gov/cgi-bin/wa?A2=MODS;fd3eba0f.1811

There is no response yet but I do hope that someone from the LC will 
eventually respond.


Linda

On 11/1/18 7:29 AM, Linda Jansova wrote:

Thank you, Josh!

We shall try and go through the reingest of all records and if no 
other XSLT-related issues appear, I can get in touch with MADS folks 
through their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:
Hello Mike, I've created a bug for this issue to get it in the 
queue.  LP#1800871


Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general 
 On Behalf Of 
Mike Rylander

Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 

Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority 
record with a 155 field


Hi Linda and Josh,

Great work figuring that out! We should definitely report this 
upstream to the MODS/MADS folks, but we maintain a local copy of the 
XSLT (altered to work without external file or network access for xml
includes) and can fix it locally.  I don't have time right now to 
jump on it, but both the file on the filesystem and the version in 
the config.xml_transform table in the db should be corrected.


Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro 
 wrote:

Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The error
message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children have 
been already added to the element.




I agree that it looks like the problem is when the xslt is 
processing the 755 and trying to set the authority source.




I think the bug may be that when processing the 755 tag on line 
1081, the genre template is called before the setAuthority 
template.  The Genre template adds child elements, then the 
setAuthority tries to set attributes, which is where the error pops up.




If I swap lines 1084 and 1085 then the error goes away and both the 
genre(155) and related genre(755) show up in the transformed xml.




I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all 
that confident that this is the issue though.  I would be happy to 
report this to the MODS listserv if it seems to make sense to 
someone that is more familiar with mods/mads/xml/authorities.




Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it 
is not actually a 155 field which causes the problem but a 755 
field. If it has any value in second indicator, xsltproc fails to 
process it. When the indicator does not have any value (or, to be 
more precise, there is just a space), it is okay.


So far, it seems that we will have to get rid either of the values 
of indicators in 755s, or of the following part of the XSL file:


 test="(700 = 
ancestor-or-self::marc:datafield/@tag and 
ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

 
 
 
 

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think the Authority ingest uses the 
MARC21slim2MADS.xsl transform file to convert the authority data 
into MADS format.  Could you try manually processing your problem 
authority record using the MADS file instead of the MODS and see 
what you get.




The MADS xsl does look like it references tag 155.



Josh Stompro - LARL IT Director



From: Open-ils-general
 On Behalf Of
Linda Jansova
Sent: Friday, October 26, 2018 5:29 AM
To: Evergreen Discussion Group
; Evergreen Development
Discussion List 
Subject: [OPEN-ILS-GENERAL] Cannot save authority record with a 155
field



Hi,

back in August we started investigating wh

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record with a 155 field

[Linda Jansova]

Thank you, Josh!

We shall try and go through the reingest of all records and if no other 
XSLT-related issues appear, I can get in touch with MADS folks through 
their listserv and report the error.


Linda

On 10/31/18 4:59 PM, Josh Stompro wrote:

Hello Mike, I've created a bug for this issue to get it in the queue.  
LP#1800871

Josh Stompro - LARL IT Director


-Original Message-
From: Open-ils-general  On 
Behalf Of Mike Rylander
Sent: Wednesday, October 31, 2018 10:09 AM
To: Evergreen Development Discussion List 

Cc: Evergreen Discussion Group 
Subject: Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Cannot save authority record 
with a 155 field

Hi Linda and Josh,

Great work figuring that out! We should definitely report this upstream to the 
MODS/MADS folks, but we maintain a local copy of the XSLT (altered to work 
without external file or network access for xml
includes) and can fix it locally.  I don't have time right now to jump on it, 
but both the file on the filesystem and the version in the config.xml_transform 
table in the db should be corrected.

Thanks!
--
Mike Rylander
  | Executive Director
  | Equinox Open Library Initiative
  | phone:  1-877-OPEN-ILS (673-6457)
  | email:  mi...@equinoxinitiative.org
  | web:  http://equinoxinitiative.org

On Wed, Oct 31, 2018 at 10:58 AM Josh Stompro  
wrote:

Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The error
message is



runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children have been 
already added to the element.



I agree that it looks like the problem is when the xslt is processing the 755 
and trying to set the authority source.



I think the bug may be that when processing the 755 tag on line 1081, the genre 
template is called before the setAuthority template.  The Genre template adds 
child elements, then the setAuthority tries to set attributes, which is where 
the error pops up.



If I swap lines 1084 and 1085 then the error goes away and both the genre(155) 
and related genre(755) show up in the transformed xml.



I think the way to report this to the MADS project is via the MODS
listserv, as listed on http://www.loc.gov/standards/mads/



I don’t have enough experience with these technologies to be all that confident 
that this is the issue though.  I would be happy to report this to the MODS 
listserv if it seems to make sense to someone that is more familiar with 
mods/mads/xml/authorities.



Josh Stompro - LARL IT Director



From: Linda Jansova 
Sent: Wednesday, October 31, 2018 7:16 AM
To: Evergreen Discussion Group
; Josh Stompro
; Evergreen Development Discussion List

Subject: Re: [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field



Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it is not 
actually a 155 field which causes the problem but a 755 field. If it has any 
value in second indicator, xsltproc fails to process it. When the indicator 
does not have any value (or, to be more precise, there is just a space), it is 
okay.

So far, it seems that we will have to get rid either of the values of 
indicators in 755s, or of the following part of the XSL file:


 
 
 
 

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think the Authority ingest uses the MARC21slim2MADS.xsl 
transform file to convert the authority data into MADS format.  Could you try 
manually processing your problem authority record using the MADS file instead 
of the MODS and see what you get.



The MADS xsl does look like it references tag 155.



Josh Stompro - LARL IT Director



From: Open-ils-general
 On Behalf Of
Linda Jansova
Sent: Friday, October 26, 2018 5:29 AM
To: Evergreen Discussion Group
; Evergreen Development
Discussion List 
Subject: [OPEN-ILS-GENERAL] Cannot save authority record with a 155
field



Hi,

back in August we started investigating why we couldn't proceed with upgrade 
from 2.12.6 to 3.1.4 (for more details please see 
http://libmail.georgialibraries.org/pipermail/open-ils-general/2018-August/015298.html).

After removing obviously invalid MARCXML records (which surprisingly made their 
way to our 2.12 installation) we still have some records which cannot be 
reingested (or saved).

Attached is a sample record americke_romany.xml which is one of those 
troublesome ones. It is a genre/form term record with the main heading in the 
field 155.

We have tried the SQL upgrade from 2.12.6 to 3.0.0 without authority records 
reingest (the particular lines were commented out) and, once we were at 3.1.4, 
used the web client to save this particular record (without actually making any 
changes in it). However, it appeared that it could not be saved:

---

open-ils.pcrud 2018-10-26 09:33

Re: [OPEN-ILS-GENERAL] Cannot save authority record with a 155 field

[Linda Jansova]

Thank you, Josh! Just tried removing the line you have mentioned 
() and I can confirm that it 
works :-)!


Linda

On 10/31/18 2:48 PM, Josh Stompro wrote:


Linda, I just noticed that the setAuthority template is called from 
the genre template also.  So it also works to just remove the call to 
setAuthority at line 1085.


Josh Stompro - LARL IT Director

*From:*Josh Stompro
*Sent:* Wednesday, October 31, 2018 8:23 AM
*To:* Linda Jansova ; Evergreen Discussion Group 
; Evergreen Development 
Discussion List 
*Subject:* RE: [OPEN-ILS-GENERAL] Cannot save authority record with a 
155 field


Linda, I wonder if this is a bug in the MARCslim2MADS.xslt?  The error 
message is


runtime error: file ./MARC21slim2MADS.xsl line 1404 element attribute

xsl:attribute: Cannot add attributes to an element if children have 
been already added to the element.


I agree that it looks like the problem is when the xslt is processing 
the 755 and trying to set the authority source.


I think the bug may be that when processing the 755 tag on line 1081, 
the genre template is called before the setAuthority template.  The 
Genre template adds child elements, then the setAuthority tries to set 
attributes, which is where the error pops up.


If I swap lines 1084 and 1085 then the error goes away and both the 
genre(155) and related genre(755) show up in the transformed xml.


I think the way to report this to the MADS project is via the MODS 
listserv, as listed on http://www.loc.gov/standards/mads/


I don’t have enough experience with these technologies to be all that 
confident that this is the issue though.  I would be happy to report 
this to the MODS listserv if it seems to make sense to someone that is 
more familiar with mods/mads/xml/authorities.


Josh Stompro - LARL IT Director

*From:*Linda Jansova mailto:skolk...@chello.cz>>
*Sent:* Wednesday, October 31, 2018 7:16 AM
*To:* Evergreen Discussion Group 
<mailto:open-ils-general@list.georgialibraries.org>>; Josh Stompro 
mailto:stomp...@exchange.larl.org>>; 
Evergreen Development Discussion List 
<mailto:open-ils-...@list.georgialibraries.org>>
*Subject:* Re: [OPEN-ILS-GENERAL] Cannot save authority record with a 
155 field


Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it is 
not actually a 155 field which causes the problem but a 755 field. If 
it has any value in second indicator, xsltproc fails to process it. 
When the indicator does not have any value (or, to be more precise, 
there is just a space), it is okay.


So far, it seems that we will have to get rid either of the values of 
indicators in 755s, or of the following part of the XSL file:


                test="(700 = ancestor-or-self::marc:datafield/@tag 
and ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

                
                    
                
            

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:

Hello Linda, I think the Authority ingest uses the
MARC21slim2MADS.xsl transform file to convert the authority data
into MADS format.  Could you try manually processing your problem
authority record using the MADS file instead of the MODS and see
what you get.

The MADS xsl does look like it references tag 155.

Josh Stompro - LARL IT Director

*From:* Open-ils-general

<mailto:open-ils-general-boun...@list.georgialibraries.org> *On
Behalf Of *Linda Jansova
*Sent:* Friday, October 26, 2018 5:29 AM
*To:* Evergreen Discussion Group

<mailto:open-ils-general@list.georgialibraries.org>; Evergreen
Development Discussion List

<mailto:open-ils-...@list.georgialibraries.org>
*Subject:* [OPEN-ILS-GENERAL] Cannot save authority record with a
155 field

Hi,

back in August we started investigating why we couldn't proceed
with upgrade from 2.12.6 to 3.1.4 (for more details please

seehttp://libmail.georgialibraries.org/pipermail/open-ils-general/2018-August/015298.html).


After removing obviously invalid MARCXML records (which
surprisingly made their way to our 2.12 installation) we still
have some records which cannot be reingested (or saved).

Attached is a sample record americke_romany.xml which is one of
those troublesome ones. It is a genre/form term record with the
main heading in the field 155.

We have tried the SQL upgrade from 2.12.6 to 3.0.0 without
authority records reingest (the particular lines were commented
out) and, once we were at 3.1.4, used the web client to save this
particular record (without actually making any changes in it).
However, it appeared that it could not be saved:

---

open-ils.pcrud 2018-10-26 09:33:37 [ERR
:49144:oils_sql.c:6570:15405352984867814] open-ils.pcrud ERROR
up

Re: [OPEN-ILS-GENERAL] Cannot save authority record with a 155 field

[Linda Jansova]

Dear Josh,

Thank you for letting me know about the right XSL file!

After some more investigations I have come to a conclusion that it is 
not actually a 155 field which causes the problem but a 755 field. If it 
has any value in second indicator, xsltproc fails to process it. When 
the indicator does not have any value (or, to be more precise, there is 
just a space), it is okay.


So far, it seems that we will have to get rid either of the values of 
indicators in 755s, or of the following part of the XSL file:


                test="(700 = ancestor-or-self::marc:datafield/@tag 
and ancestor-or-self::marc:datafield/@tag = 755 ) and @ind2='7'">

                
                    
                
            

Hopefully it will work for us and let us proceed in the upgrade :-)!

Linda

On 10/30/18 9:38 PM, Josh Stompro wrote:


Hello Linda, I think the Authority ingest uses the MARC21slim2MADS.xsl 
transform file to convert the authority data into MADS format.  Could 
you try manually processing your problem authority record using the 
MADS file instead of the MODS and see what you get.


The MADS xsl does look like it references tag 155.

Josh Stompro - LARL IT Director

*From:*Open-ils-general 
 *On Behalf Of 
*Linda Jansova

*Sent:* Friday, October 26, 2018 5:29 AM
*To:* Evergreen Discussion Group 
; Evergreen Development 
Discussion List 
*Subject:* [OPEN-ILS-GENERAL] Cannot save authority record with a 155 
field


Hi,

back in August we started investigating why we couldn't proceed with 
upgrade from 2.12.6 to 3.1.4 (for more details please 
seehttp://libmail.georgialibraries.org/pipermail/open-ils-general/2018-August/015298.html). 



After removing obviously invalid MARCXML records (which surprisingly 
made their way to our 2.12 installation) we still have some records 
which cannot be reingested (or saved).


Attached is a sample record americke_romany.xml which is one of those 
troublesome ones. It is a genre/form term record with the main heading 
in the field 155.


We have tried the SQL upgrade from 2.12.6 to 3.0.0 without authority 
records reingest (the particular lines were commented out) and, once 
we were at 3.1.4, used the web client to save this particular record 
(without actually making any changes in it). However, it appeared that 
it could not be saved:


---

open-ils.pcrud 2018-10-26 09:33:37 [ERR 
:49144:oils_sql.c:6570:15405352984867814] open-ils.pcrud ERROR 
updating authority::record_entry object with id = 356: 56966976 
56966976: ERROR: runtime error: file unknown-55cee6a934f0 element 
attribute


xsl:attribute: Cannot add attributes to an element if children have 
been already added to the element.


at line 31.

CONTEXT: PL/Perl function "oils_xslt_process"

---

Using this error message, we began to suspect a XSLT transformation 
being the culprit. We have taken XSL files from Evergreen (those from 
http://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/xsl;h=68fd13ffb2ad01ef9ceacf9f18695f25d284df05;hb=HEAD). 
When they were used (xsltproc MARC21slim2MODS33.xsl 
americke_romany.xml > output.xml), the contents of the 155 field 
(which is a heading and therefore one of the most important parts of 
the record) was never included in the output (please see the attached 
output.xml file).


Then we used a web client again to change the 155 tag to the 100 tag 
(and deleted another possible troublesome tag 755). After making these 
changes, the record could be saved.


So the question is:

Where should we add the 155 field (probably in which of the XSLT 
files) to make sure those records can be saved (or of course reingested)?


Thank you in advance for any hints!

Linda

[OPEN-ILS-GENERAL] Cannot save authority record with a 155 field

[Linda Jansova]

Hi,

back in August we started investigating why we couldn't proceed with 
upgrade from 2.12.6 to 3.1.4 (for more details please 
seehttp://libmail.georgialibraries.org/pipermail/open-ils-general/2018-August/015298.html). 



After removing obviously invalid MARCXML records (which surprisingly 
made their way to our 2.12 installation) we still have some records 
which cannot be reingested (or saved).


Attached is a sample record americke_romany.xml which is one of those 
troublesome ones. It is a genre/form term record with the main heading 
in the field 155.


We have tried the SQL upgrade from 2.12.6 to 3.0.0 without authority 
records reingest (the particular lines were commented out) and, once we 
were at 3.1.4, used the web client to save this particular record 
(without actually making any changes in it). However, it appeared that 
it could not be saved:


---

open-ils.pcrud 2018-10-26 09:33:37 [ERR 
:49144:oils_sql.c:6570:15405352984867814] open-ils.pcrud ERROR updating 
authority::record_entry object with id = 356: 56966976 56966976: ERROR: 
runtime error: file unknown-55cee6a934f0 element attribute


xsl:attribute: Cannot add attributes to an element if children have been 
already added to the element.


at line 31.

CONTEXT: PL/Perl function "oils_xslt_process"

---

Using this error message, we began to suspect a XSLT transformation 
being the culprit. We have taken XSL files from Evergreen (those from 
http://git.evergreen-ils.org/?p=Evergreen.git;a=tree;f=Open-ILS/xsl;h=68fd13ffb2ad01ef9ceacf9f18695f25d284df05;hb=HEAD). 
When they were used (xsltproc MARC21slim2MODS33.xsl americke_romany.xml 
> output.xml), the contents of the 155 field (which is a heading and 
therefore one of the most important parts of the record) was never 
included in the output (please see the attached output.xml file).


Then we used a web client again to change the 155 tag to the 100 tag 
(and deleted another possible troublesome tag 755). After making these 
changes, the record could be saved.


So the question is:

Where should we add the 155 field (probably in which of the XSLT files) 
to make sure those records can be saved (or of course reingested)?


Thank you in advance for any hints!

Linda


http://www.w3.org/2001/XMLSchema-instance; xmlns="http://www.loc.gov/mods/v3; version="3.3" xsi:schemaLocation="http://www.loc.gov/mods/v3 http://www.loc.gov/standards/mods/v3/mods-3-2.xsd;>
  
  

  abn


  
  821.111(73)-31

  
ABA001

001108
20030527081312.0

356


  cze


  

http://www.w3.org/2001/XMLSchema-instance; xmlns="http://www.loc.gov/MARC21/slim; xsi:schemaLocation="http://www.loc.gov/MARC21/slim http://www.loc.gov/standards/marcxml/schema/MARC21slim.xsd;>
 nz  a22 n  4500

356

CONS

20030527081312.0

001108|n|anznnbabn   n a|a


(CZ PrNK)fd131796



ABA001

cze

ABA001



821.111(73)-31

MRF_2003



americké romány

fd131796



American fiction

eczenas



356

authority

Re: [OPEN-ILS-GENERAL] Google Books Preview in 3.1.4 not showing up

[Linda Jansova]

Hi,

accidentally, we have discovered the following pattern:

When one uses a link to the bib record which comes from the search 
results page, the preview does not show up, e.g.:


https://spok.jabok.cuni.cz/eg/opac/record/29456?query=krizov%C3%A1%20intervence%20%C5%A1patenkov%C3%A1;qtype=keyword;locg=1;detail_record_view=0

However, when permalink (without all those search parameters) is used, 
the preview does show up:


https://spok.jabok.cuni.cz/eg/opac/record/29456?locg=1

I have been trying to verify whether it also occurs in other Evergreen 
installations. It seems that demo servers 
(https://wiki.evergreen-ils.org/doku.php?id=community_servers) do not 
have the previews switched on.


So I tried a couple of live systems and have found out that Laurentian 
probably uses at least 3.1.0 because one can see search terms being 
highlighted. The Google Books previews rewrite has been introduced in 
3.0 (http://docs.evergreen-ils.org/3.0/_public_catalog_2.html), so if 
Laurentian also uses it (and it is, indeed, the case) it would also use 
the rewritten code for the previews.


It follows the same pattern like the one we have discovered in our 
system, e.g.:


https://laurentian.concat.ca/eg/opac/record/3138661?locg=105 - the 
preview shows up


https://laurentian.concat.ca/eg/opac/record/911755?query=boudica;qtype=keyword;locg=105;detail_record_view=1 
- the preview fails to show up


Is there anybody else using Google Books previews? Could you help 
confirm if it also looks like described above? If so, I would report it 
as a bug...


Thank you!

Linda

On 08/31/2018 08:47 AM, Linda Jansova wrote:


Hi,

We have been trying to set up Google Books Preview in our 3.1.4 
installations. We have followed instructions from 
http://docs.evergreen-ils.org/reorg/3.1/command_line_admin/_customizing_templates.html 
– changed ctx.google_books_preview = 0; to ctx.google_books_preview = 
1; in parts/config.tt2 (which – judging by other examples in the same 
config file – should be okay).


When testing whether changed configuration actually changed anything, 
we used examples of bib records about which we were sure they had a 
preview in Google Books.


We have also restarted Evergreen (including memcached) but to no avail.

Is there anything else that needs to be set up (apart from setting 
ctx.google_books_preview to 1 instead of 0)? Or anything else we might 
have overlooked?


Thank you for any hints!

Linda

[OPEN-ILS-GENERAL] Google Books Preview in 3.1.4 not showing up

[Linda Jansova]

Hi,

We have been trying to set up Google Books Preview in our 3.1.4 
installations. We have followed instructions from 
http://docs.evergreen-ils.org/reorg/3.1/command_line_admin/_customizing_templates.html 
– changed ctx.google_books_preview = 0; to ctx.google_books_preview = 1; 
in parts/config.tt2 (which – judging by other examples in the same 
config file – should be okay).


When testing whether changed configuration actually changed anything, we 
used examples of bib records about which we were sure they had a preview 
in Google Books.


We have also restarted Evergreen (including memcached) but to no avail.

Is there anything else that needs to be set up (apart from setting 
ctx.google_books_preview to 1 instead of 0)? Or anything else we might 
have overlooked?


Thank you for any hints!

Linda

Re: [OPEN-ILS-GENERAL] Reminder: Student Success Working Group

[Linda Jansova]

Hi,

Although I have not used it myself yet, I do believe you can batch 
import patron records to Evergreen using SQL scripts such as those 
available from the official documentation: 
http://docs.evergreen-ils.org/3.1/_creating_an_sql_script_for_importing_patrons.html.


Linda

On 06/25/2018 05:40 PM, Bianca Parisi wrote:

Hi--

Could we please add importing batch student (patron) records to Evergreen to 
the agenda? Curious to see what other institutions are doing. We have an 
automated process at the college that we need rethink/redevelop.

Thanks,
Bianca

Bianca Parisi, MLIS
Libraries and Learning Commons Technology Coordinator

Niagara College, Welland Campus Library
100 Niagara College Blvd. Welland, ON L3C 7L3
(905) 735-2211 ext.7404
http://nclibraries.niagaracollege.ca/library
bpar...@niagaracollege.ca


-Original Message-
From: Open-ils-general  On 
Behalf Of Jane Sandberg
Sent: Monday, June 25, 2018 10:59 AM
To: Evergreen Discussion Group 
Subject: Re: [OPEN-ILS-GENERAL] Reminder: Student Success Working Group

Hi colleagues,

One last reminder about today's Student Success Working Group meeting.
We'll talk about citations, course reserves, and the Web client.

It will be held at 10am Pacific / 11am Mountain / 12pm Central / 1pm Eastern on 
the Zoom platform.  You can use this link to access the
meeting: https://linnbenton.zoom.us/j/938431327.  You can also access the 
meeting via phone.

An agenda is here:
https://wiki.evergreen-ils.org/doku.php?id=student_success_working_group:agenda_2018-06-25.
Please feel free to add to it, or to let me know of additional topics you'd 
like to discuss.

Student Success Working Group meetings are open to everybody, and have a 
particular focus on libraries that serve students at the primary, secondary, 
and post-secondary levels.


On Tue, Jun 19, 2018 at 7:36 AM, Jane Sandberg  wrote:

Hi colleagues,

The Evergreen Student Success Working Group will hold its next meeting
on Monday, 25 June.

It will be held at 10am Pacific / 11am Mountain / 12pm Central / 1pm
Eastern on the Zoom platform.  You can use this link to access the
meeting: https://linnbenton.zoom.us/j/938431327.  You can also access
the meeting via phone.

An agenda is here:
https://wiki.evergreen-ils.org/doku.php?id=student_success_working_group:agenda_2018-06-25.
Please feel free to add to it, or to let me know of additional topics
you'd like to discuss.

Student Success Working Group meetings are open to everybody, and have
a particular focus on libraries that serve students at the primary,
secondary, and post-secondary levels.


   -Jane

--
Jane Sandberg
Electronic Resources Librarian
Linn-Benton Community College
sand...@linnbenton.edu / 541-917-4655
Pronouns: she/her/hers



--
Jane Sandberg
Electronic Resources Librarian
Linn-Benton Community College
sand...@linnbenton.edu / 541-917-4655
Pronouns: she/her/hers

Re: [OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Evergreen Community Bug Squashing Week: May 21-25

[Linda Jansova]

Hi Terran (and Kathy),

Is there still a chance to get a sandbox localized to Czech for the Bug 
Squashing Week?


Apart from testing localized interfaces as such we would like to 
investigate (when comparing Czech sandbox with other sandboxes already 
provided) whether it might be Czech localization that prevents the 
reports interface to load properly. We are currently testing 3.1.1 on 
our server with our data and settings and it would be great if we could 
compare it to the sandbox.


Thank you in advance!

Linda

On 05/17/2018 09:31 PM, Cerninakova Eva wrote:

Hi Terran,

I wonder, if it would be possible again to provide sandbox localized to 
Czech for the Bug Squashing Week for me. We are currently testing issues 
concerning localization on our test server running Evergreen 3.1.1. 
However, localized sandbox (if available) would be useful to make sure 
that  test results are not twisted by our data or server settings.


Thanks
Eva





 
	Bez virů. www.avg.com 
 



<#m_2252515992254561395_m_-6558524500834925474_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>






---
Mgr. Eva Cerniňáková
cer...@jabok.cz 
Tel. +420 211 222 409

Knihovna Jabok
http:/knihovna.jabok.cz 
Tel.  +420 211 222 410
Jabok - Vyšší odborná škola sociálně pedagogická a teologická
Salmovská 8, 120 00 Praha 2


2018-05-15 3:19 GMT+02:00 Terran McCanna >:


Hello everyone,

Our next community-wide Bug Squashing Week is scheduled for *Monday,
May 21 through Friday, May 25*

(Don't worry, you don't need to set aside the entire week to
participate - you can participate however much that you can fit into
your schedule.)

You may participate in Bug Squashing Day by:

- Submitting new bug fixes for reported bugs
- Testing bug fixes that others have submitted (these should have
the "pullrequest" tag)
- Confirming bug reports that haven't been reviewed yet (this is a
great way to participate if you're not a coder!)
- Pushing bug fixes into Evergreen (for core committers)
- Assisting with documentation updates

Bug Squashing Day Info and Guidelines:
http://wiki.evergreen-ils.org/doku.php?id=dev:bug_squashing


If you would like to request a sandbox to test bug fixes on please
fill out the this form:
http://bit.ly/2tMCXiD


Please let me know if you have any questions.

Thank you!

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150


Atlanta, GA 30345



404-235-7138
tmcca...@georgialibraries.org 

Re: [OPEN-ILS-GENERAL] Evergreen as OAI-PMH provider - any plans?

[Linda Jansova]

It would be great if the code was integrated into Evergreen master! I 
have been searching high and low and failed to come across the your code 
and some others who may be interested in using it might find themselves 
in exactly the same situation.


Erhan, there is a dokuwiki page that details how to contribute code: 
https://wiki.evergreen-ils.org/doku.php?id=contributing. Maybe it will 
be helpful (especially in case you have not contributed code yet).


A side note - we have developed a module to pull external content from 
our Czech provider and also shared it with the community 
(http://docs.evergreen-ils.org/3.0/_including_external_content_in_your_public_interface.html), 
meaning that now it is very easy for everyone interested to find it and 
virtually just switch it on :-).


Linda

On 10/30/2017 01:22 PM, Rogan Hamby wrote:
I think adding it as a feature in a future release would be a good 
thing.  While not a make or break feature it's a part of the open 
ecosystem that Evergreen users ten to adopt and certainly a welcome 
enhancement IMO.


Rogan Hamby

Data and Project Analyst

Equinox Open Library Initiative

phone:  1-877-OPEN-ILS (673-6457)

email:  ro...@equinoxinitiative.org

web: http://EquinoxInitiative.org

On Mon, Oct 30, 2017 at 8:08 AM, Erhan Tuskan <e...@iisg.nl 
<mailto:e...@iisg.nl>> wrote:


Hi Jason,

If you mean in terms of use and rights, no there is no reason,
maybe we can call it "thoughtlessness". As you can notice it is
just open source and it will be great if it the community embraces
it...

-Original Message-
From: Open-ils-general
[mailto:open-ils-general-boun...@list.georgialibraries.org
<mailto:open-ils-general-boun...@list.georgialibraries.org>] On
Behalf Of Jason Stephenson
Sent: maandag 30 oktober 2017 12:53
To: open-ils-general@list.georgialibraries.org
<mailto:open-ils-general@list.georgialibraries.org>
Subject: Re: [OPEN-ILS-GENERAL] Evergreen as OAI-PMH provider -
any plans?

Erhan,

Is there any reason that this has not been shared with the
community as a potential enhancement?

I think this would be a good feature for stock Evergreen to have,
and then your institution would not be solely responsible for
maintaining it.

Jason

On 10/30/2017 06:12 AM, Erhan Tuskan wrote:
> Dear all,
>
> The International Institute of Social History (IISH) in
Amsterdam has already developed an OAI-PMH service for Evergreen.
We have been using it for a long time.
>
> You can find here more information about the service:
>
>
https://github.com/IISH/Evergreen/blob/iish_master_rel_3_0_1/OAI2.md
<https://github.com/IISH/Evergreen/blob/iish_master_rel_3_0_1/OAI2.md>
>
> For further details you can also contact Lucien van Wouw
(l...@iisg.nl <mailto:l...@iisg.nl>)
>
> Best regards,
>
> Erhan Tuskan
>
>
>
> -Original Message-
> From: Open-ils-general
> [mailto:open-ils-general-boun...@list.georgialibraries.org
<mailto:open-ils-general-boun...@list.georgialibraries.org>] On Behalf
> Of Linda Jansova
> Sent: maandag 30 oktober 2017 8:28
> To: Evergreen Discussion Group
> <open-ils-general@list.georgialibraries.org
<mailto:open-ils-general@list.georgialibraries.org>>; Evergreen
Discussion
> Group <open-ils-general@list.georgialibraries.org
<mailto:open-ils-general@list.georgialibraries.org>>
> Subject: [OPEN-ILS-GENERAL] Evergreen as OAI-PMH provider - any
plans?
>
> Hi,
>
> We are just considering drafting a grant proposal to get funding
for adding OAI-PMH provider capability to Evergreen (possibly via
OpenSRF and a piece of software which would get data from
Evergreen). If our proposal is accepted, then it is rather likely
that the project output would be ready by the end of 2018.
>
> Just a quick question before we proceed further - is there
anyone else
> also considering OAI-PMH provider development? (Just want to
make sure
> that we do not duplicate someone else's efforts.)
>
> Thank you in advance!
>
> Linda
>

Re: [OPEN-ILS-GENERAL] Evergreen as OAI-PMH provider - any plans?

[Linda Jansova]

Awsome! Thank you, Erhan! We shall definitely try it and probably also 
get in touch with Lucien :-)!


Linda

On 10/30/2017 11:12 AM, Erhan Tuskan wrote:

Dear all,

The International Institute of Social History (IISH) in Amsterdam has already 
developed an OAI-PMH service for Evergreen. We have been using it for a long 
time.

You can find here more information about the service:

https://github.com/IISH/Evergreen/blob/iish_master_rel_3_0_1/OAI2.md

For further details you can also contact Lucien van Wouw (l...@iisg.nl)

Best regards,

Erhan Tuskan



-Original Message-
From: Open-ils-general 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Linda 
Jansova
Sent: maandag 30 oktober 2017 8:28
To: Evergreen Discussion Group <open-ils-general@list.georgialibraries.org>; 
Evergreen Discussion Group <open-ils-general@list.georgialibraries.org>
Subject: [OPEN-ILS-GENERAL] Evergreen as OAI-PMH provider - any plans?

Hi,

We are just considering drafting a grant proposal to get funding for adding 
OAI-PMH provider capability to Evergreen (possibly via OpenSRF and a piece of 
software which would get data from Evergreen). If our proposal is accepted, 
then it is rather likely that the project output would be ready by the end of 
2018.

Just a quick question before we proceed further - is there anyone else also 
considering OAI-PMH provider development? (Just want to make sure that we do 
not duplicate someone else's efforts.)

Thank you in advance!

Linda

Re: [OPEN-ILS-GENERAL] Linking bibliographic records to non-LoC authorities using a support script

[Linda Jansova]

Just in case anybody else is trying to figure out something similar:

We have eventually tried testing LoC authority linking (and also Czech 
authority linking when the authorities have "n" or "z" thesaurus value 
in 008) and in this case the support script works okay :-). Actually, 
having the "n" or "z" value is even a bit more in line with MARC 
official specification (http://www.loc.gov/marc/authority/ad008.html) 
than using upper case characters 
(http://docs.evergreen-ils.org/2.12/_thesauri.html) - or any other 
characters than those mentioned in the MARC specification.


Linda

On 07/16/2017 05:09 PM, Václav Jansa wrote:

Hi Mike,
thanks for you rapid reply, and sorry for my slow reaction.
In past days I try some testing with minimal number of parameters (and 
some debug prints in script):
I tested, for simplicity, only on one bib record (TCN=5000), with 
known possible link in tag 100$7, to imported authority record


http://eg-test.osvobozena-knihovna.cz/eg/opac/record/5000?contains=contains;_special=1;detail_record_view=0;qtype=identifier%7Ctcn;query=5000;locg=1;expand=marchtml#marchtml 



  id  | creator | editor | source | quality | create_date   
|  edit_date   | active | deleted | 
fingerprint  | tcn_source | tcn_value | 
marc |  last_xact_id   | owner | share_depth

Re: [OPEN-ILS-GENERAL] Is MassLNC community demo server up?

[Linda Jansova]

Great to hear that!

Thank you for letting us know :-)!

Linda

On 09/12/2017 02:26 PM, Kathy Lussier wrote:


Hi all,

I'm happy to report that the demo server is back up again and is 
running 2.12.5. Access information is available at 
https://wiki.evergreen-ils.org/doku.php?id=community_servers.


Many thanks to Jason Stephenson of C/W MARS for getting it back in 
working order!


Kathy


On 08/28/2017 10:03 AM, Linda Jansova wrote:


Thank you, Kathy!

And yes, Equinox's demo server works okay!

Linda

On 08/28/2017 03:47 PM, Kathy Lussier wrote:


Hi,

Yes, the MassLNC demo server is down, and I don't have an estimated 
time on when we'll have it back up again. I'm going to remove the 
server's access information until we get the problem addressed.


It looks like Equinox's demo server at 
https://demo.evergreencatalog.com/ is up and running with 2.12.1.


Apologies for any inconvenience this may have caused!

Kathy


On 08/28/2017 12:51 AM, Linda Jansova wrote:


Thank you, Terran!

Linda

On 08/28/2017 01:04 AM, Terran McCanna wrote:

Yes, it's been down for a week or so.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org>


On Sun, Aug 27, 2017 at 7:04 AM, Linda Jansova <skolk...@chello.cz 
<mailto:skolk...@chello.cz>> wrote:


Hi,

just a quick check - is MassLNC community demo server up?

I have been trying to load https://mlnc2.noblenet.org/ and
also https://mlnc2.noblenet.org/eg/staff/home
<https://mlnc2.noblenet.org/eg/staff/home> (URLs are taken
from
https://wiki.evergreen-ils.org/doku.php?id=community_servers
<https://wiki.evergreen-ils.org/doku.php?id=community_servers>)
in my browser but nothing shows up...

Linda






--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter:http://www.twitter.com/kmlussier




--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter:http://www.twitter.com/kmlussier

Re: [OPEN-ILS-GENERAL] OpenSRF 2.5.1 released

[Linda Jansova]

Thank you, Galen! We shall definitely use it for testing 3.0!

At this moment I would like to suggest a little correction - the link 
from "release notes" in the release announcement 
(https://evergreen-ils.org/opensrf-2-5-1-released/) currently goes to 
https://evergreen-ils.org/documentation/release/OpenSRF/RELEASE_NOTES_2_5_0.html 
but should probably go to 
https://evergreen-ils.org/documentation/release/OpenSRF/RELEASE_NOTES_2_5_1.html 
instead.


Linda

On 09/11/2017 11:30 PM, Galen Charlton wrote:

Hi,

OpenSRF 2.5.1 is now available. 2.5.1 is a major bugfix release that
resolves a problem wherein messages could sometimes get dropped.  All
users of 2.5.0, including folks testing the Evergreen 3.0 beta
release, are advised to upgrade to 2.5.1 as soon as possible.

For additional information, please see the full release announcement at

https://evergreen-ils.org/opensrf-2-5-1-released/

Regards,

Galen

Re: [OPEN-ILS-GENERAL] Z39.50 import in 2.12.4 throws errors

[Linda Jansova]

We have already tried increasing the max_stanza_size and it works :-)! I 
have also added this comment to the bug we have reported: 
https://bugs.launchpad.net/evergreen/+bug/1713324.


Thank you once again, Dan!

Linda

On 08/28/2017 04:05 PM, Linda Jansova wrote:


Thank you, Dan! We shall definitely try changing the max_stanza_size 
and get back when we find out if it makes our Z39.50 searches work as 
usual!


Linda


On 08/28/2017 03:37 PM, Dan Scott wrote:

Hi Linda:

I have also added this comment to bug $ 1713324 - after our upgrade 
to 2.12.4 from 2.10, which included a reinstall on Ubuntu 16.04 and a 
new ejabberd configuration, we had failures when retrieving Z39.50 
searches with lots of records in the result set.


It looks like that problem was due to bug# 1709710 
<https://bugs.launchpad.net/bugs/1709710> "Default ejabberd 
max_stanza_size can be exceeded when chunking (MARC)XML-heavy 
responses". Can you check on your max_stanza_size and see if 
increasing that helps resolve the problems you're seeing? That will 
help confirm that bug.



On Sun, Aug 27, 2017 at 9:09 AM, Linda Jansova <skolk...@chello.cz 
<mailto:skolk...@chello.cz>> wrote:


An update on my previous post:

It may be a different issue as we have tested Z39.50 search
behavior in multiple Evergreen versions - full description has
been reported as a separate bug:
https://bugs.launchpad.net/evergreen/+bug/1713324
<https://bugs.launchpad.net/evergreen/+bug/1713324>. The last
version where the queries have been okay seems to be 2.12.1
(tested at http://demo.evergreencatalog.com/eg/staff/
<http://demo.evergreencatalog.com/eg/staff/>, i.e. via web client).

To conduct the tests we have been using stock Library of Congress
Z39.50 server settings.

Maybe some of the changes introduced in 2.12.2 are the reason for
this? Such as a fix that allows boolean fields to be recognized
in queries to the Z39.50 server?

The error appears when the result set is a bit large, it looks
like a timeout issue.

Linda

    On 08/18/2017 08:57 AM, Linda Jansova wrote:

I have discovered that it is probably an older issue that still
persists: https://bugs.launchpad.net/evergreen/+bug/1271559
<https://bugs.launchpad.net/evergreen/+bug/1271559>... Has
anybody come up with a working solution to this?

Linda

On 08/18/2017 08:02 AM, Linda Jansova wrote:

Hi,

We are on 2.12.4 and have been experiencing errors when trying
to import records using various fields such as title or author.
From the osrfsys.log it is clear that the records are actually
found but they fail to come up on the (either desktop or web
client) screen.

The error looks like this:

Network or server failure.  Please check your Internet
connection to 212.osvobozena-knihovna.cz
<http://212.osvobozena-knihovna.cz> and choose Retry Network. 
If you need to enter Offline Mode, choose Ignore Errors in this

and subsequent dialogs.  If you believe this error is due to a
bug in Evergreen and not network problems, please contact your
help desk or friendly Evergreen administrators, and give them
this information:
method=open-ils.search.z3950.search_class

params=["f7f979fe1172f27a598fd8d03feb530d",{"service_array":["NKC"],"username_array":[""],"password_array":[""],"limit":10,"offset":0,"search":{"author":"truhlik"},"service":["NKC"],"username":[""],"password":[""]}]

THROWN:
null
STATUS:

We are sure that there is no network failure (and we have been
experiencing these issues from two separate Evergreen
installations).

Any ideas what may be wrong?

Thanks in advance!

Linda

Re: [OPEN-ILS-GENERAL] Z39.50 import in 2.12.4 throws errors

[Linda Jansova]

Thank you, Dan! We shall definitely try changing the max_stanza_size and 
get back when we find out if it makes our Z39.50 searches work as usual!


Linda


On 08/28/2017 03:37 PM, Dan Scott wrote:

Hi Linda:

I have also added this comment to bug $ 1713324 - after our upgrade to 
2.12.4 from 2.10, which included a reinstall on Ubuntu 16.04 and a new 
ejabberd configuration, we had failures when retrieving Z39.50 
searches with lots of records in the result set.


It looks like that problem was due to bug# 1709710 
<https://bugs.launchpad.net/bugs/1709710> "Default ejabberd 
max_stanza_size can be exceeded when chunking (MARC)XML-heavy 
responses". Can you check on your max_stanza_size and see if 
increasing that helps resolve the problems you're seeing? That will 
help confirm that bug.



On Sun, Aug 27, 2017 at 9:09 AM, Linda Jansova <skolk...@chello.cz 
<mailto:skolk...@chello.cz>> wrote:


An update on my previous post:

It may be a different issue as we have tested Z39.50 search
behavior in multiple Evergreen versions - full description has
been reported as a separate bug:
https://bugs.launchpad.net/evergreen/+bug/1713324
<https://bugs.launchpad.net/evergreen/+bug/1713324>. The last
version where the queries have been okay seems to be 2.12.1
(tested at http://demo.evergreencatalog.com/eg/staff/
<http://demo.evergreencatalog.com/eg/staff/>, i.e. via web client).

To conduct the tests we have been using stock Library of Congress
Z39.50 server settings.

Maybe some of the changes introduced in 2.12.2 are the reason for
this? Such as a fix that allows boolean fields to be recognized in
queries to the Z39.50 server?

The error appears when the result set is a bit large, it looks
like a timeout issue.

Linda

    On 08/18/2017 08:57 AM, Linda Jansova wrote:

I have discovered that it is probably an older issue that still
persists: https://bugs.launchpad.net/evergreen/+bug/1271559
<https://bugs.launchpad.net/evergreen/+bug/1271559>... Has
anybody come up with a working solution to this?

Linda

On 08/18/2017 08:02 AM, Linda Jansova wrote:

Hi,

We are on 2.12.4 and have been experiencing errors when trying
to import records using various fields such as title or author.
From the osrfsys.log it is clear that the records are actually
found but they fail to come up on the (either desktop or web
client) screen.

The error looks like this:

Network or server failure.  Please check your Internet
connection to 212.osvobozena-knihovna.cz
<http://212.osvobozena-knihovna.cz> and choose Retry Network. 
If you need to enter Offline Mode, choose Ignore Errors in this

and subsequent dialogs.  If you believe this error is due to a
bug in Evergreen and not network problems, please contact your
help desk or friendly Evergreen administrators, and give them
this information:
method=open-ils.search.z3950.search_class

params=["f7f979fe1172f27a598fd8d03feb530d",{"service_array":["NKC"],"username_array":[""],"password_array":[""],"limit":10,"offset":0,"search":{"author":"truhlik"},"service":["NKC"],"username":[""],"password":[""]}]

THROWN:
null
STATUS:

We are sure that there is no network failure (and we have been
experiencing these issues from two separate Evergreen
installations).

Any ideas what may be wrong?

Thanks in advance!

Linda

Re: [OPEN-ILS-GENERAL] Is MassLNC community demo server up?

[Linda Jansova]

Thank you, Kathy!

And yes, Equinox's demo server works okay!

Linda

On 08/28/2017 03:47 PM, Kathy Lussier wrote:


Hi,

Yes, the MassLNC demo server is down, and I don't have an estimated 
time on when we'll have it back up again. I'm going to remove the 
server's access information until we get the problem addressed.


It looks like Equinox's demo server at 
https://demo.evergreencatalog.com/ is up and running with 2.12.1.


Apologies for any inconvenience this may have caused!

Kathy


On 08/28/2017 12:51 AM, Linda Jansova wrote:


Thank you, Terran!

Linda

On 08/28/2017 01:04 AM, Terran McCanna wrote:

Yes, it's been down for a week or so.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org>


On Sun, Aug 27, 2017 at 7:04 AM, Linda Jansova <skolk...@chello.cz 
<mailto:skolk...@chello.cz>> wrote:


Hi,

just a quick check - is MassLNC community demo server up?

I have been trying to load https://mlnc2.noblenet.org/ and also
https://mlnc2.noblenet.org/eg/staff/home
<https://mlnc2.noblenet.org/eg/staff/home> (URLs are taken from
https://wiki.evergreen-ils.org/doku.php?id=community_servers
<https://wiki.evergreen-ils.org/doku.php?id=community_servers>)
in my browser but nothing shows up...

Linda






--
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter:http://www.twitter.com/kmlussier

Re: [OPEN-ILS-GENERAL] Is MassLNC community demo server up?

[Linda Jansova]

Thank you, Terran!

Linda

On 08/28/2017 01:04 AM, Terran McCanna wrote:

Yes, it's been down for a week or so.

Terran McCanna
PINES Program Manager
Georgia Public Library Service
1800 Century Place, Suite 150
Atlanta, GA 30345
404-235-7138
tmcca...@georgialibraries.org <mailto:tmcca...@georgialibraries.org>


On Sun, Aug 27, 2017 at 7:04 AM, Linda Jansova <skolk...@chello.cz 
<mailto:skolk...@chello.cz>> wrote:


Hi,

just a quick check - is MassLNC community demo server up?

I have been trying to load https://mlnc2.noblenet.org/ and also
https://mlnc2.noblenet.org/eg/staff/home
<https://mlnc2.noblenet.org/eg/staff/home> (URLs are taken from
https://wiki.evergreen-ils.org/doku.php?id=community_servers
<https://wiki.evergreen-ils.org/doku.php?id=community_servers>) in
my browser but nothing shows up...

Linda

Re: [OPEN-ILS-GENERAL] Z39.50 import in 2.12.4 throws errors

[Linda Jansova]

An update on my previous post:

It may be a different issue as we have tested Z39.50 search behavior in 
multiple Evergreen versions - full description has been reported as a 
separate bug: https://bugs.launchpad.net/evergreen/+bug/1713324. The 
last version where the queries have been okay seems to be 2.12.1 (tested 
at http://demo.evergreencatalog.com/eg/staff/ 
<http://demo.evergreencatalog.com/eg/staff/>, i.e. via web client).


To conduct the tests we have been using stock Library of Congress Z39.50 
server settings.


Maybe some of the changes introduced in 2.12.2 are the reason for this? 
Such as a fix that allows boolean fields to be recognized in queries to 
the Z39.50 server?


The error appears when the result set is a bit large, it looks like a 
timeout issue.


Linda

On 08/18/2017 08:57 AM, Linda Jansova wrote:
I have discovered that it is probably an older issue that still 
persists: https://bugs.launchpad.net/evergreen/+bug/1271559... Has 
anybody come up with a working solution to this?


Linda

On 08/18/2017 08:02 AM, Linda Jansova wrote:

Hi,

We are on 2.12.4 and have been experiencing errors when trying to 
import records using various fields such as title or author. From the 
osrfsys.log it is clear that the records are actually found but they 
fail to come up on the (either desktop or web client) screen.


The error looks like this:

Network or server failure.  Please check your Internet connection to 
212.osvobozena-knihovna.cz and choose Retry Network.  If you need to 
enter Offline Mode, choose Ignore Errors in this and subsequent 
dialogs.  If you believe this error is due to a bug in Evergreen and 
not network problems, please contact your help desk or friendly 
Evergreen administrators, and give them this information:

method=open-ils.search.z3950.search_class
params=["f7f979fe1172f27a598fd8d03feb530d",{"service_array":["NKC"],"username_array":[""],"password_array":[""],"limit":10,"offset":0,"search":{"author":"truhlik"},"service":["NKC"],"username":[""],"password":[""]}] 


THROWN:
null
STATUS:

We are sure that there is no network failure (and we have been 
experiencing these issues from two separate Evergreen installations).


Any ideas what may be wrong?

Thanks in advance!

Linda

[OPEN-ILS-GENERAL] Is MassLNC community demo server up?

[Linda Jansova]

Hi,

just a quick check - is MassLNC community demo server up?

I have been trying to load https://mlnc2.noblenet.org/ and also 
https://mlnc2.noblenet.org/eg/staff/home (URLs are taken from 
https://wiki.evergreen-ils.org/doku.php?id=community_servers) in my 
browser but nothing shows up...


Linda

Re: [OPEN-ILS-GENERAL] Z39.50 import in 2.12.4 throws errors

[Linda Jansova]

I have discovered that it is probably an older issue that still 
persists: https://bugs.launchpad.net/evergreen/+bug/1271559... Has 
anybody come up with a working solution to this?


Linda

On 08/18/2017 08:02 AM, Linda Jansova wrote:

Hi,

We are on 2.12.4 and have been experiencing errors when trying to 
import records using various fields such as title or author. From the 
osrfsys.log it is clear that the records are actually found but they 
fail to come up on the (either desktop or web client) screen.


The error looks like this:

Network or server failure.  Please check your Internet connection to 
212.osvobozena-knihovna.cz and choose Retry Network.  If you need to 
enter Offline Mode, choose Ignore Errors in this and subsequent 
dialogs.  If you believe this error is due to a bug in Evergreen and 
not network problems, please contact your help desk or friendly 
Evergreen administrators, and give them this information:

method=open-ils.search.z3950.search_class
params=["f7f979fe1172f27a598fd8d03feb530d",{"service_array":["NKC"],"username_array":[""],"password_array":[""],"limit":10,"offset":0,"search":{"author":"truhlik"},"service":["NKC"],"username":[""],"password":[""]}] 


THROWN:
null
STATUS:

We are sure that there is no network failure (and we have been 
experiencing these issues from two separate Evergreen installations).


Any ideas what may be wrong?

Thanks in advance!

Linda

[OPEN-ILS-GENERAL] Z39.50 import in 2.12.4 throws errors

[Linda Jansova]

Hi,

We are on 2.12.4 and have been experiencing errors when trying to import 
records using various fields such as title or author. From the 
osrfsys.log it is clear that the records are actually found but they 
fail to come up on the (either desktop or web client) screen.


The error looks like this:

Network or server failure.  Please check your Internet connection to 
212.osvobozena-knihovna.cz and choose Retry Network.  If you need to 
enter Offline Mode, choose Ignore Errors in this and subsequent 
dialogs.  If you believe this error is due to a bug in Evergreen and not 
network problems, please contact your help desk or friendly Evergreen 
administrators, and give them this information:

method=open-ils.search.z3950.search_class
params=["f7f979fe1172f27a598fd8d03feb530d",{"service_array":["NKC"],"username_array":[""],"password_array":[""],"limit":10,"offset":0,"search":{"author":"truhlik"},"service":["NKC"],"username":[""],"password":[""]}]
THROWN:
null
STATUS:

We are sure that there is no network failure (and we have been 
experiencing these issues from two separate Evergreen installations).


Any ideas what may be wrong?

Thanks in advance!

Linda

[OPEN-ILS-GENERAL] MARC Edit screen in staff client - adding a field to context menu for authority-populated bib records

[Linda Jansova]

Hi,

Just a quick question:

Is there a way to add a field to a context menu which is displayed when 
one uses MARC Edit screen (in desktop staff client) and right-clicks on 
a bib record field which uses authority data? When one right-clicks on 
author's name, a context menu with suitable authority records appears. 
If a particular authority record is previewed, fields such as 100 show 
up. Could another field (such as 678 which contains biographical data 
and could be used for disambiguation) be displayed in this context menu?


Maybe something like a tag-tables service 
(http://docs.evergreen-ils.org/2.10/_cataloging_3.html) and "values 
supplied by the tag-table service are used to populate values in context 
menus in the web staff client MARC editor" in particular could be used 
for this purpose?


(Currently we are using 2.10.7 and are interested in this feature either 
for desktop or web staff client.)


Thank you for any hints!

Linda

Re: [OPEN-ILS-GENERAL] Record webpage and programming documentation?

[Linda Jansova]

Hi,

Just to let you know - our programmer has eventually come up with a 
workaround which we think may be useful for others and so we are sharing 
our solution:


All characters in added content with ASCII code higher than 127 have 
been converted to HTML entities :-).


Linda

On 7.9.2016 08:37, Linda Jansova wrote:


Hi,

We are currently developing a module for pulling added content (book 
jackets, tables of contents etc.) from our local provider obalkyknih.cz.


In our programming endeavor we have come across an encoding issue 
which we have not been able to resolve so far. The thing is all 
textual added content gets messed up when shown on a record webpage. 
Our programmer has made a number of tests to make sure that the 
encoding does not go wrong in the module we are developing (a list of 
tests performed is available at 
https://bugs.launchpad.net/evergreen/+bug/1610678). We have also 
tested Open Library – when it comes to tables of contents with 
diacritics, it is also messed up.


To investigate the issue further, could anyone provide us with any 
hints as to:


 *

how (where) the record webpage actually pulls together?

 *

how AddedContent.pm methods (which provide the added content) are
called?

One more question – is there any developer documentation which would 
describe Evergreen architecture in more detail available?


BTW could our developer's hint that „interestingly on URL in form 
http://evergreen-server/opac/extras/ac/toc/html/r/23225 I could see 
toc in correct encoding“ be of any use? It seems to me that if we 
figured out what the differences between how data are processed for a 
record webpage and for the sample URL above, we could actually hit the 
nail on the head...


Thank you in advance for sharing any clues!

Linda

[OPEN-ILS-GENERAL] Record webpage and programming documentation?

[Linda Jansova]

Hi,

We are currently developing a module for pulling added content (book 
jackets, tables of contents etc.) from our local provider obalkyknih.cz.


In our programming endeavor we have come across an encoding issue which 
we have not been able to resolve so far. The thing is all textual added 
content gets messed up when shown on a record webpage. Our programmer 
has made a number of tests to make sure that the encoding does not go 
wrong in the module we are developing (a list of tests performed is 
available at https://bugs.launchpad.net/evergreen/+bug/1610678). We have 
also tested Open Library – when it comes to tables of contents with 
diacritics, it is also messed up.


To investigate the issue further, could anyone provide us with any hints 
as to:


 *

   how (where) the record webpage actually pulls together?

 *

   how AddedContent.pm methods (which provide the added content) are
   called?

One more question – is there any developer documentation which would 
describe Evergreen architecture in more detail available?


BTW could our developer's hint that „interestingly on URL in form 
http://evergreen-server/opac/extras/ac/toc/html/r/23225 I could see toc 
in correct encoding“ be of any use? It seems to me that if we figured 
out what the differences between how data are processed for a record 
webpage and for the sample URL above, we could actually hit the nail on 
the head...


Thank you in advance for sharing any clues!

Linda

[OPEN-ILS-GENERAL] Error when upgrading from 2.9.3 to 2.10.0

[Linda Jansova]

Hi,

We have been trying to upgrade Jabok Evergreen database from 2.8.2. We 
have successfully reached 2.9.3. When upgrading from 2.9.3 to 2.10.0, 
the following error has occured:


psql:version-upgrade/2.9.3-2.10.0-upgrade-db.sql:4578: ERROR: insert or 
update on table "usr_circ_history" violates foreign key constraint 
"usr_circ_history_target_copy_fkey"

DETAIL:  Key (target_copy)=(52644) is not present in table "copy".

The copy in question is a copy attached to a bib record representing a 
serial (http://www.jabok.cuni.cz/eg/opac/record/2154?locg=102). We tried 
to check it in and out and then we used the updated 2.8.2 database for 
another upgrade attempt.


This time we experienced the same error (but involving a different copy 
of the same serial):


psql:version-upgrade/2.9.3-2.10.0-upgrade-db.sql:4578: ERROR: insert or 
update on table "usr_circ_history" violates foreign key constraint 
"usr_circ_history_target_copy_fkey"

DETAIL:  Key (target_copy)=(57113) is not present in table "copy".

Could it be related to the bug fixed in 2.10.2 as described at 
https://evergreen-ils.org/documentation/release/RELEASE_NOTES_2_10.html#_evergreen_2_10_2 
(Fixes a bug where serials checkouts failed for users that track 
circulation history.)?


If so, what should we do to get rid of the error in our case when 2.10.2 
has not been reached yet (in the upgrade process)?


If not, any ideas what could have gone wrong?

Thank you in advance for any hints!

Linda

Re: [OPEN-ILS-GENERAL] Adding a new book covers module to Evergreen master

[Linda Jansova]

Hi Galen,

Thanks a lot for this overview - we shall definitely follow the 
recommended steps :-)!


Linda

On 17.3.2016 15:01, Galen Charlton wrote:

Hi,

On Thu, Mar 17, 2016 at 3:41 AM, Linda Jansova <skolk...@chello.cz> wrote:

We have been awarded a grant to create a module which would add book covers
from Czech provider http://obalkyknih.cz/ to Evergreen.

Congratulations!


However, as we have not submitted code yet, we are a bit unsure about which
steps should we take to have it included in the master. Could you please let
us know how it works or how we should proceed once our module is ready?

A guide to contributing to the Evergreen project can be found here:

http://wiki.evergreen-ils.org/doku.php?id=contributing

That's a lot to digest, of course; some initial steps I recommend you
take to get started are:

[1] File a bug on Launchpad (https://bugs.launchpad.net/evergreen)
with details about the proposed book cover integration. Set the bug's
importance to "Wishlist", as it will be a new feature.

[2] Read the instructions at
http://wiki.evergreen-ils.org/doku.php?id=dev:git and have whoever
will be writing the code submit their SSH public keys so that they can
push code to the Evergreen working Git repository.

[3] Have a look at the existing added content modules
(Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent.pm and
Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent/* in the source).

Regards,

Galen

[OPEN-ILS-GENERAL] Adding a new book covers module to Evergreen master

[Linda Jansova]

Hi,

We have been awarded a grant to create a module which would add book 
covers from Czech provider http://obalkyknih.cz/ to Evergreen. It would 
probably be similar to modules described at 
http://docs.evergreen-ils.org/2.9/_including_external_content_in_your_public_interface.html. 
At this moment we plan to focus on developing the module for Evergreen 2.9.


When the module is developed (in late summer or early fall this year at 
the latest), we would appreciate very much if the module could be added 
to Evergreen master.


However, as we have not submitted code yet, we are a bit unsure about 
which steps should we take to have it included in the master. Could you 
please let us know how it works or how we should proceed once our module 
is ready?


Thanks in advance for any advice!

Linda

Re: [OPEN-ILS-GENERAL] Adding a new book covers module to Evergreen master

[Linda Jansova]

That's definitely a good idea - I have just subscribed to the dev list 
and shall surely have a look at the chat :-)...


Linda

On 17.3.2016 15:20, Yamil Suarez wrote:

Linda,

Another suggestion is to look at logs of previous developer meetings
that happen on IRC [1]. So you can see part of how new features end up
being accepted into EG. For example, you will see how the "wishlist"
Launchpad bug will be shared, and folks will give constructive
criticism on IRC or in the comments of the Launchpad bug. Eventually
as the code gets improved with the developer feedback it will be
(hopefully) accepted by the core committers into EG. Of course some of
this communication also happens in the developer mailing list, so I
recommend you subscribe to it too.

Good luck,
Yamil

[1] 
http://wiki.evergreen-ils.org/doku.php?id=dev:meetings[]=developer[]=meetings











Yamil Suarez, MCS
Library Systems Administrator/Developer

Stan Getz Library
Berklee College of Music
1140 Boylston St
Boston, MA 02215

ysua...@berklee.edu
617-747-2617


On Thu, Mar 17, 2016 at 10:13 AM, Linda Jansova <skolk...@chello.cz> wrote:

Thank you, Yamil! We will surely come up with some questions in the process
:-)...

Linda


On 17.3.2016 15:07, Yamil Suarez wrote:

Hello,

First of all, Galen that was a great summary. Linda, feel free to ask
more question about the process of contributing code on this list
(general list) or on the developer list. Also you can chat with
members of the community, including developers, on the Evergreen IRC
channel.

Good luck,
Yamil










Yamil Suarez, MCS
Library Systems Administrator/Developer

Stan Getz Library
Berklee College of Music
1140 Boylston St
Boston, MA 02215

ysua...@berklee.edu
617-747-2617


On Thu, Mar 17, 2016 at 10:01 AM, Galen Charlton <g...@esilibrary.com>
wrote:

Hi,

On Thu, Mar 17, 2016 at 3:41 AM, Linda Jansova <skolk...@chello.cz>
wrote:

We have been awarded a grant to create a module which would add book
covers
from Czech provider http://obalkyknih.cz/ to Evergreen.

Congratulations!


However, as we have not submitted code yet, we are a bit unsure about
which
steps should we take to have it included in the master. Could you please
let
us know how it works or how we should proceed once our module is ready?

A guide to contributing to the Evergreen project can be found here:

http://wiki.evergreen-ils.org/doku.php?id=contributing

That's a lot to digest, of course; some initial steps I recommend you
take to get started are:

[1] File a bug on Launchpad (https://bugs.launchpad.net/evergreen)
with details about the proposed book cover integration. Set the bug's
importance to "Wishlist", as it will be a new feature.

[2] Read the instructions at
http://wiki.evergreen-ils.org/doku.php?id=dev:git and have whoever
will be writing the code submit their SSH public keys so that they can
push code to the Evergreen working Git repository.

[3] Have a look at the existing added content modules
(Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent.pm and
Open-ILS/src/perlmods/lib/OpenILS/WWW/AddedContent/* in the source).

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

Re: [OPEN-ILS-GENERAL] Z39.50 server indexes?

[Linda Jansova]

Hi,

I have been trying to resolve the Z39.50 encoding mystery and two more 
questions have emerged in the process:


1) What actually happens in Evergreen when one submits a yaz query like 
find matoušek (via Z39.50)?


From config.index_normalizer (and also from 
http://wiki.evergreen-ils.org/doku.php?id=documentation:indexing) it is 
clear that during indexing diacritics are thrown away (Strip Diacritics 
- Convert text to NFD form and remove non-spacing combining marks.). I 
would then assume that similar normalization would be performed on OPAC 
(or staff client) queries to make sure strings from indexes and from 
queries have a chance to meet. Is it also the case of Z39.50 queries?


2) How does this process differ from what happens when one searches a 
specific field (or index), such as author or title?


Apart from our (Jabok) catalog I have also tried to send a query to 
Laurentian Univesity catalog (using access information from 
http://irspy.indexdata.com/ap.html?id=Z39.50:laurentian.concat.ca:210/OSUL=bib-1). 
It works okay when no search fields such as author or title are 
specified but when they are, it only works okay for queries without 
diacritics:


Z> open laurentian.concat.ca:210/OSUL
Connecting...OK.
Sent initrequest.
Connection accepted by v3 target.
ID : 81/81
Name   : Simple2ZOOM Universal Gateway/GFS/YAZ
Version: 1.04/5.15.2 738b345708b245e67cded6d917393a80b5bd4eca
Options: search present delSet triggerResourceCtrl scan sort namedResultSets
Elapsed: 0.990590
Z> find @attr 1=21 francais
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 7879, setno 1
records returned: 0
Elapsed: 7.993394
Z> find @attr 1=21 français
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 0, setno 2
records returned: 0
Elapsed: 1.658774

So it is not probably just our issue...

Linda

On 24.2.2016 07:50, Linda Jansova wrote:


Hi,

We have still haven't sorted out our Z39.50 server encoding issues but 
hopefully have made some steps which may help us locate and solve the 
problem. (We currently work with Evergreen 2.8.3.)


Problem summary:

When querying our Z39.50 server (mojzis.jabok.cuni.cz:/Jabok) via 
yaz, query find matoušek works okay, so does query find @attr 1=1016 
Matousek. But with find @attr 1=1016 Matoušek zero number of hits is 
returned.


When searching directly via SRU (in our case 
http://mojzis.jabok.cuni.cz/opac/extras/sru) all queries (with the 
exception of find dc.creator=matoušek) seem to work okay, e.g. find 
eg.author=matoušek reports 32 hits.


A more detailed view:

We have been digging into this for quite some time now (our previous 
posts are available at 
https://www.mail-archive.com/open-ils-general@list.georgialibraries.org/msg7.html 
and<https://www.mail-archive.com/open-ils-general%40list.georgialibraries.org/msg11442.html>https://www.mail-archive.com/open-ils-general%40list.georgialibraries.org/msg11442.html). 



We have also tried to get in touch with the yaz community 
(http://lists.indexdata.dk/pipermail/yazlist/2016-February/004159.html). 
They have advised us to have a look at the indexes.


We have had a look at the config.z3950_index_field_map. It looks like 
this in our installation:


id | label | metabib_field | record_attr | z3950_attr | z3950_attr_type

+---+---+-++-

1 | Title | 5 | | | title

2 | Author | 8 | | | author

3 | ISBN | 18 | | | isbn

4 | ISSN | 19 | | | issn

5 | LCCN | 30 | | | lccn

6 | Pubdate | | pubdate | | pubdate

7 | Item Type | | item_type | | item_type

(7 rows)

But we are not sure whether it is a configuration related to Evergreen 
Z39.50 server or to Evergreen Z39.50 client. If it is a server 
configuration, is everything included or are some data missing?


Our current dgo.conf looks like this:





http://mojzis.jabok.cuni.cz/opac/extras/sru

get

utf-8



cql

eg.title

eg.keyword

eg.keyword

eg.subject

eg.author

eg.publisher

eg.keyword

eg.keyword







But where are the indexes actually defined? Is it in the 
config.metabib_field table?

(Our current config.metabib_field table is attached to this message.)

Any hints that could help us have our Z39.50 server work as expected 
are more than welcome!


Thank you in advance!

Linda

[OPEN-ILS-GENERAL] Z39.50 server indexes?

[Linda Jansova]

Hi,

We have still haven't sorted out our Z39.50 server encoding issues but 
hopefully have made some steps which may help us locate and solve the 
problem. (We currently work with Evergreen 2.8.3.)


Problem summary:

When querying our Z39.50 server (mojzis.jabok.cuni.cz:/Jabok) via 
yaz, query find matoušek works okay, so does query find @attr 1=1016 
Matousek. But with find @attr 1=1016 Matoušek zero number of hits is 
returned.


When searching directly via SRU (in our case 
http://mojzis.jabok.cuni.cz/opac/extras/sru) all queries (with the 
exception of find dc.creator=matoušek) seem to work okay, e.g. find 
eg.author=matoušek reports 32 hits.


A more detailed view:

We have been digging into this for quite some time now (our previous 
posts are available at 
https://www.mail-archive.com/open-ils-general@list.georgialibraries.org/msg7.html 
andhttps://www.mail-archive.com/open-ils-general%40list.georgialibraries.org/msg11442.html). 



We have also tried to get in touch with the yaz community 
(http://lists.indexdata.dk/pipermail/yazlist/2016-February/004159.html). 
They have advised us to have a look at the indexes.


We have had a look at the config.z3950_index_field_map. It looks like 
this in our installation:


id | label | metabib_field | record_attr | z3950_attr | z3950_attr_type

+---+---+-++-

1 | Title | 5 | | | title

2 | Author | 8 | | | author

3 | ISBN | 18 | | | isbn

4 | ISSN | 19 | | | issn

5 | LCCN | 30 | | | lccn

6 | Pubdate | | pubdate | | pubdate

7 | Item Type | | item_type | | item_type

(7 rows)

But we are not sure whether it is a configuration related to Evergreen 
Z39.50 server or to Evergreen Z39.50 client. If it is a server 
configuration, is everything included or are some data missing?


Our current dgo.conf looks like this:





http://mojzis.jabok.cuni.cz/opac/extras/sru

get

utf-8



cql

eg.title

eg.keyword

eg.keyword

eg.subject

eg.author

eg.publisher

eg.keyword

eg.keyword







But where are the indexes actually defined? Is it in the 
config.metabib_field table?

(Our current config.metabib_field table is attached to this message.)

Any hints that could help us have our Z39.50 server work as expected are 
more than welcome!


Thank you in advance!

Linda

 id | field_class | name |label|
   xpath
| weight | format  | search_field | facet_field | facet_xpath   
   | browse_field | browse_xpath | restrict | authority_xpath | 
 browse_sort_xpath   | joiner 
+-+--+-+++-+--+-+--+--+--+--+-+--+
 16 | subject | complete | All Subjects| 
//mods32:mods/mods32:subject
   |  1 | mods32  | t| f   |
  | f|  | f|
 |  | 
 17 | identifier  | accession| Accession Number| 
//marc:controlfield[@tag='001'] 
   |  1 | marcxml | t| f   |
  | f|  | f|
 |  | 
 18 | identifier  | isbn | ISBN| 
//marc:datafield[@tag='020']/marc:subfield[@code='a' or @code='z']  
   |  1 | marcxml | t| f   |
  | f|  | f|
 |  | 
 19 | identifier  | issn | ISSN| 
//marc:datafield[@tag='022']/marc:subfield[@code='a' or @code='z']  
   |  1 | marcxml | t| f   |
  | f|  | f|
 |  | 
 26 | identifier  | tcn  | Title Control Number| 
//marc:datafield[@tag='901']/marc:subfield[@code='a']   
   |  1 | marcxml | t| f   |
  | f|  | f|
 |  | 
 27 | identifier  | bibid| Internal ID | 
//marc:datafield[@tag='901']/marc:subfield[@code='c']   
   |  1 | 

Re: [OPEN-ILS-GENERAL] Bulk deletion of authority records from Evergreen database?

[Linda Jansova]

Dear Yamil,

Thanks a lot for sharing the approach with setting authority records' 
status to deleted! We have just used it on our test server and so far it 
seems it would work for us :-)!


As we only had a handful of authority records attached to bibs, we have 
used the following simple SQL statement:


UPDATE authority.record_entry SET active='F', deleted='T' WHERE id<>7347 
AND id<>11 AND id<>1 AND id<>9 AND id<>10;


Thank you once again, you have saved us quite some work when we would 
otherwise have to merge records!


Linda

On 29.10.2015 15:24, Yamil Suarez wrote:

Linda,

I have some experience with authorities, though I did not write any of
the underlying code so I hope others chime in. My uneducated
impression that I have so far is that within the database authorities
records share a lot of the design of of bib records.

For example, the main table for bib records and auths are both called
"record_entry" though they have their own separate DB schema
(authority.record_entry v.s. biblio.record_entry).

Therefore one approach to batch delete authorities is to use SQL to
set the authority.record_entry boolean column "deleted" to a value of
"true." I have seen this approach taken with bibs, though of course in
this approach "deleted = true" the bib or authority record is not
actually destroyed but just hidden from view.

I would want to hear from someone else to see if there are other
authority tables that should be updated too for this "deleted"
approach or perhaps this is good enough.

Also, at this point I do not know how to write a SQL code that would
only list authorities that have not been linked, so that you only
delete the ones you want.

Of course there is a way with SQL to actually erase/destroy the
authority records, but I would first want to hear from others if there
are additional authority related tables/rows (besides
authority.record_entry) that should also be deleted at the same time.
Therefore keeping your database free from unnecessary table rows. BTW,
one reason you see a lot of EG folks use the "deleted = true" approach
instead of completely erasing records is to guard against accidental
deletions, because this way you can easily undo a deletion.

Hope this helps, and if it does I can supply some sample SQL code to
get you started.

Good luck,
Yamil












On Thu, Oct 29, 2015 at 2:31 AM, Linda Jansova <skolk...@chello.cz> wrote:

Hi all,

We are on 2.8.2 and just trying to delete authority records that are not
attached to bib records (or even remove all authority records from our
database as a vast majority of these records have been imported by accident
when one import file was confused with another).

Any ideas how to perform this task safely?

Thank you in advance for any clues :-)!

Linda

Re: [OPEN-ILS-GENERAL] Z39.50 client query encoding issues

[Linda Jansova]

Hi again,

We have installed a 2.8.3 and tested the Z39.50 server output, yet the 
problem with diacritics remains the same. Again, when submitting a 
generic query with diacritics (using yaz-client), we get the expected 
results, but when searching specifically for author, it results in no hits.


I have had a look at 
https://coffeecode.net/archives/217-More-granular-identifier-indexes-for-your-Evergreen-SRU-Z39.50-servers.html 
again and it seems to me that maybe the problem is caused by the fact 
that with the exception of keyword, each of the other indexes mentioned 
at Dan's blog (author, title, series, subject) is actually composed of 
more granular indexes.


Maybe I am on the wrong track but it seems to me that it would be rather 
a strange coincidence that keyword index (which I suppose the Z39.50 
client would use when no fields are specified) works fine unlike those 
other composed indexes...


Do you think that this could be the reason why we are experiencing the 
encoding problems? And if so, do you have any idea where to look for the 
appropriate encoding settings and change them to utf-8?


Thank you in advance for any clues to the puzzle!

Linda

On 08/19/2015 03:40 PM, Linda Jansova wrote:
Oh, I see! In that case we shall try the upgrade and see what happens 
(we shall keep you posted :-)...


Thank you for your help!

Linda

On 08/19/2015 03:34 PM, Jason Stephenson wrote:

Quoting Linda Jansova skolk...@chello.cz:


Thank you, Jason!

I have actually come across this bug as well but it seems that it 
has already been fixed (or at least this is my understanding of 
information from Launchpad) - we are currently using Evergreen 2.8.2...


The fix only went in last night. It will be in today's release of 2.8.3,
so it might be worth the upgrade to see if it helps.



And you hit the nail on the head - we also usually search other 
sources and so it took quite some time to discover the problem...


Linda

Re: [OPEN-ILS-GENERAL] Z39.50 client query encoding issues

[Linda Jansova]

Thank you, Elaine!

Our problem, however, is not related to making searches in external 
databases (such as Library of Congress or OCLC), this works fine. (I 
apologize for writing such a long message which has probably resulted in 
being less undestandable than desired.)


The problem occurs when someone else who acts as Z39.50 client wishes to 
query our database (playing the role of Z39.50 server). In our case we 
would like the library gateway for the disabled (especially for the 
blind people) to be able to query our database which contains quite a 
lot of documents which may be of interest to those using the gateway.


As I could not find your Z39.50 server info (especially host, port, 
database), I could not verify if those wishing to query your database 
could experience the same difficulties. But since I have encountered 
them at Laurentian University I believe it may be the same for other 
Evergreen installations...


Linda

On 08/19/2015 02:56 PM, Hardy, Elaine wrote:

I was able to retrieve 3539 hits in a search of OCLC for author matoušek and
for author matousek through our Z39.50 gateway. I am afraid I can't help
with anything else other than that it does work in our Z39.50 instance with
OCLC.

We have had occasional problems with some diacritics and with some language
scripts. It is a minor issue for us; however, and I have been able to use
Vandelay to bring in the individual record that didn't retrieve via the
Z39.50 connection. I believe it was a record with a parallel title in
Turkish. Occasionally, an OCLC record will have a nonUTF-8 character which
will also block retrieval; but, that is a simple matter of correcting the
record in OCLC.


Elaine


J. Elaine Hardy
PINES  Collaborative Projects Manager
Georgia Public Library Service
1800 Century Place, Ste 150
Atlanta, Ga. 30345-4304


404.235.7128
404.235.7201, fax
eha...@georgialibraries.org
www.georgialibraries.org
www.georgialibraries.org/pines

-Original Message-
From: Open-ils-general
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of
Linda Jansova
Sent: Wednesday, August 19, 2015 3:51 AM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] Z39.50 client query encoding issues

Hi all,

Jabok Library currently uses Evergreen 2.8.2 and we have successfully
changed charsets both for client and yazgfs (in the configuration files
mentioned at
http://docs.evergreen-ils.org/2.1/html/Z3950serversupport.html) to utf-8 and
so now Z39.50 clients can receive data (records) with the correct
diacritics.

However, one related problem still persists - the Z39.50 queries only work
when no diacritics are used. Eg. search results are returned when we submit
a query matousek (author's surname) but no results are reported when the
correct version matoušek is used.

We have tried the following but to no avail:

1) add element client_query_charset to gfs (according to
http://www.indexdata.com/yaz/doc/server.vhosts.html) but it was an unknown
element;

2) delete the second mention of encoding=utf-8 from
/xsl/MARC21slim2SRWDC.xsl and restart the open-ils.supercat service, hoping
that this procedure would have similar results like when MODS stylesheets
were treated in the same way to resolve our Zotero encoding problems (see
https://bugs.launchpad.net/evergreen/+bug/1442276).

We have also tried further query testing in yaz-client. In this case, some
interesting things happened:

When yaz-client was used for a generic query find matoušek (i.e., with
diacritics), the answer was 34 hits:

Z find matoušek
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 34, setno 1
records returned: 0
Elapsed: 0.681894

However, when searching specifically for author (with diacritics again), the
answer was zero hits:

Z find @attr 1=1003 @attr 2=3 matoušek
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 0, setno 12
records returned: 0
Elapsed: 0.117265

When diacritics were omitted, we got 34 hits again:

Z find @attr 1=1003 @attr 2=3 matousek
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 34, setno 13
records returned: 0
Elapsed: 0.637897

Our Z39.50 server runs at mojzis.jabok.cuni.cz (port , database
Jabok) and it now uses the utf-8 encoding.

When we have tried Laurentian (laurentian.concat.ca, port 210, database
OSUL), we have used a word francais and français (searching for a person
in Tellico), in case of francais we got the results but when asking for
français, no results were found. So probably it is not just our case...

Do you have any ideas what we could do to make the queries with diacritics
work correctly?

Thank you in advance for any hints!

Linda

Re: [OPEN-ILS-GENERAL] Z39.50 client query encoding issues

[Linda Jansova]

Oh, I see! In that case we shall try the upgrade and see what happens 
(we shall keep you posted :-)...


Thank you for your help!

Linda

On 08/19/2015 03:34 PM, Jason Stephenson wrote:

Quoting Linda Jansova skolk...@chello.cz:


Thank you, Jason!

I have actually come across this bug as well but it seems that it has 
already been fixed (or at least this is my understanding of 
information from Launchpad) - we are currently using Evergreen 2.8.2...


The fix only went in last night. It will be in today's release of 2.8.3,
so it might be worth the upgrade to see if it helps.



And you hit the nail on the head - we also usually search other 
sources and so it took quite some time to discover the problem...


Linda

Re: [OPEN-ILS-GENERAL] Z39.50 client query encoding issues

[Linda Jansova]

Thank you, Jason!

I have actually come across this bug as well but it seems that it has 
already been fixed (or at least this is my understanding of information 
from Launchpad) - we are currently using Evergreen 2.8.2...


And you hit the nail on the head - we also usually search other sources 
and so it took quite some time to discover the problem...


Linda

On 08/19/2015 03:20 PM, Jason Stephenson wrote:

Hello, Linda!

I cannot speak to your exact problem, but I have noticed similar issues
when searching z39.50 in general, particularly when searching other
Evergreen systems. (We don't search our own via Z39.50 except for the
occasional test.)

I can tell you that Evergreen's Z39.50 ends up going through SRU
(Simple Retrieval by URL). There has been a recent bug fix for
Evergreen's SRU and double encoding of characters:

https://bugs.launchpad.net/bugs/1431541

I just thought that I would share that information, in case you were
not aware of it.

Hope that helps,
Jason

[OPEN-ILS-GENERAL] Z39.50 client query encoding issues

[Linda Jansova]

Hi all,

Jabok Library currently uses Evergreen 2.8.2 and we have successfully 
changed charsets both for client and yazgfs (in the configuration 
files mentioned at
http://docs.evergreen-ils.org/2.1/html/Z3950serversupport.html) to utf-8 
and so now Z39.50 clients can receive data (records) with the correct 
diacritics.


However, one related problem still persists - the Z39.50 queries only 
work when no diacritics are used. Eg. search results are returned when 
we submit a query matousek (author's surname) but no results are 
reported when the correct version matoušek is used.


We have tried the following but to no avail:

1) add element client_query_charset to gfs (according to 
http://www.indexdata.com/yaz/doc/server.vhosts.html) but it was an 
unknown element;


2) delete the second mention of encoding=utf-8 from 
/xsl/MARC21slim2SRWDC.xsl and restart the open-ils.supercat service, 
hoping that this procedure would have similar results like when MODS 
stylesheets were treated in the same way to resolve our Zotero encoding 
problems (see https://bugs.launchpad.net/evergreen/+bug/1442276).


We have also tried further query testing in yaz-client. In this case, 
some interesting things happened:


When yaz-client was used for a generic query find matoušek (i.e., with 
diacritics), the answer was 34 hits:


Z find matoušek
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 34, setno 1
records returned: 0
Elapsed: 0.681894

However, when searching specifically for author (with diacritics again), 
the answer was zero hits:


Z find @attr 1=1003 @attr 2=3 matoušek
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 0, setno 12
records returned: 0
Elapsed: 0.117265

When diacritics were omitted, we got 34 hits again:

Z find @attr 1=1003 @attr 2=3 matousek
Sent searchRequest.
Received SearchResponse.
Search was a success.
Number of hits: 34, setno 13
records returned: 0
Elapsed: 0.637897

Our Z39.50 server runs at mojzis.jabok.cuni.cz (port , database 
Jabok) and it now uses the utf-8 encoding.


When we have tried Laurentian (laurentian.concat.ca, port 210, database 
OSUL), we have used a word francais and français (searching for a 
person in Tellico), in case of francais we got the results but when 
asking for français, no results were found. So probably it is not just 
our case...


Do you have any ideas what we could do to make the queries with 
diacritics work correctly?


Thank you in advance for any hints!

Linda

[OPEN-ILS-GENERAL] Evergreen Z39.50 server output – encoding issues

[Linda Jansova]

Hi all,

Jabok Library currently tries to become a part of the Czech Libary 
Gateway for Visually Impaired which uses Z39.50 protocol to access 
library data. However, when testing the results from Jabok Z39.50 
server, we have encountered encoding problems. These have been confirmed 
by further tests conducted via Tellico (http://tellico-project.org/) 
which we use as an Evergreen-independent tool capable of serving as a 
Z39.50 client.


From Evergreen documentation (although pertaining to an older release; 
Jabok itself currently uses Evergreen 2.6.2) available from 
http://docs.evergreen-ils.org/2.1/html/Z3950serversupport.html it seems 
that the server uses marc-8 encoding for the output. But even when we 
have this marc-8 encoding set up when downloading records to Tellico, 
the records seems to come up with many incorrect characters (those which 
use diacritics), not to mention that when words with diacritics are used 
for searching, no results show up at all.


Would it be enough to change the default charsets mentioned in steps 3 
to 4 at http://docs.evergreen-ils.org/2.1/html/Z3950serversupport.html 
to utf-8? Or are some other tweaks necessary? (I am rather afraid that 
the second option is closer to reality because even when marc-8 encoding 
is used, the results are incorrect – of course, supposing that Tellico 
itself is not buggy ;-).)


Maybe Dan would know more about this issue - I remember that when we 
were discussing Zotero encoding issues back in April, there was a note 
in the reply about fixing a similar problem with the Z39.50 output 
(please see 
https://www.mail-archive.com/open-ils-general@list.georgialibraries.org/msg10874.html)? 
(When I tried to download records from Laurentian University Library – 
using the host name and other data from 
http://staff.library.mun.ca/staff/toolbox/z3950hosts.htm -, it worked 
okay when encoding was set to utf-8 :-).)


Thank you in advance for any hints!

Linda

Re: [OPEN-ILS-GENERAL] Evergreen and Zotero - encoding problems

[Linda Jansova]

Thank you in advance, Dan!

Linda

On 04/08/2015 05:29 PM, Dan Scott wrote:
On Sat, Apr 4, 2015 at 8:07 AM, Linda Jansova skolk...@chello.cz 
mailto:skolk...@chello.cz wrote:


Hi,

Our colleagues in Jabok Library would like to promote the usage of
their Evergreen OPAC as Zotero source data so that their patrons
(and others of course) would be able to import individual
bibliographic records to Zotero reference management system
(https://www.zotero.org/).

When used as a Mozilla Firefox plugin, it is clear that the data
are imported via unAPI (http://en.wikipedia.org/wiki/UnAPI;
unfortunately the homepage at http://unapi.info/ does not seem to
be working; a bit of unAPI documentation is available at
http://code4lib.org/files/unapi_revision_1-14.html, though maybe
it is not the latest version).

Everything seems to work fine with one exception and these are
records with non-ASCII characters such as letters with diacritics
(č for example). As Czech language uses plenty of these, this
issue virtually prevents us from using Evergreen as Zotero data
source.

However, I have had a look at other Evergreen catalogs (including
the one from Laurentian University) and it seems to me that the
problem is also present there, e.g.

https://laurentian.concat.ca/eg/opac/record/104728?query=francais;qtype=keyword;locg=105;detail_record_view=1
(Le francais renouvelé - the é character is wrongly interpreted
as could be seen at the attached picture).

Both in Jabok library catalog and in the catalog at Laurentian I
have encountered the same problem when trying to print sample
records with these say special characters,

e.g.https://laurentian.concat.ca/eg/opac/record/print/104728?query=francais;qtype=keyword;locg=105;detail_record_view=1

Firefox seems to interpret the character encoding as Unicode when
viewing the usual (not the print) version of the bib record but
when one hits the Print button and then - when the print version
is displayed - checks the encoding, Firefox interprets it as
Western. Koha users have also been trying to sort out a similar
issue

(https://forums.zotero.org/discussion/39395/koha-translator-encoding-problem/)
- in their case the solution seems to be to modify opac-export.pl
http://opac-export.pl to export as UTF8.

Any ideas how to fix the issue in Evergreen? (Jabok uses Evergreen
2.6.4.)

Thank you in advance for sharing any hints!


Hi, that's an interesting problem. Zotero uses Evergreen's MODS 
output, and it seems that the problem crept into the conversions that 
use specific MODS versions; compare


https://laurentian.concat.ca/opac/extras/supercat/retrieve/mods/record/28391

to

https://laurentian.concat.ca/opac/extras/supercat/retrieve/mods3/record/28391

and you'll see that the first one works as expected, while the second 
one is corrupted.


This is an issue for us too, as you can imagine (we're a bilingual 
institution with an extensive French collection), so I'll be digging 
into this.  I recently fixed a similar problem with our Z39.50 server 
output, so hopefully it won't take too long.

Re: [OPEN-ILS-GENERAL] Evergreen and Zotero - encoding problems

[Linda Jansova]

Thank you once again, Dan! It is tremendously helpful for us that you 
have provided this short-term fix :-)!


Linda

On 04/09/2015 06:58 PM, Dan Scott wrote:
So I have a short-term fix that sites can apply documented in the bug 
at https://bugs.launchpad.net/evergreen/+bug/1442276 - but it's not 
something that I think is the right long-term fix.


Still, seems worthwhile to point it out so that sites that want to 
make their Zotero users (and other users of SuperCat feeds) happy can 
do so until we figure out how to fix the problem properly.


Dan

On Thu, Apr 9, 2015 at 5:56 AM, Linda Jansova skolk...@chello.cz 
mailto:skolk...@chello.cz wrote:


Thank you in advance, Dan!

Linda


On 04/08/2015 05:29 PM, Dan Scott wrote:

On Sat, Apr 4, 2015 at 8:07 AM, Linda Jansova skolk...@chello.cz
mailto:skolk...@chello.cz wrote:

Hi,

Our colleagues in Jabok Library would like to promote the
usage of their Evergreen OPAC as Zotero source data so that
their patrons (and others of course) would be able to import
individual bibliographic records to Zotero reference
management system (https://www.zotero.org/).

When used as a Mozilla Firefox plugin, it is clear that the
data are imported via unAPI
(http://en.wikipedia.org/wiki/UnAPI; unfortunately the
homepage at http://unapi.info/ does not seem to be working; a
bit of unAPI documentation is available at
http://code4lib.org/files/unapi_revision_1-14.html, though
maybe it is not the latest version).

Everything seems to work fine with one exception and these
are records with non-ASCII characters such as letters with
diacritics (č for example). As Czech language uses plenty
of these, this issue virtually prevents us from using
Evergreen as Zotero data source.

However, I have had a look at other Evergreen catalogs
(including the one from Laurentian University) and it seems
to me that the problem is also present there, e.g.

https://laurentian.concat.ca/eg/opac/record/104728?query=francais;qtype=keyword;locg=105;detail_record_view=1
(Le francais renouvelé - the é character is wrongly
interpreted as could be seen at the attached picture).

Both in Jabok library catalog and in the catalog at
Laurentian I have encountered the same problem when trying to
print sample records with these say special characters,

e.g.https://laurentian.concat.ca/eg/opac/record/print/104728?query=francais;qtype=keyword;locg=105;detail_record_view=1

Firefox seems to interpret the character encoding as Unicode
when viewing the usual (not the print) version of the bib
record but when one hits the Print button and then - when
the print version is displayed - checks the encoding, Firefox
interprets it as Western. Koha users have also been trying to
sort out a similar issue

(https://forums.zotero.org/discussion/39395/koha-translator-encoding-problem/)
- in their case the solution seems to be to modify
opac-export.pl http://opac-export.pl to export as UTF8.

Any ideas how to fix the issue in Evergreen? (Jabok uses
Evergreen 2.6.4.)

Thank you in advance for sharing any hints!


Hi, that's an interesting problem. Zotero uses Evergreen's MODS
output, and it seems that the problem crept into the conversions
that use specific MODS versions; compare

https://laurentian.concat.ca/opac/extras/supercat/retrieve/mods/record/28391

to


https://laurentian.concat.ca/opac/extras/supercat/retrieve/mods3/record/28391

and you'll see that the first one works as expected, while the
second one is corrupted.

This is an issue for us too, as you can imagine (we're a
bilingual institution with an extensive French collection), so
I'll be digging into this.  I recently fixed a similar problem
with our Z39.50 server output, so hopefully it won't take too long.

Re: [OPEN-ILS-GENERAL] Making patron data invisible for other libraries in consortium?

[Linda Jansova]

Dan, thanks a lot for your clarification! I has been very helpful for us!

Linda

On 10/04/2014 06:56 PM, Dan Scott wrote:
On Sat, Oct 4, 2014 at 9:08 AM, skolk...@upcmail.cz 
mailto:skolk...@upcmail.cz skolk...@chello.cz 
mailto:skolk...@chello.cz wrote:


Hi,

Here in the Czech Republic we are just considering a pilot project
for a simple consortium of two libraries (so far, in our country
there are only single plantings). However, the two libraries would
be two separate legal entities and we need to ensure patron data
privacy.

At this moment it seems that the easiest way would be to make sure
that the two libraries would not share their patrons (meaning that
one library would not see the other library's patrons). Can
Evergreen cope with this? And if so, how exactly?

Or is it necessary to make such legal arrangements that would
enable the two libraries share data about their patrons?

Thank you in advance for sharing any ideas or links pointing to
some hints regarding this issue!


There are some settings for patron opt-in in Evergreen that prevent 
easy access to patron info from other libraries. The idea is that 
staff at library 1 should not be able to search for a patron at 
library 2 by their name or other attributes until that patron presents 
their barcode at library 1 and agrees to share their information with 
library 1. We use this approach in our consortium to minimize 
unnecessary exposure of patron data at different branches.


There doesn't appear to be anything about the patron opt-in settings 
in the official docs, but 
http://docs.sitka.bclibraries.ca/Sitka/current/html/searching-patrons.html 
has a screenshot showing what staff see when a user from a different 
library presents their card at a library to which they have not yet 
opted in to sharing their information.


That said, anyone with the ability to create reports can easily create 
a report which extracts all user information for all libraries, and 
there are some points where information leakage can occur (for 
example, I think you can see borrowers from other libraries on an 
item's circulation history). So it's not a completely airtight 
solution by any means, but it is suitable for some setups.


Ultimately, however, if you don't want to share patron info at all 
across libraries, the only way to do that is to have separate 
Evergreen instances.

[OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather than periods

[Linda Jansova]

Hi all,

We have imported bibliographic and holdings data of the Evangelical 
Theological Seminary library to Evergreen 2.5.3!


Yet, we have encountered the following problem (maybe a bit related to a 
recent discussion on Dewey normalization: 
http://comments.gmane.org/gmane.education.libraries.open-ils.general/9661):


The library uses Dewey decimals as call numbers but these call numbers 
are not unique (no cutters are applied). In the OPAC, these data can be 
found as correctly imported in subfield a of the the 082 field (which 
means the data in MARCXML have been well preserved). But during the 
import, they were normalized in metabib.full_rec and call numbers are 
created from these data. There is no problem with padding zeroes as 
these have not been added but periods within the Dewey number have been 
overrided by spaces, e.g., 
http://lib.etspraha.cz/eg/opac/results?query=evangelical;qtype=keyword.


Therefore we have - unsuccessfully - tried to add the periods back but 
then the call numbers are expected to be unique which is not our case. 
So an error has occured:


evergreen=# UPDATE asset.call_number SET label = replace(label, ' ', '.');
ERROR:  duplicate key value violates unique constraint 
asset_call_number_label_once_per_lib
DETAIL:  Key (record, owning_lib, label, prefix, suffix)=(4465, 4, 
274.3708, -1, -1) already exists.


Is there anything we can do about it (get the periods back to call 
numbers and have the call numbers that are not unique)?


Any ideas are very welcome :-)!

Linda and Vaclav Jansovi

Re: [OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather than periods

[Linda Jansova]

Thank you, Dan! Your hint with the bib record with two versions of the 
same call number has helped us find the right way to proceed (four 
remaining troublesome records will be dealt with manually :-):


evergreen=# UPDATE asset.call_number SET label = replace(label, '.', '-');
UPDATE 10355
evergreen=# UPDATE asset.call_number SET label = replace(label, ' ', '.');
UPDATE 10355
evergreen=# UPDATE asset.call_number SET label = replace(label, '-', '.');
ERROR:  duplicate key value violates unique constraint 
asset_call_number_label_once_per_lib
DETAIL:  Key (record, owning_lib, label, prefix, suffix)=(5651, 4, 
248.84, -1, -1) already exists.


Linda

On 04/28/2014 03:26 PM, Dan Wells wrote:

Hello Linda,

I don't fully understand how you built your holdings, but it looks like you 
found something that worked for you.

Your update is failing on a record which already has both versions of the call 
number (correct with '.' and incorrect with 'space').  See here:

http://lib.etspraha.cz/eg/opac/record/4465?query=evangelical;qtype=keyword

If you manually merge those copies onto either call number, there is a chance 
your listed SQL query can succeed.  If not, you will need to determine how many 
records you have which already have a correct call number listed:

SELECT record,label FROM asset.call_number WHERE label LIKE '%.%';

That doesn't tell the whole story (i.e whether you have *both* types of call 
numbers on that record), but it's a quick way to see what you are up against.  
If it's just a few, I'd merge them manually.  Otherwise, I'd next do a JOIN to 
see how many actually have both types of call number.  If it is still a lot, 
working up a little script or even a more complex query to do the merging would 
be your best bet.

Sincerely,
Dan


Daniel Wells
Library Programmer/Analyst
Hekman Library, Calvin College
616.526.7133

-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org 
[mailto:open-ils-general-boun...@list.georgialibraries.org] On Behalf Of Linda 
Jansova
Sent: Monday, April 28, 2014 1:56 AM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] Non-unique Dewey call numbers with spaces rather 
than periods

Hi all,

We have imported bibliographic and holdings data of the Evangelical Theological 
Seminary library to Evergreen 2.5.3!

Yet, we have encountered the following problem (maybe a bit related to a recent 
discussion on Dewey normalization:
http://comments.gmane.org/gmane.education.libraries.open-ils.general/9661):

The library uses Dewey decimals as call numbers but these call numbers are not unique (no 
cutters are applied). In the OPAC, these data can be found as correctly imported in 
subfield a of the the 082 field (which means the data in MARCXML have been 
well preserved). But during the import, they were normalized in metabib.full_rec and call 
numbers are created from these data. There is no problem with padding zeroes as these 
have not been added but periods within the Dewey number have been overrided by spaces, 
e.g., http://lib.etspraha.cz/eg/opac/results?query=evangelical;qtype=keyword.

Therefore we have - unsuccessfully - tried to add the periods back but then the 
call numbers are expected to be unique which is not our case.
So an error has occured:

evergreen=# UPDATE asset.call_number SET label = replace(label, ' ', '.');
ERROR:  duplicate key value violates unique constraint 
asset_call_number_label_once_per_lib
DETAIL:  Key (record, owning_lib, label, prefix, suffix)=(4465, 4, 274.3708, 
-1, -1) already exists.

Is there anything we can do about it (get the periods back to call numbers and 
have the call numbers that are not unique)?

Any ideas are very welcome :-)!

Linda and Vaclav Jansovi

[OPEN-ILS-GENERAL] Any ideas how to include payments from external sources into Evergreen?

[Linda Jansova]

Dear all,

Czech library users would appreciate if it was possible to add money to 
their Evergreen account using bank transfers (this way of making 
payments is used by a number of public libraries in our country).


Our idea is that a CSV file from electronic banking (with a variable 
symbol as a payment identifier, see 
http://en.wikipedia.org/wiki/Variable_symbol, and a particular amount of 
money) would be processed with a script that we would write. The script 
output would call an OpenSRF function or insert data into a table.


If the first method (calling a function) was used, which OpenSRF 
function should be called in order to enable adding money to a 
particular user account (using a user account ID as a variable -- or 
other identifier from the electronic banking data -- and an amount of 
money)?


If the second method (inserting data into a table) was used, which are 
the tables into which the data should be inserted and how should the 
insertion be done?


Which of these methods would you recommend?

(Indeed, if there are any other options, we will be more than happy to 
hear about them :-).)


A programmer would do this work for us (provided that we are awarded 
grant money for this purpose -- the grant writing activities are just 
underway) and we would definitely share the results of our work with the 
Evergreen community.


Thank you in advance for any hints!

Linda and Vaclav Jansovi (and especially Eva Cerninakova from Jabok 
Library who is about to submit the grant application :-)

[OPEN-ILS-GENERAL] Javascript libraries - documentation?

[Linda Jansova]

Hi all,

Could you please advise us where to find some documentation to Evergreen 
javascript libraries? We are trying to retrieve isbns of search results 
via a javascript call but we could neither find a relevant function, nor 
a Javascript API description.


Thank you for any hints!

Linda Jansova

Re: [OPEN-ILS-GENERAL] Javascript libraries - documentation?

[Linda Jansova]

Hi Lebbeous,

Thank you very much for such a detailed explanation! I appreciate it 
very much (and so - or even more so - does Mila Nic who actually does 
the programming :-).)


Linda

Dne 19.4.2013 16:58, Lebbeous Fogle-Weekley napsal(a):

Hello Linda,

** The following is a general outline of how to reach Evergreen API
methods.  For your specific question about ISBNs, skip to the bottom
of my e-mail. **

Much of Evergreen's business logic is available through the registered
API methods of several OpenSRF applications.  Instead of
Evergreen-specific Javascript libraries, the way to access these is to
use the OpenSRF javascript libraries best explained by documentation
here:
http://evergreen-ils.org/opensrf.php#opensrf_development  (thanks to Dan Scott).

As for the API methods themselves, they have documentation which is
often helpful in telling you at least enough about the expected
parameters that you can experiment.  If you would rather not look in
the Evergreen source code for that documentation, there is an easier
way to find it by consulting any appropriately configured Evergreen
server in this way:
http://demo.evergreencatalog.com/opac/extras/docgen.xsl

In the 'application' field, enter any of these:

opensrf.math
open-ils.actor
open-ils.acq
open-ils.auth
open-ils.booking
open-ils.serial
open-ils.cat
open-ils.circ
open-ils.collections
open-ils.fielder *
open-ils.pcrud *
open-ils.reporter
open-ils.search
open-ils.supercat
open-ils.url_verify
open-ils.vandelay

And then check the All methods checkbox before clicking submit,
except for the applications I have marked with an asterisk (*).  These
applications have tons of dynamically generated methods, and so the
retrieving documentation for all of them may be very slow.

In this way you can explore the API documentation for all methods of
the publicly available applications (we also call the applications
services sometimes) of an Evergreen system.

The demo system I have linked to is somewhat dated, at version 2.2 RC1
of Evergreen, but system administrators can find docgen.xsl in the
OpenSRF source code repository and deploy it on any site running the
Evergreen version of their choice.

Now, having explained all that, for your specific task of retriving
ISBNs from a set of search results, I don't know that you'll find a
suitable API method to do exactly that for you.  However, there are
other ways to access Evergreen.

It has nothing to do with Javascript per se, but I would use
Evergreen's OpenSearch API to perform a search and return a feed of
MODS records.  Example:
http://demo.evergreencatalog.com/opac/extras/opensearch/1.1/-/mods3?searchTerms=harry+pottersearchClass=keyword

You will notice that the resulting XML document contains many
instances of identifier type=isbn tags. You can parse the
collection of MODS records with available XML libraries for any
programming language, including Javascript, and pick out the ISBN tags
you're interested in.

I hope this helps!

Lebbeous


On Fri, Apr 19, 2013 at 7:28 AM, Linda Jansova skolk...@chello.cz wrote:

Hi all,

Could you please advise us where to find some documentation to Evergreen
javascript libraries? We are trying to retrieve isbns of search results via
a javascript call but we could neither find a relevant function, nor a
Javascript API description.

Thank you for any hints!

Linda Jansova

Re: [OPEN-ILS-GENERAL] Copy status for reference books?

[Linda Jansova]

Dan, we have tried it already but without success. We have made the 
changes in the file 
/openils/var/web/opac/skin/default/xml/result/result_table.xml.


Do you think that it should be sufficient to make the desired changes in 
this file or is it necessary to make them during the installation 
process (as the location 
Open-ILS/web/opac/skin/default/xml/result/result_table.xml you have 
mentioned might indicate)? Or - in case we have Evergreen already 
installed - is it necessary to make some changes in some other files or 
something like that?


Thank you in advance for your view!

Linda

PS: Also a big thank you goes to you for all of your recommendations 
regarding our favorite ;-) facet translations etc. - we usually proceed 
little by little as we fiddle with Evergreen in our spare time :-).


Dne 19.1.2012 07:22, Linda Jansova napsal(a):

Thank you, Dan! We shall definitely try it :-)!

Linda

Dne 18.1.2012 16:15, Dan Scott napsal(a):

On Mon, Jan 16, 2012 at 02:34:41PM -0500, Mike Rylander wrote:

2012/1/16 Linda Jansovaskolk...@chello.cz:

Hi,

We have come across a probably more or less country-specific issue:

In Jabok Library, reference books (i.e., books which cannot be
checked out
and can only be read in the library) don't share the same copy
location (as
often, though probably not always, do reference books in US libraries).
Rather, the books in Jabok Library are dispersed throughout the
library. A
typical example would five copies of the book - four of them could be
checked out and one of them could not be. All five copies would be
physically located on the very same shelf - distinguished by a spine
label
so that the user immediately sees whether he or she is able to check
out the
particular copy.

When it comes to Evergreen (we are currently using version 2.0.9),
would you
recommend creating a new copy status (in Server Administration - Copy
statuses) entitled (in English) say Reference which would be
visible in
the OPAC and one could not place holds on it? What we need is to
make it
more visible for the user to see whether a particular copy is a
usual copy
which could be checked out whether it is a reference book... In case
we use
the copy status as indicated, we (and the users of course) can
conveniently
see the status below the record of the title...

Or perhaps an entirely different solution would be better in this case?


There's a Reference flag that can be set on a per-copy basis, and can
be used to disallow holds and circulations.

Building on what Mike said, that Reference flag for copies is exposed in
the data available to BibTemplate (in the JavaScript OPAC) using the
marcxml-full data type - which is what the search result copy summaries
are built from.

So, let's peek behind the veil to see a snippet of the XML that's
returned:

holdings xmlns=http://open-ils.org/spec/holdings/v1;
counts
count type=public count=2 available=2 unshadow=2
transcendant=0 org_unit=1 depth=0/
count type=public count=2 available=2 unshadow=2
transcendant=0 org_unit=105 depth=1/
/counts
volumes
volume id=tag:open-ils.org:asset-call_number/1744485 lib=OSUL
opac_visible=t deleted=f label=QA 76.76 S46 Z55 2006
copies
copy id=tag:open-ils.org:asset-copy/490288
create_date=2006-03-14T00:00:00-0500
edit_date=2011-03-28T09:36:52-0400 copy_number= circulate=t
deposit=f ref=f holdable=t deleted=f deposit_amount=0.00
price= barcode=30007008266958 circ_modifier=BOOK circ_as_type=
opac_visible=t
status ident=0 opac_visible=tAvailable/status
location ident=142 opac_visible=tCirculation (3rd floor)/location
circlib ident=103 opac_visible=tJ.N. Desmarais Library/circlib
circ_lib xmlns=http://open-ils.org/spec/actors/v1;
id=tag:open-ils.org:actor-org_unit/103 shortname=OSUL
name=J.N. Desmarais Library opac_visible=t/
monograph_parts/monograph_parts
copy_notes/copy_notes
statcats/statcats
/copy
/copies
uris/
prefix ident=-1 id=tag:open-ils.org:asset-call_number_prefix/-1
label_sortkey=/
suffix ident=-1 id=tag:open-ils.org:asset-call_number_suffix/-1
label_sortkey=/
owning_lib xmlns=http://open-ils.org/spec/actors/v1;
id=tag:open-ils.org:actor-org_unit/103 shortname=OSUL name=J.N.
Desmarais Library/
/volume
/volumes
/holdings

All of that is mostly to expose what is available to sites to fairly
easily customize displays. In your case, thecopy element is what
you're looking for, and the ref attribute is what tells you whether
the reference flag has been checked off. You could then adjust the
BibTemplate code in
Open-ILS/web/opac/skin/default/xml/result/result_table.xml to check the
value of the ref attribute and alter the display accordingly, within
the scope of the dojo.query('copy', vol).forEach(function (cp) { loop.

For example, you could assign the value of copy.getAttribute('ref') to a
variable, and then within the chunk of code that determines the display
status, make it generate Reference instead of Available (or append
Reference to the current status string, and/or make it an HTML element
with a title

Re: [OPEN-ILS-GENERAL] Copy status for reference books?

[Linda Jansova]

Thank you, Jennifer, we shall try it and see whether it would work for 
us :-)!


Linda

Dne 17.1.2012 16:49, Turner, Jennifer M napsal(a):


Hi Linda,

Our libraries had this problem, too.  To work around it, they created 
separate volumes for reference copies.  This allows the call number 
and location to display separately from the items in the general 
collection.


The following is an example on our development system:

http://ecrldev.mnpals.net/opac/en-US/skin/default/xml/rdetail.xml?r=146847t=free%20moneytp=titled=0hc=10rt=title 
http://ecrldev.mnpals.net/opac/en-US/skin/default/xml/rdetail.xml?r=146847t=free%20moneytp=titled=0hc=10rt=title 



I hope this helps!

Jennifer Turner | PALS, A Program of the Minnesota State Colleges and 
Universities | 507-389-2000


*From:*open-ils-general-boun...@list.georgialibraries.org 
[mailto:open-ils-general-boun...@list.georgialibraries.org] *On Behalf 
Of *Linda Jansova

*Sent:* Tuesday, January 17, 2012 1:06 AM
*To:* open-ils-general@list.georgialibraries.org
*Subject:* Re: [OPEN-ILS-GENERAL] Copy status for reference books?

Mike, I forgot to mention that Jabok Library actually uses the 
reference flag but the problem is that the user only sees what is 
displayed in the OPAC and it seems that it is impossible for the user 
to distinguish between a copy which is a reference copy and a copy 
which is not.


An example could be this book:

http://www.jabok.cuni.cz/opac/en-US/skin/default/xml/rdetail.xml?r=11941t=soci%C3%A1ln%C3%AD%20v%20praxi%20matou%C5%A1ektp=keywordd=0hc=1rt=keyword 
http://www.jabok.cuni.cz/opac/en-US/skin/default/xml/rdetail.xml?r=11941t=soci%C3%A1ln%C3%AD%20v%20praxi%20matou%C5%A1ektp=keywordd=0hc=1rt=keyword


and a copy with a barcode 424480018601 listed in copy location 
Odborná knihovna. The user sees that it is available. However, he or 
she does not see whether it is a reference copy or not...


Linda

Dne 16.1.2012 20:34, Mike Rylander napsal(a):

2012/1/16 Linda Jansovaskolk...@chello.cz  mailto:skolk...@chello.cz:

Hi,

  


We have come across a probably more or less country-specific issue:

  


In Jabok Library, reference books (i.e., books which cannot be checked out

and can only be read in the library) don't share the same copy location (as

often, though probably not always, do reference books in US libraries).

Rather, the books in Jabok Library are dispersed throughout the library. A

typical example would five copies of the book - four of them could be

checked out and one of them could not be. All five copies would be

physically located on the very same shelf - distinguished by a spine label

so that the user immediately sees whether he or she is able to check out the

particular copy.

  


When it comes to Evergreen (we are currently using version 2.0.9), would you

recommend creating a new copy status (in Server Administration -  Copy

statuses) entitled (in English) say Reference which would be visible in

the OPAC and one could not place holds on it? What we need is to make it

more visible for the user to see whether a particular copy is a usual copy

which could be checked out whether it is a reference book... In case we use

the copy status as indicated, we (and the users of course) can conveniently

see the status below the record of the title...

  


Or perhaps an entirely different solution would be better in this case?

  

  
There's a Reference flag that can be set on a per-copy basis, and can

be used to disallow holds and circulations.
  
HTH,
  

[OPEN-ILS-GENERAL] Copy status for reference books?

[Linda Jansova]

Hi,

We have come across a probably more or less country-specific issue:

In Jabok Library, reference books (i.e., books which cannot be checked 
out and can only be read in the library) don't share the same copy 
location (as often, though probably not always, do reference books in US 
libraries). Rather, the books in Jabok Library are dispersed throughout 
the library. A typical example would five copies of the book - four of 
them could be checked out and one of them could not be. All five copies 
would be physically located on the very same shelf - distinguished by a 
spine label so that the user immediately sees whether he or she is able 
to check out the particular copy.


When it comes to Evergreen (we are currently using version 2.0.9), would 
you recommend creating a new copy status (in Server Administration - 
Copy statuses) entitled (in English) say Reference which would be 
visible in the OPAC and one could not place holds on it? What we need is 
to make it more visible for the user to see whether a particular copy is 
a usual copy which could be checked out whether it is a reference 
book... In case we use the copy status as indicated, we (and the users 
of course) can conveniently see the status below the record of the title...


Or perhaps an entirely different solution would be better in this case?

Any advice on this matter is appreciated...

Linda

Re: [OPEN-ILS-GENERAL] How to translate facet labels in Evergreen 2.1.1?

[Linda Jansova]

Hi Dan,

Thanks a lot for your explanation! We are well aware of the fact that 
the strings don't really travel from one place to the other on their own 
- on the other hand, we do appreciate the possibility to use Launchpad 
for translations (it used to be far more difficult to cooperate on 
translations with downloaded files). Anyway, we look forward to the next 
version with our Czech strings included :-)!


Linda and Vaclav

Dne 5.12.2011 00:08, Dan Scott napsal(a):

Hi Linda:

On Sun, Dec 4, 2011 at 2:32 PM, Linda Jansovaskolk...@chello.cz  wrote:

Dan, thanks a lot for your quick and precise answer :-)! We have followed
your recommendations and succeeded in making facets look correct in Czech -
as you can see in the attached picture :-).

One more tiny little question - is it possible to translate the More...
button which appears in case more items belonging to facets are available,
yet not presented to the user straightaway?

Yes, that string comes from the Searcher.js set of strings at
Open-ILS/web/js/dojo/openils/widget/nls/cs-cz/Searcher.js - but
similar to the database strings, ultimately they're fed into the
process from http://translations.launchpad.net/evergreen - which
appears to have had fully translated strings since August 2011. Hmm.

insert investigation noises

Unfortunately, it looks like the translated strings haven't been
updated in our source repo - there's
nobuild/i18n/po/Searcher.js/cs-CZ.po file, so all that's in 2.1.1 is a
copy of the English strings. This is my fault, as I updated the
strings in September 2011 but appear to have missed bringing over
brand new files that were added :(

If you haven't guessed, the process of pulling updated strings from
Launchpad and pushing them into our git repo, and the reverse process
of updating new and changed strings in Launchpad, has not been
automated. The whole git / bzr divide is a bit of a pain to cross, and
Launchpad uses different locale codes that Evergreen does, so getting
it automated would be awesome.

Dan

Re: [OPEN-ILS-GENERAL] Jabok Library (Czech Republic) now live with Evergreen

[Linda Jansova]

Thank you, Ben and Dan! (We do look forward to having all of our 
translations included in Evergreen :-)!)


Linda

Dne 2.10.2011 16:32, Ben Shum napsal(a):

Congratulations and welcome!

Based on the details provided, I've added a new entry for your library 
on the wiki.  It is now listed on the Evergreen Libraries page.


Not too sure about the Google map, I think that's Bob's area of expertise.

In any case, wonderful to have new additions.  :)

Cheers,

-- Ben

On Oct 2, 2011, at 7:51 AM, Linda Jansova wrote:


Dear all,

It is our pleasure to let you know that Jabok Library (Prague, Czech 
Republic) now successfully uses Evergreen :-)!


Below we are sending more details about the library so that it can be 
added to the list of Evergreen libraries (available at
http://www.open-ils.org/dokuwiki/doku.php?id=evergreen_libraries) and 
to the map (we have already been with touch with Bob regarding this 
issue).


***
Name:
Jabok Library

Note:
Jabok Library is a part of a larger organization called (in English) 
Jabok – Institute of Social Pedagogy and Theology which is a 
vocational school or - more generally - a higher education 
institution. The library itself could be probably best categorized as 
a special library.


Library website:
http://knihovna.jabok.cz/

Catalog homepage:
http://www.jabok.cuni.cz/opac/cs-CZ/skin/default/xml/index.xml

Location:
Prague, Czech Republic

Full address:
Salmovská 8, 120 00 Prague 2, Czech Republic

Coordinates:
50.074421,14.422988

Type:
Single planting

Contact:
Eva Cerninakova (cerninak...@jabok.cz or cerninak...@gmail.com)

Migration:
2011-09-05

Installation Notes:
Self-administered, Evergreen 2.0.9, Debian Squeeze, PostgreSQL 8.4, 
In-house developers (N)

***

Vaclav Jansa, Eva Cerninakova and Linda Jansova (or the three of us 
who have worked hard to make it all come true :-) - Eva is the 
library director, Vaclav and Linda are her external collaborators - 
actually working in other libraries and plunging into Evergreen in 
their spare time)

[OPEN-ILS-GENERAL] Jabok Library (Czech Republic) now live with Evergreen

[Linda Jansova]

Dear all,


It is our pleasure to let you know that Jabok Library (Prague, Czech 
Republic) now successfully uses Evergreen :-)!



Below we are sending more details about the library so that it can be 
added to the list of Evergreen libraries (available at


http://www.open-ils.org/dokuwiki/doku.php?id=evergreen_libraries) and to 
the map (we have already been with touch with Bob regarding this issue).



***

Name:
Jabok Library


Note:
Jabok Library is a part of a larger organization called (in English) 
Jabok -- Institute of Social Pedagogy and Theology which is a 
vocational school or - more generally - a higher education institution. 
The library itself could be probably best categorized as a special library.



Library website:
http://knihovna.jabok.cz/

Catalog homepage:
http://www.jabok.cuni.cz/opac/cs-CZ/skin/default/xml/index.xml

Location:
Prague, Czech Republic

Full address:
Salmovská 8, 120 00 Prague 2, Czech Republic


Coordinates:
50.074421,14.422988

Type:
Single planting


Contact:
Eva Cerninakova (cerninak...@jabok.cz or cerninak...@gmail.com)


Migration:
2011-09-05


Installation Notes:
Self-administered, Evergreen 2.0.9, Debian Squeeze, PostgreSQL 8.4, 
In-house developers (N)


***


Vaclav Jansa, Eva Cerninakova and Linda Jansova (or the three of us who 
have worked hard to make it all come true :-) - Eva is the library 
director, Vaclav and Linda are her external collaborators - actually 
working in other libraries and plunging into Evergreen in their spare time)

[OPEN-ILS-GENERAL] Printing UTF-8 characters from Evergreen

[Linda Jansova]

Hi,

One more question - it seems that when printing from Evergreen (e.g. 
from circulation) takes place, UTF-8 characters (those not in ASCII) are 
not printed out as they are supposed to. Is there a way to persuade 
Evergreen to print these characters correctly? It is important 
especially when it comes to book titles etc.


Example: the word Křesťan is currently printed as K%u0159es%u0165an 
(the two non-ASCII characters are represented by their UTF-8 codes)


Thank you in advance for sharing any printing tips :-)!

Linda

Re: [OPEN-ILS-GENERAL] Accession numbers, copy notes and diacritics in call numbers

[Linda Jansova]

Dear Dan and Thomas,

Thank you very much for your recommendations!

As to the sorting issues - I believe that now we have a number of hints 
to investigate, so we can further proceed in our efforts :-)... I do 
appreciate you have taken the trouble to test things for us and thus 
facilitated testing in our own installation. Thanks a lot for that :-)!


(And, yes, you are right - I apologize for not mentioning it in my 
message - we are on EG 2.0.)


Linda

Dne 28.7.2011 16:19, Dan Scott napsal(a):

Hi Linda:

2011/7/18 Linda Jansovaskolk...@chello.cz:

snip


3) In case we use diacritics in call numbers, is there a way to make the
Shelf Browser show first the particular letters letters without diacritics
and then those with diacritics? E.g. to have the letter Č after the letter
C instead of somewhere at the beginning of the virtual shelf? (We are
especially interested in Czech alphabet - the correct order of letters is
available at http://en.wikipedia.org/wiki/Czech_alphabet.) Or maybe is it
better do do without and use only call numbers with decent ;-) letters?

You would think that the answer to this would be simple, but it looks
like the answer will require us to check a number of points.

First, as of Evergreen 2.0 we generate call number sort keys that
are used for sorting purposes. (I can't remember but I think you're on
2.0 by now?). I'm guessing that you still have your library set to the
default call number classification scheme, so the first thing we'll
need to do is check to ensure that the sort keys that we generate
aren't doing something bad to diacritic characters.

Second, sorting depends on the glibc locale environment on your
database server - the collating sequence for the locale your database
has been created in should match the behaviour of the sort command
from the command line on the database server for each given locale.

For example, if I create the text file sortme that contains the
following lines:

C
Č
C
Č

I can then test the collation behaviour of different locales. On my
laptop running Fedora 15, for example, using the 'C' locale that we
expect the database to be using:

$ LANG=C sort sortme
C
C
Č
Č

And then if I switch to the cs_CZ UTF8 locale:

$ LANG=cs_CZ.utf8 sort sortme
C
C
Č
Č

But if I switch to the cs_CZ ISO locale:

$ LANG=cs_CZ.iso88592 sort sortme
Č
Č
C
C

So - it looks like on my environment I would expect to get the
appropriate sorting sequence for call numbers using the recommended
'C' locale for the database. It's possible that your database server's
locale environment does not match this behaviour, of course.

Finally, the actual call number sort key is then wrapped in an
oils_text_as_bytea(label_sortkey) function when we sort the results of
a call number browse, which converts the sortkey at run time to a
bytea data type. Checking out the definition of bytea strings, I had
the sinking feeling that this was the reason for your problems. To
paste from the PostgreSQL documentation:

operations on binary strings process the actual bytes, whereas the
processing of character strings depends on locale settings. In short,
binary strings are appropriate for storing data that the programmer
thinks of as raw bytes, whereas character strings are appropriate
for storing text.

In addition,

But then, when I tested this theory on a PostgreSQL 9.0 database
created with the C locale, that theory of doom doesn't seem to hold
up:

-- Show that we are using the right database locale
SHOW LC_COLLATE;

  lc_collate

  C
(1 row)

-- Create a test table to try out our theory
CREATE TABLE test_bytea(input TEXT, output BYTEA);

-- Insert our sample data
INSERT INTO test_bytea(input) VALUES ('C'), ('Č'), ('C'), ('Č');

-- Create the BYTEA version of the text in the output column
UPDATE test_bytea SET output = oils_text_as_bytea(input);

-- Get the table as sorted by the untouched text
SELECT input, output FROM test_bytea ORDER BY input ASC;

  input | output
---+
  C | \x43
  C | \x43
  Č | \xc48c
  Č | \xc48c
(4 rows)

-- Now get the table as sorted by the BYTEA version of the strings
SELECT input, output FROM test_bytea ORDER BY output ASC;

  input | output
---+
  C | \x43
  C | \x43
  Č | \xc48c
  Č | \xc48c
(4 rows)

And... as you can see, I'm still getting the expected sort order that
you want - even though the string has been converted to a BYTEA column
(and the oils_text_as_bytea() function throws in an UPPER() call that
also normally raises a warning flag that non-ASCII data may be
destroyed).

So - I'm having trouble reproducing the problem that you're seeing
with these simple tests. Maybe you can have your systems people try
out these tests on your database server to see if they get the same
results?

Re: [OPEN-ILS-GENERAL] Accession numbers, copy notes and diacritics in call numbers

[Linda Jansova]

Hi,

I'm just posting my questions (see below) once again. So far there has 
been no reply but - as you can see - I haven't given up yet :-)...


Thank you very much in advance :-)!

Linda

Dne 18.7.2011 17:06, Linda Jansova napsal(a):

Hi all,

Three more questions to ask:

1) In the Czech Republic, libraries usually use accession numbers for 
individual copies. These are not accession numbers related to bib 
records but solely to individual copies. Is it okay to insert these in 
the copy number field in Holdings Maintenance? And if so, how can it 
be inserted during import? Can the staging table 
(http://open-ils.org/dokuwiki/doku.php?id=importing:holdings:import_via_staging_table) 
be used for this purpose?


2) In case we wish to record how a particular copy has been aquired 
(bought, received as a gift etc.), should we use copy notes (say 
with a locally standardized copy note title distinguishable from other 
types of copy notes)?


3) In case we use diacritics in call numbers, is there a way to make 
the Shelf Browser show first the particular letters letters without 
diacritics and then those with diacritics? E.g. to have the letter Č 
after the letter C instead of somewhere at the beginning of the 
virtual shelf? (We are especially interested in Czech alphabet - the 
correct order of letters is available at 
http://en.wikipedia.org/wiki/Czech_alphabet.) Or maybe is it better do 
do without and use only call numbers with decent ;-) letters?


Thank you in advance for sharing any thoughts and ideas :-)!

Linda

[OPEN-ILS-GENERAL] Accession numbers, copy notes and diacritics in call numbers

[Linda Jansova]

Hi all,

Three more questions to ask:

1) In the Czech Republic, libraries usually use accession numbers for 
individual copies. These are not accession numbers related to bib 
records but solely to individual copies. Is it okay to insert these in 
the copy number field in Holdings Maintenance? And if so, how can it 
be inserted during import? Can the staging table 
(http://open-ils.org/dokuwiki/doku.php?id=importing:holdings:import_via_staging_table) 
be used for this purpose?


2) In case we wish to record how a particular copy has been aquired 
(bought, received as a gift etc.), should we use copy notes (say with 
a locally standardized copy note title distinguishable from other types 
of copy notes)?


3) In case we use diacritics in call numbers, is there a way to make the 
Shelf Browser show first the particular letters letters without 
diacritics and then those with diacritics? E.g. to have the letter Č 
after the letter C instead of somewhere at the beginning of the 
virtual shelf? (We are especially interested in Czech alphabet - the 
correct order of letters is available at 
http://en.wikipedia.org/wiki/Czech_alphabet.) Or maybe is it better do 
do without and use only call numbers with decent ;-) letters?


Thank you in advance for sharing any thoughts and ideas :-)!

Linda

Re: [OPEN-ILS-GENERAL] Tags and labels in bib records, shortcut keys in staff client

[Linda Jansova]

Jason and Dan, thank you both for your replies, now I know exactly what 
I needed :-)!


Linda

Dne 14.7.2011 15:30, Dan Scott napsal(a):

On Thu, Jul 14, 2011 at 9:22 AM, Jason Etheridgeja...@esilibrary.com  wrote:

Hi Linda,


Is there a way to make (customized) textual descriptions of MARC fields
visible - instead of the usual tags?

It'd take some programming however you slice it.


If one opens the staff client, chooses an item from the menu and then the
subitem, in some cases some letters are underlined and that letters (in each
case a single letter) are a part of the shortcut key. My questions is this -
how are these letters chosen? As we use both the native English and the
translated Czech version of the staff client, this would be a very useful
piece of information for us...

They're not chosen programmatically, but by hand.

So for example, we have a file containing entities like this:

!ENTITY staff.cat.opac.menu.accesskey A
!ENTITY staff.cat.opac.menu.label Actions for this Record

And the label is what gets displayed, and the accesskey is what gets
underlined.  These are defined initially in English, and then
translated.  There are a few principles that we (or maybe I) try to
adhere to when choosing the accesskey, but they're not explicit, and
we're not consistent.  I have no idea what translators do and whether
they test their choices for usability. :(

Translators don't see the separate ENTITY definitions; the
translate-toolkit translation tools combine those into a single string
in the POT/PO files with an ampersand () marker for the access key
and that's what is presented to the translator.

So the English string is:Actions for this Record

And the current Czech translation is:Akce pro tento záznam

In each case, the access key will be A.

[OPEN-ILS-GENERAL] Tags and labels in bib records, shortcut keys in staff client

[Linda Jansova]

Hi,

Maybe the following questions are slightly silly but I'll be courageous 
enough and ask them anyway ;-):


Question # 1 - concerning cataloging templates in staff client (for EG 
2.0 or the latest release):


Is there a way to make (customized) textual descriptions of MARC fields 
visible - instead of the usual tags? E.g., to see Title Statement (or 
a translation of this expression into the Czech language or other words 
which can be helpful to the cataloger) instead of 245? Now the tags 
are visible straightaway and the description is visible as an 
alternative text only... I am well aware that this may not be possible 
without some hacks (in that case I wouldn't go for it) but in case it is 
possible to make it happen without severely wounding Evergreen, it may 
be a path to follow (at least for us :-)...


Question # 2 - concerning shortuct keys in staff client (also for EG 2.0 
or the latest release):


If one opens the staff client, chooses an item from the menu and then 
the subitem, in some cases some letters are underlined and that letters 
(in each case a single letter) are a part of the shortcut key. My 
questions is this - how are these letters chosen? As we use both the 
native English and the translated Czech version of the staff client, 
this would be a very useful piece of information for us...


Thanks in advance for sharing your ideas regarding these two topics!

Linda

Re: [OPEN-ILS-GENERAL] Bib records not indexed - Evergreen 1.6.0.3

[Linda Jansova]

 Hi Dan,

Thank you very much for testing those records in 2.0 :-)! Since we are 
currently using Evergreen for a small private library (presumably first 
in the Czech Republic to use Evergreen), we should be able to upgrade to 
2.0 when it becomes available. Supposing the bib records get reindexed 
after the upgrade, it will hopefully work fine :-).


At the same time we are working with a bigger library (part of JABOK, a 
school focusing on social pedagogy and theology) and planning to do the 
migration in the fall, so we will probably wait for 2.0 version. So it 
will be our pleasure to help with some testing :-).


Linda Jansova and Vaclav Jansa

Dne 11.9.2010 04:23, Dan Scott napsal(a):

On 10 September 2010 02:42, Linda Jansovaskolk...@chello.cz  wrote:

  Dan, thanks for the explanation and also for the positive news that
Evergreen 2.0 should be able to handle these characters without problems
:-)!

Deanna, I believe that USMARC or SUTRS syntax should not be the problem as
other bib records in USMARC format have been processed correctly.

BTW, we encountered problems with these characters also in the older
versions of Evergreen we experimented with earlier - an example (which is
still valid)  would be a record from the Library of Congress (TCN 3760924
- or it can be found using Author Čapek, Karel and Title RUR :-). Maybe this
could also be an example worth trying in Evergreen 2.0...


Hi Linda:

I had a few minutes this evening and tried the NKC examples and the
Library of Congress example that you gave (thanks for such a clear
description of the problem and such great sample data!); all of the
examples imported perfectly and get indexed properly; keyword searches
and title searches retrieve the records. So, good news on that front!

If you're wondering about the timing of Evergreen 2.0, we'll be
putting out a second alpha release of Evergreen 2.0 soon, with a beta
release expected in October, and then more betas until we stamp out
all of the bugs our determined testers find, hopefully resulting in a
final release in December or January. It would be great if you could
help us with some early testing of 2.0!

Dan

Re: [OPEN-ILS-GENERAL] Bib records not indexed - Evergreen 1.6.0.3

[Linda Jansova]

 Dan, thanks for the explanation and also for the positive news that 
Evergreen 2.0 should be able to handle these characters without problems 
:-)!


Deanna, I believe that USMARC or SUTRS syntax should not be the problem 
as other bib records in USMARC format have been processed correctly.


BTW, we encountered problems with these characters also in the older 
versions of Evergreen we experimented with earlier - an example (which 
is still valid)  would be a record from the Library of Congress (TCN 
3760924 - or it can be found using Author Čapek, Karel and Title RUR 
:-). Maybe this could also be an example worth trying in Evergreen 2.0...


Linda

Dne 9.9.2010 17:08, Dan Scott napsal(a):

On Thu, 2010-09-09 at 08:04 +0200, Linda Jansova wrote:

It seems that the use of letters such as Ú or Č at the beginning
of
fields such as 100 a or 710 a may cause the problem (although it is
merely an assumption of ours).

Is there any way how this complication can be overcome and the
records
get indexed properly?

In Evergreen 1.6.x, as part of the indexing, all records get passed from
Perl through a server-side JavaScript routine then back to Perl, and
that seems to be a little shaky with handling Unicode. We've found in
the past that some characters need their Unicode normalized to NFC
(composed), and some need to be normalized to NFD (decomposed), to pass
through the JavaScript routine safely, and some don't make it through at
all (http://markmail.org/search/?q=NFC+NFD+import
+list:org.georgialibraries.list.open-ils-dev). I suspect this is what is
causing your problems.

The good news is that Evergreen 2.0 does away with the server-side
JavaScript routine and performs all of the indexing directly in the
database, so it should just work. I'll try importing some of those
records in a 2.0 test server when I get a chance, but I'm confident that
it will work. The bad news is that Evergreen 2.0 is still only at an
alpha release stage at this point, so relief won't be available in a
stable release for some time yet.

[OPEN-ILS-GENERAL] Bib records not indexed - Evergreen 1.6.0.3

[Linda Jansova]

Hi,

We have (in Evergreen 1.6.0.3) successfully downloaded (via Z39.50) a 
number of bibliographic records from Czech libraries -- especially from 
the National Library of the Czech Republic, from the Librarianship 
Institute Library and from the Union Catalog of the Czech Republic.


However, we have come accross a strange problem -- some of the 
downloaded records do not get properly indexed in Evergreen and so using 
keywords to find them in the catalog does not work (even in case 
holdings are already attached). We have only managed to find the records 
using the TCN search.


The records in question have been downloaded using the following Z39.50 
settings in Evergreen:


NKC
!-- NKC does not require username/password --
nameNKC/name
hostaleph.nkp.cz/host
port9991/port
dbNKC-UTF/db
record_formatFI/record_format

!-- Record transmission format from the server.  Supported --
!-- formats include usmarc and xml (for marcxml). --
transmission_formatusmarc/transmission_format

attrs
tcncode12/codeformat1/format/tcn
isbncode7/codeformat6/format/isbn
authorcode1003/codeformat6/format/author
titlecode4/codeformat6/format/title
issncode8/codeformat1/format/issn
publishercode1018/codeformat6/format/publisher
pubdatecode31/codeformat1/format/pubdate
/attrs
/NKC


SKC
!-- SKC does not require username/password --
nameSKC/name
hostaleph.nkp.cz/host
port9991/port
dbSKC-UTF/db
record_formatFI/record_format

!-- Record transmission format from the server.  Supported --
!-- formats include usmarc and xml (for marcxml). --
transmission_formatusmarc/transmission_format

attrs
tcncode12/codeformat1/format/tcn
isbncode7/codeformat6/format/isbn
authorcode1003/codeformat6/format/author
titlecode4/codeformat6/format/title
issncode8/codeformat1/format/issn
publishercode1018/codeformat6/format/publisher
pubdatecode31/codeformat1/format/pubdate
/attrs
/SKC


KKL
!-- KKL does not require username/password --
nameKKL/name
hostaleph.nkp.cz/host
port9991/port
dbKKL-UTF/db
record_formatFI/record_format

!-- Record transmission format from the server.  Supported --
!-- formats include usmarc and xml (for marcxml). --
transmission_formatusmarc/transmission_format

attrs
tcncode12/codeformat1/format/tcn
isbncode7/codeformat6/format/isbn
authorcode1003/codeformat6/format/author
titlecode4/codeformat6/format/title
issncode8/codeformat1/format/issn
publishercode1018/codeformat6/format/publisher
pubdatecode31/codeformat1/format/pubdate
/attrs
/KKL

All of these are used without usernames and passwords.

The TCNs of the problematic records are the following (the records can 
be downloaded using the Accession # or TCN (in case local catalog is 
included in the targets to be searched) search box):


nkc20061687667
spoj008315
KN314800416268
nkc20051627559
np9310787
cpk19960137165
cpk19960137167
cpk20010997473
m0225675
spoj016730
spoj033909
cpk20030053035
nkc20091928001
cpk20070063851
cpk20050058496
zpk20060061459
cpk20031173817


It seems that the use of letters such as Ú or Č at the beginning of 
fields such as 100 a or 710 a may cause the problem (although it is 
merely an assumption of ours).


Is there any way how this complication can be overcome and the records 
get indexed properly?


Thank you in advance for your help!

Linda Jansova

Re: [OPEN-ILS-GENERAL] Profile Group in 1.6.0.3

[Linda Jansova]

 Dear Kathy,

Thank you very much for your advice - it has worked and so now we can 
proceed further :-)!


Linda

Dne 31.8.2010 14:54, Kathy Lussier napsal(a):

Hi Linda,

You might want to check to see if the group_application.user and the
group_application.user.patron permissions have been enabled for your local
admin and circ groups.

Kathy Lussier


-
Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 756-0172
(508) 755-3721 (fax)
kluss...@masslnc.org
IM: kmlussier (AOL  Yahoo)
Facebook: http://www.facebook.com/techielibrarian
Twitter: http://www.twitter.com/kmlussier



-Original Message-
From: open-ils-general-boun...@list.georgialibraries.org [mailto:open-ils-
general-boun...@list.georgialibraries.org] On Behalf Of Linda Jansova
Sent: Tuesday, August 31, 2010 2:10 AM
To: Evergreen Discussion Group
Subject: [OPEN-ILS-GENERAL] Profile Group in 1.6.0.3

Hi,

I am just trying to create patrons in Evergreen 1.6.0.3 but I don't seem
to see profile groups (in section 4. Groups and Permissions of the
registration form). I only see it when logged in as admin but I do not
see it when I change the login to local admin, circ etc.

Does anyone have any idea how to make the profile groups visible?

Thanks in advance for any suggestions!

Linda

--
Mgr. Linda Jansova
E-mail: linda.jans...@ff.cuni.cz, skolk...@chello.cz

Ustav informacnich studii a knihovnictvi
Filozoficka fakulta, Univerzita Karlova v Praze
--
Institute of Information Studies and Librarianship
Faculty of Arts, Charles University in Prague
http://uisk.ff.cuni.cz/

Paths are made by walking. Franz Kafka

[OPEN-ILS-GENERAL] Profile Group in 1.6.0.3

[Linda Jansova]

Hi,

I am just trying to create patrons in Evergreen 1.6.0.3 but I don't seem 
to see profile groups (in section 4. Groups and Permissions of the 
registration form). I only see it when logged in as admin but I do not 
see it when I change the login to local admin, circ etc.


Does anyone have any idea how to make the profile groups visible?

Thanks in advance for any suggestions!

Linda

--
Mgr. Linda Jansova
E-mail: linda.jans...@ff.cuni.cz, skolk...@chello.cz

Ustav informacnich studii a knihovnictvi
Filozoficka fakulta, Univerzita Karlova v Praze
--
Institute of Information Studies and Librarianship
Faculty of Arts, Charles University in Prague
http://uisk.ff.cuni.cz/

Paths are made by walking. Franz Kafka

[OPEN-ILS-GENERAL] MARCXML sample data for 1.6.0.3?

[Linda Jansova]

Hello everybody, 

we are just trying to import some bibliographic data in MARCXML format using
Evergreen MARC File Upload in 1.6.0.3 version but apparently we are doing
something wrong as none of our attempts has been successful so far. 

Are there any sample data in MARCXML format which we could work with -
meaning upload them directly to Evergreen using staff client (for 1.6.0.3)
only?

Thanks in advance!

Linda

**
Linda Jansova (Skolkova), M.A.
E-mail: linda.jans...@ff.cuni.cz, skolk...@chello.cz 
 
Instutite of Information Studies and Librarianship
Faculty of Arts, Charles University, Prague
http://uisk.ff.cuni.cz/ 
**
Paths are made by walking. Franz Kafka