advance notices / pre-overdues

Once again, apologies for the delay in getting the script available!

introduction

At Huddersfield, we’ve recently gone live with a bespoke Perl script for generating pre-overdue emails:

advanceNotices.pl
settings.ini

To run the script, use the following command:

perl advanceNotices.pl settings.ini

You can use multiple settings files and then just tell the script which settings to use, e.g.:

perl advanceNotices.pl settings1.ini
perl advanceNotices.pl settings2.ini

To run the script, you’ll need the following:

  1. an installation of Perl (e.g. ActivePerl for Windows)
  2. the following Perl modules:
  3. a working ODBC connection to your Horizon database – if you use ODBC for EasyAsk or ReportSmith, then that should do

The script also expects to be able to create log files and these are stored in a subdirectory called logs – create this subdirectory within the directory where you’ve got the script. So, if you run in the script in C:scripts, then create the subdirectory C:scriptslogs.

To use the script, you’ll need to edit the “settings.ini” file and also make a couple of small changes to the Perl script.

the “settings.ini” file

The “settings.ini” file contains the following settings that the script uses to generate the emails:

  • days_in_advance

    The number of days in advance to check for items due back – e.g. if you set it to 1 and run the script on a Monday, then it will generate emails for items that are due back on the Tuesday.

  • debug

    Set this to either yes or no – if set to yes then all emails will be sent to the address(es) specified in the debug_email setting rather than to the patron. You should leave this set to yes until you’ve finished your testing!

  • debug_email

    If debug is set to yes, then all email notices are sent to the address(es) listed in this setting. To send to multiple addresses, separate each address with a space.

  • summary

    Set this to either yes or no – if set to yes then the script will send a summary email to the email address(es) specified in summary_email

  • summary_email

    If summary is set to yes, then a summary email is sent to the address(es) listed in this setting. To send to multiple addresses, separate each address with a space.

  • smtp_server

    Set this to the IP address (or DNS name?) of your SMTP server.

  • email_replyto

    Set this to the email address that the notices should appear to have come from – this is also used as the “reply to” address.

The remaining settings are used to decide which types of borrowers and items are suitable for sending the notices. If you want to send notices to all patrons for all types of items, then simply leave each of the settings blank.

If you prefer to fine tune the borrowers / items, then you need to set up suitable inclusions or exclusions.

So, if you have a specific list of borrower types that you want to send the notices to, then list them in the inclusion settings.

Alternatively, if you have a specific list of borrower types that you don’t want to send the notices to, then list them as an exclusion.

However, don’t try setting both a borrower type inclusion and exclusion, as that doesn’t make sense!

For example, if you only want to send emails to borrower types STU, FTP and PRE, then you’d use:

btype_include         STU FTP PRE

As well as borrower types, you can also add inclusions or exclusions for collection codes, itype codes and location codes.

In the example “settings.ini” file that I’ve posted are the settings we use at Huddersfield. If you look at it, you’ll see that we don’t send emails to lef borrower types (which stands for “left”) and we don’t send notices for the SL location (which is Short Loan).

If you want to, you can create multiple settings files – for example, you might want to send 1 day in advance for everyone except part-time borrowers, and then have another file that’s set up to send 3 days in advance to only the part-time borrowers.

setting up the script

As well as setting up the “settings.ini” file, you need to make a small chance to the script to set up your ODBC connection information. These changes need to made near line 100:

my $dbh = DBI->connect('dbi:ODBC:REPORTSMITH',
      'report', 'abc123', { RaiseError => 1 });

You’ll need to change:

  1. REPORTSMITH – change this the name of your ODBC connection
  2. report – change this to your ODBC connection username
  3. abc123 – change this to your ODBC connection password

final notes

  • At Huddersfield, the script runs daily on the HIP server as a scheduled task.
  • There’s a few lines of code that are commented out relating to providing a direct secure link to the patron’s “items out” page in HIP. Let me know if providing this kind of functionality in your notices is of interest, and then I’ll send you further details of how to do this.
  • You can probably guess that the script isn’t for the faint hearted! If you’re looking for an easy method of implementing pre-overdues, then you might want wait until Dynix build the functionality into Horizon or maybe take a look Alpha-G Consulting solution.
  • I can only offer limited support for the script (d.c.pattern@hud.ac.uk), but I’ll try and make sure that any bugs get fixed.
  • If you spot any errors in these instructions, please let me know!

Finally – have fun and I hope the script comes in useful!

Horizon "reconst" in Perl

Apologies to everyone who was interested in this for the delay in getting it posted!

The Horizon database stores several fields (e.g. title, author, etc) in the format “processed” / “reconst”, where the “processed” column contains the text stripped of punctuation and the indefinite/definite article, and “reconst” contains the stripped characters.

For example, the title “The great Aussie fashion : Australian fashion designers 1984-1985 /” is stored in Horizon as:

processed:
    great Aussie fashion Australian fashion designers 1984 1985
reconst:
    <M /7R-M: MThe

The “processed” version of the title is much more suitable for sorting than the original title.

Browsing through the Horizon mailing list archive, I came across a set of instructions for interpreting the “reconst” value.   As we generate a lot of custom HTML reports at Huddersfield, I decided to have a stab at coding the instructions in Perl:

reconstructTitle.txt

To use it in your own Perl script, just paste the subroutine in and call it with the “processed” and “reconst” strings, e.g.:

reconstructTitle( $processed, $reconst );

I’ve only used the code for reconstructing titles so far, but it might also work with author names, call number, etc.

The code is definitely “beta” and I’m not sure if it handles every “reconst” command yet, but feel free to make use of it.  If you can improve it, please do!

Been way too busy!

No posts for ages because I’ve been too busy at work getting things ready for the start of term – we’re launching out new MetaLib service on Monday. Hopefully things will start to calm down after that!

Anyway, just found this on my hard drive – unfortunately I don’t know who created it, but I’m 99% sure it came from b3ta.com

:-)