C/W MARS is looking at potential development on this function and is
looking for community comment.
*Idea:* Ability to set parts order
*
*
*Description:* Parts are currently appearing in no real discernible order.
We would like to be able to define the order in which they appear.
*
*
Under use case #2, how would you then configure the system so that you
could easily remove the item from storage to available in a case where
storage is a temporary status?
Elaine
_
J. Elaine Hardy
PINES Bibliographic Projects Metadata Manager
Georgia Public Library Service
1800
I'm not sure but I think there are two ways the interface could work (and
I could envision both options being available).
- A flag in the copy record that indicates the status is essentially
sticky and return after reshelving to the status once it is checked in.
- Another field where
My personal view is that the status should still go to Available, period.
However, I could see assigning a field that overrides for display
purposes in the OPAC. A table of such values could include a Always
or just when Available flag, and doing something like %s in the name
could inject
Hi Tim,
In general ordered parts and parts display in the TPAC would be a very good
thing, I'm sure. I am curious, though, about parts' relationship to
serials.
How are you making your received serials issues into parts? I'm not
familiar with any way that Evergreen would do this for you
Hi Lebbeous,
I won't speak for Tim on the grouped serials display, but I have spent
some time looking at the display and, overall, prefer this display over
the default serials display. However, in my testing, I've found you
can't display a textual holdings statement from the 866 field when
Kathy,
That's a great observation, and to answer your question, no, not currently.
However, I would think the development time needed to show textual
holdings alongside the grouped serials display would be less than efforts
that combine serials and parts (unless I'm missing something).
Thanks,
Lebbeous,
The grouping might work well in most instances and Kathy told me about this
yesterday but as she points out there are issues with the 866 in the MFHD.
For some clarification, I can explain the workflow of our libraries using
the serials functions now:
1. Receive a serial in Serials
Hi all,
Just a reminder that the next batch of point releases will be cut tomorrow.
Please try to wrap up any merging today.
Thanks,
-b
--
Bill Erickson
| Senior Software Developer
| phone: 877-OPEN-ILS (673-6457)
| email: ber...@esilibrary.com
| web: http://esilibrary.com
| Equinox
Hi Tim,
I see! Let's suppose for the moment that your staff's need to use parts
for serials could be obviated by two features.
The first such feature, issue-level holds, reachable through the grouped
serials display, may be serviceable already. The second feature, to
display 866 (and other?)
Tim,
Kathy informs me via IRC that a wishlist bug for copy stat cats applicable
to serials already exists!
https://bugs.launchpad.net/evergreen/+bug/1078795
So that's good. I would still be interested in knowing whether you agree
that, combined with the other features discussed, might save your
Lebbeous,
If we had it working the way you describe, that would generally address our
needs including Kathy's wishlist. We still have libraries that do not use
any of the serials functions (and probably never will) so they will be
creating individual copies straight through cataloging and
12 matches
Mail list logo
