| Time |
Nick |
Message |
| 02:03 |
|
gsams joined #evergreen |
| 03:56 |
|
gsams joined #evergreen |
| 07:18 |
|
jboyer-isl joined #evergreen |
| 07:27 |
|
timf joined #evergreen |
| 08:05 |
|
akilsdonk joined #evergreen |
| 08:24 |
|
mrpeters joined #evergreen |
| 08:30 |
|
Shae joined #evergreen |
| 08:36 |
|
RoganH joined #evergreen |
| 08:42 |
|
ericar joined #evergreen |
| 08:56 |
|
mmorgan joined #evergreen |
| 09:07 |
|
kmlussier joined #evergreen |
| 09:23 |
|
dluch joined #evergreen |
| 09:24 |
|
gsams joined #evergreen |
| 09:28 |
|
yboston joined #evergreen |
| 10:19 |
|
mrpeters joined #evergreen |
| 11:18 |
dbs |
Random fun stats question of the day: how many entries do you have in your money.billing table? "SELECT COUNT(*) FROM money.billing;" |
| 11:18 |
eeevil |
dbs: all the entries. all. of. them. |
| 11:18 |
dbs |
We're at 2.5 million |
| 11:19 |
eeevil |
dbs: I was about to ask if your billing table is longer than your mfr table ... it's not ;) |
| 11:22 |
dbs |
Heh, definitely not |
| 11:22 |
mmorgan |
dbs: We're at 11.9 million |
| 11:22 |
jeff |
14.1M here, and I know that 9M are not needed. |
| 11:23 |
jeff |
with that 14.1M, we're CLOSE to mfr (16.2M) :-) |
| 11:29 |
|
jwoodard joined #evergreen |
| 11:29 |
eeevil |
back in the day, PINES mfr used to be ~110M, IIRC |
| 11:33 |
dbs |
110 million. Wow. |
| 11:33 |
dbs |
oh, MFR :) |
| 11:34 |
eeevil |
billing might be that big by now |
| 11:34 |
bshum |
dbs: 14434358 for us when I run that query. |
| 11:34 |
eeevil |
but if you really want your mind blown, see action.hold_copy_map in a busy 1.4-era install ;) |
| 11:35 |
dbs |
Cool. Nice to know that even with our 5-minute fines we're still well within normal limits :) |
| 11:35 |
eeevil |
(HINT: there was a good reason for the change from SERIAL to BIGSERIAL) |
| 11:36 |
dbs |
Yeah, we're at 102 million MFR rows |
| 11:37 |
|
Wyuli joined #evergreen |
| 11:37 |
dbwells |
We've only got 200k rows in money.billing. Our fine policies must be too lax, because I don't think our users are *that* responsible ;) |
| 11:39 |
|
snowkitten_ joined #evergreen |
| 11:40 |
* dbs |
wonders if anyone else has implemented a sitemap for their Evergreen install |
| 11:42 |
jeff |
talked about it long long ago, but no. |
| 11:43 |
jeff |
i'd be supportive of something that helped increase search engine visibility while reducing load generated by search engine crawling. |
| 11:43 |
jeff |
which i suspect covers the goals you had in mind? |
| 11:45 |
jeff |
and, i just noticed you said "anyone else" -- are you saying you created a sitemap? simply a list of all records in the system, or something else? |
| 11:45 |
|
kbeswick joined #evergreen |
| 11:45 |
jeff |
rather, simply generated a list of all /eg/opac/record/* urls based on a db query, or something else? |
| 11:46 |
dbs |
jeff: yeah, I created one a few years ago, lemme expose the very rough doc I created for that |
| 11:46 |
dbs |
https://docs.google.com/document/d/1kWZDoRse92WEWLzGEeVgo6ES01YByRcVdUqYw04dEuA/edit?usp=sharing |
| 11:49 |
csharp |
dbs: PINES is at 134.7M billings |
| 11:49 |
csharp |
and that's after a purge of pre-2010 billings 2 years ago |
| 11:49 |
dbs |
csharp: wow. |
| 11:49 |
csharp |
yep |
| 11:51 |
bshum |
Hmm, for the SIP config in the part where it lists <checkout_override> events. Would the actual selfcheck user require the override permissions to automatically override those events? Or does the SIP server just exclude any listed events as they occur? |
| 11:51 |
csharp |
PINES is a humongous green monster |
| 11:52 |
bshum |
Some library wants to add more situations where checkouts are just automatically allowed for a particular SIP device. |
| 11:52 |
bshum |
Like a selfcheck where everything is greenlit |
| 11:54 |
|
RoganH joined #evergreen |
| 12:19 |
|
kbeswick joined #evergreen |
| 12:20 |
|
jihpringle joined #evergreen |
| 12:20 |
tsbere |
bshum: The selfcheck user would, I believe, need override permissions |
| 12:21 |
tsbere |
But I could be wrong |
| 12:21 |
tsbere |
You do need to list *all* events you want to automatically override, though, so "greenlight everything" would be problematic in that case |
| 12:29 |
bshum |
Yeah |
| 12:29 |
bshum |
Sigh |
| 12:37 |
|
geoffsams joined #evergreen |
| 12:45 |
mmorgan |
Does anyone have a recommendation for a kiosk browser for simple self-check? |
| 12:47 |
dbs |
mmorgan: "chrome --kiosk <url>"? |
| 12:47 |
bshum |
mmorgan: I like openKiosk personally |
| 12:47 |
bshum |
http://openkiosk.mozdevgroup.com/ |
| 12:47 |
bshum |
(oh they changed their website...) |
| 12:51 |
mmorgan |
Do slips print with either of those? |
| 12:52 |
bshum |
mmorgan: I... think it can. But I haven't tested it quite yet. |
| 12:54 |
mmorgan |
We've had trouble getting the slips to print with different kiosks, but we'll take a look at these. Thanks! |
| 12:57 |
|
krvmga joined #evergreen |
| 12:58 |
krvmga |
i've got a situation where one of the holds that a patron has placed is causing errors. in the staff client, looking at the patron's holds, there is one that is always "retrieving" and i can't see what it is. how can i get at that hold? |
| 12:59 |
krvmga |
i was thinking i'd need to go into the database to look for it. |
| 13:00 |
krvmga |
i pulled up the patron's record in the database. |
| 13:00 |
krvmga |
under actor.usr |
| 13:00 |
krvmga |
where do i pull up his holds? |
| 13:01 |
mmorgan |
select * from action.hold_request where usr = <usr.id> and fulfillment_time is null and cancel_time is null |
| 13:01 |
mmorgan |
will get you the holds that haven't been filled or cancelled |
| 13:01 |
krvmga |
mmorgan++ |
| 13:01 |
krvmga |
thank you |
| 13:02 |
Wyuli |
mmorgan: For self-check kisosks, I've used Firefox Portable (http://portableapps.com/apps/internet/firefox_portable) with pretty decent results on one of our machines. Having it default to open in fullscreen has worked fine provided you don't have a keyboard attached. |
| 13:02 |
mmorgan |
I would look for maybe a broken hold that has hold_type = P |
| 13:03 |
|
kbeswick joined #evergreen |
| 13:04 |
mmorgan |
Wyuli: Thanks! we'll look at that, too. |
| 13:08 |
Wyuli |
mmorgan: Now that I think on it, I believe that we had to edit the page setup to eliminate margins and remove headers/footers/page numbers etc. when printing, else the receipt printer would spit out of a foot of paper for one item. |
| 13:08 |
Wyuli |
Is that the problem you're having, or are things just not printing at all? |
| 13:10 |
mmorgan |
Things were just not printing at all. |
| 13:16 |
Wyuli |
Hmm. Have you made proper sacrificial offerings to appease the printers? Pretty sure that's what they require to work correctly. |
| 13:16 |
dbs |
with "chrome --kiosk", you can also pass a "--user-data-dir=<directory>" argument to set up a separate profile, which would presumably enable you to set up printer options |
| 13:18 |
bshum |
mmorgan: Oh you know... there was a bug for awhile in selfcheck |
| 13:18 |
bshum |
Where the receipts didn't print at all due to a javascript error |
| 13:19 |
bshum |
But I can't remember if that was ever resolved in more recent versions. Or if it only affected certain parts of the receipts. Like billings. |
| 13:20 |
mmorgan |
Do bugs work as sacrificial offerings? :) |
| 13:22 |
mmorgan |
I know a few kiosks have been tried and some printed but had other issues. We need to do some more testing, these suggestions will help. |
| 13:23 |
mmorgan |
dbs++ bshum++ Wyuli++ |
| 13:25 |
|
jwoodard joined #evergreen |
| 13:33 |
tsbere |
bshum: I think part of the problem with printing is "modern web browsers don't allow automatic printing, or interaction with printer settings in general, at all from web pages anymore" |
| 13:36 |
Wyuli |
mmorgan, tsbere: The Evergreen self-check module and I are not on real good terms. :\ There's a pretty slick open source self checkout packge that runs on PHP and is pretty slick. |
| 13:37 |
Wyuli |
Upside: Fully customizable |
| 13:37 |
Wyuli |
Downside: Fully customizable. Also requires a PHP server. |
| 13:40 |
dbs |
Wyuli: which evergreen self-check module? |
| 13:41 |
mmorgan |
can't stand the suspense... |
| 13:46 |
Wyuli |
Sorry, patrons pulled me away. |
| 13:46 |
Wyuli |
I erm...can't say which module we're running. I'm a simple librarian in the Indiana network, I don't have access to the self-check code itself. :) |
| 13:48 |
Wyuli |
As far as the custom self-check, please forgive the shameless plug, but I've tried to consolidate as many of the help guides / tutorials / file downloads as I can in one place: http://www.greensburglibrary.org/selfcheck |
| 13:49 |
dbs |
Wyuli: the one we support now is at https://[hostname]/eg/circ/selfcheck/main (per http://docs.evergreen-ils.org/2.5/_self_checkout.html) |
| 13:50 |
Wyuli |
dbs++ Thank you! |
| 14:05 |
Wyuli |
dbs: That site is working correctly and not throwing JavaScript errors when we try and print. Hooray! |
| 14:05 |
Wyuli |
I think I ran into some issues with the workstation parameter, though. :| |
| 14:06 |
Wyuli |
I can get by without the ?ws=..., but not sure if that would invoke the wrath of folks at Evergreen Indiana central command. :) |
| 14:06 |
bshum |
"central command" I love it. |
| 14:10 |
|
brent_sage joined #evergreen |
| 14:12 |
|
rjackson-isl joined #evergreen |
| 14:17 |
|
Dyrcona joined #evergreen |
| 14:25 |
|
RoganH joined #evergreen |
| 14:26 |
|
gsams joined #evergreen |
| 14:39 |
jboyer-isl |
Wyuli, bshum: Always watching. http://www.lightmasterstudios.co.uk/wp-content/uploads/2012/01/Monsters-Inc-Roz.jpg |
| 14:40 |
bshum |
jboyer-isl++ #awesome. |
| 14:40 |
dbwells |
jboyer-isl: Wait, *you're* number one? |
| 14:41 |
jboyer-isl |
Wyuli: More seriously: you have to either 1. register a new workstation id through a real client, or 2. put in a ticket and one of us will make one you can use. The thing after ?ws= has to already exist before you can use it. (And you'll probably want to use it for reporting!) |
| 14:41 |
* dbwells |
gasps |
| 14:42 |
jboyer-isl |
dbwells: I don't like paperwork enough, to be honest. |
| 14:51 |
|
geoffsams joined #evergreen |
| 15:01 |
Wyuli |
jboyer-isl: That is basically how I picture ISL staff members every time I submit a help desk ticket. |
| 15:02 |
Wyuli |
Though the eyes could be a little more judgmental and filled with hatred, though. |
| 15:02 |
|
snowkitten__ joined #evergreen |
| 15:03 |
Wyuli |
(Seriously though, you guys are great!) |
| 15:03 |
jboyer-isl |
Not at all. We're a kindler, gentler, judgementaler helpdesk. (choose 2, but choose wisely) |
| 15:06 |
Wyuli |
Truly a helpdesk of wealth and taste! |
| 15:07 |
Wyuli |
Scholars and gentlefolk, all. |
| 15:09 |
|
shadowspar joined #evergreen |
| 15:16 |
|
rfrasur joined #evergreen |
| 15:20 |
|
kmlussier joined #evergreen |
| 15:27 |
Wyuli |
Hmm...on the bills tab of the patron's account screen, any idea why billed items in the list are unchecked by default on some staff clients but not others? |
| 15:27 |
kmlussier |
Wyuli: There's a setting for that. |
| 15:27 |
kmlussier |
Maybe a library setting? |
| 15:28 |
bshum |
It is a library setting, yes. |
| 15:29 |
bshum |
"Uncheck bills by default in the patron billing interface" |
| 15:29 |
bshum |
In the "GUI" category of settings |
| 15:30 |
kmlussier |
bshum: Beat me to it. :) |
| 15:30 |
bshum |
kmlussier: Does that mean my staff client launching was just fractionally faster than yours? :D |
| 15:30 |
Wyuli |
bshum++ kmlussier++, thanks! |
| 15:30 |
kmlussier |
bshum: I was distracted. |
| 15:30 |
Wyuli |
It's defaulting to checked on some and unchecked on others...which is odd. Will take a look there. |
| 15:30 |
bshum |
kmlussier: So was I, seeing what medals got sent out :D |
| 15:30 |
bshum |
dbwells++ # fun! |
| 15:31 |
kmlussier |
Wyuli: Are the workstations registered at different org units? |
| 15:31 |
Wyuli |
kmlussier: I'm about to find out!! |
| 15:32 |
Wyuli |
The staff clients were installed before my time by someone else (*ominous peal of thunder*) so not sure. |
| 15:35 |
Wyuli |
Date Changed Location Original Value New Value |
| 15:35 |
Wyuli |
2014-03-04T09:24:58-0500GDCPLGtruenull |
| 15:35 |
Wyuli |
2014-03-04T08:03:19-0500GDCPLGnulltrue |
| 15:36 |
Wyuli |
Oh my that is ugly, should have used pastebin, apologies.\ |
| 15:36 |
jboyer-isl |
Wyuli: Also, some settings are only checked at login, so if some clients were started later in the day (Say, after we changed that setting at your library while working on a ticket...) they'll behave differently. |
| 15:36 |
Wyuli |
Looks like the setting was true for...90 minutes earlier today? |
| 15:36 |
Wyuli |
Ohoho |
| 15:37 |
bshum |
Hehe |
| 15:37 |
Wyuli |
jboyer-isl++ Thanks; I think that solves the mystery rather succinctly. :) |
| 15:38 |
berick |
dbwells++ # 2.6 beta summary |
| 15:48 |
|
senator joined #evergreen |
| 15:54 |
eeevil |
I think we have code attached to all the RC blockers now ... https://bugs.launchpad.net/evergreen/+bugs?field.tag=2.6-rc-blocker is looking for testers. IMO, the sooner we can get those big ones out of the way the sooner we can start sweeping up the smaller bugs ... so, here's a call for testing, folks! |
| 15:55 |
dbs |
eeevil++ |
| 15:56 |
dbwells |
eeevil++ |
| 16:01 |
gmcharlt |
eeevil++ |
| 16:05 |
|
kbeswick joined #evergreen |
| 16:05 |
eeevil |
whee thanks! |
| 16:06 |
eeevil |
dbwells: not trying to steal your thunder, of course. but I /am/ hoping for a new category of award... ;) |
| 16:52 |
|
kbeswick left #evergreen |
| 17:20 |
|
mmorgan left #evergreen |
| 17:25 |
|
dcook joined #evergreen |
| 17:26 |
* bshum |
twiddles his thumbs waiting for 0864 to run on his test server. (finish already!!) |
| 17:31 |
bshum |
And it dies. |
| 17:31 |
bshum |
Oy :( |
| 17:31 |
dbwells |
:( |
| 17:31 |
bshum |
Stupid reporter.classic_current_circ depends on rec_descriptor stuff |
| 17:31 |
bshum |
Guess that's a killer. |
| 17:32 |
bshum |
@hate custom reporter stuff |
| 17:32 |
pinesol_green |
bshum: The operation succeeded. bshum hates custom reporter stuff. |
| 17:33 |
dbwells |
bshum: so classic_current_circ is something local? I don't think I've heard of it before otherwise. |
| 17:33 |
bshum |
dbwells: I think anything "classic" is one of the custom reporter-extension things that PINES created. |
| 17:33 |
bshum |
And is used by Indiana, myself, and probably a few others. |
| 17:33 |
bshum |
It's part of the stock, but not installed by default. (and not super well supported) |
| 17:34 |
dbwells |
Ah, thanks. |
| 17:34 |
bshum |
I try to avoid it when I can, but it's one of the many things I'd like to see revised someday to either become part of stock or unofficial nuked from existence :) |
| 17:35 |
bshum |
But that's definitely going to hurt somebody in production someday. |
| 17:35 |
* bshum |
ponders |
| 17:35 |
bshum |
Yeah, it's looking for metabib.rec_descriptor |
| 17:35 |
bshum |
Which is one of the things we're dropping |
| 17:36 |
dbwells |
I am guessing we should just drop that view and recreate it when the upgrade is done. It should still work with the rec_descriptor view replacement, I think. |
| 17:36 |
dbwells |
Might be really slow, though. |
| 17:37 |
bshum |
I'm not even sure why it's part of the view... |
| 17:37 |
bshum |
The join for metabib.rec_descriptor rd isn't even in the SELECT for the view itself. |
| 17:38 |
bshum |
Oooh |
| 17:38 |
bshum |
I see |
| 17:38 |
bshum |
It's used for stuff further on |
| 17:38 |
bshum |
Bleh |
| 17:38 |
dbwells |
Yeah, it's the middle man for other stuff. |
| 17:40 |
dbwells |
Dropping and recreating views is obviously a pretty painless fix, though a better fix would be to rework the view itself to use the new stuff. |
| 17:42 |
bshum |
So like... DROP VIEW IF EXISTS reporter.classic_current_circ; before the DROP VIEW for metabib.rec_descriptor, I guess. |
| 17:43 |
bshum |
And then maybe put a note at the end about running the recreate for it if you still want it. |
| 17:44 |
bshum |
Sigh, maybe that'll be yet another project idea for Hackfest. Fix and generalize the example reporter scripts and make them stock. |
| 17:44 |
bshum |
Because some people do find value in parts of them. |
| 17:48 |
bshum |
To make it so that 0864 doesn't kill those of us who have this issue on master, should we write a commit to fix that in the actual file and then make a minor adjustment to the main 2.5-2.6 upgrade scripts? |
| 17:49 |
* bshum |
is never sure what's the best way to proceed with broken upgrade scripts. |
| 17:50 |
bshum |
And yes, 0864 completes if you put that DROP VIEW for that classic_current_circ |
| 17:50 |
dbwells |
How long did it take, and on what size data set? I am curious about the performance of that upgrade. |
| 17:51 |
bshum |
Err |
| 17:51 |
bshum |
Couple minutes only |
| 17:52 |
dbwells |
ok |
| 17:52 |
bshum |
What parts would interest you? the inserts? |
| 17:52 |
bshum |
SELECT 26088753 |
| 17:52 |
bshum |
DELETE 5073636 |
| 17:52 |
bshum |
INSERT 0 3344788 |
| 17:52 |
bshum |
INSERT 0 2021 |
| 17:52 |
bshum |
INSERT 0 1184798 |
| 17:52 |
bshum |
Oh, and joy, I guess I can confirm https://bugs.launchpad.net/evergreen/+bug/1287510 too |
| 17:52 |
bshum |
:) |
| 17:52 |
pinesol_green |
Launchpad bug 1287510 in Evergreen "2.5.2-2.5.3-upgrade-db.sql and ERROR: column "behind_desk" does not exist" (affected: 1, heat: 6) [Undecided,New] |
| 17:53 |
|
Callender_ joined #evergreen |
| 17:54 |
bshum |
Oh you know dbwells |
| 17:54 |
bshum |
This is a bad, bad test |
| 17:54 |
bshum |
I keep forgetting I'm using my Thinkpad with the SSD |
| 17:54 |
bshum |
So it's probably doing the job much faster than it does with our regular disk servers. |
| 17:54 |
bshum |
I'll let you know when I run it on the other machines. |
| 17:54 |
|
mrpeters left #evergreen |
| 17:56 |
dbwells |
Oh, I was really just curious if we were talking minutes, 10s of minutes, or hours. I am not too worried about it. |
| 17:56 |
bshum |
Well, on the Thinkpad with SSD, it was no more than just minutes then. |
| 17:57 |
* bshum |
loves his portable Evergreen instance now. |
| 17:57 |
dbwells |
How much RAM do you have in that machine? |
| 17:58 |
bshum |
16 GB |
| 17:58 |
dbwells |
sweeeet |
| 17:58 |
bshum |
The SSD is a 500 GB one. I did a full sized copy of our live database. |
| 17:58 |
bshum |
The thing is like 50% faster on searching. And was about 200% better at hold placement too (pre patches) |
| 17:58 |
|
mrpeters joined #evergreen |
| 17:58 |
bshum |
So I wanted to see if it worked faster at hold placement now that we got those patches in |
| 17:59 |
dbwells |
Dang, that SSD is probably worth more than any computer I own. |
| 17:59 |
|
mrpeters left #evergreen |
| 17:59 |
bshum |
I'm making the pitch to get SSDs for our nextgen database server hardware. And using my Thinkpad to demo potential gains. |
| 18:00 |
dbwells |
Desktop SSDs have definitely become a better value, but enterprise-grade SSDs are still pretty pricey (to my pockets, anyway). |
| 18:01 |
bshum |
Indeed they are. |
| 18:01 |
dbwells |
Plus, you run the danger of losing touch with us normal folk :) |
| 18:04 |
bshum |
Meep, meep. |
| 18:07 |
bshum |
dbwells: I'll go ahead and file a new bug regarding what I discovered with the MVF upgrade script. |
| 18:07 |
bshum |
And that classic reporter issue |
| 18:07 |
bshum |
We'll figure out what to do about it sometime before release I guess :\ |
| 18:07 |
dbwells |
bshum++ # thanks, man |
| 18:08 |
bshum |
I'll finish whipping my test Evergreen frontend into shape and then see what things look like tomorrow. |
| 18:31 |
bshum |
@later tell berick When you have a chance, curious to get your opinion on this new bug https://bugs.launchpad.net/evergreen/+bug/1287973 |
| 18:31 |
pinesol_green |
bshum: The operation succeeded. |
| 18:31 |
pinesol_green |
Launchpad bug 1287973 in Evergreen "TPAC - CSS for advanced search filters" (affected: 1, heat: 6) [Undecided,New] |
| 18:31 |
bshum |
It's a tiny thing, but it irks me enough that I'd like to get to the bottom of it before 2.6 is "done" |
| 18:33 |
* bshum |
boggles at what URIs look like now... gah.... |
| 18:36 |
bshum |
Oh, I see... that's some weird group formats/editions weirdness maybe. |
| 18:39 |
bshum |
Internal server errors and timeouts. Well that's no good. |
| 18:49 |
bshum |
Yeah something is wrong. It goes 70 seconds and then times out whenever I try to click on a bib that seems to be combined with others through the group formats/editions. Maybe there's something in the enhancements that berick is working on that I should check out. |
| 18:50 |
eeevil |
bshum: there definitely is. I plan to merge a squashed, rebased version of that branch tomorrow morning |
| 18:50 |
bshum |
eeevil: Ah, cool. I'll watch for it then. |
| 18:51 |
bshum |
And make sure that nobody clicks on that option in advanced search during tomorrow's demos :) |
| 18:51 |
eeevil |
:) |
| 18:52 |
eeevil |
I'm not certain that what you're seeing is covered, but I am certain that there are bug fixes and that it works on fresh and upgraded test instances 'round here |
| 18:52 |
eeevil |
(and that we don't see ... that) |
| 18:52 |
|
ericar joined #evergreen |
| 18:52 |
bshum |
I have to take a closer look at these icon_format things |
| 18:52 |
eeevil |
bshum: I assume you reingested (or, at least the attrs, if not the full records)? |
| 18:53 |
bshum |
eeevil: I was just thinking that maybe I need to do some sort of reingest. It didn't note that in the upgrade actions. |
| 18:54 |
eeevil |
the CRA rewrite takes care of converting the SFV data to the new structure, but I'm not sure it gets all the new attrs ATM, and I am sure it doesn't gather all values for MVF-capable attrs |
| 18:55 |
eeevil |
(that upgrade set was written to swap ... have not page faulted it back in yet ;) ) |
| 18:59 |
bshum |
Well I guess I'll let that run for awhile then. |
| 19:02 |
bshum |
eeevil: One thing I saw too that I wasn't sure if maybe it's just a quirk for us is that on bibs that seemed to be grouped with electronic resources, the electronic resources links were displayed numerous times over. I'm not entirely sure if that's just a quirk with our system and how $9's work for us (I don't think we've enabled any other changes yet) |
| 19:03 |
bshum |
But also maybe it's a weird template issue for us |
| 19:03 |
bshum |
I'm going to try seeing what this should look like stock too. |
| 19:04 |
eeevil |
I'm almost positive that that's fixed. lemme check |
| 19:07 |
eeevil |
bshum: hrm... actually, I'm thinking of (part of) 169805f |
| 19:07 |
pinesol_green |
[evergreen|Mike Rylander] Teach evergreen.located_uris() about the new URI visiblity flag - <http://git.evergreen-ils.org/?p=Evergreen.git;a=commit;h=169805f> |
| 19:07 |
eeevil |
whoa .... good work pinesol |
| 19:07 |
bshum |
Heh |
| 19:07 |
eeevil |
(specifically, the SELECT DISTINCT wrapper query) |
| 19:08 |
bshum |
That's what I was wondering at first, but I didn't think it'd bubble up the electronic resources in the results like that for the whole consortium if I did a search unless I toggled the setting.... oh I see. |
| 19:08 |
* bshum |
looks again |
| 19:08 |
eeevil |
well, as far as duplication is concerned... |
| 19:08 |
eeevil |
but I might have misunderstood you |
| 19:09 |
bshum |
It's alright, I often have trouble with my words. And this is the first time I've actually had time to try applying these things to a test system. |
| 19:14 |
eeevil |
you know ... we might need to add "AND all_orgs.flag" (and wrap the pair in parens) for the right hand side of the OR in those where clauses. (let me know if you're not following ... I'm not giving a ton of context, I know) |
| 19:14 |
bshum |
Oh I'm surely lost. But maybe that's a consequence of not going home to eat dinner. |
| 19:15 |
eeevil |
heh ... poke me tomorrow re evergreen.located_uris() and all_orgs.flag, I'll know what you mean ;) |
| 19:15 |
eeevil |
now, go eat, man! |
| 19:15 |
bshum |
Yep, wandering. Thanks for trying on me anyways. Cheers and good luck till then. |
| 19:28 |
|
timf joined #evergreen |
| 22:29 |
|
shadowspar joined #evergreen |
| 22:49 |
|
jeff_ joined #evergreen |
| 22:50 |
|
gmcharlt joined #evergreen |
| 22:51 |
|
zerick joined #evergreen |
| 22:52 |
|
bradl joined #evergreen |
| 22:53 |
|
dbs joined #evergreen |
| 23:31 |
|
Guest76924 joined #evergreen |
