| Time |
Nick |
Message |
| 02:23 |
|
gsams joined #evergreen |
| 07:46 |
|
jboyer-isl joined #evergreen |
| 07:48 |
|
rjackson-isl joined #evergreen |
| 09:20 |
|
mmorgan joined #evergreen |
| 10:23 |
|
afterl joined #evergreen |
| 10:47 |
|
vladasvanej joined #evergreen |
| 11:06 |
|
keggle joined #evergreen |
| 11:07 |
keggle |
I have been working on updating my library catalog to the TPAC and need some hlp finding where to change the list of Formats on the Basic Search |
| 11:08 |
tsbere |
keggle: Change how? |
| 11:08 |
keggle |
the defaults are a bit much |
| 11:09 |
tsbere |
keggle: Admin->Server Admin->MARC Coded Value Maps, Attribute type of "Type", is the default set. If you are late enough in Evergreen you can change the Search Labels to change their names, and "OPAC Visible" false should hide those you don't want. If you want to go beyond that, however, we may need more info as to what you want to do. |
| 11:09 |
keggle |
the default list is very "wordy" and doesnt really represent the recognized formats such as : " Books, Large Print, E-Books etc" |
| 11:10 |
|
jboyer_isl joined #evergreen |
| 11:15 |
keggle |
tsbere: is the "Code" Field what the actual material type is? |
| 11:16 |
tsbere |
You want to avoid changing, or removing, codes. But that would be the MARC code, yes. |
| 11:16 |
|
mceraso_ joined #evergreen |
| 11:16 |
tsbere |
keggle: If you want to do things like "Large Print Books" you need to go with something other than the basic item_type filter, though |
| 11:18 |
keggle |
thanks tsbere |
| 11:18 |
tsbere |
keggle: Oh, and for added fun, if you add *new* entries you can combine things with commas in the "code" field. We mainly do that for advanced search entries, though, not item types. |
| 11:23 |
|
bshum joined #evergreen |
| 11:23 |
|
bshum joined #evergreen |
| 11:23 |
|
bshum joined #evergreen |
| 11:24 |
|
kmlussier joined #evergreen |
| 11:24 |
|
bshum joined #evergreen |
| 11:24 |
|
bshum joined #evergreen |
| 11:25 |
|
bshum joined #evergreen |
| 11:26 |
|
jbfink joined #evergreen |
| 11:56 |
|
kmlussier joined #evergreen |
| 12:12 |
|
mmorgan left #evergreen |
| 12:28 |
|
fparks joined #evergreen |
| 12:31 |
|
smyers_ joined #evergreen |
| 13:08 |
|
stevenyvr2 joined #evergreen |
| 13:18 |
|
sseng_ joined #evergreen |
| 13:24 |
|
book` joined #evergreen |
| 13:27 |
bshum |
@roulette |
| 13:27 |
pinesol_green |
bshum: *click* |
| 13:27 |
|
sseng joined #evergreen |
| 13:38 |
|
Polonel joined #evergreen |
| 13:41 |
Polonel |
In the Coded Value Maps > Record Attribute Type: Type. Where does it look for the CODE field to match the record to the type? |
| 14:12 |
|
finnx_ joined #evergreen |
| 14:14 |
tsbere |
Polonel: That is the marc type field, in the fixed fields. Which one I forget. >_> |
| 14:17 |
Polonel |
Now I'm getting a Internal Server Error when clicking on a book in the opac only in the staff client..... :( |
| 14:17 |
Polonel |
this is on a test box just upgraded to 2.5.1 |
| 14:18 |
tsbere |
I would check the apache logs to see what they say |
| 14:19 |
Polonel |
I get this |
| 14:19 |
Polonel |
egweb: template error: undef error - Invalid date format: at /openils/var/templates/opac/parts/record/summary.tt2 line 147\n |
| 14:19 |
Polonel |
this is the default TPAC |
| 14:19 |
Polonel |
with 2.5.1 |
| 14:19 |
Polonel |
works fine when goign to the opac on a browser |
| 14:20 |
tsbere |
Hmmm |
| 14:20 |
tsbere |
The creation date of copies is shown only to staff, and date.format is being called in the copy table... |
| 14:20 |
Polonel |
Strange indeed. I can search for a book. I get the search results. I try to click the title and I get the 500 response |
| 14:21 |
Polonel |
that line in that template file is.. |
| 14:21 |
Polonel |
[%- INCLUDE "opac/parts/record/copy_table.tt2" copies=ctx.copies %] |
| 14:21 |
tsbere |
yea, and copy_table.tt2 shows the create date to staff only, for example, so if there is a problem with the way create_date is coming out |
| 14:21 |
tsbere |
you will get errors |
| 14:21 |
tsbere |
oh, wait |
| 14:22 |
tsbere |
Polonel: Have you changed templates/opac/parts/header.tt2, specifically the SET DATE_FORMAT line? |
| 14:22 |
Polonel |
No |
| 14:23 |
tsbere |
Are you in non-en-US mode? |
| 14:23 |
Polonel |
I don't believe so. is there a way to check |
| 14:23 |
* tsbere |
is guessing at this point |
| 14:23 |
tsbere |
I can't say if the "invalid" part is the date from the DB or the format itself that is to be output |
| 14:24 |
Polonel |
I follow.. I just don't know where to begin to try and pinpoint it |
| 14:25 |
|
keggle joined #evergreen |
| 14:26 |
tsbere |
I would start by removing the l( and ) from around the SET DATE_FORMAT line - Hardcode it to a hopefully known good value |
| 14:26 |
tsbere |
(the l( ) bit is the "get the localized version of this" function) |
| 14:29 |
Polonel |
I have:#SET DATE_FORMAT = l('%m/%d/%Y'); |
| 14:29 |
Polonel |
oops |
| 14:29 |
Polonel |
wrong line |
| 14:29 |
Polonel |
SET DATE_FORMAT = '%m/%d/%Y'; |
| 14:30 |
Polonel |
and I get same error |
| 14:31 |
tsbere |
hmmm |
| 14:32 |
tsbere |
Polonel: In copy_table.tt2 you could change the date.format template directives to spit out the raw dates, to see what is coming out of the DB. That would basically be "replace the whole date.format() function with what appears inside of ctx.parse_datetime()" |
| 14:32 |
tsbere |
As a test, anyway |
| 14:33 |
tsbere |
I think there are two calls in there |
| 14:40 |
Polonel |
tsbere: Okay that made the page show. But Create Date is showing blank and DUE DATE is show - |
| 14:40 |
tsbere |
Polonel: Well, due date should show that if there isn't one. The blank create date is the bigger concern. |
| 14:41 |
Polonel |
right. I'm looking over my notes and I don't see any error that happen during the upgrade of the .sql scripts that were ran |
| 14:41 |
tsbere |
Huh. Create date is allowed to be null in the DB. |
| 14:42 |
Polonel |
I wonder if a function / view is incorrect in the DB thats causing it |
| 14:42 |
Polonel |
Create data is not null empty in the DB |
| 14:42 |
Polonel |
its populated with the correct date |
| 14:42 |
Polonel |
not null or empty * |
| 14:42 |
tsbere |
Polonel: So does this return two identical numbers? select count(create_date), count(id) from asset.copy; |
| 14:43 |
Polonel |
no.. wondering what has happened here |
| 14:43 |
Polonel |
count = 5856 count1=138833 |
| 14:44 |
Polonel |
missing alot |
| 14:44 |
tsbere |
Which, I imagine, is your problem. :/ |
| 14:44 |
Polonel |
yes it woudld be :( |
| 14:45 |
Polonel |
My guess is the create data wasn't set during the orginal import |
| 14:47 |
tsbere |
Polonel: You could copy the due date logic that causes it to be - when not set to the create date display area there |
| 14:47 |
tsbere |
(the IF copy_info.due_date; <format> ELSE; '-'; END bit) |
| 14:47 |
Polonel |
yes. I'm going to try a set a generic create date of when the import occured to all nulls in the table |
| 14:47 |
tsbere |
Just do that with create_date in the proper location |
| 14:48 |
Polonel |
because I don't want to have to change the template every time |
| 14:48 |
Polonel |
and Its just not right for them to be null |
| 14:48 |
Polonel |
and it seems its all the books from the orginal import |
| 14:51 |
Polonel |
Thanks for helping me find this issue tsbere. :) |
| 14:52 |
tsbere |
no problem. Tis a good thing for me to realize can happen for the future anyway. ;) |
| 14:52 |
tsbere |
Polonel: On the "don't want to keep changing that" front - Make a git branch with your customizations, then you don't need to keep making them. Just merge them in. |
| 14:52 |
rjackson-isl |
anyone have advice on how to prevent a pile of invalid emails from courtesy notices created via action triggers? |
| 14:52 |
tsbere |
(assuming you also install from git, which isn't that hard either) |
| 14:53 |
tsbere |
rjackson-isl: Define "pile of invalid emails" perhaps and I might be able to help |
| 14:53 |
rjackson-isl |
we have from 1000 to 2000 nightly that are invlaid (no email in patron account or garbage such as N/A) |
| 14:53 |
tsbere |
Well, on the garbage ones we use a regex to prevent people from entering bad ones |
| 14:53 |
tsbere |
Not that we have cleaned up all the pre-regex ones, mind you, but it stops new ones |
| 14:53 |
rjackson-isl |
most are of the null or empty variety |
| 14:54 |
rjackson-isl |
we suspect that an out of children issue on our utility server may be caused due to the attempted invalild emails |
| 14:55 |
tsbere |
Can't say much on that front. Ensure check_email_notify is set to 1 in the params on the A/T def to start with, beyond that not sure. |
| 15:19 |
Polonel |
tsbere: Where are the Fixed Fields Stored at. I see them in MARC EDIT but not MARC View |
| 15:20 |
tsbere |
Polonel: Varies on the field. Some, like item type and bib level, are in the leader, I believe. Others are in tags like the 008 |
| 15:21 |
tsbere |
You need a better understanding of MARC to grasp it, I think. |
| 15:21 |
Polonel |
Yea. I'm just the IT guy I don't know MARC stuff lol. I'm only concerned about item type |
| 15:21 |
tsbere |
Polonel: You may want to look at http://www.loc.gov/marc/marcdocz.html and, for things like "Type of Record", http://www.loc.gov/marc/bibliographic/bdleader.html |
| 15:24 |
Polonel |
Thanks |
| 15:24 |
Polonel |
Got me what I wanted it |
| 15:26 |
|
zerick joined #evergreen |
| 15:40 |
jboyer-isl |
A little backstory on rjackson-isl and my problem: The only validators that actually check the check_email_notify parameter are holds related. We've got multiple thousands of "your card will expire in 30 days" and "your items are due in 3 days" types of messages going out with null emails. |
| 15:41 |
jboyer-isl |
Looking at the code, it's not terribly difficult to put in a check, but there's currently nothing there that can help. |
| 15:41 |
tsbere |
jboyer-isl: Given that holds are the only thing in the system with a "email notify" flag to check... |
| 15:42 |
tsbere |
jboyer-isl / rjackson-isl : On a different note, have you considered just upping the number of children on the utility server? Or reducing the number of things being done at the same time? |
| 15:43 |
jboyer-isl |
True, though it would be nice if the opac.hold_notify user setting were a more generic "this is how to notifiy me about anything" setting. |
| 15:44 |
jboyer-isl |
tsbere: We have done that before. It's not hitting the limit commonly, we were just thinking that removing a bunch of "impossible" emails would reduce the load on it. |
| 15:44 |
tsbere |
jboyer-isl: Also, on the "your items are due in 3 days" type emails, we created a user setting and tagged that one with it so that it can be turned on/off by the patron to begin with. Also allows for "email or sms or both or neither" (neither being popular with people who use third party services for that, actually) |
| 15:46 |
tsbere |
predues, two overdue periods, shelf expired holds, canceled holds....each with an opac visible setting for the patron to be picky about. |
| 15:46 |
jboyer-isl |
So you have about 9 notification options for patrons? (3 holds + those 6) |
| 15:47 |
tsbere |
Well, the hold related ones also check the hold, I believe, so you need to say "I want hold canceled notices" AND the hold has to have email notification enabled, for example |
| 15:47 |
* tsbere |
doesn't have this open in front of him to be 100% sure how they configured everything |
| 15:48 |
tsbere |
The user settings are mainly a global on/off for that kind of notification. Whether or not the notification fires an email off still needs things like the validation checks to pass. |
| 15:49 |
jboyer-isl |
I see. |
| 15:49 |
tsbere |
We can also make them not opac visible if we want for some of them, if we desire to, so that staff have to toggle them. But we have no real reason to do that for the most part right now. |
| 15:51 |
|
ktomita_ joined #evergreen |
| 16:04 |
|
ktomita joined #evergreen |
| 16:17 |
|
ktomita_ joined #evergreen |
| 16:23 |
|
jbfink joined #evergreen |
| 16:34 |
|
smyers__ joined #evergreen |
| 16:51 |
|
ktomita joined #evergreen |
| 17:23 |
|
ktomita_ joined #evergreen |
| 19:28 |
|
stevenyvr2 left #evergreen |
| 21:30 |
|
jboyer-isl joined #evergreen |
| 23:45 |
|
wjr joined #evergreen |
| 23:58 |
bshum |
Goodbye 2013. |
