Thanks to everyone for your feedback on this idea. What I've distilled out of this: - Cart used to work off items, but switched to biblios for a reason - In some contexts, users don't care about particular items, only titles, so the system would need to continue function on the OPAC just like user's are used to - In other contexts, users DO care about which volume, issue or version of a material they're adding, and having the option to pick that one specifically could be handy - In a multi-branch setup, there should be an option to only add items from one's home library. - All the hard work should be done developer-side in order to make the interface experience as consistent and simple as possible. Perhaps item-based Cart makes more sense on the staff side only. Or, maybe having two separate Carts, Biblios and Items, would be the way to go, though that seems to be overcomplicating things. Thank you all for helping me understand this idea a little better; one of the many reasons why I love being part of this community so much. Cheers, -Ian On Wed, Mar 9, 2011 at 3:10 AM, LAURENT Henri-Damien < henridamien.laurent@biblibre.com> wrote:

Le 08/03/2011 22:32, Ian Walls a écrit :

...

Koha Community,

I'd like to solicit some feedback on this idea. It seems to me that we could greatly increase the utility of the Cart, both on the patron side and the staff side, if we had it work off Item records primarily instead of the Biblio record. Some things we'd be able to do from the Cart if we had this:

1. Batch Item mod 2. Move items from multiple biblios to a single new biblio, in one step 3. Print label batches 4. Place item-level holds (in addition to title-level)

Since item records all contain the biblionumbers for their Biblios, it would be a single additional step to convert the list of itemnumbers into a list of distinct biblionumbers, and do all the same biblio-level functions we do now (like biblio-level holds, emailing/printing, and adding to Lists).

Am I missing a complication in the implementation or a workflow issue that would make this untenable? What does everyone think?

Cheers,

-Ian

Hi Ian I think that one thing you are missing is the user point of view of the cart. From the OPAC user point of view, you donot care of items, what you want is to be able to read the book or the collection you placed on your cart. So Yes, we could add item level for Cart, like we did for reserves. But it should not be done without taking into account the OPAC users' need. And it should be done with cautious, since when doing batch operations with your cart, you would have to take care of ppl doing the same operation in // . (I reckon this has not been dealt with many of our developments, reserves, batch edits... But maybe could be added) Maybe it would be the time to consider having OPAC and intranet as separate applications. But this would duplicate the effort and maintenance. Hope that helps. -- Henri-Damien LAURENT _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal

2011/3/10 Robin Sheat <robin@catalyst.net.nz>:

...

Or, maybe having two separate Carts, Biblios and Items, would be the way to go, though that seems to be overcomplicating things.

Presumably an option so that a cart can contain both items and biblios would be a good middle-ground. A little more complex to deal with programmatically, but if written properly it shouldn't be too bad. It would also be easy to have a syspref that lets this be items only/biblios only/both, as it would just have to change a bit of OPAC UI.

Wow, the fact that carts are biblio-level is news to me, and actually throws a bit of a spanner in the works for my plans for using item-level item-types. I was really hoping to take advantage of the fact that I could have different types of items associated with a single biblio record. But it seems if I go this route, then I should disable Carts for patrons? Is that even an option? To review my situation with an example:

My current use case is that I have multiple media types for a single film. It's all exactly the same video, not a different edition, but one might be a disc that's playable on a consumer player (Disc-Video), another may contain computer files (Disc-Data), another combines both (Disc-Mixed), some of our VHS tapes haven't been converted yet, and some really old home movies are even on 35mm!

If I catalog these as separate biblios, this will creates multiple identical copies of the biblio-level MARC data, and just different ("holdings level") data in the items table, including item type. So when a patron searches for "2009 Proms Gala" they will get four identical but separate results. Also, I'm planning on using user tagging, virtual shelves, etc. which if I use duplicated biblio-level item-types will somehow need to be synchronized between duplicate biblio records - yech! Any advice would be appreciated