| Time |
Nick |
Message |
| 06:40 |
|
rlefaive joined #evergreen |
| 07:11 |
|
Stompro joined #evergreen |
| 07:14 |
|
rjackson_isl joined #evergreen |
| 07:16 |
|
agoben joined #evergreen |
| 07:51 |
|
gsams joined #evergreen |
| 08:06 |
|
Ilie` joined #evergreen |
| 08:09 |
|
kmlussier joined #evergreen |
| 08:20 |
|
Dyrcona joined #evergreen |
| 08:37 |
|
mmorgan joined #evergreen |
| 08:40 |
|
remingtron joined #evergreen |
| 08:53 |
Dyrcona |
Hmm... Looks like I used Evergreen backend calls in my Safari record load program. (A propos yesterday's conversation about Overdrive record loading.) |
| 08:57 |
Dyrcona |
One bonus of using DBI or SQL with these loads is it usually easier to point it at a test database/environment. You don't have to setup a full-blown Evergreen installation to test it. |
| 08:57 |
* Dyrcona |
goes back to working on his EBL load. |
| 09:24 |
|
yboston joined #evergreen |
| 09:31 |
jeff |
i'm a fan of making "you don't have to setup a full-blown Evergreen installation to test" sound silly. |
| 09:32 |
|
jvwoolf1 joined #evergreen |
| 09:32 |
jeff |
almost (but perhaps not quite) how git changed how many people from cvs or svn days thought about branches. |
| 09:33 |
jeff |
nobody says "but then i'd have to create a branch, and i don't want to go through that hassle" anymore. |
| 09:34 |
jeff |
(perhaps they never used those exact words -- i'm exaggerating a little bit to try and make this analogy work!) |
| 09:34 |
tsbere |
jeff: I say that on a regular basis! Mainly due to being lazy about making more generic versions of my MVLC-specific solutions. ;) |
| 09:35 |
Dyrcona |
Well, once I started scripting vm creation, I didn't worry so much about setting up a full blown installation to test. :) |
| 09:36 |
|
bos20k joined #evergreen |
| 09:36 |
Dyrcona |
Still, it's nice sometimes to just run a script and change a host name or database name command line option rather than worrying so much about where you are running it. |
| 09:37 |
jeff |
yes. |
| 09:37 |
jeff |
I didn't mean to critique your statement earlier, just took the opportunity to riff off of it a bit. :-) |
| 09:39 |
Dyrcona |
Understood, and I pretty much agree. |
| 09:40 |
Dyrcona |
At one point, I configured a server with Evergreen installed as a client so that it could communicate with production or with my development vm. |
| 09:41 |
Dyrcona |
I would set the environment so that the appropriate conf files and libs would be in place. |
| 09:41 |
Dyrcona |
That was a little tedious, so I mostly left it talking to production. |
| 09:50 |
csharp |
JBoyer: I was afk most of yesterday - yes, I would love to see autorenew, but I never did follow up with a bug report |
| 09:51 |
* csharp |
sings ""you don't have to setup a full-blown Evergreen installation to have a good time, oh no" |
| 11:38 |
|
brahmina joined #evergreen |
| 12:05 |
|
bmills joined #evergreen |
| 12:37 |
csharp |
I've been arguing for years that we don't need the "freeform SQL" interface for the reporter because end users would be even more out of their depth than they are with the GUI, but I'm deciding it would be super handy to be able to construct an arbitrary query and schedule it to recur (within the EG reports structure) |
| 12:37 |
csharp |
like, with actual subqueries and more advanced logic and stuff :-) |
| 12:37 |
tsbere |
csharp: Make a new permission for it, don't grant it to the normal users ever? ;) |
| 12:41 |
csharp |
tsbere: exactly |
| 12:42 |
csharp |
I've just come up against a couple of use cases this week where I don't want to create a view/fieldmapper object, but I do want it to *act* like a regular report |
| 12:43 |
JBoyer |
The very thought of an ILS having the equivalent of phppgadmin or similar in it makes me cringe in ways that make me cringe. |
| 12:44 |
csharp |
JBoyer++ |
| 12:44 |
JBoyer |
I mean, I get it, better reports, better join control, etc. but still, the cringing. |
| 12:44 |
csharp |
I understand |
| 12:45 |
kmlussier |
We had an open source discussion group at a local conference a couple of weeks ago, and the Koha folks talked about how much they loved their freeform SQL reports. Of course, I think part of the love was due to the fact that their wiki has such a large library of SQL queries that can be used. |
| 12:46 |
* jeff |
waits for csharp to realize that he has described something pretty similar to JasperReports Server |
| 12:46 |
rhamby |
I have and continue to be a proponent of a similar to Koha reports interface to Evergreen, not to replace the current reporter but in addition to. |
| 12:47 |
jeff |
(though upon review, i retract my action -- different on a few fronts) |
| 12:47 |
kmlussier |
I would be in favor of adding it, with the caveat that it have its own permission as tsbere and csharp already noted. |
| 12:47 |
csharp |
jeff: it hit me about forty-five seconds ago :-P |
| 12:50 |
rhamby |
I agree it would need seperate permissions from the regular reporting to create reports or edit them but my vision is slightly different from Koha's in that I would like to see variables that can be assigned and lower permission levels could be used to edit the variables |
| 12:50 |
JBoyer |
CREATE_SQL_TEMPLATE vs SCHEDULE_SQL_TEMPLATE ? |
| 12:51 |
tsbere |
JBoyer: I would say you just need the create permission. If you want to let someone *run* it then they need to have access to it. If they shouldn't run it, don't share the template folder. |
| 12:51 |
gmcharlt |
rhamby: well, Koha's reporting system does allow for placeholders that the user must supply values for when running the report |
| 12:52 |
rhamby |
gmcharlt: then my vision is closer to Koha's than I realized :) |
| 12:52 |
* rhamby |
makes note to go back and spend a bit more time in the Koha reporter for familiarity |
| 13:10 |
|
jihpringle joined #evergreen |
| 13:12 |
|
hbrennan joined #evergreen |
| 13:42 |
kmlussier |
@dessert |
| 13:42 |
* pinesol_green |
grabs some Coconut Cream Pie for kmlussier |
| 13:56 |
hbrennan |
mmm totally morning-appropriate snack for me |
| 14:00 |
berick |
I eat more coconut cream pie before breakfast than most people eat all day |
| 14:05 |
hbrennan |
berick: So that's your secret. Smart guy. |
| 15:03 |
csharp |
@dunno add I eat more coconut cream pie before breakfast than most people eat all day |
| 15:03 |
pinesol_green |
csharp: The operation succeeded. Dunno #50 added. |
| 15:05 |
mmorgan |
So, in a patron's bill history, you can filter by a range of either the transaction start date or a payment date. Am I missing a way to retrieve by xact id? |
| 15:06 |
mmorgan |
Just thinking of a situation where a patron has paid for a lost item and then brings it back. What's the easiest way to find the transaction? |
| 15:10 |
|
maryj joined #evergreen |
| 15:13 |
tsbere |
mmorgan: I don't know of any way to retrieve things by xact id in the client. |
| 15:15 |
mmorgan |
tsbere: Thanks, didn't think there was a way. So for libraries looking for the transaction in the bill history to do a refund, what's the quickest way to find it? |
| 15:15 |
|
collum joined #evergreen |
| 15:16 |
tsbere |
mmorgan: Show, say, the barcode column, retrieve as far back as you want to, then sort by the barcode column? Unless you know the ID, in which case show and sort by the Bill # column? |
| 15:22 |
mmorgan |
Ok, so there really isn't a way to find it other than working from a date range, sorting in various ways and wading through the various charge and payment types til you find the transaction you're looking for. |
| 15:22 |
tsbere |
Not that I know of. |
| 15:23 |
tsbere |
I don't claim to be an expert, though. |
| 15:23 |
mmorgan |
Thanks for the eyes. tsbere++ |
| 15:24 |
tsbere |
mmorgan: Also, I make no claim to knowing what is and is not possible in the web client. |
| 15:25 |
tsbere |
mmorgan: I suppose one option, if you have the item, is to use item status to look up the last few circulations to get potentially useful information? |
| 15:25 |
tsbere |
(like the circ id, which I believe is also the bill id on the history transactions tab) |
| 15:26 |
tsbere |
mmorgan: And, if you want to "re-activate" you could add a .01 billing or something to make the circ active again.....not sure I like that idea though. |
| 15:27 |
mmorgan |
Yes, you could get the dates there, and the circ id/bill#, but still it seems cumbersome to zero in on the transaction on the patron record. |
| 15:27 |
mmorgan |
You'd need to find it before you could add the .01 |
| 15:28 |
tsbere |
mmorgan: Er, the "last few circulations" window has an "add billing" button |
| 15:29 |
mmorgan |
So it does. But not sure I like the idea of adding the extra billing either. |
| 15:30 |
jeff |
mmorgan: what prevents you from checking in the item and letting the system take care of any billing adjustments via configured policy? is this for scenarios where you are intentionally... applying human subjective reasoning possibly in contradiction with configured policy? :-) |
| 15:32 |
mmorgan |
jeff: This would be for case by case refunds. |
| 15:35 |
mmorgan |
Automatic refunds are problematic when the library turns the money over to the municipality. |
| 15:38 |
Dyrcona |
mmorgan: Those libraries should have a no refund policy and use the appropriate negative balance settings. |
| 15:39 |
Dyrcona |
You lost it, you paid for it, it's yours. |
| 15:39 |
kmlussier |
There is always a need for case-by-case decisions. |
| 15:39 |
mmorgan |
Dyrcona: They do use the no negative balance settings. Hence the case by case refund question. |
| 15:40 |
* Dyrcona |
prefers general cases. :) |
| 15:41 |
* mmorgan |
does as well, but ... what kmlussier said. |
| 15:49 |
* kmlussier |
reads feedback evergreen-ils.org e-mail asking if TLC records in MARC text format can be migrated to Evergreen. |
| 15:50 |
kmlussier |
I'm not quite sure what is meant by 'MARC text format.' |
| 15:52 |
dbs |
kmlussier: line-oriented MARC |
| 15:52 |
JBoyer |
kmlussier, probably similar to MARCEdit's text format. |
| 15:52 |
dbs |
yaz-marcdump generates a flavour of this; MARCEdit can too I believe |
| 15:52 |
JBoyer |
Ah, like dbs said. |
| 15:55 |
kmlussier |
Can those records be imported into Evergreen then or does she need to manipulate them first? |
| 15:59 |
JBoyer |
Oh right, the actual question. No. |
| 16:00 |
dbs |
kmlussier: but the effort to manipulate them back into MARC21 or MARCXML is probably 1/1000th of the effort of setting up evergreen |
| 16:00 |
JBoyer |
If the format is similar enough to MARCEdit's text format it may be able to convert them to MARC or MARCXML. |
| 16:01 |
Dyrcona |
I've never tried that. |
| 16:02 |
Dyrcona |
yaz-marcdump looks like it could do it. |
| 16:02 |
JBoyer |
Is this because you can't get proper MARC out of a TLC install without some outside assistance? (I don't have enough experience with it to know) |
| 16:02 |
kmlussier |
Has anyone here ever worked with TLC records before? |
| 16:03 |
kmlussier |
JBoyer: I don't know. She didn't say. |
| 16:03 |
Dyrcona |
I might have. I don't remember what Groton was using before they joined MVLC. |
| 16:04 |
Dyrcona |
What do ya know... They were on Library.Solution from TLC. |
| 16:05 |
Dyrcona |
If she can get the records into either binary MARC or MARCXML, they should load. |
| 16:05 |
kmlussier |
OK, that gives me enough to write a somewhat helpful response. Thanks! |
| 16:05 |
kmlussier |
dbs++ JBoyer++ Dyrcona++ |
| 16:06 |
dbs |
kmlussier++ # actually responding |
| 16:06 |
Dyrcona |
And, here's a quote from the TLC Extraction Services document: The library can extract their own bibliographic MARC records from Library•Solution® using Cataloging Utilities/Extract Records feature. The extracted file is MARC Communication format. |
| 16:06 |
kmlussier |
dbs: I'm surprised I caught it. I usually just assume those e-mails are spam. |
| 16:06 |
rhamby |
I've gotten records from TLC before and they were standard bin marc files |
| 16:07 |
Dyrcona |
rhamby kmlussier: That's what I suspect the user has. They just don't know it. But I don't know anything about it beyond what I was given and what's in the TLC document that I still have. |
| 16:23 |
|
mmorgan1 joined #evergreen |
| 16:32 |
|
bmills joined #evergreen |
| 17:05 |
|
jvwoolf1 left #evergreen |
| 18:50 |
|
brahmina joined #evergreen |
| 20:57 |
|
bmills joined #evergreen |
| 21:22 |
|
bmills joined #evergreen |
