[OPEN-ILS-GENERAL] 099 / 090 / 050

2014-08-01 Thread Donald Butterworth
All,

After a decent night's sleep, I reread the email I sent yesterday about LC
call numbers and printing, and realized the  099 / 090 / 050 question has
nothing to do with printing. (Duh)

The question really has to do with what call number is supplied in the call
number display when a new volume is created. I should have asked if
Evergreen follows the 099 / 090 / 050 hierarchy protocol.

Sorry about that,

Don
--

First a question about default call numbers. A bib record potentially could
contain all 3 call number fields for an LC library.
099 Local Free-Text Call Number
090 Local LC-type Call Number
050 LC Assigned Call Number

It would be extremely rare for a bib record to have all three numbers, but
if they were present, the 099 tag should be the one chosen by the system to
print. When an 090 and an 050 are present the system should choose the 090
to print. When only the 050 is present it should print. Is this protocol
being followed in Evergreen?




-- 
Don Butterworth
Faculty Associate / Librarian III
B.L. Fisher Library
Asbury Theological Seminary
don.butterwo...@asburyseminary.edu
(859) 858-2227


Re: [OPEN-ILS-GENERAL] 099 / 090 / 050

2014-08-01 Thread Yamil Suarez
Donald,

We also use LC call numbers and to see the change you are talking
about in the create volume, here is what we did.
We made a change to the table asset.call_number_class in the column
called field using SQL...

from stock values of...

select * from asset.call_number_class;


 id |   name   |   normalizer   |
  field
+--++-
snip
  3 | Library of Congress (LC) | asset.label_normalizer_lc  |
050ab,055ab,090abef


To what we have now...

 id |   name   |   normalizer   |
  field
+--++-
snip
  3 | Library of Congress (LC) | asset.label_normalizer_lc  |
090abef,050ab,055ab

I used some SQL along the lines of (if I recall correctly)...

UPDATE asset.call_number_class SET field = ''090abef,050ab,055ab'
WHERE normalizer = 'asset.label_normalizer_lc'

Though in your case you might want to use something like to put the
099 before the 090...

UPDATE asset.call_number_class SET field = ''099XYZ,090abef,050ab,055ab'
WHERE normalizer = 'asset.label_normalizer_lc'

NOTE: I don't know the subfields values for the 099 tag off the top of
my head, so I put XYZ as placeholders. You will need to look up the
proper subfields for the 099.

Good luck,
Yamil




On Fri, Aug 1, 2014 at 8:43 AM, Donald Butterworth
don.butterwo...@asburyseminary.edu wrote:
 All,

 After a decent night's sleep, I reread the email I sent yesterday about LC
 call numbers and printing, and realized the  099 / 090 / 050 question has
 nothing to do with printing. (Duh)

 The question really has to do with what call number is supplied in the call
 number display when a new volume is created. I should have asked if
 Evergreen follows the 099 / 090 / 050 hierarchy protocol.

 Sorry about that,

 Don
 --

 First a question about default call numbers. A bib record potentially could
 contain all 3 call number fields for an LC library.
 099 Local Free-Text Call Number
 090 Local LC-type Call Number
 050 LC Assigned Call Number

 It would be extremely rare for a bib record to have all three numbers, but
 if they were present, the 099 tag should be the one chosen by the system to
 print. When an 090 and an 050 are present the system should choose the 090
 to print. When only the 050 is present it should print. Is this protocol
 being followed in Evergreen?




 --
 Don Butterworth
 Faculty Associate / Librarian III
 B.L. Fisher Library
 Asbury Theological Seminary
 don.butterwo...@asburyseminary.edu
 (859) 858-2227



-- 





Yamil Suarez, MCS
Library System Administrator/Developer

Stan Getz Library
Berklee College of Music
1140 Boylston St
Boston, MA 02215

ysua...@berklee.edu
617-747-2617


Re: [OPEN-ILS-GENERAL] Bug squashing days

2014-08-01 Thread Kathy Lussier

Hi all,

Unfortunately, it looks like I mistakenly added July dates to the poll 
instead of some of the August dates we were polling. I usually can edit 
a Doodle poll to fix these mistakes, but Doodle just isn't cooperating 
with me on this poll.


