| # | Time | Nick | Message |
|---|
| # | 00:07:22 | tpham has joined #evergreen |
| # | 02:22:05 | tpham has quit IRC |
| # | 04:51:41 | phasefx | and concerning the z39.50 suggestion, I don't think PINES is exposing one |
| # | 07:18:36 | jhaig has joined #evergreen |
| # | 07:23:04 | jhaig | I have EG 2.0 beta 1 installed and I see that beta 2 is available. Can it be installed over the top, or should I uninstall first? I assume that I do not need to reinstall the database - I have had a quick search through the change log for the word 'database' and there doesn't seem to be any change to the structure indicated. |
| # | 07:31:10 | jhaig | Also (and I realise that this may be a bug that is fixed between beta 1 and beta 2) I have started setting up my library structure based on the example 'consortium' that comes with a default install. I am trying to delete some of the original organisational types and units but they do not delete when I click the 'delete' button or reload. |
| # | 07:49:33 | jhaig | I'm disconnecting now but if someone does see these questions and is kind enough to answer I will check the irc logs later. Thanks in advance. |
| # | 07:49:40 | jhaig has left #evergreen |
| # | 10:37:39 | Dyrcona has joined #evergreen |
| # | 10:57:38 | Dyrcona | Is sourceforge still the definitive source for the OpenNCIP code? I thought I saw something posted in IRC or the dev list that suggested it was now on github. However, searching github for OpenNCIP turns up nothing. |
| # | 10:57:52 | atz_ | SIPServer |
| # | 10:58:22 | Dyrcona | atz_: thanks, and does that mean there is no intention to add NCIP support to that module? |
| # | 10:59:01 | atz_ | well, it's been how many years and not even the stub of NCIP functionality is there. |
| # | 10:59:28 | atz_ | i think there might be intent, but I'm not sure it will involve that module much |
| # | 10:59:46 | atz_ | https://github.com/atz/SIPServer |
| # | 11:00:43 | Dyrcona | thanks, again. i just found the project on github |
| # | 11:03:10 | Dyrcona | I have two reasons for asking about it: 1. Actually adding NCIP functionality in Evergreen and 2. looking into this bug https://bugs.launchpad.net/evergreen/+bug/577068 |
| # | 11:04:17 | atz_ | sometime or other, the plan is to properly namespace the module and get it on CPAN, subclassed for Koha, EG, whatever else... |
| # | 11:04:19 | Dyrcona | If I could add the ability to configure port-based connections, that would ease our transition to Evergreen, since our current SIP server is set up with port-based connections rather than user name authentication. |
| # | 11:05:20 | atz_ | Dyrcona: ports work fine for SIP2 |
| # | 11:05:36 | Dyrcona | oh. I thought that bug implied that they didn't. |
| # | 11:05:56 | atz_ | no, it just shows that on the 3rd failure you get disconnected before getting the 940 |
| # | 11:06:41 | atz_ | and some other weirdness if you use invalid branchcodes |
| # | 11:07:07 | atz_ | so the bugs are related to *unsuccessful* logins |
| # | 11:07:24 | Dyrcona | ok. i am going to make a to-do list for myself with deadlines, and looking at SIP2 is going to be a high priority item. |
| # | 11:09:34 | atz_ | i'll be interested to know what the dev path for NCIP actually ends up being |
| # | 11:09:56 | Dyrcona | i'm looking at the Michigan RFQ. |
| # | 11:10:14 | atz_ | apparently the XC project has some framework in place |
| # | 11:10:16 | Dyrcona | i'd like to know what Eastern Oregon University comes up with. |
| # | 11:11:17 | Dyrcona | From what investigation I have done, NCIP is a bit of a mess. |
| # | 11:11:26 | atz_ | to put it nicely |
| # | 11:11:37 | Dyrcona | It's not so much a standard as it is a menu of options that vendors can implement. |
| # | 11:11:44 | atz_ | it's a lot of idea, and not much implementation. yeah. |
| # | 11:11:57 | atz_ | and implement differently |
| # | 11:12:01 | Dyrcona | yep |
| # | 11:12:24 | Dyrcona | hence the need for the profile documentation. |
| # | 11:13:05 | atz_ | i actually think some of the linked data stuff out there already will be a better path toward complete functionality, but NCIP *sounds* like something that works |
| # | 11:13:26 | Dyrcona | i'd like to look at ISO1060 and 10161, but have to convince the powers that be that it is worth the $541. |
| # | 11:13:26 | atz_ | like TCPIP or HTTP or something |
| # | 11:14:10 | Dyrcona | i wish it worked like tcp/ip or http. pretty hard to have a standards conforming implementation of those that is incompatible with other implementations. |
| # | 11:14:42 | Dyrcona | in NCIP, its all too easy to conform to the standard and be incompatible with everyone else. |
| # | 11:15:00 | atz_ | yeah, that's why i treat NCIP w/ complete skepticism |
| # | 11:15:16 | Dyrcona | ditto |
| # | 11:16:20 | atz_ | gotta love the ISO and their pay-to-play spec PDFs |
| # | 11:17:48 | Dyrcona | yep. |
| # | 11:19:03 | Dyrcona | our state is looking a vdx-based ILL solution, so i should be able to convince the boss to let me buy a copy of the ISO standards. my understanding is that vdx implements the ISO standards. |
| # | 11:20:49 | atz_ | looks like pennsylvania already has one |
| # | 11:20:50 | atz_ | http://www.accesspa.state.pa.us/ |
| # | 11:21:14 | atz_ | see "VDX Version 3.2.2..." |
| # | 11:21:34 | atz_ | w/ their incredible retro frames-based navigation |
| # | 11:22:35 | atz_ | not to mention the 3D "POWER" logo :) |
| # | 11:23:31 | Dyrcona | heh. |
| # | 11:34:40 | Dyrcona | heh. i apparently got some cream/sugar sauce on my sweat pants and the heat from the notebook caramelized it. |
| # | 11:59:01 | atz_ | pleasant smell, unpleasant image |
| # | 12:04:05 | Dyrcona | it was a topping for french toast. |
| # | 12:05:59 | Dyrcona | home-made whipped cream, basically. |
| # | 12:06:09 | atz_ | nice |
| # | 12:06:10 | afterl has joined #evergreen |
| # | 12:07:49 | Dyrcona | yeah. |
| # | 12:07:59 | Dyrcona | so i've been looking at the SIPServer code. |
| # | 12:08:45 | Dyrcona | is it possible to configure a port say, 6002, to not require a login but to have an institution associated with it? I seem to be missing that. |
| # | 12:09:17 | atz_ | your device still has to send a 9300 request upon connection to the port |
| # | 12:09:28 | Dyrcona | what i'd like to do is configure different raw ports to function as self-checks for different libraries. |
| # | 12:09:44 | Dyrcona | so, it still has to login. |
| # | 12:10:03 | atz_ | it specifies the institution in the 9300. for some kind of pre-logged-in connectivity, you'd need a middleman or expect script |
| # | 12:10:21 | atz_ | (expect scripts are pretty common on SIP machines) |
| # | 12:10:32 | Dyrcona | I see. |
| # | 12:10:51 | atz_ | or you could hack at the SIP backend |
| # | 12:11:05 | atz_ | how are you going to control security though? |
| # | 12:11:06 | Dyrcona | that's what i was thinking of doing, the hacking. |
| # | 12:11:25 | atz_ | it's not really something we'd want exposed for most people |
| # | 12:11:55 | Dyrcona | i could do something like add an institution to the raw port configuration and have it always that institution for that port, right? |
| # | 12:12:09 | Dyrcona | ^always^always use |
| # | 12:12:47 | atz_ | that's still not sufficient for a login... you'd need a user/pass/inst |
| # | 12:13:02 | atz_ | user being a machine account in this case |
| # | 12:13:12 | Dyrcona | ok. |
| # | 12:13:31 | Dyrcona | so i could configure that information for a port and then fake the 9300, etc. |
| # | 12:14:14 | Dyrcona | i haven't looked at what Evergreen does with SIP in much detail, yet. |
| # | 12:14:16 | atz_ | imho, it's not really advisable... SIP doesn't have a lot of security to begin w/, but this would be circumventing the last little piece that it does have |
| # | 12:14:47 | Dyrcona | well, that's pretty much how we do our SIP now. |
| # | 12:14:58 | Dyrcona | it's all port-based with no login. |
| # | 12:15:24 | Dyrcona | we do restrict access to the ports in the firewall by source ip address though, so not just anyone can talk to the server. |
| # | 12:16:24 | afterl has quit IRC |
| # | 12:16:28 | atz_ | yeah, that's what i was asking about. are you sure they aren't sending a 93 message upon connection though? |
| # | 12:16:55 | Dyrcona | i'd have to check the logs and won't have easy access to that machine until tomorrow. |
| # | 12:17:20 | Dyrcona | I do know that the client machines don't have to authenticate with the server. |
| # | 12:17:43 | atz_ | weird |
| # | 12:18:32 | Dyrcona | we configure each listener to have its own port and the equivalent of the aou.shortname for self-checks. |
| # | 12:19:20 | Dyrcona | for simple patron authentication, we have two other ports set up, one requires the patron PIN to authenticate and the other authenticates on barcode alone. these use the aou.shortname for our central office. |
| # | 12:20:52 | atz_ | interesting. EG has too many permissions and inst.-dependent settings internally to perform transactions w/o an associated operator/inst. |
| # | 12:22:55 | Dyrcona | looks like it may be easier just to tell our users that they need to configure a username and passwd on their SIP clients. |
| # | 12:23:22 | Dyrcona | i've already mentioned to several of them that SIP2 will change when we migrate. |
| # | 12:23:25 | atz_ | it's also weird b/c individual SIP transaction requests will include the terminal user/pass and inst. |
| # | 12:23:38 | atz_ | so it's not just the moment of login where it is needed |
| # | 12:24:12 | Dyrcona | yeah. i'll need to look at the logs on our current system, but I think the password field is almost always blank. |
| # | 12:24:31 | Dyrcona | our current ILS does quite a few things very differently from Evergreen. |
| # | 12:24:51 | Dyrcona | though, I think we can configure usernames and passwords. |
| # | 12:25:18 | Dyrcona | i believe our vendor set this up for us the first time and they recommended using different ports with not authentication. |
| # | 12:25:44 | Dyrcona | i've added a few listeners in the meantime. |
| # | 12:27:24 | Dyrcona | one thing i will want to do, is add support for the "fee paid" message. we have at least 1 member who uses that now. |
| # | 12:27:38 | Dyrcona | i'm sure that is harder than it sounds. :) |
| # | 12:28:32 | atz_ | would be cool. would be concerned to make sure implementation was compatible w/ 3M hardware |
| # | 12:29:01 | atz_ | then ppl could start using vending-style cash fee payments |
| # | 12:29:22 | Dyrcona | yes. we have 1 member doing that already with our current ILS. |
| # | 12:29:28 | atz_ | really important to send back proper signal if failed/refused, since that is what spits the money back out! |
| # | 12:29:46 | Dyrcona | there does seem to be some stub functionality for fee payment in SIPServer. |
| # | 12:30:21 | Dyrcona | yeah. hopefully that would be a rare occurrence. |
| # | 12:30:38 | atz_ | yeah, i think the problem will be knowing what the heck the money should be associated with, if anything |
| # | 12:30:58 | atz_ | like a patron might contest one fine and want to pay another |
| # | 12:31:11 | Dyrcona | yeah. |
| # | 12:31:15 | atz_ | i don't think SIP deals w/ that at all. |
| # | 12:31:57 | Dyrcona | our current ILS doesn't necessarily associate a payment with a particular fine or fee, but it reduces the total that the patron owes. |
| # | 12:32:12 | Dyrcona | either that or it picks one at random. |
| # | 12:32:23 | Dyrcona | i'll have to check on that tomorrow. |
| # | 12:33:01 | atz_ | yeah, i think we would want to send a screen message warning. pay oldest fine first is probably the least unpredictable behavior. |
| # | 12:33:23 | Dyrcona | yeah. that sounds good. |
| # | 12:33:50 | Dyrcona | it would only be an issue for us if the patron owes $10.00 or more. that's the point where their circulation is stopped. |
| # | 12:34:29 | Dyrcona | hmm. credits might be an issue. I wonder if the vending machine gives change? |
| # | 12:35:44 | atz_ | good question |
| # | 12:37:06 | Dyrcona | that might depend on the model, too. guess there would need to be a configuration for that as well. |
| # | 12:45:43 | Dyrcona | hmm. doesn't look like SIP2 supports telling the vending machine to give change. |
| # | 12:45:57 | Dyrcona | there's nothing in a 38 response that says the patron overpaid. |
| # | 12:46:31 | Dyrcona | so, if the patron overpays, the Evergreen side of things should store a credit. |
| # | 12:48:01 | atz_ | yeah, i think so. the hardware interface can say "you have X fine(s). how much do you want to pay?" ... "OK, please insert Y" |
| # | 12:48:24 | atz_ | and dispense change for overage, but that is on the hardware mfr. |
| # | 12:48:31 | Dyrcona | i have to admit, that I haven't seen the machine first hand. |
| # | 12:49:31 | Dyrcona | so really all the software on the server side would do is take the 37 message, process it, and send back a 38 to say yes or no it was accepted. |
| # | 12:49:41 | atz_ | right |
| # | 12:49:50 | Dyrcona | it's the process it bit where the magic happens. :) |
| # | 12:51:46 | Dyrcona | well, now I know what I need to look at in SIPServer and the Evergreen SIP.pm modules. |
| # | 13:34:55 | tsbere | I can verify, for the record, that our current SIP doesn't use a login message. My PHP code never sends one. |
| # | 13:46:53 | Dyrcona | tsbere: right now, i think the login message and its absence are secondary to getting the fee paid message handled in Evergreen/SIPServer. |
| # | 13:49:05 | Dyrcona | tsbere: also, none of the blocks loaded in my latest run. a missing checkout date in some old data managed to throw an unhandled exception and stop the whole load, probably the very first record processed. i'm not going to fix that before we load the data for the demo server. |
| # | 13:49:16 | tsbere | ok |
| # | 13:49:41 | Dyrcona | will be too much of a rush to build the clients on Wednesay? |
| # | 13:50:09 | Dyrcona | let's try again.... |
| # | 13:50:44 | Dyrcona | Would it be too much of a rush to build the demo clients on Wednesday, because I don't think I can have Laura test it until Tuesday? |
| # | 13:51:03 | tsbere | I don't think it will be too much of a rush. I can always finish next week, though. |
| # | 13:51:08 | Dyrcona | these are Evergreen clients, for the rest of the channel. |
| # | 13:51:12 | Dyrcona | ok |
| # | 13:51:31 | tsbere | And the client is built. The USB sticks are a different story ;) |
| # | 13:51:51 | Dyrcona | the sticks are what I meant actually. loading the clients on the sticks. |
| # | 13:52:39 | Dyrcona | if anyone is interested, we're distributing Evergreen clients to our member libraries on USB sticks. |
| # | 13:53:12 | Dyrcona | these will have a clickable, ready to run client pre-configured with the server address and a pre-registered workstation. |
| # | 13:53:34 | Dyrcona | there will also be a windows-executable installer if they want to install onto their workstation. |
| # | 13:53:52 | tsbere | That won't be pre-registered, but it will have the server pre-populated |
| # | 13:54:52 | Dyrcona | yep. we're just going to put them in delivery after the US holiday weekend next weekend. |
| # | 13:57:03 | Dyrcona | just so everyone can groan, we call them "pine cones." |
| # | 14:36:09 | phasefx | har |
| # | 16:40:55 | Dyrcona has quit IRC |
| # | 20:45:19 | artunit has quit IRC |
| # | 21:24:50 | artunit has joined #evergreen |
| # | 21:45:59 | leed has quit IRC |
| # | 21:46:03 | leed has joined #evergreen |
| # | 21:48:11 | tildeequals has quit IRC |
| # | 21:48:30 | tildeequals has joined #evergreen |
| # | 22:28:48 | dbs has joined #evergreen |
| # | 22:28:48 | dbs has joined #evergreen |
| # | 22:32:53 | dbs | @later tell phasefx I gave a shot at moving from window.open to xulG.new_tab but it oddly didn't seem to have any effect (still opened in a window instead of a tab) |
| # | 22:32:53 | pinesol` | dbs: The operation succeeded. |
| # | 22:33:42 | dbs | assuming opac.js was the right point to try opening volume_copy_creator in a tab instead of a window |
| # | 22:38:50 | shadowspar has quit IRC |
| # | 22:56:28 | shadowspar has joined #evergreen |
| # | 23:29:28 | gmcharlt | @later tell dbs the construction you're using in line 1492 of Storage/Publisher/action.pm (and friends) breaks hold targeting if the OU settings the code is looking up aren't set for the pickup library; $foo->{value} doesn't work if $foo is undef |
| # | 23:29:28 | pinesol` | gmcharlt: The operation succeeded. |
| # | 23:47:06 | dbs | gmcharlt: thanks for the heads up. should be fixed now. |
April 10-13