Unsuppressing works - Version 2
Submitted by John Springett on Wed, 2007-01-31 14:30.
This script seems to unsuppress everything that is 'In Stock', even if it wasn't suppressed in the first place. Is this correct? I've managed to tell it not to unsuppress our ILL's and serial volume entries but has anyone managed to reduce the number of items unsuppressed. I thought I'd done it by telling it to only retrieve the SUPPRESS_FROM_INDEX='T' items from the WORK_META table but I must be doing something wrong.
Cheers
John
Unsuppressing works
The script is designed is to select batches of works as defined by the -b and -e range to check if the work should be unsuppressed. Items are not suppressed as you mention in the posting although the items attached or not attached to a work will be govern if the work is unsuppressed.
For each work processed if the work is of deleted status the next work is used.
If the work is not of deleted status then the script will check if the work is unsuppressed based on whether there is a row in the WORKS_META table.
The script then checks the work to see if there are any available items now based on the various parameter settings than would mean that the work should now be unsuppressed.
Currently the script checks the WORKS_META table by running the following subroutine for each work that is not of deleted status.
sub already_suppressed_marc21
{
my ($work_id) = @_;
my ($rowcount) = &sql($d, " select count(*)
from WORKS_META
where WORK_ID = $work_id
");
return 0 if (!$rowcount);
return 1;
}
As you can see it does not check the SUPPRESS_FROM_INDEX attribute. This means that it would be processing works that are not suppressed but are in the table. Although this should only mean that more effort is done than is strictly necessary and should be corrected.
What I suggest is updating the section above in the script with this code:
my ($rowcount) = &sql($d, " select count(*)
from WORKS_META
where WORK_ID = $work_id
and SUPPRESS_FROM_INDEX='T'
");
If you can test this, initially on the MIS server and that solves the issue then I will update the download.
Thanks
Brian Crampton
Developer, Talis
Unsuppressing works - Version 2
Thank you, this worked perfectly on our MIS. I just changed it so to not included our I'lls or serials as I'm sure works have been suppressed with hundreds of 'in stock' volumes. We are waiting on a new server so when it arrives this script will be run in our cron at least once a week maybe more.
Thanks again
John
Unsuppressing works update
The unsuppress script v2 has been updated to only look at already suppressed works.
Brian Crampton
Developer, Talis
work_unsuppress_2.pl script update
The work_unsuppress_2.pl script has been updated to correct a minor issue with the default parameter name and to ensure the changes in this thread are up-to-date.
If you have previously downloaded the script please download the new version on the Talis Alto Scripts Page and replace any previous versions.
Thanks
Brian Crampton
Developer, Talis
Unsuppressing works
Although I've just noticed that ILL's now create M control number and not 'I' as before!! So these will all be unsuppressed and display on the catalogue.
Interloans works
The type of control number shouldn't have an effect on the display of the a work used for an interloan only. I say shouldn't as I don't know your local configuration.
If you find works are appearing that weren't before then it needs to be investigated and your local settings taken into account.
Also what did you alter in the script to avoid serials and interloans? Someone else may wish to do the same in the future.
Thanks
Brian Crampton
Developer, Talis
Unsuppressing works
I was using the control number to filter out the interloans but I'm now using -
my (@works_rows) = &sql($d,"
select WORK_ID, STATUS, CONTROL_NUMBER
from WORKS
where WORK_ID >= $start_id
and MONOGRAPH='T'
and WORK_ID not in (select WORK_ID from ILL_REQUEST)
and WORK_ID <= $end_id");
This all seems to work.
Thanks for your help,
cheers.
John
Usuppressing works update
This bit was missing from the bottom of my previous post:
and WORK_ID >= $end_id");
This all seems to work.
Thanks for your help,
cheers.
excluding an "unsupression" on basis of Sequence
Our ILLs all have a sequence of "ILL" within Talis, and are manually supressed from OPAC (with the tickbox)as they are added to stock. Unfortunately these are being unsupressed each time the work_unsuppress_2.pl script is run, as it only filters things out by Status.
This is not a problem in the longrun, as they are all unsuppressed when they are finally returned to another authority either manually, or because they are withdrawn from stock, and the work_logdelete.pl script picks them up.
I would like to add some code to the work_unsuppress_2.pl script so that items with the "ILL" sequence are excluded from unsuppression, as the window of time before they are finally returned is typically several weeks, and we would like them to be unreservable during that period.
Any ideas what code I should use, and where it should be inserted?
excluding on basis of sequence
I'm not entirely sure why the changes above would not work for you as if the work was requested through the interloan module then it would be in the ILL_REQUEST table and the item sequence wouldn't matter.
However if you don't want to include items of a particular sequence in the items to be checked for a work then you can modify the check_for_items subroutine in the script.
At the moment it is
sub check_for_items
{
my ($work_id) = @_;
(@item_rows) = &sql($d, " select STATUS_ID
from ITEM
where WORK_ID = $work_id");
return @item_rows;
}
The select statement could be changed to
sub check_for_items
{
my ($work_id) = @_;
(@item_rows) = &sql($d, " select STATUS_ID
from ITEM
where WORK_ID = $work_id
and SEQUENCE_ID != 'ILL'
");
return @item_rows;
}
I have assumed that the sequence code is ILL but change it as required. Because a not statement is being used script performance may be affected.
I think this will work but as usual test the changes fully on your MIS server until you are happy that the correct database updates are being made before running on the live server.
Brian Crampton
Developer, Talis