Therefore, I had to create a new poll for bug squashing day. The poll is 
available at http://doodle.com/2dx9h3cccwbp84v4. Anyone who filled out 
the first poll will need to enter their dates again on the new poll.


Sorry!

Kathy

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 7/29/2014 1:45 PM, Kathy Lussier wrote:

Hi all,

Based on the discussion at yesterday's developers meeting, I'm putting 
out a poll to find out when people would be available for the Bug 
Squashing Day. To give us plenty of time to get ready, I'm targeting 
the final two weeks of August, but I have excluded days when we have 
previously-scheduled Evergreen meetings (EOB and web team.) The poll 
is available at http://doodle.com/6ush6hyx9pa39pv3.


Once again, this day is not just for developers. We're looking at 
setting up sandboxes to make it easier for people to make it easier to 
test bug fixes. If you think you might be interested in testing 
patches or in helping to confirm bugs, please take time to fill out 
the Doodle poll.


Thanks all! I think it will be a great day and, hopefully, a 
productive one as well!


Kathy

Kathy Lussier
Project Coordinator
Massachusetts Library Network Cooperative
(508) 343-0128
kluss...@masslnc.org
Twitter: http://www.twitter.com/kmlussier

On 7/25/2014 7:27 PM, Kathy Lussier wrote:

Hi all,

Last fall, I put out an e-mail message suggesting community bug 
squashing days- http://markmail.org/message/22six3nkgbhr3f3t. It 
received some support at the time, but I didn't do any follow-through 
to make it happen.


Last week, I took some time to update a local spreadsheet I'm 
maintaining on Launchpad bugs that are important to libraries in the 
three MassLNC networks. I was pleased to remove some bugs that have 
since been fixed, but then I added a whole lot more. We started with 
about 50 bugs on the list, and the number is now at 83. These numbers 
reminded me of how it important it is that we try to allocate some 
time on a community level to fix bugs.


I have a more formal proposal I would like to put forward and, if 
it's agreeable to others, I commit to doing my part to try to make 
these days happen.


Proposal: Evergreen Bug Squashing Days

Goal: The goal of bug squashing days is for contributors and 
volunteers to commit the entire day to the following activities:


* Fixing bugs
* Testing bugs that have pullrequests
* General bug wrangling activities (confirming bugs, marking 
duplicates, etc.)

* Pushing bug fixes into Evergreen (for core committers)

When:
I'm proposing that we try to schedule bug squashing days on a 
quarterly basis. I was thinking August/November/February/May would be 
a good schedule where the bug squashing days aren't running up 
against an Evergreen release.


What is Needed:
* Somebody to work on scheduling the day and set up a wiki page (I 
volunteer, but am happy to hand off the task or work with somebody 
else if needed.)
* Volunteers willing to devote a day of their time to the above 
activities. These volunteers do not need to just be developers or sys 
admins. Anyone can confirm bugs, look for duplicates, or perhaps team 
up with a sys admin to test patches.


Extras:
The idea for these bug squashing days came from similar days 
organized by the Koha community. 
http://wiki.koha-community.org/wiki/Category:Global_bug_squashing_days. 
They do a couple of things that I would love to see for Evergreen bug 
squashing days.


* The Koha community uses this great scoreboard on bug squashing days 
- http://scoreboard.koha-community.org/.  The code for the scoreboard 
is available at https://gitorious.org/scoreboard/scoreboard. It would 
be great if we had a volunteer who was willing to create a similar 
scoreboard for Evergreen bug squashing days.
* The Koha community also has Sandboxes available that makes it 
easier for librarians to test patches. It may be a little difficult 
to pull together something  for Evergreen that's as automated as 
these Sandboxes, but I think it's worthwhile to set a goal to 
eventually have some Sandbox servers available to the Evergreen 
community where patches can be tested (not just on Bug Squashing days).


I've also added this proposal to the agenda for Monday's developers 
meeting. If there is general support for this idea, then I'll put out 
a Doodle poll next week to see if we can schedule a day.


Thanks all!
Kathy