Bug 11354 - NewItemsDefaultLocation Override in Cataloging
Summary: NewItemsDefaultLocation Override in Cataloging
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low trivial (vote)
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-07 16:18 UTC by Ian Palko
Modified: 2015-06-04 23:24 UTC (History)
1 user (show)

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


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ian Palko 2013-12-07 16:18:31 UTC
The value of NewItemsDefaultLocation indiscriminately sets the location of a new item to this value.

That is, when adding a new item, no matter what the cataloger sets for 952$c, the record defaults to the preference value, even if 952$c is not null.

The matter is trivial, because one can easily just edit the item after the addition, and the edit sticks.

It would be nice, however, for the NewItemsDefaultLocation value to only be applied to a new record when 952$c is null. If non-null, the default should not be applied.
Comment 1 Owen Leonard 2014-11-20 16:01:04 UTC
I think this bug is invalid, but I hope others will give their opinions as well:

If NewItemsDefaultLocation is turned on, items which are added get the PROC shelving location by default. I think this is what libraries expect when they turn on the preference.

If you select a specific shelving location when you're adding the item, the "current shelving location" (items.location) is set to "PROC," as it should be, and the "permanent shelving location" (items.permanent_location) is set to the value you chose in the item editor. That means that the when the item is checked in and the PROC location is removed, the value in items.permanent_location will be copied to items.location.

I think that, especially with the patch for Bug 13297, this works as it should.
Comment 2 Ian Palko 2014-11-20 20:40:05 UTC
Owen,

I think you mistake my original commentary, or maybe I made a mistake.

It was the 952$c I was concerned with, not $a (Permanent Location) or $b (Current Location.

We default 953$c to our "General Stacks" for new items. This means they don't go to PROC at all.

What I would like it to set an override for the shelving location, when creating a new item, so I can easily add Reference books or Periodicals to a different set of shelves in our library.

As it stands now, when I catalog any book it gets the shelving location "General Stacks". If I choose a different shelving location when cataloging, I still get "General Stacks". This means for a set of Reference items or Serials, I have to add the items, then go back and bulk edit the whole batch I just added to change the location to "Reference Stacks" or "Periodical Stacks".

That is not a great burden, but easily is forgotten by my catalogers. One more step, you know.

It would be much easier to be able to choose the shelving location when adding an item, and if none is chosen, to default to the preference.

This would be especially helpful when using the "Add and Duplicate" feature to enter large sets.

Perhaps given the way koha handles this, I'm just going about it wrongly, though.
Comment 3 Owen Leonard 2014-11-24 18:31:20 UTC
It sounds to me like you don't want to have anything set in the NewItemsDefaultLocation preference, because the shelving location you set there isn't intended to be permanent. It's intended to be temporary ("When items are created, give them the *temporary* location of...").

You should only use NewItemsDefaultLocation if you want to set a temporary shelving location which indicates a central processing location or something like that. The intention of the preference is that whatever shelving location you specify is replaced with the permanent shelving location upon check-in.
Comment 4 Ian Palko 2014-11-25 14:43:40 UTC
Owen,

Thanks for the lesson.

You're entirely right. Unfortunately, being an engineer by training before entering the seminary and getting tasked with cataloging and running our 40,000+ volume seminary library, I have ingrained habits. Often I just jump in the driver's seat and figure it out as I go.

We'll be fixing our process.

I concur, the bug is invalid. I have marked it as such.