| Time |
Nick |
Message |
| 00:33 |
|
b_bonner_ joined #evergreen |
| 00:58 |
|
Mark__T joined #evergreen |
| 05:15 |
|
eeevil joined #evergreen |
| 05:21 |
|
RBecker joined #evergreen |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:14 |
|
Callender joined #evergreen |
| 07:19 |
|
TaraC joined #evergreen |
| 07:35 |
|
sarabee joined #evergreen |
| 08:02 |
|
rjackson_isl joined #evergreen |
| 08:05 |
|
mrpeters joined #evergreen |
| 08:19 |
|
_bott_ joined #evergreen |
| 08:33 |
|
Dyrcona joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:39 |
|
Shae joined #evergreen |
| 08:57 |
|
rlefaive joined #evergreen |
| 09:02 |
|
rlefaive joined #evergreen |
| 09:10 |
|
ericar joined #evergreen |
| 09:12 |
|
rlefaive joined #evergreen |
| 09:13 |
* Dyrcona |
is gonna add some code to marc_export to trap warnings and print better diagnostics. |
| 09:16 |
Dyrcona |
Ooh, and there are related bugs that have gone unnoticed. |
| 09:16 |
|
RoganH joined #evergreen |
| 09:17 |
Dyrcona |
S'pose I should make two branches/two lp bugs. |
| 09:25 |
|
maryj joined #evergreen |
| 09:40 |
|
yboston joined #evergreen |
| 09:49 |
Dyrcona |
lp 1502156 |
| 09:49 |
pinesol_green |
[evergreen|Remington Steed] Docs 2.9: Add summary of Web Client changes - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=c11b12c> |
| 09:49 |
pinesol_green |
Launchpad bug 1502156 in Evergreen 2.8 "marc_export calls non-existent MARC::Record->id()" [Undecided,New] https://launchpad.net/bugs/1502156 |
| 09:50 |
Dyrcona |
Well, that was interesting timing.... ;) |
| 09:50 |
Dyrcona |
lp 1502152 |
| 09:50 |
pinesol_green |
Launchpad bug 1502152 in Evergreen "Trap Warnings in marc_export for better error reporting" [Wishlist,New] https://launchpad.net/bugs/1502152 |
| 09:59 |
Dyrcona |
Whee! Look at all the "No mapping found" messages! |
| 10:05 |
Dyrcona |
Ah, fun. So I used a similar variable ($r) in a different way in one subroutine than I did in the others. |
| 10:05 |
Dyrcona |
That is what I think I'll change to make that one subroutine more like the others. |
| 10:19 |
jeff |
"Optionally pass each record through MARC::Lint and display output" [Wishlist,New] https://example.com/not/really |
| 10:24 |
Dyrcona |
heh. |
| 10:24 |
Dyrcona |
And I triggered it: Can't locate object method "id" via package "MARC::Record" at /openils/bin/marc_export line 786. |
| 10:41 |
|
krvmga joined #evergreen |
| 10:42 |
krvmga |
"group by formats and editions" seems to pull in all consortial holdings and ignore scoping. (in other words, i can't see all the formats and editions only my library owns). is my understanding correct? |
| 10:46 |
kmlussier |
hmmm...I don't recall that being a problem with metarecords |
| 10:46 |
krvmga |
http://bark.cwmars.org/eg/opac/results?query=%22be+happy+at+work%22+gordon&qtype=keyword&fi%3Asearch_format=&locg=291&sort=&modifier=metabib |
| 10:46 |
krvmga |
an example ^ |
| 10:47 |
kmlussier |
Oh, you're talking about ebooks. I think there is a bug related to located uris |
| 10:47 |
krvmga |
STCC does not own this but does own a different edition of the ebook (which has a different title) and has the original title in a 500 |
| 10:47 |
* kmlussier |
looks |
| 10:48 |
krvmga |
well, that's a horse of a different color then. |
| 10:48 |
krvmga |
:) |
| 10:48 |
Dyrcona |
Bay as opposed to chestnut.... |
| 10:49 |
kmlussier |
Well, there's this bug 1403907 |
| 10:49 |
pinesol_green |
Launchpad bug 1403907 in Evergreen "E-resources not included in ver 2.7.1 Group formats and editions search" [Medium,Confirmed] https://launchpad.net/bugs/1403907 |
| 10:49 |
kmlussier |
Not sure if it's the same thing. |
| 10:49 |
krvmga |
it seems like the opposite |
| 10:49 |
krvmga |
a bug with two faces |
| 10:49 |
Dyrcona |
Transcendant [sic] source? |
| 10:50 |
kmlussier |
krvmga: No, I don't think it is. The bug report is unclear. |
| 10:50 |
Dyrcona |
No, I'm asking krvmga. |
| 10:50 |
krvmga |
maybe i should add a note to that bug |
| 10:50 |
kmlussier |
You're seeing the eresource result on the first screen. And that's consistent with what I found when I tested the bug. |
| 10:50 |
kmlussier |
But then, when you click into the results, that's where the e-resources aren't showing up. |
| 10:50 |
krvmga |
kmlussier: yes |
| 10:50 |
Dyrcona |
We find that e-resources on transcendant sources show up where you might not want them. |
| 10:50 |
kmlussier |
In your case, there is just one other record, so it's immediately jumping to that. So I think it's a spin on that bug. |
| 10:51 |
kmlussier |
Dyrcona: They're using located uri's, not transcendant sources. |
| 10:51 |
Dyrcona |
I'm just spitballing. |
| 10:51 |
kmlussier |
krvmga: They're may be another related bug too. I'll keep looking around. |
| 10:52 |
* Dyrcona |
waits to see if his bug is fixed. |
| 10:54 |
kmlussier |
krvmga: It's weird, though, that you are getting that book when you click into the metarecord since stcc doesn't own it. |
| 10:54 |
krvmga |
kmlussier: i know. weird. |
| 10:55 |
Dyrcona |
Reason I mentioned the possibility of a transcendent bib source is they do that. Show up when limiting to libraries, and even copy locations, though they lack copies. |
| 10:56 |
krvmga |
want another weird one? http://bark.cwmars.org/eg/opac/record/99191?query=work%20career%20whitman;qtype=keyword;locg=291;modifier=metabib |
| 10:56 |
kmlussier |
But when I try other searches that don't include e-resources, the scoping works properly on that second screen. So I think it's definitely related to issues with the located URI |
| 10:56 |
krvmga |
the search is - work career whitman |
| 10:56 |
krvmga |
the word "career" doesn't appear in the bib record |
| 10:56 |
Dyrcona |
Doesn't have to if any of the others do. |
| 10:56 |
krvmga |
if the search is an AND search, this search should have failed |
| 10:56 |
krvmga |
yes? |
| 10:57 |
Dyrcona |
depends. |
| 10:57 |
kmlussier |
krvmga: When I do the search, I don't retrieve that record. http://bark.cwmars.org/eg/opac/results?query=work+career+whitman&qtype=keyword&fi%3Asearch_format=&locg=291 |
| 10:57 |
Dyrcona |
If you just type those three words into the keyword box, it is not an AND. |
| 10:58 |
krvmga |
Dyrcona: really? i thought that was how the system worked. |
| 10:58 |
Dyrcona |
But, I should stop before I get in above my knowledge of the search code. |
| 10:58 |
krvmga |
today is for learning |
| 10:58 |
* Dyrcona |
doesn't know anything. |
| 10:58 |
Dyrcona |
@dunno |
| 10:58 |
pinesol_green |
Dyrcona: I see nothing, I know nothing! |
| 10:59 |
|
collum joined #evergreen |
| 10:59 |
krvmga |
long cherished assumptions washed down the drain |
| 10:59 |
Dyrcona |
Well, I can always be wrong. |
| 10:59 |
kmlussier |
krvmga: For that search, I would go into the database to see which records are linked to that metarecord. One of those probably has the word career in it, as Dyrcona said above. |
| 10:59 |
krvmga |
ayah! another illusion shattered! Dyrcona can be *wrong*!? |
| 11:00 |
Dyrcona |
Anyway, my marc_export made it past the point where it blew up and is still going, so guess that is fixed. |
| 11:00 |
krvmga |
kmlussier: yes, that's logical. |
| 11:00 |
krvmga |
:) |
| 11:00 |
* Dyrcona |
usually is. ;) |
| 11:00 |
kmlussier |
krvmga: But you might not be seeing that record because of the problem retrieving e-resources. |
| 11:00 |
* krvmga |
has been binge watching Enterprise. |
| 11:02 |
* Dyrcona |
suffers from fernweh. |
| 11:03 |
kmlussier |
krvmga: Another bug that may or may not be related to what you're seeing - bug 1420509 |
| 11:03 |
pinesol_green |
Launchpad bug 1420509 in Evergreen "Grouped metabib results shows format icons that are not included" [Undecided,New] https://launchpad.net/bugs/1420509 |
| 11:03 |
krvmga |
Dyrcona: not me. i'm happy to be around home. |
| 11:04 |
krvmga |
kmlussier: thx for that. |
| 11:06 |
Dyrcona |
Whee! 124M of authorities dumped so far and it is still chugging. |
| 11:07 |
Dyrcona |
'Course, it doesn't dump the ones with errors, and that's a lot of records. |
| 11:08 |
Dyrcona |
Suppose I should have piped through tee, then I could count the errors. |
| 11:09 |
|
Christineb joined #evergreen |
| 11:20 |
Dyrcona |
Is it just me or is it cold in here? |
| 11:20 |
kmlussier |
It's freezing in here. |
| 11:20 |
kmlussier |
But I'm a few miles away from you. |
| 11:24 |
RoganH |
@weather |
| 11:24 |
pinesol_green |
RoganH: Error: I did not find a preset location for you. Set via setweather <location> |
| 11:24 |
RoganH |
@weather 29732 |
| 11:24 |
pinesol_green |
RoganH: Rock Hill, SC :: Overcast :: 58F/14C | Friday: Cloudy with showers. High 58F. Winds NNE at 15 to 25 mph. Chance of rain 50%. Friday Night: Windy at times with rain likely. Low 54F. Winds NNE at 20 to 30 mph. Chance of rain 100%. 2 to 3 inches of rain expected. Localized flooding is expected. |
| 11:25 |
RoganH |
I keep talking about building an arc. I think satellite has awful upstream latency and bandwidth though. |
| 11:25 |
mmorgan |
@weather 01923 |
| 11:26 |
pinesol_green |
mmorgan: Danvers, MA :: Overcast :: 52F/11C | Friday: Windy with occasional light rain. High 53F. Winds NNE at 20 to 30 mph. Chance of rain 60%. Winds could occasionally gust over 40 mph. Friday Night: Showers this evening, becoming a steady rain overnight. Low around 45F. Winds NNE at 15 to 25 mph. Chance of rain 80%. Rainfall near a quarter of an inch. Winds could occasionally gust (1 more message) |
| 11:26 |
RoganH |
Ark rather. Though I could use an arc reactor on the ark. |
| 11:29 |
krvmga |
@weather 01606 |
| 11:29 |
pinesol_green |
krvmga: Worcester, MA :: Overcast :: 47F/8C | Friday: Cloudy with showers. High 52F. Winds NE at 10 to 20 mph. Chance of rain 50%. Friday Night: Showers this evening, becoming a steady rain overnight. Low 42F. Winds NNE at 10 to 20 mph. Chance of rain 70%. Rainfall around a quarter of an inch. Winds could occasionally gust over 40 mph. |
| 11:29 |
|
rlefaive joined #evergreen |
| 11:29 |
krvmga |
i am freezing |
| 11:30 |
Dyrcona |
@weather 01845 |
| 11:30 |
pinesol_green |
Dyrcona: North Andover, MA :: Mostly Cloudy :: 52F/11C | Friday: Cloudy with occasional rain showers. High 54F. Winds NNE at 15 to 25 mph. Chance of rain 40%. Friday Night: Cloudy this evening with showers after midnight. Low 43F. Winds NNE at 10 to 20 mph. Chance of rain 60%. |
| 11:30 |
Dyrcona |
Guess that's the downside of the wall of window in the office. |
| 11:31 |
* mmorgan |
will take windows over walls any day, even the grey blustery ones. |
| 11:37 |
|
rlefaive joined #evergreen |
| 11:42 |
|
bmills joined #evergreen |
| 11:42 |
|
bmills joined #evergreen |
| 12:10 |
|
sandbergja joined #evergreen |
| 12:49 |
mmorgan |
Hmm. So aborting a single transit put two items in Reshelving status :-( |
| 12:49 |
mmorgan |
Anyone seen that before? |
| 12:51 |
phasefx |
I'm skeptical. :) Was it a hold transit? |
| 12:52 |
mmorgan |
Yes, pretty sure. |
| 12:53 |
phasefx |
items on the same title? |
| 12:53 |
mmorgan |
Yes, same title. |
| 12:53 |
phasefx |
and finally, from which interface was the transit aborted? |
| 12:54 |
mmorgan |
I believe it was item status, but not entirely sure. |
| 12:57 |
tsbere |
I can believe one item, but not two. <_< |
| 12:57 |
pastebot |
"mmorgan" at 64.57.241.14 pasted "Abort transit log" (78 lines) at http://paste.evergreen-ils.org/15 |
| 12:58 |
phasefx |
so there's the bit in the code where it cancels the transit and changes the copy status.. but there's another bit where it resets a hold, and I wonder if that is where a second copy mistakenly got pulled in |
| 12:59 |
mmorgan |
I see a filled hold from July being reset, id 1767304 |
| 13:00 |
mmorgan |
When the second copy was set to reshelving, it was on the holdshelf for a different hold, so that hold ended up with the -1 status |
| 13:01 |
phasefx |
actually three different copies referenced in those logs |
| 13:01 |
mmorgan |
Oh? |
| 13:02 |
phasefx |
just looking at copy.retrieve |
| 13:02 |
phasefx |
why they're all tied together with the same thread trace I'm not sure |
| 13:04 |
mmorgan |
Hmm. not seeing the refernce to the third copy. There are only two on that title. |
| 13:06 |
kmlussier |
copy 10365393 2563413 and 10292536 |
| 13:08 |
mmorgan |
Looks to me like 2563413 is an action.transit_copy.id |
| 13:09 |
mmorgan |
The row that was deleted when the transit was aborted. |
| 13:14 |
kmlussier |
Ah, you're right. Ignore me. I don't kwow what I'm talking about. :) |
| 13:17 |
kmlussier |
know even |
| 13:19 |
* mmorgan |
will need to dig into this further at some point. |
| 13:49 |
* Dyrcona |
waits for marc_export -a --items 2>&1 > bibs.mrc | tee bibs.err to actually start doing something. |
| 13:55 |
Dyrcona |
And it is spitting warnings to my screen and bibs to the file. |
| 13:56 |
* Dyrcona |
is concerned that the warning code may be swallowing errors and invalid records could be getting exported. |
| 13:58 |
|
jihpringle joined #evergreen |
| 14:00 |
pinesol_green |
[evergreen|Jason Stephenson] LP 1502156: Fix marc_export error when dumping authorities. - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=885758d> |
| 14:06 |
Dyrcona |
gmcharlt++ |
| 14:14 |
jeff |
Dyrcona++ gmcharlt++ |
| 14:21 |
Dyrcona |
binmode(..., ":raw") still produces the "Wide character in print messages...." Apparently, so does :btyes, but the latter is at least documented. |
| 14:25 |
Dyrcona |
heh... btyes...... should be bytes. |
| 14:36 |
|
rlefaive joined #evergreen |
| 15:15 |
kmlussier |
Are there any core committers interested in reviewing/merging a small patch from jlitrell so that he could get his first code contribution in? Well also so that we can have one more bug fixed in Evergreen. :) https://bugs.launchpad.net/evergreen/+bug/1340852 |
| 15:15 |
pinesol_green |
Launchpad bug 1340852 in Evergreen "Copy Location Groups search not retaining original search params after searching" [Medium,Confirmed] |
| 15:23 |
Stompro |
If I want to change the Series facet to only include subfield a, where would I go to find that setting? |
| 15:26 |
kmlussier |
Stompro: You configure the facets in config.metabib_field |
| 15:27 |
Stompro |
kmlussier, the template file? ./var/templates/conify/global/config/metabib_field.tt2 |
| 15:27 |
kmlussier |
Stompro: No, in the database. |
| 15:28 |
jeff |
I never did understand a "series" facet that included the book/volume in the series in the facet itself. Can't recall if I've gotten clarification on that before or not. |
| 15:29 |
jeff |
I have seen it used as a poor replacement for metarecords, though. |
| 15:29 |
kmlussier |
So, the facet_xpath field, is that where you tell it how the facet should display? |
| 15:29 |
jeff |
Filed that under "interesting emergent behavior" |
| 15:30 |
kmlussier |
I agree that it doesn't make sense to display that info in the facet. Might be a night enhancement to add. Or a bug fix. |
| 15:31 |
Stompro |
kmlussier, ah ok, that is the Admin -> Server Admin -> MARC Search/Facet Fields gui. |
| 15:31 |
kmlussier |
Stompro: Yes, that's right. When I began playing with indexes, that interface didn't exist, so I often forget it's there. |
| 15:32 |
kmlussier |
I also used to walk uphill to school every day. Both ways. |
| 15:34 |
Stompro |
kmlussier, I know nothing of Mods, and I don't see anything in that XPath having to do with subfields. Any pointers on how to modify "//mods32:mods/mods32:relatedItem[@type="series"]/mods32:titleInfo[not(@type="nfi")]" to only include subfield a? |
| 15:34 |
Stompro |
I would be happy to file a bug on this also. |
| 15:35 |
kmlussier |
Stompro: Well, I don't know that you want to change the main xpath since that also controls what's being indexed for search. I was speaking specifically of the facet_xpath field. |
| 15:36 |
jeff |
ah. now i remember at least part of the rabbit hole i ended up in when looking at this last. |
| 15:36 |
kmlussier |
Stompro: And, no, I don't really know what you would have to put in there. |
| 15:37 |
kmlussier |
I'm sure there is a better way to do this, but you could also set facet to false for that field and create a new facet field that is based on marcxml, not mods. |
| 15:37 |
jeff |
Stompro: so, you're looking at an xpath expression that references MODS. At that point, you're no longer dealing with MARCXML, because the MARCXML has been passed through a MARCXML to MODS XSLT which has performed some complex, handy, but very lossy transformations on the record. |
| 15:38 |
kmlussier |
What I meant to say is create a new series field based on marcxml that is only used for faceting. |
| 15:39 |
jeff |
> Sorry, no entries were found for deathly hallows. |
| 15:39 |
jeff |
er, right. |
| 15:39 |
jeff |
I don't believe you, gapines.org. |
| 15:41 |
Stompro |
Thanks kmlussier and jeff for the pointers. |
| 15:41 |
kmlussier |
mods doesn't give you much flexibility with series information, does it? It's just something lumped under relateditem. |
| 15:42 |
Stompro |
I'll submit a bug report also, it doesn't seem right to have multiple listings for a series in the facet... I want it to show me all titles in the series, not just one. |
| 15:44 |
jeff |
A can of worms worth opening. |
| 15:53 |
Stompro |
LP 1083796 looks like it might be related, along with lp 1102739 |
| 15:53 |
pinesol_green |
Launchpad bug 1083796 in Evergreen 2.4 "Series display on record details page may be corrupt" [Medium,Confirmed] https://launchpad.net/bugs/1083796 |
| 15:53 |
pinesol_green |
Launchpad bug 1102739 in Evergreen "TPAC - series link in record fails with non-title series entries" [Medium,In progress] https://launchpad.net/bugs/1102739 - Assigned to Ben Shum (bshum) |
| 15:55 |
|
jlitrell joined #evergreen |
| 15:55 |
* jeff |
nods |
| 15:55 |
Stompro |
And lp 1353092 |
| 15:55 |
pinesol_green |
Launchpad bug 1353092 in Evergreen "Searching: Series Browse issues" [Undecided,New] https://launchpad.net/bugs/1353092 |
| 16:16 |
dbs |
Hmm, do our Google-based calendars use XML feeds? |
| 16:16 |
dbs |
"Because of low usage, and in an effort to streamline our services, from 18 November 2015, XML feeds will no longer be available in Google Calendar." |
| 16:18 |
* dbs |
disappears |
| 16:19 |
jeff |
dbs: I'm not aware of anywhere where we rely on the XML feed for any community Google calendars |
| 16:25 |
* eeevil |
reads up ... so, the MODS 3.2 tranform says that 440av (all together) goes into <relatedItem><titleInfo><title> ... I haven't checked later MODS revisions |
| 16:27 |
eeevil |
however, 490[ind1=0]a is different, and is stored separate from $v |
| 16:28 |
jeff |
I have, and grew frustrated. |
| 16:28 |
eeevil |
so, cataloging can control it today. just use 490[ind1=0] instead of 440. easier said than done, I know |
| 16:29 |
eeevil |
3.3 and 3.5 are the same in this respect |
| 16:31 |
jeff |
eeevil: Memory (and a quick check just now) serves that subfields a and v of the 490 are concatenated into the same element in MODS. Are you seeing a MARCXML to MODS XSLT that creates series info from just the 490$a? |
| 16:33 |
eeevil |
jeff: I'm just reading the rules at http://www.loc.gov/standards/mods/v3/mods-mapping.html#relateditem ... the xslt could certainly differ from the docs, obv ;) |
| 16:33 |
eeevil |
also... |
| 16:33 |
miker |
jeff: that suggests 440 has a and v concatenated, but 490 with ind1=0 should not |
| 16:34 |
miker |
if I'm reading it right, of course |
| 16:36 |
miker |
if so, a facet_xpath should be able to grab just <title> and not <partNumber> |
| 16:36 |
miker |
(but, again, docs...) |
| 16:37 |
* jeff |
nods |
| 16:38 |
* jeff |
tests |
| 16:45 |
Stompro |
miker, our series titles are stored with 490[ind1=0], so that shouldn't be an issue. |
| 16:46 |
berick |
hmm, in all the discussion of negative balances, has there ever been any talk of avoiding a negative balance only when it's negative because of a forgive payment? |
| 16:46 |
miker |
if I'm, indeed, correct, you could set the facet_xpath to "//*[local-name()='title']" on the series title index definition, then. my tuits are lacking for testing, but give it a try? |
| 16:47 |
miker |
berick: specifically a money.forgive_payment row? I don't thinks so |
| 16:47 |
berick |
for example, if a patron returns a lost item they paid for, they get the money back. but, if a patron returns a lost item whose charge was forgiven, they don't |
| 16:47 |
berick |
miker: right |
| 16:47 |
kmlussier |
berick: We made a distintion between overdue balances and lost items. No talk of forgive fines in discussions I've been involved in. |
| 16:48 |
miker |
berick: the problem usually comes from payments on large lost-related fines, and then having the item come home, I think. kmlussier, is that right? |
| 16:49 |
jeff |
our approach is just "no refunds" |
| 16:49 |
jeff |
so that part was simple for our branch. |
| 16:49 |
kmlussier |
Yes, that's right. But in our case, we don't want those negative balances to generate whether they're were paid with cash or forgiven, so it's a distinction we weren't concerned with. |
| 16:50 |
kmlussier |
From what I understand, even the libraries that do provide refunds prefer to track it manually in some other way. |
| 16:50 |
* jeff |
shudders |
| 16:50 |
miker |
berick: are you thinking along the lines of: void the fines, if neg then void any forgives, if pos forgive the remainder ... ? |
| 16:51 |
mmorgan |
Another frequent cause of negative balances is amnesty checkin. |
| 16:51 |
* jeff |
nods |
| 16:51 |
berick |
miker: something along those lines, yes |
| 16:51 |
berick |
didn't want to go do deep before consulting the oracle^H^H^H^HIRC |
| 16:52 |
miker |
berick: hrm... I see the logic conceptually (forgiveness only goes so far ... ;) ) but that may be even more subtle than void vs adjust |
| 16:52 |
jeff |
Evergreen 2.next: nuke billing from orbit |
| 16:52 |
berick |
miker: my fear exactly. |
| 16:52 |
berick |
it won't be straightforward |
| 16:52 |
kmlussier |
I understand the use case, but I also feel my blood pressure rising over more complications in the negative balance code. |
| 16:53 |
berick |
kmlussier: omg, i know :) |
| 16:53 |
miker |
kmlussier: I think we all do :) |
| 16:53 |
kmlussier |
On the other hand, this one isn't my project. So I can pretend it just isn't happening. :) |
| 16:53 |
berick |
the shoe's on the other foot, now |
| 16:54 |
berick |
i might let the simmer for a bit unless anyone has any particular thoughts |
| 16:54 |
berick |
not ready to dive all in just yet |
| 16:55 |
jeff |
kmlussier: other than what may be in the bug, did the set of billing use cases / scenarios ever happen? |
| 16:56 |
jeff |
i have some vague memory of discussing its usefulness at the conference, but i don't remember if it existed, was likely to happen, or just remains a "nice to have" |
| 16:56 |
kmlussier |
Well, there are a couple of things. |
| 16:57 |
Stompro |
miker, what needs to be done after a config.metabib change for the change to take effect? I tried the facet_xpath you suggested and restarted apache/opensrf but didn't see any change in behavior. |
| 16:57 |
kmlussier |
There's this http://wiki.evergreen-ils.org/doku.php?id=scratchpad:negative_balances . But then I forgot that I wrote that, so I then did this several months later. http://wiki.evergreen-ils.org/doku.php?id=qa:billing_test_cases |
| 16:57 |
jeff |
kmlussier++ thanks |
| 16:58 |
jeff |
kmlussier: anything else, before you presumably start your weekend? |
| 16:58 |
kmlussier |
The latter is what remingtron referred to when adding some of the live tests with the code. |
| 16:58 |
kmlussier |
Weekend? What's that? |
| 16:58 |
kmlussier |
Nope. That's all. |
| 17:03 |
miker |
Stompro: reingest a record (save it in the marc editor) and search again with a cache killer (put "-sdflkklsdaklsdf" without quotes at the end of the search string) |
| 17:05 |
miker |
berick: entirely unrelated to your topic, we can't cause the webstaff to set is_staff in mod_perl today (and cause staff searches in the embedded opac) because it will force an oils: protocol. correct? |
| 17:07 |
miker |
well, and because it's currently done via an http header |
| 17:09 |
berick |
miker: actually, it is set when a workstatoin is linked to the login session |
| 17:09 |
berick |
that was my compromise |
| 17:10 |
berick |
though it does look like there may be cases where oils: may still be used |
| 17:11 |
berick |
specifically in the redirect_ssl and redirect_auth functions |
| 17:11 |
berick |
those should be modified to use $ctx->{proto} instead of hardcoding "oils:" |
| 17:11 |
|
mmorgan left #evergreen |
| 17:12 |
miker |
hrm... ok... thanks. seeing bugs where they don't be. pardon the noise |
| 17:14 |
miker |
and, yep. ye olde "no workstation" prob |
| 17:28 |
Stompro |
miker, no change after reingesting ~10 records and using the cache killer line. Thanks for the help though, I'll keep trying various things. |
| 17:29 |
miker |
np, thanks for testing |
| 17:34 |
|
bmills joined #evergreen |
| 18:06 |
|
Dyrcona joined #evergreen |
| 18:07 |
|
Dyrcona left #evergreen |
| 18:09 |
|
jihpringle_ joined #evergreen |
