| Time |
Nick |
Message |
| 00:23 |
|
jeff_ joined #evergreen |
| 00:39 |
|
mrpeters left #evergreen |
| 03:05 |
|
zxiiro joined #evergreen |
| 04:27 |
|
gsams joined #evergreen |
| 07:00 |
|
timf joined #evergreen |
| 08:01 |
|
ningalls joined #evergreen |
| 08:03 |
|
collum joined #evergreen |
| 08:10 |
|
kmlussier joined #evergreen |
| 08:20 |
|
mrpeters joined #evergreen |
| 08:25 |
|
mdriscoll joined #evergreen |
| 08:30 |
|
RoganH joined #evergreen |
| 08:37 |
|
kbeswick joined #evergreen |
| 08:38 |
|
akilsdonk joined #evergreen |
| 08:51 |
|
mmorgan joined #evergreen |
| 08:59 |
|
rfrasur joined #evergreen |
| 09:00 |
|
Shae joined #evergreen |
| 09:00 |
|
ericar joined #evergreen |
| 09:10 |
|
dbs joined #evergreen |
| 09:11 |
|
dbs joined #evergreen |
| 09:21 |
|
Dyrcona joined #evergreen |
| 09:37 |
|
gdunbar joined #evergreen |
| 10:19 |
|
yboston joined #evergreen |
| 10:42 |
bshum |
Dyrcona: While not explicit, the logo links back to search for the reason that we removed search from being seen. |
| 10:42 |
Dyrcona |
bshum: Add that to the bug, please. |
| 10:43 |
bshum |
Sure thing. |
| 10:43 |
Dyrcona |
Apparently, our members voted to change that: silly members. |
| 10:44 |
bshum |
I guess it could be more explanatory, but everything counts in screen real estate that small. |
| 10:44 |
Dyrcona |
Yes, of course. |
| 10:44 |
* bshum |
still wants less stuff everywhere. |
| 10:44 |
Dyrcona |
There should be nothing, but a search box and a search button. |
| 10:45 |
tsbere |
Our members voted on the logo being a link to the library back when the default was it linking to evergreen-ils.org |
| 10:46 |
tsbere |
The fact that has changed since in default is a different story entirely for us |
| 10:46 |
dbs |
Yeah. The idea was to do what your members did with the logo, originally |
| 10:47 |
* Dyrcona |
thinks the two questions are orthogonal to one another. |
| 10:47 |
dbs |
Then the logo got a more specific purpose with the MOPAC work |
| 10:47 |
dbs |
but it's not necessarily intuitive either way if it's just a logo |
| 10:48 |
dbs |
mystery navigation |
| 10:50 |
bshum |
Dyrcona: I added a reply to the bug and marked it as "triaged" while we look for further discussion and refinement of the approach I guess. |
| 10:51 |
Dyrcona |
Feel free to set it to invalid. |
| 10:51 |
Dyrcona |
You won't hurt my feelings. :) |
| 10:51 |
bshum |
I was thinking to mark it "Opinion" :) |
| 10:51 |
bshum |
Until someone were to champion it as an area for change |
| 11:03 |
bshum |
Maybe something to do is to add a "Go back to search" type link in your footers that only displays in mobile view. |
| 11:04 |
bshum |
Well |
| 11:04 |
bshum |
I guess that could also be useful in the main view too |
| 11:05 |
bshum |
Basically if using the footers for navigation, that's an option I guess |
| 11:05 |
bshum |
For fun reading, I'm enjoying the many options suggested with http://responsivenavigation.net/ |
| 11:24 |
pinesol_green |
[evergreen|Angela Kilsdonk] Documentation for 2.5 - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=2423f2a> |
| 11:27 |
rfrasur |
am I right in assuming that Circ datas and Publisher datas are from diff sources (with reference to reports)? |
| 11:29 |
|
tfaile joined #evergreen |
| 11:31 |
bshum |
akilsdonk: Hmm, I think in that last commit I see a potential typo for a missing underscore with Default_Patron_Billing Screen.jpg (between Billing and Screen) in the circulation_patron_records.txt file |
| 11:31 |
akilsdonk |
bshum: argh. I thought I got them all. thanks for pointing it out! |
| 11:32 |
bshum |
akilsdonk++ #documenting for the rest of us :D |
| 11:36 |
|
dMiller_ joined #evergreen |
| 11:38 |
pinesol_green |
[evergreen|Angela Kilsdonk] Asciidoc fix - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ed8434b> |
| 11:39 |
akilsdonk |
fixed! bshum++ |
| 11:45 |
|
ktomita_ joined #evergreen |
| 11:55 |
dbs |
what's the convention for hours of operation for days the library is closed: 12:00 - 12:00? |
| 11:56 |
bshum |
It's either that or 00:00 to 00:00 |
| 11:56 |
bshum |
I'll double check |
| 11:56 |
linuxhiker |
anybody having problems with oom killer nailing opensrf on 2.4? |
| 11:56 |
eeevil |
bshum: you're correct |
| 11:56 |
dbs |
bshum++ |
| 11:56 |
dbs |
eeevil++ |
| 11:57 |
bshum |
Yep, clearly I've been staring at the database too long. |
| 11:58 |
bshum |
linuxhiker: I haven't seen that occur in our systems (we're master/master, Evergreen/OpenSRF respectively), but our application servers have so much extra RAM on them that we never touch the limit. |
| 11:58 |
bshum |
I think in our case, I've been watching usage and it hovers around 25 GB or so, while we have 48 GB available overall. |
| 11:59 |
bshum |
linuxhiker: Do you have more specific information on the bricks and how they're configured? Perhaps the opensrf.xml is setting things too high and the physical hardware isn't up to snuff to handle as many child processes for Evergreen services and needs to be rescaled. |
| 12:00 |
bshum |
(just guessing, I might just as easily be making stuff up) :D |
| 12:00 |
linuxhiker |
bshum: Well we certainly don't have that level of resources but then against we have 6 apache servers and 12 app servers, that we load balance |
| 12:00 |
eeevil |
linuxhiker: if you are sure you wont run out of ram+swap, and the oom killer is just being too aggressive, you can disable it. The loss of a service listener process is catastrophic in a full-stack server that does not participate in router cross-registration with other opensrf nodes |
| 12:01 |
eeevil |
and listeners are likely candidates for oom killing IME, when there's high mem pressure |
| 12:07 |
* dbs |
plugging away at providing sample library data (hours, addresses) to use in generating per-library info pages in the TPAC that (naturally) have schema.org markup |
| 12:11 |
|
smyers__ joined #evergreen |
| 12:11 |
bshum |
dbs++ # saw your working branch, looks fun! |
| 12:12 |
dbs |
bshum: there will be much squashing to do, but I think it will be a nice feature for 2.6 |
| 12:17 |
bshum |
Heh |
| 12:24 |
dbs |
A commit with the only comment being "OMG" sums up my brain power at the moment |
| 12:25 |
dbs |
BUT... what is there works now. a nice mix of sample address and hours data for branches, with corresponding display pages |
| 12:25 |
dbs |
Need to add some sample contact info now... |
| 12:38 |
|
dMiller__ joined #evergreen |
| 13:09 |
|
kmlussier joined #evergreen |
| 13:12 |
|
stevenyvr2 joined #evergreen |
| 14:35 |
|
dMiller___ joined #evergreen |
| 14:35 |
bshum |
Dyrcona: So I applied the other commit from bug 1243280 and so far no pointless warning errors anymore. |
| 14:35 |
pinesol_green |
Launchpad bug 1243280 in Evergreen 2.5 "'TypeError: obj.active_services is undefined' error when entering z39.50 MARC import UI" (affected: 2, heat: 10) [Medium,Confirmed] https://launchpad.net/bugs/1243280 |
| 14:35 |
bshum |
I'm testing the different parts of the client and so far, so good. |
| 14:35 |
bshum |
Might apply both commits |
| 14:36 |
Dyrcona |
OK. The other one just makes a useless console warning disappears. |
| 14:36 |
Dyrcona |
It checks if some field exists before using it. |
| 14:36 |
bshum |
Yeah, that's what I thought |
| 14:36 |
Dyrcona |
Should be mostly harmless. :) |
| 14:36 |
bshum |
It seems safe then. |
| 14:37 |
bshum |
Looking at the error/warning log makes my head hurt |
| 14:37 |
Dyrcona |
I have it on my development server and have not noticed anything, but I haven't used it much either. |
| 14:37 |
|
dMiller____ joined #evergreen |
| 14:43 |
pinesol_green |
[evergreen|Jason Stephenson] Eliminate an annoying and useless warning in the JavaScript Console. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=bb4a797> |
| 14:43 |
pinesol_green |
[evergreen|Jason Stephenson] Break out of focus() in cat/z3950.js if obj.active_services is undefined. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=cf9a0d4> |
| 14:51 |
bshum |
phasefx: dbwells: Looking over bug 1260481 and I think that it was decided during 2.5's development not to do the i18n stuff with upgrade scripts? Or that it didn't really matter either way because the function wasn't working properly anyways? |
| 14:51 |
pinesol_green |
Launchpad bug 1260481 in Evergreen "The label on the desk renewal global flag is misleading" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/1260481 |
| 14:51 |
bshum |
Eyeballed Callender's patch and it makes sense to me |
| 14:51 |
bshum |
Other than the i18n question |
| 14:52 |
bshum |
Or wait, let me re-read it again |
| 14:52 |
bshum |
Because actually I think it's wrong |
| 14:52 |
dbs |
the oils_i18n flag isn't processed in upgrade scripts, only on the base schema |
| 14:53 |
bshum |
dbs: Ah, cool. Thanks for confirming that. |
| 14:54 |
bshum |
Okay, I had to read it like 5 times to be sure. |
| 14:55 |
bshum |
Callender++ |
| 14:55 |
bshum |
I just can't read |
| 14:55 |
Callender |
lol thanks Ben |
| 14:56 |
bshum |
Calling 0849 |
| 15:05 |
pinesol_green |
[evergreen|Steven Callender] Updated the label on the desk renewal global setting. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=7853a5f> |
| 15:05 |
pinesol_green |
[evergreen|Ben Shum] Stamping 0849 - desk renewal description - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=d0d6a7d> |
| 15:14 |
berick |
looks like latest safari works fine w/ staff prototype. coool |
| 15:15 |
bshum |
I'm sure that'll make iPad users happy? :P |
| 15:18 |
RoganH |
bshum: the mobile safari and desktop have some big differences despite having the same name so no guarantee lol |
| 15:18 |
bshum |
RoganH: Yeah I believe that... |
| 15:19 |
berick |
ditto Opera |
| 15:19 |
RoganH |
Actually it's odd, I have no trouble with your dev server Bill under Safari but Chrome on my Macbook doesn't seem to like it |
| 15:19 |
berick |
if you feel like sharing, i'm all ears |
| 15:21 |
RoganH |
Let me see the error again. |
| 15:22 |
RoganH |
Nevermind. I think I was doing something stupid repeatedly like capitalizing the 'a' or something. |
| 15:22 |
RoganH |
It's one of those days. |
| 15:24 |
dbs |
bug 1261896 is in, more to come |
| 15:24 |
pinesol_green |
Launchpad bug 1261896 in Evergreen "Move sample library data from seed data into sample data" (affected: 1, heat: 6) [Wishlist,New] https://launchpad.net/bugs/1261896 |
| 15:24 |
bshum |
dbs++ |
| 15:24 |
berick |
RoganH: gotcha, thanks for checking |
| 15:24 |
berick |
dbs++ indeed |
| 15:38 |
mrpeters |
so, what is the proper path from 2.3.12 > 2.4.0 these days? when i upgraded someone about 3 months ago you had to run the 2.3-2.4.alpha1-upgrade-db.sql > 2.3-2.4.0RC-upgrade-db.sql > 2.3-2.4.0-upgrade-db.sql > 2.3-2.4-supplemental.sh -- is that still the case or were the scripts fixed to avoid having to use the pre-release upgrade scripts? |
| 15:40 |
bshum |
Err |
| 15:40 |
bshum |
I would have gone with just the final version of the scripts and none of the development ones. |
| 15:40 |
bshum |
Or at least, that's what I would have expected. |
| 15:41 |
mrpeters |
yeah, in the past, like i say, i ran the dev ones but maybe ill try skipping them this time |
| 15:43 |
bshum |
Running a quick 3-way comparison on them as they exist in master |
| 15:43 |
bshum |
Maybe we can nuke away the alpha1 and RC ones |
| 15:44 |
mrpeters |
yeah, perhaps...that would be great if so |
| 15:44 |
bshum |
Just my quick eyeballing it, they look like the same thing just iterations over time. |
| 15:44 |
bshum |
I would imagine you could just run 2.3-2.4.0-upgrade-db.sql |
| 15:45 |
bshum |
And you can ignore the other development ones |
| 15:47 |
bshum |
Huh |
| 15:47 |
bshum |
The only thing really different about the final 2.4.0 is that it doesn't say at the end to run the 2.3-2.4-supplemental.sh file |
| 15:48 |
bshum |
Which the RC says to do |
| 15:48 |
bshum |
Otherwise, it reordered only one thing 0788 to pull it out of the main body, probably cause there's a backported version in one of the minor point releases of 2.3's series. |
| 15:49 |
bshum |
So probably just need to add in that echo statement at the end to run the supplemental script |
| 15:49 |
bshum |
And then we can remove alpha1 and RC from the version-upgrade directory |
| 15:49 |
bshum |
But I'll defer to eeevil in case I'm missing something else entirely. |
| 15:52 |
eeevil |
yes, you can skip the pre-release upgrade scripts. they are superseded by the 2.4.0 one. and the reason why 2.4.0 does not mention the supplemental script is that it should happen /after/ you run the 2.4.1 script |
| 15:53 |
bshum |
Ahh, right |
| 15:53 |
bshum |
Now I remember, thanks eeevil |
| 15:53 |
bshum |
eeevil++ |
| 15:54 |
* eeevil |
really needs to write down his plan for no more minor-version upgrade scripts and only major version number reification of the baseline schema... sorry for the delay on that, folks |
| 15:55 |
mrpeters |
eeevil++ bshum++ |
| 15:56 |
mrpeters |
ah, i remember this old friend |
| 15:56 |
mrpeters |
ERROR: cannot drop view metabib.full_rec because other objects depend on it |
| 15:56 |
mrpeters |
needs to be a drop cascade |
| 15:58 |
bshum |
mrpeters: What are the other dependent objects? MIght be non-stock stuff at play that wasn't shown during testing. |
| 15:58 |
bshum |
(there was lots of that and we noted a few with the reporter views) |
| 15:58 |
mrpeters |
hmm whats the easiest way to tell? |
| 15:59 |
mrpeters |
DETAIL: view reporter.steve_old_super_simple_record depends on view metabib.full_rec |
| 15:59 |
mrpeters |
heh, yeah thats probably not stock :P |
| 15:59 |
bshum |
steve_old_super_simple_record... lol |
| 15:59 |
bshum |
:) |
| 16:00 |
mrpeters |
sorry about that guys, glossed over the detail line |
| 16:13 |
|
gdunbar joined #evergreen |
| 16:15 |
csharp |
mrpeters++ |
| 16:17 |
csharp |
mrpeters: I hit several bumps in the 2.3-2.4 script - had to do some manual dropping of old crufty tables, functions, and indexes |
| 16:19 |
csharp |
http://git.evergreen-ils.org/?p=evergreen/pines.git;a=shortlog;h=refs/heads/rel_2_5_1 has examples of what I did |
| 16:24 |
mrpeters |
yep, i remember :) |
| 16:24 |
mrpeters |
all of this is coming back to me like deja vu hehe |
| 16:32 |
|
xtanya joined #evergreen |
| 16:41 |
|
signora joined #evergreen |
| 16:45 |
bshum |
berick++ # prototype fun |
| 16:46 |
|
dMiller_ joined #evergreen |
| 16:55 |
|
mdriscoll left #evergreen |
| 16:56 |
bshum |
jboyer-isl: Around? |
| 17:01 |
|
mmorgan left #evergreen |
| 17:03 |
|
pmurray_away joined #evergreen |
| 17:05 |
|
pmurray_away joined #evergreen |
| 17:09 |
dbs |
berick++ # thanks for giving the library sample data branch a test run |
| 17:10 |
|
pmurray left #evergreen |
| 17:10 |
* dbs |
scoots |
| 17:16 |
|
netadres joined #evergreen |
| 17:22 |
|
mceraso joined #evergreen |
| 17:22 |
|
bshum joined #evergreen |
| 17:24 |
sseng |
anyone able to export to (print/email/cvs) when using the "Marc Batch Import / Export" while having the queue filters "Limit to Records with Matches" checked? going to head over and submit as a bug on LP with more details |
| 17:27 |
kmlussier |
sseng: I have heard reports of this locally, but I never had time to confirm the problem. |
| 17:28 |
pinesol_green |
[evergreen|Remington Steed] Docs: bug fixes in new files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=3f2a30d> |
| 17:28 |
sseng |
kmlussier: sounds good, submitting bug now |
| 17:37 |
|
dcook joined #evergreen |
| 17:46 |
|
kmlussier joined #evergreen |
| 17:52 |
sseng |
bug regarding export submited: https://bugs.launchpad.net/evergreen/+bug/1261973 |
| 17:52 |
pinesol_green |
Launchpad bug 1261973 in Evergreen "Hanging progress bar when tyring to export to Print/Email/Cvs using "Marc Batch Import / Export"" (affected: 1, heat: 6) [Undecided,New] |
| 17:53 |
kmlussier |
bshum++ #for general awesomeness. :) |
| 17:53 |
dcook |
Quick question for Evergreen folks! |
| 17:53 |
kmlussier |
sseng: If I have a chance, I'll try to confirm it tonight. |
| 17:53 |
* bshum |
waves at dcook! |
| 17:53 |
dcook |
Hey, bshum! |
| 17:53 |
sseng |
kmlussier: great, thanks! |
| 17:53 |
dcook |
How's it going? |
| 17:54 |
bshum |
dcook: It's good times, plotting out my eventual trip overseas to visit Australia and other places :D |
| 17:54 |
dcook |
\o/ |
| 17:54 |
dcook |
I'm still trying to get everything shipped back to Australia from my last trip to North America ;). Accidentally left a laptop charger in Vancouver.. |
| 17:55 |
dcook |
As for Evergreen, could you confirm that you can export bib records, modify them using an external program, and then re-import and overwrite existing records in the ILS? |
| 17:55 |
* dcook |
is writing a little article on metadata management and wants to make sure he's giving correct info on Evergreen |
| 17:55 |
bshum |
dcook: I would generally say that is possible based on the workflow and how it was being done. |
| 17:56 |
bshum |
More specifically, Evergreen does tag every record in it with a custom 901 tag that usually keeps the bib's ID as the subfield c portion. |
| 17:56 |
dcook |
Cool beans. I took a little look at the documentation last night and it looks pretty similar to Koha in that regard. |
| 17:56 |
bshum |
So that'd a good way of noting which bib is the same for overlaying |
| 17:56 |
bshum |
I imagine there'd be ways of using other conventions too |
| 17:57 |
dcook |
For sure. I suppose I was thinking more about the existence of matchers in Evergreen but I seem to recall seeing some |
| 17:57 |
dcook |
One of these days, I really need to install it myself |
| 17:58 |
bshum |
It's not exactly apt-get install, but I like to think it's come very much farther along compared to where it was when I first started :) |
| 17:58 |
dcook |
:) |
| 17:59 |
dcook |
Yeah, I briefly looked at the install instructions a few months ago and was a bit intimidated ;) |
| 17:59 |
dcook |
I'm sure it's one of those things where you need to try it until you get it, and then it makes sense |
| 18:00 |
bshum |
There's occasionally some demo servers floating around too |
| 18:00 |
dcook |
Hmm. That would be cool. |
| 18:00 |
bshum |
http://evergreen-ils.org/dokuwiki/doku.php?id=community_servers |
| 18:01 |
dcook |
I suppose I'm curious about this server/client architecture |
| 18:01 |
dcook |
Is Evergreen a desktop app? |
| 18:01 |
bshum |
The 2.5.0 one from ESI should work |
| 18:01 |
bshum |
Yeah, the app runs on Windows or Linux (though I'm not sure if the Linux builds are linked) |
| 18:01 |
bshum |
(and Mac if you know how to build a custom mac app) |
| 18:06 |
dcook |
Wow, I'm really digging the catalogue |
| 18:07 |
bshum |
Really the green didn't scare you off? ;) |
| 18:08 |
dcook |
Green is my favourite colour :p |
| 18:08 |
bshum |
Heh |
| 18:09 |
dcook |
The staff client is a bit...interesting |
| 18:09 |
dcook |
Oh my, something isn't good |
| 18:10 |
dcook |
!! This software has encountered an error. Please tell your friendly system administrator or software developer the following:\nmenu_frame.xul\nTypeError: obj.data.hash.aous is undefined\n |
| 18:10 |
bshum |
Heh |
| 18:10 |
bshum |
Sounds like whoever set up the demo server didn't run autogen properly |
| 18:11 |
dcook |
Maybe I pressed too many buttons as well? :p |
| 18:12 |
dcook |
I thought it was a desktop staff client...but I assume it had a web staff client like Koha |
| 18:12 |
dcook |
Yep, I think it might've been me |
| 18:13 |
dcook |
Unless I'm using the standalone interface and don't know it? |
| 18:13 |
bshum |
Heh |
| 18:13 |
* dcook |
will start over |
| 18:14 |
dcook |
I try logging in... |
| 18:14 |
dcook |
Now it shows a greyed out username and no password |
| 18:14 |
dcook |
As well as a greyed out Login button |
| 18:14 |
dcook |
What's the next step? :S |
| 18:14 |
bshum |
There's a part of the process for workstation registration |
| 18:14 |
bshum |
The right upper part of the screen should have a location selector and a part to fill in a name |
| 18:15 |
dcook |
Yeah, I've already set up that part :/ |
| 18:15 |
bshum |
Ah |
| 18:15 |
bshum |
Well then |
| 18:17 |
bshum |
And you got the loading stuff across the bottom right? |
| 18:17 |
bshum |
Well, what's normally expected |
| 18:17 |
dcook |
Only after I clicked on "Standalone interface" |
| 18:17 |
bshum |
is that you see the loading stuff, and then it's supposed to open another window with the actual client interface |
| 18:18 |
bshum |
With that other thing as a background window |
| 18:18 |
dcook |
I think it might've loaded? |
| 18:18 |
bshum |
Try closing out the whole thing and logging in again then |
| 18:18 |
dcook |
Hehe. That's what I did just try ;) |
| 18:18 |
bshum |
Or there's a button for "Open New Window" too |
| 18:18 |
bshum |
That's super strange. |
| 18:18 |
dcook |
Ah, so that's the standalone interface.. |
| 18:19 |
dcook |
It did open the regular interface (after I opened the standalone) |
| 18:19 |
dcook |
I don't recall seeing any loading info at the bottom (except for the standalone) but it definitely worked |
| 18:19 |
dcook |
Just maybe slower than I thought |
| 18:19 |
bshum |
It is slow |
| 18:19 |
bshum |
:) |
| 18:19 |
dcook |
The "Open New Window" button definitely works as well |
| 18:19 |
bshum |
Or rather, the negotiation with the server can be. |
| 18:20 |
dcook |
Yeah, I'm thinking that's what it probably is |
| 18:20 |
dcook |
I think it's Equinox's server and there's probably how many proxies between it and me |
| 18:21 |
dcook |
This is a very interesting experience though! |
| 18:22 |
* dcook |
can feel his experience points piling up |
| 18:22 |
dcook |
Ohh, there's a batch edit as well.. |
| 18:22 |
bshum |
Yeah, I was going to mention that before. |
| 18:22 |
bshum |
Depending on what you're doing, you could edit bibs that way in the client (though I know folks have expressed concern about knowing how to do so) |
| 18:23 |
bshum |
And also, it's unclear how many bibs are easily processed through the interface vs. faster to do in the backend direct with the database if you have access and/or tricks |
| 18:24 |
dcook |
For sure |
| 18:24 |
dcook |
Yeah, the batch editor seems a bit confusing |
| 18:24 |
bshum |
I think there's regex involved. |
| 18:24 |
dcook |
Does Evergreen use helper tables or does it just use the MARC record as the only record? |
| 18:24 |
bshum |
Which means not for end user staff catalogers :) |
| 18:24 |
dcook |
Probably not, eh? |
| 18:25 |
dcook |
My intent with the article is to get more librarians to try getting their hands dirty with things like MarcEdit and programming libraries though, so you never know.. |
| 18:25 |
bshum |
MarcEdit is a neat little tool |
| 18:25 |
bshum |
I know our catalogers use it from time to time to poke at bibs before loading |
| 18:26 |
bshum |
I'm not sure what a "helper table" would be exactly. |
| 18:27 |
bshum |
But as far as storing information goes, MARC is a big central point. But item and volume data are stored in other tables. |
| 18:27 |
bshum |
So I guess it doesn't include that as part of the bib record |
| 18:28 |
bshum |
Evergreen's database stores volume and copy data in their own tables. |
| 18:28 |
bshum |
So you could have one bib, with multiple volumes, with the volumes having multiple copies of their own too. |
| 18:29 |
bshum |
But it's not reflected in MARC as a holding line or such. Though I think you can export it that way. |
| 18:29 |
* bshum |
smells pasta cooking... and should disappear for a bit |
| 18:29 |
dcook |
Mmm pasta |
| 18:29 |
bshum |
dcook: Happy poking, feel free to pass along questions or such. If not IRC there's always our general mailing list too. |
| 18:30 |
dcook |
Thanks, bshum |
| 18:30 |
dcook |
I might have to put this off to the side for a little while, but this helps a lot. Have a good...evening? |
| 18:30 |
dcook |
Yes, evening. Good evening, hehe. |
| 18:30 |
bshum |
dcook: Heh, yes, evening. Thanks and you too have a nice day. |
| 19:31 |
|
stevenyvr2 left #evergreen |
| 19:47 |
|
afterl1 left #evergreen |
| 21:55 |
|
mrpeters joined #evergreen |
| 22:04 |
|
mrpeters left #evergreen |
| 22:10 |
|
stevenyvr2 joined #evergreen |
| 22:10 |
|
stevenyvr2 left #evergreen |
| 23:20 |
|
book` joined #evergreen |
