| # | Time | Nick | Message |
|---|
| # | 01:13:53 | Callender has quit IRC |
| # | 01:40:40 | Callender has joined #evergreen |
| # | 01:59:58 | Callender has quit IRC |
| # | 02:00:27 | Dmagick_ has quit IRC |
| # | 02:00:33 | phasefx has quit IRC |
| # | 02:00:39 | leed has quit IRC |
| # | 02:01:00 | mtate has quit IRC |
| # | 02:05:46 | youdonotexist has quit IRC |
| # | 03:21:59 | bjwebb has joined #evergreen |
| # | 03:54:12 | phasefx has joined #evergreen |
| # | 04:09:16 | Callender has joined #evergreen |
| # | 07:48:33 | wolf29 has joined #evergreen |
| # | 07:48:47 | wolf29 | Good Morning! |
| # | 07:49:21 | collum has joined #evergreen |
| # | 08:08:32 | Dmagick has joined #evergreen |
| # | 08:08:57 | Dmagick has joined #evergreen |
| # | 08:25:33 | mrpeters-isl | dbs++ thanks for the security patch |
| # | 08:30:01 | mrpeters-isl | one typo though -- should be ./configure --prefix=/openils --sysconfdir=/openils/conf i think not -sysconf/-prefix |
| # | 08:31:25 | wolf29 | Is this the right syntax to change the user on the staff-client? It is not working. perl Open-ILS/src/support-scripts/eg_db_config.pl --admin-user staff --admin-pass ssecret |
| # | 08:34:27 | mrpeters-isl | can i compile oils_auth.so on one system, and distribute to all of my bricks with that one file or do i need to build from the tarball on every server? |
| # | 08:35:03 | adbowling-isl has joined #evergreen |
| # | 08:39:14 | tsbere | mrpeters-isl: If the bricks are all running identical configs you can probably skip a few steps |
| # | 08:40:53 | mrpeters-isl | yeah, they are |
| # | 08:41:06 | mrpeters-isl | so i figured i could just build it once and then distribute it |
| # | 08:49:20 | Dyrcona has joined #evergreen |
| # | 08:56:46 | mrpeters-isl | is there anything visible to the user saying they've been locked out after 10 attempts? |
| # | 08:56:54 | mrpeters-isl | i can still sit here and hammer away and just get a login failed |
| # | 08:56:54 | tsbere | Nope |
| # | 08:57:05 | mrpeters-isl | best way of testing then? |
| # | 08:57:08 | tsbere | Giving an indication would be telling an attacker they hit the limit |
| # | 08:57:14 | mrpeters-isl | yeah, agreed |
| # | 08:57:23 | tsbere | I use srfsh and the login command. |
| # | 08:57:32 | tsbere | First hit I use the correct password to make sure things let people in |
| # | 08:57:41 | tsbere | Then I drop the last letter of the password for 10 attempts |
| # | 08:57:48 | tsbere | Then I go back to the correct password. It should fail me. |
| # | 08:57:56 | tsbere | Then I wait a couple of minutes and try again, it should let me in. |
| # | 08:58:04 | mrpeters-isl | ew yeah i can't get in with a good user...thats not good |
| # | 08:58:59 | wolf29 | tsbere: is the system checking the IP from which the hammerings are coming? |
| # | 08:59:17 | tsbere | wolf29: No. |
| # | 08:59:45 | mrpeters-isl | ah, know what...i bet the server i built this on has a different distro than my production server |
| # | 09:00:03 | wolf29 | tsbere: that would clear issues of a malicious user locking everybody - everywhere out of the system |
| # | 09:00:28 | tsbere | wolf29: But would make a botnet bruteforcing a lot easier. |
| # | 09:01:07 | tsbere | Besides, the auth code doesn't know where the request came from. It could be internal, it could be TPac, it could be the HTTP translator, it could be some other service that happens to talk XMPP to the system, etc. |
| # | 09:02:09 | gmcharlt has joined #evergreen |
| # | 09:04:28 | wolf29 | hmmm if the users logging in were xmpp users, instead of entirely internal-to-eg users, wouldn't the botnet angle just be cut out? I am looking into XMPP (just for fun) This might just be a solution looking for a problem |
| # | 09:05:03 | tsbere | That would be a horror show due to how the system uses XMPP |
| # | 09:05:13 | tsbere | Also, I don't want to open XMPP auth up to the outside. |
| # | 09:05:42 | wolf29 | Yeah. That could be a mess |
| # | 09:06:37 | mrpeters-isl | yeah, i can't get this working :( |
| # | 09:06:48 | eeevil | in the very early days, there was app-to-app auth/authz ... no EG-level users, but a layer between xmpp and EG |
| # | 09:06:56 | mrpeters-isl | possible memcache has to be restarted too? |
| # | 09:07:23 | tsbere | memcache shouldn't be an issue |
| # | 09:07:48 | mrpeters-isl | hmm...i just get LOGIN_FAILED "stacktrace":"oils_auth.c:714" |
| # | 09:08:01 | mrpeters-isl | with the old oils_auth.so it's success |
| # | 09:08:51 | eeevil | but the cost was too high, so we killed that in preference to telling the router about client domains and restricting app registration |
| # | 09:14:37 | tsbere has figured out how to make recall holds automatically drop into cataloging status :D |
| # | 09:26:36 | Dyrcona grumbles something about meetings. |
| # | 09:28:53 | mtate has joined #evergreen |
| # | 09:28:54 | sal_ has joined #evergreen |
| # | 09:30:49 | leed has joined #evergreen |
| # | 09:44:00 | dbs has joined #evergreen |
| # | 09:44:00 | dbs has joined #evergreen |
| # | 09:49:44 | yboston has joined #evergreen |
| # | 09:53:46 | mrpeters-isl | anyone ever tinkered with turning off the "did you mean?" suggestions in the OPAC? |
| # | 09:53:59 | mrpeters-isl | err..."maybe you meant" |
| # | 09:54:59 | tsbere | I haven't. You feel there is a need? |
| # | 09:55:18 | mrpeters-isl | apparently...i've been asked to turn it off for some strange reason |
| # | 09:55:37 | mrpeters-isl | i guess i could just hide the <span>&result.lowhits.did.you.mean; </span> |
| # | 09:55:45 | tsbere | Tell them you need to update to do so ;) |
| # | 09:56:00 | mrpeters-isl | haha finally making progress on that front :) |
| # | 10:08:04 | dbs | mrpeters-isl: we've added things to that section of the JSPAC; easy enough to turn it off too |
| # | 10:20:40 | dbs | tsbere++ # awesome staff client documentation |
| # | 10:21:43 | tsbere | In rigging up force and recall holds to be something other than aliases for "Regular Copy Hold" I am adding two new permissions. Anyone have objections to those permissions being checked based on the copy circ library instead of the pickup library? |
| # | 10:33:25 | jenny1 has joined #evergreen |
| # | 10:38:28 | AaronZ-PLS | Thinking about automatic updates in 2.1... How does that work in Windows 7 which has a phobia about letting people change files in %PROGRAMFILES% without administrative priviliges (ie: run as administrator)? |
| # | 10:39:24 | tsbere | AaronZ-PLS: The installer changes the permissions of the install dir when installing automatic updating. |
| # | 10:40:07 | dbs ran into a "locked down" XP workstation that tried to prevent him from installing the 2.0 client in %PROGRAMFILES%, so he just installed into My Documents instead |
| # | 10:41:36 | AaronZ-PLS | tsbere:Intresting. I have been using a batch file and wget for our libraries (hackish, but it mostly works) and even whe I change the permissions, Windows 7 will not allow a non-administrative user to update the files in %PROGRAMFILES%\Evergreen Staff Client |
| # | 10:42:10 | tsbere hasn't had anyone report issues |
| # | 10:42:49 | tsbere | Of course, the only win7 users I know that do regular updates ARE administrators, and the updater is supposed to ask for elevation when needed. |
| # | 10:43:12 | AaronZ-PLS | me: Adds auto updates on Win 7 to the list of things to check after we install a 2.1 test VM |
| # | 10:43:41 | tsbere | AaronZ-PLS: The permissions granted are "Everyone -> FullAccess", just so you know. |
| # | 10:44:07 | enhancin has joined #evergreen |
| # | 10:44:07 | dbs | Heh, talk about yer security vulnerabilities :) |
| # | 10:44:59 | tsbere has less concern there as he isn't having the client elevate itself under normal circumstances, and in fact at that point the updater doesn't need to elevate itself to run |
| # | 10:44:59 | enhancin | Has anyone else had issues with the Evergreen Client working correctly on Windows XP? |
| # | 10:45:17 | AaronZ-PLS | tsbere:I will have to play with that. Currently, you must right click on Evergreen and click on "Run as Administrator" or wget doesnt actually update anything. It just gets permission denied messages |
| # | 10:45:31 | enhancin | My boss can't get it to work correctly on XP, we couldn't figure it out forever until she installed it on win7 and it worked (I'm across the country on win7) |
| # | 10:45:45 | AaronZ-PLS | enhancin: What version? |
| # | 10:45:49 | enhancin | 2.0.9 |
| # | 10:46:01 | enhancin | I can upgrade to 2.0.10 but it just came out |
| # | 10:46:04 | dbs | enhancin: define "work correctly". Would it install? |
| # | 10:46:08 | tsbere | We have no problems with the 2.1/2.2ish client on XP. If we DID have issues, whoo boy, would I be dealing with fallout right now. |
| # | 10:46:11 | enhancin | Yeah it installs, I mean. Okay |
| # | 10:46:21 | enhancin | So we go into the cataloging, import a record, and then try to add the barcode to it and change it's 'location' |
| # | 10:46:39 | dbs | 2.0.x staff cients are working fine for us on XP |
| # | 10:47:51 | enhancin | she gets an error that says fancy_prompt.xul and TypeError: data.modal_xulG_stack[key] is undefined. I don't get this error here and then she gets a blank error message |
| # | 10:48:01 | enhancin | that's weird, I've had her reinstall it a couple of times |
| # | 10:48:20 | phasefx | modal_xulG_stack-- |
| # | 10:48:37 | tsbere | phasefx: Not sure I agree with that. |
| # | 10:48:41 | tsbere | xulG-- |
| # | 10:48:42 | tsbere | In general |
| # | 10:48:43 | tsbere | :P |
| # | 10:48:47 | phasefx | haha |
| # | 10:49:16 | phasefx | if remote xul would work in the long term, we could generate some with TT :) |
| # | 10:49:17 | enhancin | could it by chance be other software on her system out of date |
| # | 10:49:40 | enhancin | does evergreen use anything else to do it's internet things? |
| # | 10:49:53 | tsbere | phasefx: There are ways to make it work. I would have made them work, but I can't get later versions of xulrunner to *start*, let alone load the client code. :( |
| # | 10:52:49 | phasefx | enhancin: there's an error that the fancy prompt error is sadly obscuring |
| # | 10:53:33 | phasefx | enhancin: if you could run the staff client with the -console (tacked onto the end of the target in the shortcut), we might be able to see more of what's happening |
| # | 10:53:43 | dbs | well - it will be interesting to see where wolf29 goes with the Drupal front end thing |
| # | 10:57:16 | wolf29 | dbs: it should keep me out of trouble for a while |
| # | 10:57:32 | tsbere | I predict "nowhere near far enough to not need a staff client" due to printing issues alone. |
| # | 10:58:10 | dbs | wolf29: once you get to the point of sketching out a plan, that would be good to share |
| # | 10:58:35 | enhancin | phasefx: I found a bug online about it and it had me raise max_requests and max_children so we're testing it |
| # | 11:04:49 | phasefx | tsbere: even if you hack support for remote xul back into later xulrunners, it's still not going to be very well supported, and will be less of a citizen than it is now. Parts of remote xul are broken even in supported versions |
| # | 11:05:30 | phasefx thinks we need to pull the plug, but.. lots of work however we do it |
| # | 11:05:32 | dbs | as tsbere suggests, supporting the full range of printing options that the staff client currently supports will be... challenging. But there are a number of workflows that don't require printing capabilities, or that might be able to live with standard browser-based printing (hold / transit slips I guess) |
| # | 11:05:50 | tsbere | phasefx: I have two possible fixes. Both may even fix some of the issues we see already with remote xul. One by making remote xul no longer look to be remote at all. |
| # | 11:05:56 | dbs | for sure. Maybe agreement that we don't create any more XUL interfaces to start with? |
| # | 11:06:35 | phasefx | you have my vote, and I think ESI has already said as much internally |
| # | 11:07:15 | enhancin | so that bug no worky. Let me get a pastebin full of the errors she's getting...one se |
| # | 11:07:43 | phasefx | tsbere: I think that could buy us time (or we could stick with a pinned version of xulrunner) |
| # | 11:14:46 | enhancin | nevermind, got it. I told her to reinstall evergreen last night but she did it just barely and now it works |
| # | 11:14:54 | enhancin | i love how people listen to the admin... |
| # | 11:25:51 | enhancin has quit IRC |
| # | 11:26:59 | kmlussier has joined #evergreen |
| # | 11:27:17 | jenny1 has left #evergreen |
| # | 11:40:16 | tsbere | So, I finally figured out why some hold types succeed when they should fail. <_< |
| # | 11:46:18 | dbs guesses javascript type coercion |
| # | 11:48:42 | tsbere | indb hold permit doesn't check the item, status, or location holdable flags. |
| # | 11:51:46 | tsbere | Well, ok, that appears to be *one* issue. With catalog-originating hold attempts. |
| # | 11:52:23 | mrpeters-isl | looks like the 2.1 README may be missing the make -f Open-ILS/src/extras/Makefile.install install_pgsql_server_debs_90 step |
| # | 11:52:24 | dbs | script-based circulation FOREVAH |
| # | 11:52:48 | dbs | mrpeters-isl: "Creating the Evergreen database:" ? |
| # | 11:53:13 | mrpeters-isl | oh i see, it' been moved |
| # | 11:53:29 | mrpeters-isl | used to be up towards the beginning |
| # | 11:53:47 | dbs | yep. change happens. |
| # | 11:55:24 | dbs | made more sense to me to keep all of the database-related steps together |
| # | 11:59:18 | matt_carlson has joined #evergreen |
| # | 12:01:09 | kmlussier has quit IRC |
| # | 12:01:23 | mrpeters-isl | fair enough |
| # | 12:01:53 | mrpeters-isl | i had just gotten alarmed because i thought maybe they'd been moved into the earlier dependency install |
| # | 12:08:32 | tsbere | Oh, goody, the other interface I thought wasn't doing things right is just broken due to another bug I fixed not being committed yet. It does do things correctly now. :D |
| # | 12:14:44 | dbs | tsbere: pointers to said bug? |
| # | 12:16:00 | tsbere | dbs: https://bugs.launchpad.net/evergreen/+bug/863657 |
| # | 12:16:43 | dbs will get back to a clean master dev env and try to reproduce |
| # | 12:16:59 | dbs | (the bug, that is; I already have two kids, that's plenty) |
| # | 12:17:12 | tsbere | dbs++ |
| # | 12:17:30 | Dyrcona | reminds me of xkcd.... |
| # | 12:19:23 | Dyrcona | Are there any plans to add the "Add MFHD Record" link in the tpac record page as exists in rdetail.xml when used via the staff client? |
| # | 12:19:31 | Dyrcona tortures his native language. |
| # | 12:20:19 | Dyrcona | If not, please do NOT consider this a request to have it added. I want to know because of my branch where I'm add the can_have_copies field to bib sources. |
| # | 12:22:30 | sal_ has quit IRC |
| # | 12:23:11 | dbs | Dyrcona: no, I think we're planning on just keeping the "Add MFHD Record" to the staff client menu in TPAC |
| # | 12:23:34 | dbs | having the button inline in the page itself was just an artifact of my very hastily/clumsily implemented hack |
| # | 12:38:24 | dbs | so tsbere: to reproduce the bug, I should place just one hold for a patron in the staff client? |
| # | 12:38:42 | tsbere | dbs: Via the item status's "request item" menu, not the opac menus |
| # | 12:38:50 | Dyrcona | dbs: thanks. that means my branch is done. :) |
| # | 12:39:16 | dbs | tsbere: okay - will do. I tried the "Place Hold" button under the Patron's "Holds" tab |
| # | 12:39:40 | tsbere | Yea, that one works. For certain definitions of "works" when using indb, anyway. |
| # | 12:40:33 | dbs amused by cancelling the hold, and clicking "Refresh" but not being able to get the cancelled hold to disappear from the screen without cache clear / reload patron |
| # | 12:42:29 | dbs | yay! 0 holds created! |
| # | 12:42:35 | dbs | now to apply tsbere's bug fix |
| # | 12:42:47 | tsbere | dbs: Take note, it likely created 1 hold |
| # | 12:42:54 | tsbere | Even though it said 0 |
| # | 12:44:48 | dbs wouldn't know how to check, as "Holds / transits" only shows items captured for a hold |
| # | 12:45:09 | dbs hates holds |
| # | 12:45:44 | tsbere | dbs: View In catalog -> View Holds or load the patron you are logged in as/placed the hold for and view holds? |
| # | 12:46:55 | dbs | yup, view in catalog does the trick. so item status doesn't show us anything about targeted holds, we need to go back up to bib level and view from there. got it |
| # | 12:51:33 | tsbere | dbs: Note that the more I fight with them, the less I like holds myself. |
| # | 12:52:04 | tsbere doesn't think he started off with a positive view of them either |
| # | 12:52:26 | tsbere | But I have to live with a lot more holds stuff going on then you do, I guess. |
| # | 12:52:27 | dbs | yay. it works |
| # | 12:52:50 | dbs | yes. holds are fuzzy and we can mostly live with them that way |
| # | 12:54:29 | mrpeters-isl | is there anything sweeter in life than a git-cherry-pick that resolves with no conflicts? :) |
| # | 12:54:49 | dbs | tsbere: pushed to master |
| # | 12:55:10 | tsbere | mrpeters-isl: I say ^^ ;) |
| # | 12:55:15 | tsbere | dbs++ |
| # | 13:01:56 | tlilleberg has joined #evergreen |
| # | 13:04:09 | collsk12 has joined #evergreen |
| # | 13:06:15 | collsk12 | Can anyone help me figure out why every time I edit the rdetail page to add queries for other tags, it completely breaks the book cover images? On every page? |
| # | 13:06:58 | collsk12 | And even after reverting to a backup file? |
| # | 13:08:39 | jenny2 has joined #evergreen |
| # | 13:09:16 | mrpeters-isl | cache? |
| # | 13:09:18 | phasefx | collsk12: won't help now, but when you test out skin changes, a useful thing to do is work with a test skin. cp -R default test |
| # | 13:09:59 | phasefx | one gotcha with non-default skins is that they often have 'default' hard-coded in places, like for pulling in javascript files |
| # | 13:10:01 | dbs | phasefx: followed up by deep sed magic to change all of the links to /default/js/blah to /newskin/js/blah |
| # | 13:10:06 | dbs | jinx |
| # | 13:10:06 | phasefx | dbs: exactly |
| # | 13:10:22 | dbs loves tpac |
| # | 13:10:56 | phasefx | different world |
| # | 13:11:03 | berick | @love tpac |
| # | 13:11:03 | pinesol_green | berick: Error: "love" is not a valid command. |
| # | 13:11:12 | collsk12 | Anyway to revert the entire folder? I don't have any other modifications. |
| # | 13:11:20 | tsbere | So, should I call "force and recall holds don't do anything" a bug alongside the "you can place holds when using indb that shouldn't be allowed" or should I split those two into different branches? |
| # | 13:11:46 | jamesrf | can anyone tell me if a < 2.0.10 client will work ok on a 2.0.10 server? |
| # | 13:12:10 | tsbere | For the most part I think one will. But I am not positive. |
| # | 13:12:15 | phasefx | jamesrf: if it's 2.0.x, it should |
| # | 13:12:15 | tsbere | Just don't delete workstations from the DB ;) |
| # | 13:12:29 | jamesrf | yeah i only imagine problems with registering workstations |
| # | 13:12:32 | dbs | jamesrf: works for me |
| # | 13:12:42 | jamesrf | but presumably they would download a fresh staff client most of the time they do that |
| # | 13:12:54 | jamesrf | dbs: thanks |
| # | 13:14:09 | agJohn has quit IRC |
| # | 13:17:21 | matt_carlson has quit IRC |
| # | 13:18:13 | matt_carlson has joined #evergreen |
| # | 13:20:27 | sal_ has joined #evergreen |
| # | 13:20:37 | collsk12 | So is there a fix for my situation? |
| # | 13:22:07 | phasefx | collsk12: I'd move mv default default.orig and copy the whole default/ folder from the install directory |
| # | 13:26:22 | collsk12 | And if that doesn't work? |
| # | 13:26:40 | matt_carlson has quit IRC |
| # | 13:28:09 | phasefx | collsk12: more targeted debugging |
| # | 13:28:49 | dbs | it's always possible that there was a purely coincidental series of added content timeouts that disabled added content for a period of time |
| # | 13:28:53 | collsk12 | aka - Beat self in head with keyboard? |
| # | 13:29:42 | phasefx | collsk12: given what dbs said, you could use memdump/memcdump to check for the ac. key that disables added content. I forget what it's called exactly |
| # | 13:30:19 | phasefx | how far back does A/T go for hold ready for pickup notifications? |
| # | 13:30:26 | phasefx | 2.0? 1.6? |
| # | 13:30:38 | dbs | ac.no_lookup |
| # | 13:30:42 | phasefx | dbs++ |
| # | 13:31:30 | phasefx | collsk12: memcat --servers 127.0.0.1 ac.no_lookup |
| # | 13:32:06 | phasefx | or just do memrm --servers 127.0.0.1 ac.no_lookup |
| # | 13:32:15 | phasefx | it'll tell you whether it existed or not |
| # | 13:33:54 | bshum | phasefx: I've been trying to follow changes in the staff client and at least up through 2.0.6 (the version we gave to our libs) the only major things to change was the addition of those security changes and some serials stuff. Since we're not using Serials yet, we haven't forced anybody to upgrade to the latest staff clients (or built one ourselves) |
| # | 13:34:25 | phasefx | bshum: <nods> |
| # | 13:35:06 | dbs | phasefx: 2.0 for sure |
| # | 13:35:19 | bshum | We used it in 1.6 too. |
| # | 13:35:39 | bshum | Well... 1.6.0.2 I think. |
| # | 13:35:41 | bshum | :) |
| # | 13:35:46 | phasefx | noticed that email notifications for holds are going out despite .email_notify = 'f' |
| # | 13:36:12 | phasefx | or at least, templates are generated for such. I don't actually have outgoing email configured on my system |
| # | 13:36:14 | dbs | hah |
| # | 13:36:27 | bshum | phasefx: That's interesting... cause that would explain an odd issue that was reported to us last week. |
| # | 13:36:44 | bshum | Someone showed us a list of holds where email notify was false and yet all the patrons in the book club reported receiving hold notifications. |
| # | 13:36:57 | bshum | We hadn't investigated that deep yet though. |
| # | 13:38:46 | dbs sent an email to bjwebb last night asking what we can do to integrate his work on automatic livecd / vm builds into the core of the project |
| # | 13:39:06 | dbs | seems a shame to have a bunch of releases and to have to go back to manually building vms and such |
| # | 13:39:54 | collsk12 | Now I'm in deep! How do I fix the symlink stuff on these xmls? |
| # | 13:39:55 | dbs | the livecd / vm builds rely on packages generated by openSUSE's build service, which are controlled by bjwebb and haven't been refreshed since August 20th |
| # | 13:40:49 | dbs is hoping that the reins (and know-how!) can be shared, and that some of the nice enhancements tsbere has contributed like --create-database will help simplify things |
| # | 13:42:00 | Dyrcona | new Milestones: 2.0.11, 2.1.1 ? |
| # | 13:42:14 | dbs | collsk12: something like: "for i in 'advanced.xml authbrowse.xml cnbrowse.xml mresult.xml myopac.xml rdetail.xml rresult.xml' do; ln -sf index.xml $i; done" ? |
| # | 13:42:33 | dbs | Dyrcona: sounds good |
| # | 13:45:09 | tsbere | phasefx / bshum : Looks like a/t will send out an email notice so long as the patron has an email address. Period. I can't find any indication of it checking the email notify field. :( |
| # | 13:45:50 | berick | A/T supports opt-in user preferences |
| # | 13:45:53 | phasefx | tsbere: I think the patron may be able to opt out entirely of the A/T |
| # | 13:46:00 | Dyrcona | I will flag 2.0.10, 1.6.1.9 and 2.1.0 as released in Launchpad? |
| # | 13:46:05 | berick | 1.6 may not have them, though.. |
| # | 13:46:29 | tsbere | phasefx: That doesn't help specific holds with the setting disabled, right? |
| # | 13:46:40 | phasefx | tsbere: right |
| # | 13:46:56 | berick | ... and only tpac actually allows users to edit their A/T opt-in prefs ATM |
| # | 13:49:39 | yboston | hello everyone, quick question about running authority_control_fields.pl |
| # | 13:49:47 | yboston | should this script be run as opensrf or is root OK? do I have to run it from a specific location (the $boostrap path is already set)? Thanks in advance. |
| # | 13:53:18 | dbs | yboston: running it as opensrf will ensure that your environment is set appropriately |
| # | 13:53:34 | yboston | dbs: thanks |
| # | 13:59:40 | collsk12 has quit IRC |
| # | 14:04:41 | collsk12 has joined #evergreen |
| # | 14:05:00 | jenny2 has quit IRC |
| # | 14:05:14 | collsk12 | Just an update: I'm still broken and I think I quit. |
| # | 14:06:09 | jenny1 has joined #evergreen |
| # | 14:10:20 | jenny1 has left #evergreen |
| # | 14:11:51 | phasefx | collsk12: you can grab the URL for a jacket image and test it. That should work or not work independently of any OPAC skin changes you did |
| # | 14:29:08 | collsk12 | phasefx: It doesn't look like the covers are being cached by the server, even though I can reach the covers through my network. What do you think? |
| # | 14:30:09 | phasefx | collsk12: what version of EG are you using, and are you trying to mix added content with local content (say with /openils/var/web/opac/extras/ac) |
| # | 14:30:16 | bshum | senator++ #acq miracle worker |
| # | 14:34:56 | collsk12 | I'm using 2.1 and I don't think I'm doing anything fancy like that. I also noticed that I don't have an "ac" folder. |
| # | 14:35:06 | senator | bshum++ # feedback means better bugfixes |
| # | 14:38:24 | kmlussier has joined #evergreen |
| # | 14:42:11 | phasefx | collsk12: that's good (not having that folder) |
| # | 14:42:56 | phasefx | collsk12: using OpenLibrary for added content? |
| # | 14:43:21 | collsk12 | I was...when it was working. |
| # | 14:52:53 | Callender has quit IRC |
| # | 14:53:30 | Callender has joined #evergreen |
| # | 14:57:31 | tsbere is considering opening a new bug or two on launchpad, but doesn't want them lost in the current flood |
| # | 14:58:12 | dbs | collsk12: are you sure that openlibrary itself is still working? they've been known to go down :) |
| # | 14:58:44 | collsk12 | dbs: lol...I checked. I know how that can happen. But thanks for the suggestion. |
| # | 14:59:02 | dbs | http://images.concat.ca/opac/extras/ac/jacket/large/0309052823 works for me - adjust your hostname accordingly? |
| # | 14:59:26 | adbowling-isl has quit IRC |
| # | 15:00:43 | lisah_ has joined #evergreen |
| # | 15:06:07 | lisah_ has quit IRC |
| # | 15:25:50 | sal_ has quit IRC |
| # | 15:29:08 | dbs has quit IRC |
| # | 15:39:10 | dbs has joined #evergreen |
| # | 15:39:58 | dbs | sorry folks, our campus connection to the outside world died. back thanks to the miracle of tethering |
| # | 15:40:08 | dbs | (I know, y'all missed me terribly) |
| # | 15:40:16 | collsk12 | Thank you room for the help today. I have to run. Hopefully I can figure this thing out and update you on what I get done. Thanks again!! |
| # | 15:40:19 | collsk12 has quit IRC |
| # | 15:51:11 | wolf29 | I am a quarter done counting up individual screens on the staff_client for the possible Drupal-based web-client. Going home to Hope Springs. |
| # | 15:51:41 | wolf29 has left #evergreen |
| # | 15:52:28 | tsbere suspects wolf29 won't ever finish |
| # | 16:22:54 | Dyrcona thinks it must be some kind of abuse of git to create a branch to track a change to 1 character in 1 file, but it works far better than remembering to edit the file every time before one builds. |
| # | 16:27:49 | wlayton__ has joined #evergreen |
| # | 16:31:56 | moodaepo wonders why one has to count individual screens for a drupal based client |
| # | 16:32:31 | dbwells | tsbere: sorry for the delay in testing the grace_period extension branch. I finally got a chance to spend a few hours putting it through its paces, and have posted a potential fix here: https://bugs.launchpad.net/evergreen/+bug/787542 Please take a look whenever you get a chance, no hurry. |
| # | 16:33:45 | moodaepo was at the Nobel conference the last two days and missed all the hullabaloo! |
| # | 16:34:07 | tsbere | dbwells: My interpretation of things was "if your grace period runs out just before a closed date, well, you should have gotten your materials back sooner" |
| # | 16:34:23 | tsbere | Because the end of your grace period was eaten up by an open date |
| # | 16:36:24 | dbs | moodaepo: did you win? |
| # | 16:37:17 | moodaepo | dbs++ #funny man. Was attending this > http://gustavus.edu/events/nobelconference/2011/ |
| # | 16:39:09 | tsbere | dbwells: Note that fines aren't charged on closed dates, so backdating to the previous day when dealing with bookdrops will take care of the last fine at that point. |
| # | 16:40:46 | kmlussier has quit IRC |
| # | 16:52:09 | collum has quit IRC |
| # | 16:55:09 | moodaepo | In the library settings editor I'm trying to check that the patron barcode starts with a "2" and it just doesn't seem to work. I am trying a basic regex ^2\d[0-9] |
| # | 16:56:39 | dbs | 2, followed by a digit, followed by any char in the 0-9 range |
| # | 16:56:56 | dbs | ^2\d{0-9} ? |
| # | 16:57:32 | dbs | ^2\d{0,9} # (thinking vim syntax) |
| # | 16:59:13 | moodaepo | No go with ^2\d{0-9} |
| # | 16:59:19 | tsbere | ^2[0-9].* |
| # | 16:59:38 | tsbere | or ^2[0-9]{2}.* |
| # | 16:59:50 | tsbere | For "needs to have 3 digits at the start, the first being a 2" |
| # | 16:59:53 | tsbere | I think |
| # | 17:01:03 | tsbere | moodaepo: Also, that barcode regex thing? Until master it only applies to the *opac* |
| # | 17:01:42 | moodaepo | tsbere++ #I've been testing in the client |
| # | 17:02:09 | tsbere | actually. I don't recall if I made it apply to the client at all, even in master. |
| # | 17:02:11 | tsbere goes to check |
| # | 17:03:25 | tsbere | Looks like I did not make it apply anywhere you enter a barcode. |
| # | 17:03:50 | dbwells | tsbere: I suppose I can see it both ways, but from my perspective, grace periods cover fine periods, so since closed days are not fine periods, they should be considered part of the grace whether they fall before, during, or after. It avoids needless fine generation and subsequent voiding, and is less prone to user error, since you only need to backdate into the closed date, not worrying about when the closed period actually began. Does that |
| # | 17:03:50 | dbwells | make sense? |
| # | 17:03:54 | tsbere | Just for "usernames can look like barcodes or usernames, if you have a regex for both" |
| # | 17:04:08 | tlilleberg has quit IRC |
| # | 17:05:39 | AaronZ-PLS has quit IRC |
| # | 17:05:43 | tsbere | dbwells: I think your proposed fix will make the day after the closed period an extra grace day, though. |
| # | 17:05:55 | tsbere | maybe |
| # | 17:05:57 | tsbere hasn't tested |
| # | 17:06:00 | matt_carlson has joined #evergreen |
| # | 17:07:20 | dbs | moodaepo / bshum: I've updated downloads.php in place, not in git, to point to 2.1.0a / 2.0.10a / 1.6.1.9a versions of the tarballs due to a bug we found |
| # | 17:07:30 | dbs | and updated http://evergreen-ils.org/blog/?p=687 |
| # | 17:07:37 | bshum | dbs: Alright. |
| # | 17:07:41 | moodaepo | dbs++ |
| # | 17:07:48 | tsbere | dbwells: My view is "if you didn't get the item back by the end of the last grace day, even if the day after is a closed date, you are now liable for *all fines up until then*" either way. It was due thursday, had a single day of grace. Friday and saturday the library is closed. You return the item monday, your grace period was *over* friday. |
| # | 17:07:55 | dbs | just wanted to give you a heads-up that I was bad and didn't get it into git :( |
| # | 17:08:02 | bshum | Heh |
| # | 17:08:36 | dbs | if anyone has the chance to copy/paste the update from the blog post into a response to my security release mailing list posts to -general and -dev, that would be appreciated |
| # | 17:08:42 | dbs | I have to hightail it out of here :( |
| # | 17:09:18 | dbs | (or if you come up with something more eloquent than what I wrote, have at it! too rushed to be eloquent) |
| # | 17:09:20 | tsbere | dbwell: er, in the above, saturday and sunday were closed. Bah. |
| # | 17:09:45 | dbwells | tsbere: right, if you return it on Monday, you are charged for Friday and Monday. The code still should do that. However, if you backdate into Sat or Sun, you should have no fines, right? |
| # | 17:10:07 | _bott_ has quit IRC |
| # | 17:10:38 | _bott_ has joined #evergreen |
| # | 17:10:41 | bshum | moodaepo: I can add dbs' change to the git repo |
| # | 17:11:05 | bshum | Least... I think I can. |
| # | 17:11:43 | moodaepo | bshum: Sure go for it..just scp the file into your local repo and push into git |
| # | 17:12:01 | bshum | Freaking vim |
| # | 17:12:29 | moodaepo | I can copy/paste the blog update and send out an update to the list |
| # | 17:12:33 | moodaepo | *lists |
| # | 17:13:03 | bshum | Alright. |
| # | 17:13:50 | gmcharlt | dbs++ |
| # | 17:15:40 | dbs has quit IRC |
| # | 17:21:49 | dbwells | tsbere: I think my biggest concern here aside from loose backdating errors is that fine generator will dutifully generate a fine on Saturday (for Friday), and even if it is eventually voided by a proper backdate, this is bound to cause some consternation for certain patrons, particularly if the library is closed for some time and these imaginary fines pile up. |
| # | 17:25:40 | tsbere | dbwells: The current way the system works the fine(s) for the grace period will be generated the day after the grace period ends, whether the library is open or closed that day. But no fines are generated *for* a day the library is closed. So due thursday, grace period friday, backdated checkin in to sunday on monday would charge the patron for friday only. |
| # | 17:28:53 | dbwells | tsbere: If a library is closed on Sat and Sun, backdating to Fri, Sat, or Sun should be identical as far as fines are concerned, shouldn't it? |
| # | 17:29:40 | tsbere | dbwells: IMO, no. |
| # | 17:29:52 | Dyrcona has quit IRC |
| # | 17:30:04 | tsbere | the library was open friday. You didn't return it Friday. Thus ended your grace period. |
| # | 17:31:18 | dbwells | Backdating general assumes the best, i.e. that I returned it on Friday after the library closed. |
| # | 17:31:34 | tsbere | Then backdate to friday, not sat or sun ;) |
| # | 17:32:15 | tsbere hits the road |
| # | 17:33:03 | dbwells | I think I will take this discussion to the list, as more opinions are needed. Thank you, tsbere |
| # | 17:44:08 | moodaepo | @later tell dbs IMO in the future it might be better to just re-release the versions especially with such a short update period, maybe I'm just being picky about having "a" versions and thinking alpha : ) |
| # | 17:44:08 | pinesol_green | moodaepo: The operation succeeded. |
| # | 17:47:42 | gmcharlt | moodaepo: that can invite confusion |
| # | 17:48:02 | gmcharlt | of the form, "will the real Evergreen-ILS-2.0.10.tar.gz please stand up" |
| # | 17:48:22 | rangi | could do the -1 like debian and ubuntu |
| # | 17:48:27 | rangi | instead of the a ? |
| # | 17:48:48 | bshum | Back to four point releases? Oh boy... |
| # | 17:48:56 | rangi | not a point |
| # | 17:49:05 | bshum | Oh dash |
| # | 17:49:06 | moodaepo | gmcharlt: True but I think we've actually re-released versions before..within minutes/hours though. |
| # | 17:49:11 | bshum | Silly tired eyes :( |
| # | 17:49:14 | rangi | :) |
| # | 17:49:23 | rangi sows more confusion |
| # | 17:49:35 | bshum | moodaepo: 2.1.0 was re-tarred at least once the night before "release" |
| # | 17:49:38 | moodaepo | I'd +1 -1 |
| # | 17:50:03 | gmcharlt | moodaepo: a day != minutes, particularly in the case of a set of security releases that are meant to be installed ASAP |
| # | 17:51:17 | gmcharlt | at least for 2.1+, building releases is much closer to being fully automated thanks to some work by tsbere |
| # | 18:09:58 | matt_carlson has quit IRC |
| # | 18:13:16 | yboston has quit IRC |
| # | 18:55:46 | AaronZ-PLS has joined #evergreen |
| # | 18:57:39 | AaronZ-PLS has quit IRC |
| # | 19:52:44 | Callender has quit IRC |
| # | 20:10:45 | Callender has joined #evergreen |
| # | 20:40:29 | mrpeters-isl_ has joined #evergreen |
| # | 20:41:09 | mrpeters-isl_ | brute force patch question -- wouldnt a multi brick enviornment actually allow up to 10 attempts, per brick? |
| # | 20:41:50 | mrpeters-isl_ | because the lockout would only occur on a brick by brick basis? |
| # | 20:42:22 | tsbere | @later tell dbwells I force-pushed a compromise option for grace period extension there. Left a note on the launchpad bug about it. |
| # | 20:42:22 | pinesol_green | tsbere: The operation succeeded. |
| # | 20:42:58 | tsbere | mrpeters-isl_: The lockout count is stored in memcache. Unless you are running a memcache server for each brick they will share the info. |
| # | 20:43:24 | mrpeters-isl_ | aha...it doesn't seem to last long then |
| # | 20:43:41 | tsbere | Default of 90 seconds of no attempts before the count resets |
| # | 20:43:55 | tsbere | You can, of course, change that. |
| # | 20:43:58 | mrpeters-isl_ | ok, that's just about the timeframe it took me to switch bricks |
| # | 20:44:06 | mrpeters-isl_ | no no, all good...just wanted to clarify |
| # | 20:44:19 | mrpeters-isl_ | gmcharlt:++ for the update for multi-bricks |
| # | 21:14:06 | mrpeters-isl_ has quit IRC |
| # | 21:20:41 | atz_ has joined #evergreen |
| # | 21:24:27 | atz has quit IRC |
| # | 21:26:03 | Callender has quit IRC |
| # | 21:40:43 | Callender has joined #evergreen |
| # | 22:34:53 | Callender has quit IRC |
| # | 22:55:48 | Callender has joined #evergreen |
| # | 23:25:03 | Callender has quit IRC |
| # | 23:33:32 | youdonotexist has joined #evergreen |
| # | 23:40:53 | Callender has joined #evergreen |
| # | 23:43:34 | edoceo has quit IRC |
| # | 23:45:28 | Callender has quit IRC |
April 10-13