| Time |
Nick |
Message |
| 01:14 |
bshum |
@later tell kmlussier Since you originated that page as part of work in porting from the Evergreen in Action book as per commit 67a5b12, you'd have to go back and see who wrote that part of the book during the doc sprint to know how it was decided to put that content in. |
| 01:14 |
pinesol_green |
bshum: The operation succeeded. |
| 01:14 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67a5b12ed5b8c7e2455bf20e78a69949eb8fffba |
| 01:14 |
pinesol_green |
[evergreen|Kathy Lussier] Adding Designing Your Catalog chapter from the Evergreen In Action manual. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=67a5b12> |
| 01:15 |
bshum |
Personally I wouldn't consider "Russian" to be a supported language right now given that no strings are set in LP for the "tpac" file. |
| 01:16 |
bshum |
and that chapter is about making languages show up for your catalog. |
| 01:19 |
bshum |
Although as I look at the cs-CZ.po file for tpac in the build/i18n/po/tpac/.. directory I wonder if we're a bit behind the times too. |
| 01:20 |
bshum |
It might be that we need to check and make sure that the PO bzr that we pull from is up to date with what's in LP actually. |
| 01:20 |
* bshum |
will ponder this more later today. |
| 02:34 |
|
alisha joined #evergreen |
| 05:15 |
|
sseng_ joined #evergreen |
| 05:27 |
dbs |
@later tell kmlussier rsoulliere and I possibly to blame for what languages are "supported",; not sure what we would have been basing that on though |
| 05:27 |
pinesol_green |
dbs: The operation succeeded. |
| 05:28 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 05:36 |
* dbs |
looks at change history in http://booki.flossmanuals.net/evergreen-in-action/_edit/ and it was rsoulliere who added that, but I bet he chatted with me about it at the time. |
| 06:39 |
|
vr304 joined #evergreen |
| 07:25 |
|
snigdha26 joined #evergreen |
| 07:42 |
|
krvmga joined #evergreen |
| 07:49 |
|
collum joined #evergreen |
| 08:07 |
|
akilsdonk joined #evergreen |
| 08:30 |
|
mdriscoll joined #evergreen |
| 08:34 |
|
mrpeters joined #evergreen |
| 08:43 |
|
mmorgan joined #evergreen |
| 08:51 |
|
kmlussier joined #evergreen |
| 08:54 |
kmlussier |
dbs / bshum: I was part of the Evergreen in Action discussion too. But my recollection isn't very helpful. dbs looked something up and told rsoulliere what to put in. |
| 08:55 |
kmlussier |
I was thinking it might be best to update that page to simply link to the Launchpad translations page so that we don't have to update it every time a new language is translated. |
| 09:09 |
|
tspindler joined #evergreen |
| 09:41 |
|
RoganH joined #evergreen |
| 09:42 |
csharp |
mmorgan: didn't you mention doing back processing of lost/longoverdue circs via A/T? |
| 09:42 |
csharp |
I'm interested in what parameters you set to do month by month processing to catch up |
| 09:47 |
* csharp |
is technically off sick today, so is mostly not here :-/ |
| 10:10 |
|
jwoodard joined #evergreen |
| 10:23 |
|
dMiller joined #evergreen |
| 10:26 |
|
yboston joined #evergreen |
| 10:51 |
|
alisha joined #evergreen |
| 10:56 |
|
eby joined #evergreen |
| 11:15 |
dbwells |
I am wondering why, in the patron editor, ident_value2 is labeled as "Parent/Guardian". Does anyone know? It looks like it came in as part of 90b645f1, but with no explanation. I think it might be a local customization which was committed by accident so long ago. |
| 11:15 |
pinesol_green |
[evergreen|erickson] break the main registration table out to a separate template to ease the process of locally overriding the field order - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=90b645f> |
| 11:17 |
gmcharlt |
dbwells: that's a long-standing feature, albeit hackish |
| 11:18 |
|
bmills joined #evergreen |
| 11:19 |
|
Dyrcona joined #evergreen |
| 11:19 |
|
bmills1 joined #evergreen |
| 11:20 |
gmcharlt |
dbwells: e.g., see f6ae3127f8f |
| 11:20 |
pinesol_green |
[evergreen|erickson] displaying ident2 (parant / guardian) when editing existing non-adult. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=f6ae312> |
| 11:20 |
|
bmills1 joined #evergreen |
| 11:20 |
|
bmills1 left #evergreen |
| 11:33 |
|
akilsdonk joined #evergreen |
| 11:35 |
dbwells |
gmcharlt: Thanks for the explanation. I don't think there is any logic to show/hide it anymore. |
| 11:35 |
gmcharlt |
that may be - IIRC, it's supposed to be based on dob |
| 11:36 |
|
mmorgan joined #evergreen |
| 11:36 |
dbwells |
Was that the entire point of ident_value2? We have use cases where we actually want to store two ident_values, which is why I am asking. |
| 11:37 |
gmcharlt |
I think ident_value2 came first, then the use of it for parent/guardian got shoe-horned on to it, but berick, phasefx, or eeevil would know the history |
| 11:38 |
gmcharlt |
we do have a some customers who just use ident_value2 as a separate identifier |
| 11:38 |
dbwells |
I think that sounds likely :) |
| 11:38 |
dbwells |
The history, that is. |
| 11:38 |
gmcharlt |
one in particular for the purpose of maintaining a link back to a student information system from which the patron records are derived |
| 11:38 |
dbwells |
Wow, bingo! |
| 11:38 |
* gmcharlt |
had a sneaking suspicion :) |
| 11:40 |
dbwells |
We've been trying to maintain that student's retain their student ID for life in our system, but they invariably get overwritten with DL#s in some cases, then cause duplicate accounts if the student re-enrolls or comes back as faculty/staff/etc. |
| 11:40 |
mmorgan |
csharp: Our back processing was with a notice trigger, not an actual "lost" trigger. But I'll look up my notes. |
| 11:41 |
gmcharlt |
dbwells: yeah - quick and dirty would be to use ident_value2, and maybe push a couple local tweaks to ensure that "Parent/Guardian" isn't used as a label, ever, and to prevent staff members from editing that field |
| 11:42 |
berick |
student ID sounds like a job for patron stat cats |
| 11:42 |
gmcharlt |
that is, assuming that you never register new student patron accounts at the desk |
| 11:43 |
dbwells |
gmcharlt: We do not (well, they try, but they shouldn't :) |
| 11:43 |
dbwells |
They are synced in. |
| 11:44 |
dbwells |
berick: We've been using our student ID as our ident_value since the beginning. Is there a reason we should use stat cats instead? |
| 11:45 |
dbwells |
I am also not sure what else we would use as the ident_value. |
| 11:45 |
berick |
dbwells: they can be given a nice staff-friendly "Student ID" label to avoid some of these accidental data clobbering issues |
| 11:46 |
berick |
ident1 and ident2.. IIRC (which, I may not), PINES allowed patrons to provide two forms of identification in some cases |
| 11:47 |
berick |
say, if their primary identification wasn't "good enough". i may be halucinating that, though. |
| 11:49 |
eeevil |
berick: that's my recollection |
| 11:49 |
mmorgan |
stat cat isn't searchable, which would not work for us. |
| 11:51 |
jeff |
stat cats also aren't even indexed, iirc... so you'd need to either add a local index or suffer slowness if you were, say, doing lookups based on student ID for something external... |
| 11:51 |
csharp |
mmorgan: thanks for checking for me |
| 11:52 |
berick |
mmorgan: jeff: all good points.. for which I have no reply ;) |
| 11:53 |
berick |
eeevil: yay, my memory is still somewhat functional. (or it's a shared halucination) |
| 11:53 |
dbwells |
Thanks for the input, all. I guess my vote would be that ident_value2 be made more generic OOTB (and ident_type2 be made visible). The current state seems a little funky, but maybe that's just me. |
| 11:56 |
dbwells |
I'll probably open a bug about it and see if any consensus is there. It isn't a big deal. |
| 11:57 |
dbs |
dbwells: haven't read the entire backscroll, but we put institutional ID into ident_value |
| 11:57 |
dbs |
anything that blindly overwrites that would be highly annoying |
| 11:57 |
dbwells |
dbs: We put institutional ID into ident_value as well. |
| 11:58 |
gmcharlt |
dbwells: yeah, I think the bigger deal is a better way of managing parent/guardian relationships |
| 11:58 |
gmcharlt |
I know eeevil has IDEAS on that score ;) |
| 11:58 |
eeevil |
:) |
| 11:58 |
eeevil |
a few |
| 11:59 |
dbwells |
Is this idea coming in the near future? If so, this problem of shoe-horned data might just go away naturally. |
| 11:59 |
jeff |
what, pay all of your family's fines in one transaction? nobody would ever want that! |
| 11:59 |
eeevil |
dbwells: it's an old (4+ years?) idea. there's already a goodly pile of code in there |
| 12:00 |
gmcharlt |
jeff: of course not! they really want the family's fines to be *forgiven* in one transaction! ;) |
| 12:00 |
eeevil |
tl;dr: the "friends" infrastructure, where patron A can grant patron B privs |
| 12:00 |
jeff |
see (and renew) the items your children have out, while respecting laws/policy/etc? what is this madness! |
| 12:00 |
dbwells |
eeevil: Ah, well, maybe not exactly safe to hold my breath ;) |
| 12:00 |
jeff |
gmcharlt: well, yes. :-) |
| 12:00 |
mmorgan |
csharp: found notes, if it helps at all, I used values like 466 for processing delay and 498 for max validity delay to get a month's worth of overdues. |
| 12:01 |
jeff |
dbwells: please don't hold your breath. we need you around. |
| 12:02 |
eeevil |
whoa... nearly 6 years |
| 12:02 |
kmlussier |
eeevil: But the friends infrastructure would go beyond parent/guardian relationships, right? |
| 12:02 |
jeff |
it could. |
| 12:03 |
jeff |
at the risk of making a statement about something that isn't even fully exposed, nothing in it at present limits to parent/guardian. |
| 12:03 |
Dyrcona |
One use I've thought of/heard of for it would be teaching assistant/professor, and something like assistant/boss. |
| 12:03 |
eeevil |
kmlussier: yes, very far past |
| 12:04 |
gmcharlt |
Dyrcona: indeed - the classic use case of the professor commissioning a grad student to build the Dr. X Branch Library^W^W^W^W^W^W borrow on the prof's behalf |
| 12:04 |
eeevil |
spouses, teacher/student, gamification (compete with your friends!) |
| 12:05 |
jeff |
we would see benefit from things like granting a spouse the ability to check out your holdshelf items (to you? to them? local policy? dunno), allowing patrons to opt in to having a "master" account (or accounts?) see their circs, possibly obscuring items to just BOOK due DATE, etc.. |
| 12:06 |
gmcharlt |
and for the case of a library that just wants a place to stick the name of the parent/guardian, no need to search, no fancy permissions functionality ... a stat cat would be better than ident_value2 |
| 12:06 |
jeff |
useful beyond parent/child, but also adut foster homes / caregivers, friends, etc. |
| 12:06 |
|
evergreenTest joined #evergreen |
| 12:06 |
eeevil |
gmcharlt: aye |
| 12:06 |
evergreenTest |
howdy i have a question: |
| 12:06 |
Dyrcona |
And, we could threaten Library Elf, by eliminating any reason to use it with Evergreen. |
| 12:06 |
kmlussier |
evergreenTest: Hello! |
| 12:07 |
jeff |
for a generalized "this person or persons has been granted permission to discuss/see details about this account" note for staff, we use a custom alerting standing penalty (non-blocking, so "penalty" is a bit of a misnomer) called Confidentiality Note |
| 12:07 |
evergreenTest |
I wanted to get some advice about building my catalog |
| 12:07 |
evergreenTest |
I just setup evergreen, I have the server and staff client up and running |
| 12:08 |
kmlussier |
Dyrcona: Well, one of the advantages of Library Elf is not only seeing info on all your family members, but also seeing circ info for multiple library cards in case you use more the one library/consortia. So there may still be a value in using Library Elf. |
| 12:08 |
Dyrcona |
evergreenTest: Contratulations on that. It isn't always easy to get that far. |
| 12:08 |
evergreenTest |
thanks! we have several hundred books that were previously managed by hand (as in we kept paper record) |
| 12:09 |
Dyrcona |
kmlussier: Yep. I missed adding a smiley. :) |
| 12:09 |
evergreenTest |
so now I want to create marc records for everything |
| 12:09 |
evergreenTest |
I'm using another application called "marcedit" |
| 12:09 |
dbwells |
Well, looks like there is already a few bugs about ident_value2 / Parent/Guardian, but Bug #1089767 being the more significant. |
| 12:09 |
pinesol_green |
Launchpad bug 1089767 in Evergreen "Add Parent/Guardian Field to Patron Summary Record" (affected: 2, heat: 10) [Low,Triaged] https://launchpad.net/bugs/1089767 |
| 12:09 |
evergreenTest |
to generate a file with a few marc entries |
| 12:10 |
evergreenTest |
then I go to acquisition->load marc order records |
| 12:10 |
Dyrcona |
evergreenTest: Do you think these are things that other libraries or the Library of Congress in the US would have? |
| 12:10 |
evergreenTest |
and i upload that file that i generated using marcedit |
| 12:10 |
evergreenTest |
does this sound like the right steps so far? |
| 12:10 |
dbwells |
Also bug #1183970. |
| 12:10 |
pinesol_green |
Launchpad bug 1183970 in Evergreen "Make labels on ident_value2 fields in the client consistent" (affected: 1, heat: 6) [Wishlist,Triaged] https://launchpad.net/bugs/1183970 |
| 12:10 |
evergreenTest |
yes, the library of congress has them |
| 12:10 |
kmlussier |
evergreenTest: I wouldn't use acquisitions to load your MARC records. |
| 12:10 |
Dyrcona |
evergreenTest: You don't want to use Acquisitions for that. It is geared to buying materials from a vendor. |
| 12:10 |
evergreenTest |
ah |
| 12:10 |
kmlussier |
Dyrcona: jinx! |
| 12:11 |
evergreenTest |
so how do I import them to the catalog? |
| 12:11 |
Dyrcona |
mffmmm. *cough* |
| 12:11 |
evergreenTest |
because they're not already listed |
| 12:11 |
kmlussier |
evergreenTest: Try this: http://docs.evergreen-ils.org/2.6/_importing_materials_in_the_staff_client.html |
| 12:11 |
Dyrcona |
evergreenTest: If you think you can get records from other libraries, I'd use Z39.50. |
| 12:12 |
evergreenTest |
I was taking a look at that actually |
| 12:12 |
evergreenTest |
the problem is that I don't have barcodes |
| 12:12 |
evergreenTest |
for my books |
| 12:12 |
evergreenTest |
and it suggests on that page that if I don't have barcodes to use acquisistion->load marc order record |
| 12:12 |
evergreenTest |
acquisition* sorry |
| 12:13 |
kmlussier |
Ugh. That is poorly stated. |
| 12:13 |
evergreenTest |
Dyrcona: I use z39.50 in marcedit to generate the marc entries in bulk |
| 12:13 |
kmlussier |
@blame kmlussier |
| 12:13 |
pinesol_green |
kmlussier: It's all kmlussier's fault! |
| 12:14 |
kmlussier |
evergreenTest: At the time that documentation was written, you couldn't import items without barcodes and call numbers, but you could import MARC records. |
| 12:14 |
Dyrcona |
evergreenTest: OK, then, that works, too. :) |
| 12:14 |
kmlussier |
You would then need to add volumes/copies to get the bib records to appear in the public catalog. |
| 12:14 |
|
RoganH joined #evergreen |
| 12:15 |
kmlussier |
However, this has changed in recent releases, and the MARC batch importer will now automatically generate call numbers and barcode. |
| 12:15 |
* kmlussier |
needs to update the docs. |
| 12:15 |
Dyrcona |
evergreenTest: You could just make barcodes up. Evergreen expects there to be barcodes at some point. |
| 12:15 |
evergreenTest |
ok i'll give that a shot and brb |
| 12:15 |
evergreenTest |
my test machine isn't actually connected to the net |
| 12:16 |
evergreenTest |
its in another room so i'll be afk to test |
| 12:16 |
evergreenTest |
thanks for the info :) |
| 12:16 |
yboston |
kmlussier: is that a good bitesize docs bug? (the barcode acq thing)? |
| 12:16 |
kmlussier |
yboston: Yes, maybe. There might even be existing documentation on the new feature that you could point to. |
| 12:18 |
* Dyrcona |
doesn't use marcedit. Can you tell? |
| 12:22 |
yboston |
kmlussier: not sure what you mean, do you mean make a bitesize bug for the part that threw off evergreenTest and mention aother art of the docs that explains thigs better (for reference)? |
| 12:25 |
kmlussier |
yboston: Yes, something like that. Maybe that whole statment needs to be replaced with something that says "If you plan to import copies that do not have call numbers/barcodes, follow these steps..." And those steps *may* already be elsewhere in the docs, but I'm not sure. I haven't checked. |
| 12:25 |
kmlussier |
I think that feature was added in 2.6, to it *should* be there since it was our first release where we tried documenting all new featuers. |
| 12:27 |
yboston |
kmlussier: OK, just checking. do you know what spot in the acq docs he saw that one fateful sentence? |
| 12:27 |
dbwells |
eeevil, et. al.: Maybe resurrect the "friends" code at the Hack-a-Way? Just a thought... |
| 12:27 |
kmlussier |
I think I pasted the link above |
| 12:27 |
kmlussier |
http://docs.evergreen-ils.org/2.6/_importing_materials_in_the_staff_client.html |
| 12:27 |
yboston |
OK |
| 12:27 |
yboston |
kmlussier: I can start the bug, but I wonder if you are allowed to go in and make changes after I make it, if not I wil email you first |
| 12:28 |
kmlussier |
Sure |
| 12:33 |
mmorgan |
Anyone had any experience with selfcheck receipts? My specific issue is that the receipt for items on hold does not print, other selfcheck receipts do print. |
| 12:34 |
* kmlussier |
stares in the direction of bshum. |
| 12:57 |
|
jihpringle joined #evergreen |
| 13:00 |
|
mmorgan joined #evergreen |
| 13:00 |
|
yboston joined #evergreen |
| 13:00 |
|
tspindler joined #evergreen |
| 13:00 |
|
kmlussier joined #evergreen |
| 13:00 |
|
pinesol_green joined #evergreen |
| 13:00 |
|
jeff joined #evergreen |
| 13:02 |
|
gsams joined #evergreen |
| 13:02 |
|
Dyrcona joined #evergreen |
| 13:02 |
|
sseng_ joined #evergreen |
| 13:02 |
|
dbs joined #evergreen |
| 13:02 |
|
dcook joined #evergreen |
| 13:06 |
* bshum |
stares at... well, nobody |
| 13:07 |
jeff |
goodnight nobody, goodnight mush? |
| 13:08 |
* bshum |
reads up |
| 13:11 |
Dyrcona |
Good night, Moon! |
| 13:11 |
dbwells |
jeff: One of my favorite Seseme Street moments: Oscar the Grouch's book "Get Lost, Moon" :) |
| 13:11 |
bshum |
mmorgan: When you say that it does not print, does it not generate a print prompt? Or is it just spinning and doing nothing? Or it prints literally nothing? |
| 13:12 |
Dyrcona |
IRC apparently doesn't like staring. |
| 13:13 |
RoganH |
dbwells++ |
| 13:14 |
kmlussier |
I had to stare for a good 30 minutes before we lost everyone. |
| 13:17 |
bshum |
mmorgan: fwiw, I'm getting a javascript error in my console when I try to print list from the holds screen in selfcheck |
| 13:17 |
bshum |
Uncaught TypeError: Cannot read property 'length' of undefined selfcheck.js:1355 |
| 13:17 |
bshum |
So I'm assuming you may be seeing something similar there |
| 13:22 |
|
dMiller joined #evergreen |
| 13:30 |
eeevil |
dbwells: I'd love to. at this point, for the basic cases, it really just needs a UI and some testing, IIRC |
| 13:30 |
kmlussier |
eeevil: How would a user identify who their "friends" are? |
| 13:31 |
eeevil |
kmlussier: by usrname or barcode, I'd assume. "pre-shared secret" :) |
| 13:32 |
bshum |
gmcharlt: Hmm, it occurs to me as I try putting the finishing touches on Evergreen 2.7.0 that we're still in testing phases for OpenSRF 2.4. Is there any reason we need to talk about any changes in our present plans for Evergreen 2.7 due to further work on OpenSRF? |
| 13:32 |
bshum |
Or any other major blockers anyone would like to bring up for Evergreen 2.7.0 |
| 13:33 |
bshum |
Other than the Ubuntu 14.04 issues. :( |
| 13:33 |
kmlussier |
eeevil: Or maybe provide two pieces of information. (usrname or barcode) and first name. Because it might be easy to guess a usrname? |
| 13:33 |
gmcharlt |
bshum: the main thing I'm planning for OpenSRF 2.4.0 is improving the install instructions (and thanks for your patches) and possibly throwing in a sample nginx config for those who want to both Evergreen HTTPS and WSS on port 443 |
| 13:34 |
gmcharlt |
other than that, I'm comfortable with the instructions for the webstaff prototype in 2.7.0 being known to be in need of polish |
| 13:35 |
bshum |
gmcharlt: Yeah I was going to see if I could take some time to pull those steps into a new section of the 2.7 README later today. |
| 13:35 |
eeevil |
kmlussier: maybe... but, it's like facebook, where you have to accept the request to become friends. then you can hand over privs |
| 13:35 |
bshum |
Okay cool. |
| 13:35 |
bshum |
Steady as she goes then. |
| 13:36 |
gmcharlt |
aye-aye, cap'n! |
| 13:39 |
kmlussier |
eeevil: Sure, but I guess it depends what kind of information they see when they initially identify a barcode/user name. So if a person enters a user name (or guesses a library card number), would they then see the person's name to confirm the request? If so, they would then be able to connect an identity with that user name or library card. If not, then it might not be as much of an issue. |
| 13:40 |
kmlussier |
Just thinking aloud when I really should be paying attention to a webinar. |
| 13:40 |
eeevil |
heh |
| 13:41 |
jeff |
i think the "target" user approving the request would see the name of the requestor, but not the other way around until confirmed. requiring additional info to even request could be another option -- or turn it on its head, and the "target" user sends an offer to another user... |
| 13:41 |
jeff |
many ways to skin the cat, but something good to put thought into |
| 13:42 |
eeevil |
kmlussier: those sorts of things are exactly what we should iron out, thank you! I would think ... um ... what jeff just said :) |
| 13:48 |
|
vlewis joined #evergreen |
| 13:50 |
|
buzzy joined #evergreen |
| 13:54 |
kmlussier |
Part of the problem with asking that they supply the first name is that they might not always know which form of a name was used on an account. I'm not even sure what name I use on my own library account. |
| 13:54 |
kmlussier |
So maybe jeff's approach would work better. |
| 14:03 |
* gmcharlt |
tosses http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9032 into the conversation as an example of where Koha folks recently talks through similar issues |
| 14:03 |
gmcharlt |
although the context is sharing bookbags in particular |
| 14:07 |
|
sandbergja joined #evergreen |
| 14:07 |
|
sandbergja left #evergreen |
| 14:07 |
|
sandbergja joined #evergreen |
| 14:07 |
|
sandbergja left #evergreen |
| 14:13 |
mmorgan |
bshum: Click print and nothing happens. As if I didn't click anything at all. |
| 14:13 |
bshum |
mmorgan: Yeah that's what I got too. With that javascript error in my browser console. |
| 14:13 |
bshum |
I assume that it's probably a bug then :) |
| 14:14 |
mmorgan |
that's what I suspected. I'll file one in Launchpad, as long as it's not just me ;-) |
| 14:15 |
* bshum |
wanders off to meetings |
| 14:19 |
jeff |
gmcharlt++ thanks |
| 14:24 |
* Dyrcona |
files bugs even if it just me. Sometimes, it is the only way to find out. ;) |
| 14:43 |
|
akilsdonk joined #evergreen |
| 14:49 |
Bmagic |
Im struggling to identify a table/query that will show me the format icons associated with each bib record... anyone have some insight? metabib.record_attr_vector_list ? |
| 14:52 |
kmlussier |
Bmagic: Which Evergreen release? |
| 14:52 |
Bmagic |
2.6.1 |
| 14:52 |
kmlussier |
Bmagic: I don't know the answer, I just know the answer for 2.6 is different than for 2.5. :) |
| 14:55 |
bshum |
Bmagic: I've done that before. |
| 14:56 |
bshum |
Bmagic: It's in the IRC logs somewhere how I did it, probably during the 2.6 dev cycle when MVF/CRA was added. |
| 14:56 |
bshum |
But I can dig it back out |
| 15:00 |
|
alisha joined #evergreen |
| 15:04 |
|
nhilton joined #evergreen |
| 15:07 |
bshum |
Bmagic: I think the easiest thing to use is one of the views |
| 15:07 |
bshum |
Like metabib.record_attr_flat |
| 15:08 |
bshum |
So like SELECT * FROM metabib.record_attr_flat WHERE attr = 'icon_format' AND source = bibID#; |
| 15:08 |
bshum |
Might help you out |
| 15:09 |
eeevil |
Bmagic: if you're looking at specific records, bshum is right on. if you're trying to get the icon format for /every/ bib, you'll want to build something more targetted |
| 15:09 |
Bmagic |
eeevil: bshum: awesome! thanks! |
| 15:13 |
|
Dyrcona1 joined #evergreen |
| 15:22 |
bshum |
I just realized that I haven't started a new rel_2_7 branch yet |
| 15:22 |
bshum |
Is there anything special I need to do when I create it? Like where to base it from |
| 15:23 |
eeevil |
bshum: hrm... I used to branch master to rel_2_X and create the gold release from there. so whatever commit you were on when you started the release process is "right" for the branch, IMO |
| 15:23 |
bshum |
eeevil: Okay, just thought I would check to see what others have done with that. |
| 15:24 |
kmlussier |
bshum: We just noticed today that the roots.txt file points to the 2.6 release notes in master. At some point one of us needs to udpate that. Don't know if it needs to happen before the branch is created. |
| 15:24 |
bshum |
kmlussier: Well right now, everything in master is eventually intended to be branched. |
| 15:24 |
bshum |
But I can branch later, after we make all those changes |
| 15:25 |
kmlussier |
yboston: Feel free to make that change if you want (sorry I didn't respond to your earlier e-mail.) |
| 15:25 |
kmlussier |
Otherwise, I can make the change, but I won't get to it until tomorrow. |
| 15:26 |
bshum |
Yeah, maybe I'll branch rel_2_7 after tomorrow's last minute activities. |
| 15:27 |
bshum |
kmlussier: I did some more thinking about i18n and the PO files. |
| 15:27 |
bshum |
And I think that even though we keep metadata at the top of the PO files for when they were updated, etc. we haven't been changing those if they were the only modification to the PO files in Evergreen. |
| 15:27 |
bshum |
That's one of the steps in the RM cheat sheet I got to ignore metadata changes like PO timestamps/last authors |
| 15:28 |
bshum |
So we'd have to compare the files themselves to verify that they're "up to date" with what's in Launchpad |
| 15:28 |
bshum |
But I think it's pretty close. |
| 15:28 |
* kmlussier |
will give more thought to what bshum said later. |
| 15:29 |
bshum |
Like, for example |
| 15:29 |
bshum |
http://git.evergreen-ils.org/?p=Evergreen.git;a=blobdiff;f=build/i18n/po/circ.properties/cs-CZ.po;h=114f78f8d8d2b3c5d3eec2652a9ffaf74f37e939;hp=47eb6b8bcf9a3d17b5ecb3839dd5d2fb894e3e17;hb=ebc4ce10a596610c970f7dded9f40f176b5e52cd;hpb=b45bc0bad508560e5dd834304967326f81f65e42 |
| 15:29 |
pinesol_green |
[evergreen|Ben Shum] Translation updates - po files - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=ebc4ce1> |
| 15:29 |
pinesol_green |
[evergreen|Jason Boyer] LP#1241644: Remove xact_finish IS NULL checks from CLAIMSRETURNED and LONGOVERDUE - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=b45bc0b> |
| 15:29 |
bshum |
With that changeset, the X-Launchpad-Export-Date is changed and the build ID too |
| 15:29 |
kmlussier |
I need to fly. Open house at my daughter's school, and I have a long commute to get there. |
| 15:29 |
bshum |
Because it apparently removed a translation string from the file |
| 15:30 |
bshum |
But if only the X-metadata was changed, we wouldn't commit/update that |
| 15:30 |
bshum |
So even though a file in Evergreen master might say, last export date of 2012 |
| 15:30 |
bshum |
Well, no |
| 15:30 |
bshum |
THen I guess it wouldn't have changed :( |
| 15:30 |
bshum |
Nevermind everything I said |
| 15:30 |
bshum |
I'm still figuring things out :) |
| 15:32 |
kmlussier |
bshum: OK, I'll touch base with you tomorrow on it. I don't necessarily need to understand the inner workings. I just need to know what should be in the docs. |
| 15:32 |
kmlussier |
Have a nice night! |
| 15:38 |
* dbs |
needs to keep plugging away at the fr_CA translation of tpac.po. *somebody* added all of the relator codes, which were never translated. harrumph |
| 15:39 |
bshum |
Heh |
| 15:54 |
|
nhilton_ joined #evergreen |
| 16:01 |
|
yboston_ joined #evergreen |
| 16:06 |
|
bbqben joined #evergreen |
| 16:12 |
|
mrpeters left #evergreen |
| 16:31 |
|
tspindler left #evergreen |
| 16:44 |
|
nhilton joined #evergreen |
| 16:50 |
|
mdriscoll left #evergreen |
| 16:51 |
|
nhilton joined #evergreen |
| 16:56 |
pinesol_green |
[evergreen|Angela Kilsdonk] 2.7 documentation from ESI - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=9ae8d24> |
| 17:06 |
|
nhilton_ joined #evergreen |
| 17:08 |
|
mmorgan left #evergreen |
| 17:18 |
|
nhilton joined #evergreen |
| 17:40 |
pinesol_green |
[evergreen|Yamil Suarez] Docs: updated root.txt to point to 2.7 release notes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=04bf2f2> |
| 17:51 |
|
bbqben joined #evergreen |
| 17:53 |
|
dMiller joined #evergreen |
| 18:00 |
pinesol_green |
Incoming from qatests: Test Success - http://testing.evergreen-ils.org/~live/test.html <http://testing.evergreen-ils.org/~live/test.html> |
| 18:30 |
|
nhilton_ joined #evergreen |
| 18:55 |
|
jeff joined #evergreen |
| 18:55 |
|
jeff joined #evergreen |
| 19:08 |
|
nhilton joined #evergreen |
| 19:21 |
csharp |
e26298a |
| 19:22 |
gmcharlt |
quick, let's all change csharp's screensaver! |
| 19:22 |
csharp |
meh - it was a commit hash-ish |
| 19:22 |
csharp |
looking for an upgrade script |
| 19:22 |
gmcharlt |
ah, OK :) |
| 19:23 |
csharp |
my passwords nowadays look a lot like DLQFuCalDFdQOt2TniT9 |
| 19:23 |
csharp |
keepass++ |
| 19:29 |
rangi |
mine look like |
| 19:29 |
rangi |
this is a really really long password that is hard to guess but easy for me to remember |
| 19:30 |
rangi |
where sites dont have ridiculous policies :) |
| 19:45 |
* csharp |
screams in rage |
| 19:46 |
csharp |
I'm doing exactly what was suggested to me in the discussion here http://irc.evergreen-ils.org/evergreen/2014-09-09#i_122166 to fix bug 1311467 and its after effects |
| 19:46 |
pinesol_green |
Launchpad bug 1311467 in Evergreen "validate headings broken in 2.6.0" (affected: 1, heat: 8) [High,Fix released] https://launchpad.net/bugs/1311467 |
| 19:47 |
csharp |
it works great on test - immediate validation, but the same fix on production is still resulting in 60+ second seq scans of authority.record_entry |
| 19:47 |
csharp |
however, I'm not at my best today, so I think I'm going to have to troubleshoot tomorrow |
| 19:54 |
csharp |
wth? it works! |
| 19:55 |
csharp |
heh |
| 20:26 |
|
dcook joined #evergreen |
| 20:34 |
|
artunit_ joined #evergreen |
| 23:37 |
|
buzzy joined #evergreen |
