Bug 12090 - Disabling Library Location
Summary: Disabling Library Location
Status: RESOLVED DUPLICATE of bug 12450
Alias: None
Product: Koha
Classification: Unclassified
Component: System Administration (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-04-15 22:03 UTC by Christopher Brannon
Modified: 2020-06-26 17:50 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Christopher Brannon 2014-04-15 22:03:03 UTC 
There needs to be a way to disable a library easily.  There are libraries in our consortium that close for the summer, and currently we have a library that is closed due to structural damage.  Right now, to disable the library, we have to make all item types for that library non-holdable, hide there library in the pickup location dropboxes in at least 3 places, and it looks like we might have to also disable their values in the transport cost matrix.  By the way, when we do this, we lose all values, and have to re-enter them when the library is operating again.

It would be great if there were a switch next to the library in Libraries and Groups that would allow us to enable/disable the library and all items and traffic with one switch.

Christopher
Comment 1 Lisette Scheer 2018-09-12 17:07:46 UTC 
We also have schools in our consortium that close for the summer and being able to just set them as closed with a button would be great. 

Lisette
Comment 2 Katrin Fischer 2019-02-04 23:15:54 UTC 
Just a ntoe: there is HoldsQueueSkipClosed now that might help with some of the issues mentioned.
Comment 3 Katrin Fischer 2020-01-05 14:39:15 UTC 
Opting for the newer bug as it has had a bit more discussion.

*** This bug has been marked as a duplicate of bug 12450 ***
Comment 4 Christopher Brannon 2020-01-06 15:41:27 UTC 
(In reply to Katrin Fischer from comment #2)
> Just a ntoe: there is HoldsQueueSkipClosed now that might help with some of
> the issues mentioned.

This is a tricky preference.  I'm not finding sufficient information on it.  If this option is set to closed, is the hold queue re-evaluated and a hold moved over to a library if it becomes open while the hold is still in a request state?  For example:

Library A & B have book in question.
Library A is closed 3 days out of the week, but is the closer library.
Book goes on hold the last of the 3 days library A is closed, and goes into library B's queue.
The next day, both libraries are open, and the hold hasn't been filled yet.

Does the hold request move to library A the next day, or does is stay stuck to library B?
Comment 5 Katrin Fischer 2020-01-22 22:31:16 UTC 
I guess you'd have to test that out - my understanding is that the holds queue is rebuilt every run of the cron... if that assumption is correct, it should move.
Comment 6 Katrin Fischer 2020-01-22 22:33:18 UTC 
(In reply to Katrin Fischer from comment #5)
> I guess you'd have to test that out - my understanding is that the holds
> queue is rebuilt every run of the cron... if that assumption is correct, it
> should move.

Yep, it starts fresh with every run:

 174 sub CreateQueue {
 175     my $dbh   = C4::Context->dbh;
 176 
 177     $dbh->do("DELETE FROM tmp_holdsqueue");  # clear the old table for new info
 178     $dbh->do("DELETE FROM hold_fill_targets");
Comment 7 Christopher Brannon 2020-06-26 17:50:12 UTC 
Thanks for the info.  Good to know.  This does make a difference.  I will continue my campaign on the other bug.