| # | Time | Nick | Message |
|---|
| # | 00:18:08 | luisb has joined #evergreen |
| # | 00:30:32 | luisb has quit IRC |
| # | 00:41:45 | luisb has joined #evergreen |
| # | 00:49:57 | luisb has quit IRC |
| # | 00:54:50 | luisb has joined #evergreen |
| # | 00:59:07 | luisb has quit IRC |
| # | 01:56:59 | elene has joined #evergreen |
| # | 02:28:29 | youdonotexist has quit IRC |
| # | 03:58:59 | elene has quit IRC |
| # | 03:59:08 | elene has joined #evergreen |
| # | 04:01:31 | elene_ has joined #evergreen |
| # | 04:03:55 | elene has quit IRC |
| # | 04:03:55 | elene_ is now known as elene |
| # | 04:41:39 | elene has quit IRC |
| # | 05:18:19 | elene has joined #evergreen |
| # | 07:28:32 | kivilahtio | Any documentation enywhere about the credit card payment module? |
| # | 07:29:05 | kivilahtio | We would like to extend the vendor list with some Finnish ePayment vendors |
| # | 07:48:28 | tsbere | kivilahtio: At a minimum I think you need to add a function for each vendor to Open-ILS/src/perlmods/lib/OpenILS/Application/Circ/CreditCard.pm and add the proper set of settings to the org unit setting type table. Beyond that not sure. |
| # | 07:50:22 | hopkinsju has joined #evergreen |
| # | 08:12:28 | plux has joined #evergreen |
| # | 08:20:42 | hopkinsju has quit IRC |
| # | 08:24:37 | sfortin has joined #evergreen |
| # | 08:56:18 | kmlussier has joined #evergreen |
| # | 08:56:33 | kmlussier has left #evergreen |
| # | 08:57:18 | tspindler has joined #evergreen |
| # | 09:01:35 | Meliss has joined #evergreen |
| # | 09:05:22 | kmlussier has joined #evergreen |
| # | 09:13:51 | tsbere | Barring objections from mrpeters-isl about "it didn't work at all" I am thinking I will push the updated upgrade script from https://bugs.launchpad.net/evergreen/+bug/798255 today. Unless someone else has good reason for me not to? |
| # | 09:13:51 | pinesol_green | Launchpad bug 798255 in Evergreen master "archiving stat cats with aged circulation" (affected: 2, heat: 14) [Medium,In progress] |
| # | 09:15:35 | hopkinsju has joined #evergreen |
| # | 09:15:57 | eeevil | tsbere: user/tsbere/faster_0663_upgrade ? |
| # | 09:16:34 | Shae has joined #evergreen |
| # | 09:16:39 | tsbere | eeevil: Well, I was going to push the signed off by dyrcona copy |
| # | 09:17:04 | tsbere | collab/dyrcona/faster_0663_upgrade |
| # | 09:18:02 | eeevil | righto |
| # | 09:25:11 | tsbere decided to run some sanity checkish stuff on things and found 11 upgrade script files total with no COMMIT in them.....which isn't a perfect check but is interesting |
| # | 09:26:26 | jeff | did those same lack a BEGIN? |
| # | 09:27:01 | tsbere | At least one is a BEGIN/END block instead of a BEGIN/COMMIT. Another was literally just a "reserve this number" comment. A third was just the deps block check command, again to reserve the number. |
| # | 09:28:26 | tsbere pulls up the full list |
| # | 09:31:02 | tsbere | Explicit no transaction with comment to that effect x 7, just a comment or upgrade log entry for placeholder use x 3, BEGIN/END instead of BEGIN/COMMIT x 1 |
| # | 09:34:18 | jenny1 has joined #evergreen |
| # | 10:00:19 | atheos has quit IRC |
| # | 10:02:27 | tsbere | Ok....I understand the self employed individual born on Feb 29th doing a one day birthday sale because it is his actual birthday. But the 8 library vendors making really bad leap puns in their marketing emails are insane, especially when they aren't even running sales. |
| # | 10:05:36 | bshum | Hmm, the opensrf readme differs slightly from the instructions we've had up for the wiki |
| # | 10:06:07 | tsbere | That happens |
| # | 10:06:26 | tsbere | So often that I think officially we now say "use the README, not the wiki" |
| # | 10:06:30 | bshum | Like max_user_sessions is still listed at 1000 in the README vs. 10000 for the wiki. |
| # | 10:06:47 | tsbere isn't sure which way to go on that one |
| # | 10:07:11 | tsbere | I think I tend to say "INSANE HO!" and bump it to 100000 |
| # | 10:08:41 | bshum | That's what I figured |
| # | 10:12:27 | bshum | Bleh, the README definitely could use some love |
| # | 10:12:43 | tsbere | bshum: You have git. YOU HAVE THE POWER! :P |
| # | 10:12:55 | bshum | Yeah I know |
| # | 10:13:06 | bshum | I'll try tweaking it a bit after I get the latest master installed |
| # | 10:16:52 | tsbere attempts to log into the VM Host for the training system here at the office and has issues |
| # | 10:21:24 | denials | bshum: yes, the OpenSRF README needs love - basically needs a refactoring into the same structure as Evergreen |
| # | 10:23:25 | denials finds a README commit hanging around locally that hasn't been pushed that does just that, apparently |
| # | 10:23:45 | denials | c894480990a from Jan 4 |
| # | 10:24:07 | denials | working/user/dbs/README_202 it looks like |
| # | 10:24:56 | bshum | Oooh |
| # | 10:24:57 | bshum | Fun |
| # | 10:27:12 | denials will update the README for the max_user_sessions to 10000 to match the wiki and push the dammed thing |
| # | 10:28:21 | bshum | denials++ |
| # | 10:28:46 | bshum | The only other thing I noted that might be "confusing" for newbies is that it doesn't explicitly mention to copy the .example files for opensrf.xml and opensrf_core.xml |
| # | 10:29:52 | denials | good point |
| # | 10:29:55 | bshum | That and on line 202 where it specifics hosts, the README doesn't keep "localhost" as one of the listen names for ejabberd.cfg |
| # | 10:30:01 | bshum | But I expect that's not really required |
| # | 10:44:09 | denials | Pushed another update |
| # | 10:46:17 | bshum | denials: Just one last little tweak, noted that the opensrf_core.xml.example got left .example during the copy command. |
| # | 10:47:03 | bshum | Otherwise, denials++ for keeping us all on track with the README's |
| # | 10:49:48 | denials | okay, updated again. |
| # | 10:49:57 | denials is kind of like bshum's git interface |
| # | 10:50:52 | bshum | :D Thanks denials! |
| # | 10:52:53 | akilsdonk has joined #evergreen |
| # | 10:57:53 | sal_ has joined #evergreen |
| # | 11:12:18 | denials | btw, tsbere, I say go ahead and push the faster_0663_upgrade branch |
| # | 11:13:10 | tsbere has been sidetracked by rage-inducing issues, will get to it after he beats down a few more of said issues |
| # | 11:22:13 | denials | we should probably introduce a standard "review dependency versions for source packages" step somewhere into the release process. example: yaz is now at 4.2.26, we still spec 4.2.17 in Makefile.install |
| # | 11:24:52 | bshum | 4.2.27 actually. |
| # | 11:25:08 | bshum remembered updating that yesterday |
| # | 11:31:43 | Meliss has quit IRC |
| # | 11:38:31 | sampero has joined #evergreen |
| # | 11:43:19 | sampero has quit IRC |
| # | 11:53:28 | sfortin has quit IRC |
| # | 11:53:35 | _bott_ | Has anyone experienced a payment problem, where everything seems happy, then the receipt shows: "Original Balance: $??? ", and the payment is applied to only a portion of the bills? |
| # | 12:01:09 | akilsdonk has quit IRC |
| # | 12:53:10 | luisb has joined #evergreen |
| # | 13:00:51 | sal_ has quit IRC |
| # | 13:05:24 | tsbere | _bott_: That sounds freaky. Does it actually have question marks? |
| # | 13:28:04 | sal_ has joined #evergreen |
| # | 13:28:48 | fortin has joined #evergreen |
| # | 13:37:23 | _bott_ | tsbere: yes, it literally has "$???" as the value |
| # | 13:39:59 | tsbere | _bott_: I was not aware that *could* happen normally....I guess I would need to see the template though. |
| # | 13:43:22 | _bott_ | I'm waiting for a copy of the template from the machine in question. I'm also wondering if it's a materialized view issue of some kind, but since I never hear about it until after the issue... |
| # | 13:43:40 | tsbere | _bott_: 2.1+ or pre-2.1? |
| # | 13:44:50 | _bott_ | 2.1'ish |
| # | 13:45:35 | tsbere | With the no javascript work, I assume.....perhaps ??? is the default value of the span to receive the monetary amount and no line item sum entries existed? |
| # | 13:45:56 | _bott_ | I'm aware of one other occurrance back in Sept. But now a location is seeing it almost daily |
| # | 13:47:02 | _bott_ | I'm asking for them to watch for a mismatch between sidebar, summary, and Bills screen, but that's just a hunch |
| # | 13:56:32 | tsbere scans for commonish issues in the alpha2 upgrade script.....and finds some. :( |
| # | 13:57:54 | collum has joined #evergreen |
| # | 13:59:03 | bshum will wait for tsbere to push new upgrade script before trying 2.1+ upgrading |
| # | 13:59:49 | denials | tsbere: was the alpha2 script basically just concatenated upgrade scripts? if so, common issues probably shouldn't be a surprise |
| # | 14:00:17 | tsbere | denials: That is what I was told to do. Unless someone has changed their mind on that? |
| # | 14:01:41 | denials | tsbere: well, given that the upgrade scripts themselves introduce errors that are fixed by later upgrade scripts, and we're not using supercedes-ish stuff, I don't think it's possible to create a good upgrade script without human intervention |
| # | 14:02:06 | tsbere | denials: At this point I am aiming for a *working* upgrade script. Good can come later ;) |
| # | 14:02:11 | denials | heh |
| # | 14:02:14 | tsbere | Like at beta stage or something. |
| # | 14:02:14 | tsbere | <_< |
| # | 14:02:29 | jamesrf | to put it in a bit of context, the upgrade scripts have come a long way from the "miker writes the whole thing by hand" days |
| # | 14:02:31 | tsbere | You know, once we have a branch for 2.2 specifically. Unless we want to call it 3.0? :P |
| # | 14:03:21 | denials | maybe we should write the version_upgrade script as we go, while the changes are fresh... |
| # | 14:03:39 | tsbere | That gets tricky |
| # | 14:03:40 | denials is fine with 3.0 |
| # | 14:03:41 | tsbere | <_< |
| # | 14:04:00 | tsbere | most common issue I know of? ALTER TABLE after INSERT or UPDATE on said table. |
| # | 14:04:46 | denials | of course, if we had sample data and ran version upgrades after each commit, we'd know quickly when things were broken |
| # | 14:04:52 | denials | (or before each commit!) |
| # | 14:05:23 | tsbere | <_< |
| # | 14:05:28 | denials | and then we could maintain the base schema, and the #### upgrade scripts, _and_ the version upgrade script |
| # | 14:05:53 | denials | (and the expected output) |
| # | 14:06:33 | tsbere | and we could drive ourselves insane little by little? :P |
| # | 14:07:25 | denials is already there |
| # | 14:09:09 | tsbere | Ok, drive ourselves beyond the traditional definitions of sanity and insanity into a new realmn of madness? :P |
| # | 14:10:30 | tsbere | Hmmm. I need to update my make release script to use the new upgrade script folder. |
| # | 14:10:46 | tsbere | Good to know, I will get right on that *after* I fix the currently busted upgrade script ;) |
| # | 14:14:23 | denials | is your make release script in master? |
| # | 14:14:44 | tsbere | no. I have been keeping it in a branch, but the branch is out of date because I keep a copy out of the branch too. <_< |
| # | 14:14:55 | denials | would be great to get that into build/tools/ or the like |
| # | 14:15:01 | tsbere | Twas the idea ;) |
| # | 14:15:10 | denials | cool |
| # | 14:18:15 | tsbere uses 2.1-2.2-alpha2-upgrade-db.sql instead of 2.1-2.2-upgrade-db.sql for the time being....unless there is a complaint about that course of action? |
| # | 14:19:35 | tsbere | Oh, wait, I already have a "no, I don't need you to deal with the upgrade script" command line parameter. Guess I can go with that. |
| # | 14:20:32 | denials | I would just go with 2.1-2.2-upgrade-db.sql - it's a step in the evolution of the script - but doesn't matter to me particularly |
| # | 14:20:53 | tsbere | I forgot that I made make_release understand "we already have one, don't bother" |
| # | 14:21:07 | tsbere | Otherwise it bothers if it doesn't find the filename it decided upon ;) |
| # | 14:27:25 | tsbere | Translation building. <_< |
| # | 14:31:21 | tsbere | denials: http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/tsbere/make_release should be the latest version now. |
| # | 14:31:53 | tsbere | As translations don't require the original git folder, so I can go branch jump in there just fine ;) |
| # | 14:42:04 | eeevil | late to this party, but to resurface an option discussed in the past: reify the baseline schema and drop all commit-level upgrade scripts at, say, the release of 3.0. Then, ONLY use commit-level upgrade scripts, period, moving forward, until 4.0 where we reify again |
| # | 14:42:21 | eeevil | so each install after 3.0.0 is an upgrade from 3.0.0 |
| # | 14:48:39 | tsbere | Hmmm...no MD5 for the linux client bz2.....I should add that to the make release script |
| # | 14:57:17 | tsbere | So, I uploaded my latest alpha attempt. |
| # | 14:57:33 | tsbere | Who wants to play "test stuff"? *pokes bshum* |
| # | 14:57:53 | tsbere needs to double-check the branch and push it too, for that matter.... |
| # | 14:58:12 | tsbere | and what do I do about the updated upgrade script and the version upgrade directory in master? Do I need a sign off to update that? |
| # | 14:58:44 | jenny has joined #evergreen |
| # | 15:00:09 | jenny1 has quit IRC |
| # | 15:00:20 | bshum | tsbere: Wait, what am I trying? |
| # | 15:00:38 | tsbere | bshum: I pushed alpha2 tarballs and such to the website. |
| # | 15:00:56 | tsbere | Which include the "I have not pushed it via git yet" upgrade script, for that matter. |
| # | 15:01:42 | tsbere is thinking he would like someone to at least verify that things *look* good before he does that push, less to clean up if something is horribly wrong ;) |
| # | 15:03:39 | edoceo has joined #evergreen |
| # | 15:04:17 | tsbere | The staff client looks like it works, at least to get to the login screen ;) |
| # | 15:04:28 | edoceo | This page http://open-ils.org/dokuwiki/doku.php?id=evergreen-admin:importing:bibrecords - shows using direct_ingest.pl for the Gutenberg records - is direct_ingest not used anymore? |
| # | 15:05:16 | edoceo has left #evergreen |
| # | 15:05:21 | edoceo has joined #evergreen |
| # | 15:07:56 | denials | edoceo: it's dead, jim |
| # | 15:08:16 | edoceo | How does the import go now? |
| # | 15:08:53 | denials generally does "yaz-marcdump -t xml", wrap in a minimal "INSERT INTO biblio.record_entry ... VALUES ..." statement, and go |
| # | 15:08:54 | tsbere starts uninstalling 19 defunct staff clients he forgot he had installed |
| # | 15:09:27 | denials | edoceo: kind of like Open-ILS/tests/datasets/concerto.sql |
| # | 15:09:35 | edoceo | thx |
| # | 15:10:39 | tsbere | denials: Any thoughts on updating master's upgrade script and sign-offs? As in, do I need a second one there at this stage? |
| # | 15:13:23 | denials | tsbere: just the upgrade script? I'd say no, if you think it's good to go. Unless someone's idling in channel with a 2.1 system ready to test against |
| # | 15:13:49 | tsbere | I tested it against a clean rel_2_1 with concerto and test users loaded. No circs or holds, though. |
| # | 15:14:11 | bshum | 2.1 ready to go! |
| # | 15:14:26 | bshum | And tsbere just shared me a copy of the new file, guess I'll watch it whiz |
| # | 15:14:44 | tsbere | bshum: I shared with you how to grab an entire file from another branch ;) |
| # | 15:14:58 | bshum | Well, you know |
| # | 15:15:02 | bshum | :) |
| # | 15:15:18 | hopkinsju has quit IRC |
| # | 15:15:23 | tsbere | Oh, crap, I just noticed a problem. :( |
| # | 15:15:31 | bshum | Heh |
| # | 15:15:54 | hopkinsju has joined #evergreen |
| # | 15:15:58 | tsbere | bshum: I apparently grabbed the wrong copy of the file. I grabbed the final one with a ROLLBACK at the end, rather than a COMMIT, when I put the file in the version upgrade directory. |
| # | 15:16:30 | denials | hah |
| # | 15:17:51 | denials | huh, the signed-off-by's look weird in the emailed version of the commit |
| # | 15:18:13 | denials | also, I thought we were no longer creating tags-as-branches |
| # | 15:18:38 | denials | but just using tags-as-tags :) |
| # | 15:19:12 | tsbere | denials: I can't add commits to tags-as-tags, can I? :P |
| # | 15:19:39 | denials | @blame email for munging commit message sign-offs |
| # | 15:19:40 | pinesol_green | denials: Error: "blame" is not a valid command. |
| # | 15:21:09 | tsbere | Ok, updated the tarball and md5 |
| # | 15:21:14 | tsbere | <_< |
| # | 15:21:25 | tsbere waits for bshum to do some initial testing of the upgrade script, though |
| # | 15:22:30 | tsbere loves the ability to open tarballs in vim and just save edited files, for the record |
| # | 15:23:37 | berick learned something about vim today |
| # | 15:24:25 | denials | berick: :tab ? |
| # | 15:24:48 | denials | :syntax off (before loading a monstrously large XML file)? |
| # | 15:25:32 | tsbere | denials: Maybe my comment about being able to directly edit files inside of tarballs? :P |
| # | 15:26:15 | berick | denials: what tsbere said... |
| # | 15:26:23 | berick | denials: :tab ? |
| # | 15:26:38 | denials | tsbere: oh, am I supposed to read a whole two lines back? |
| # | 15:26:43 | denials | :tab new |
| # | 15:26:48 | denials is a berick fanboi |
| # | 15:27:20 | berick | ohh, tabs.. forgot about those |
| # | 15:27:27 | senator | neato burrito |
| # | 15:28:02 | tsbere likes :tabnew, :split, :vsplit, :new, and :vnew, amongst others |
| # | 15:28:44 | tsbere | and set mouse=a inside of my SSH session so I can grab dividers with the mouse after I do the splits rather than fighting with the various "expand/shrink this subwindow" commands. |
| # | 15:29:25 | senator | i once in a while use split, but really for editing multiple files i'd almost always rather run another instance of vim in another xterm or screen window |
| # | 15:30:18 | tsbere | senator: I commonly split two files when I am comparing something between them. Or when one is a list of things to look for in the other.... |
| # | 15:31:44 | tsbere also commonly launches vim as "vim -p <list o file>" |
| # | 15:33:01 | sal_ | * sal_ still uses emacs to split view. And vi for just about everything else... |
| # | 15:34:08 | tsbere | I also amaze myself with how often I vim `grep -Rl regex *` and similar. That came in handy with the new_xulrunner stuff. |
| # | 15:34:26 | eeevil | ack FTW |
| # | 15:38:41 | luisb_ has joined #evergreen |
| # | 15:39:18 | luisb has quit IRC |
| # | 15:39:18 | luisb_ is now known as luisb |
| # | 15:39:18 | jenny has quit IRC |
| # | 15:40:12 | jenny has joined #evergreen |
| # | 15:41:13 | denials likes :sp & :vsp too, as well as "(g)vimdiff file1 file2" |
| # | 15:42:10 | plux has quit IRC |
| # | 15:42:14 | denials | so much of my brain is in my fingers |
| # | 15:53:18 | edoceo | When I try to load concerto.sql I get errors about ERROR: query string argument of EXECUTE is null - PL/pgSQL function "label_normalizer" line 16 at EXECUTE statement... and a bunch more (starting in indexing_ingest_or_delete) - thoughts? |
| # | 16:01:37 | tspindler has quit IRC |
| # | 16:02:38 | kmlussier has left #evergreen |
| # | 16:05:36 | hopkinsju has quit IRC |
| # | 16:08:51 | hopkinsju has joined #evergreen |
| # | 16:08:56 | eeevil | denials: I recall recently seeing a question pop up about authority sorting, particularly about it only being done on subfield a |
| # | 16:09:51 | eeevil | denials: I can't find where that was now, but I seem to recall you being involved in the discussion, and saying something about materializing the data we use for the unique index in an actual column |
| # | 16:11:56 | hopkinsju has quit IRC |
| # | 16:12:29 | eeevil | denials: so ... since you're the only participant I recall specifically, and I can't find the actual discussion, I wanted to point you at authority.simple_heading (table) and all of the surrounding stored proceedures (authority.atag_browse_* stored procs, in particular) |
| # | 16:20:13 | denials | eeevil: yeah, I saw that at the same time, but doesn't SuperCat still just sort by subfield a? |
| # | 16:21:06 | denials | return authority_tag_sf_browse($self, $client, \@tags, 'a', @_); # XXX TODO figure out something more correct for the subfield param |
| # | 16:22:40 | denials | (in O:A:SuperCat::axis_authority_browse()) ... all the infrastructure in the world doesn't matter if it's not hooked up (of course, a happy response would be that that's just dead code) |
| # | 16:26:52 | hopkinsju has joined #evergreen |
| # | 16:41:02 | hopkinsju has quit IRC |
| # | 16:48:44 | mtcarlson has joined #evergreen |
| # | 16:55:34 | jamesrf has quit IRC |
| # | 16:55:44 | jamesrf has joined #evergreen |
| # | 17:01:29 | Shae has quit IRC |
| # | 17:04:36 | sal_ has quit IRC |
| # | 17:11:39 | tsbere | evergreen vs public. BAH. |
| # | 17:13:42 | bshum | Yep. |
| # | 17:15:06 | fortin has quit IRC |
| # | 17:23:00 | tsbere has made note of the issue bshum saw and added it to a tweaked upgrade script he is poking at, but hopes that bshum isn't waiting for said tweaked script ;) |
| # | 17:23:34 | bshum | tsbere: I was just looking around for that is_json function actually. |
| # | 17:23:43 | bshum | tsbere: Not as quick on the rebound |
| # | 17:24:10 | bshum | But yeah, I should add it the "fix" and then try again, since it's going through ridiculous number of rows along the way |
| # | 17:24:36 | bshum | Could I just copy in the missing function I guess? (or change it from evergreen to public, and keep going) |
| # | 17:25:58 | tsbere | bshum: I grabbed it from 002.functions or whatever, added the evergreen. to the name, and pasted it right before the alter table statement in question. |
| # | 17:30:27 | denials | tsbere: I take it that the fixes for the previous 2.2 upgrade script that I had merged were blown away? |
| # | 17:30:40 | denials | merged/pushed branches & opened bugs for? |
| # | 17:31:47 | denials | maybe once we get to alpha state we start tweaking the version_upgrade script only by hand |
| # | 17:32:40 | denials | (fwiw, 6db17fe4e94531 is what I was talking about) |
| # | 17:33:15 | denials heads out |
| # | 17:43:26 | collum has quit IRC |
| # | 17:47:17 | jenny has quit IRC |
| # | 17:51:16 | mtcarlson has quit IRC |
| # | 18:11:44 | mtcarlson has joined #evergreen |
| # | 18:12:48 | Dyrcona has joined #evergreen |
| # | 18:15:48 | tsbere | @later tell denials I hope I didn't give you the impression that I had more than a cursory idea of what I should be doing about upgrade scripts. The whole process has been hard to follow. We should probably discuss the mess at the next developer meeting and come up with an official policy of some kind. :/ |
| # | 18:15:48 | pinesol_green | tsbere: The operation succeeded. |
| # | 18:19:32 | finnx has joined #evergreen |
| # | 19:03:28 | mtcarlson has quit IRC |
| # | 19:12:59 | mtcarlson has joined #evergreen |
| # | 19:17:49 | mtcarlson has quit IRC |
| # | 20:06:00 | bshum | tsbere: Looks like the script is wrapping up. |
| # | 20:06:06 | bshum | It's on "COMMIT" apparently |
| # | 20:06:20 | bshum | So that sounds promising. |
| # | 20:12:42 | tsbere | bshum: Yay! |
| # | 20:14:13 | bshum | tsbere: Committed and.... looking happy so far, based on the results in the log. |
| # | 20:14:34 | bshum | I'll have to finish installing master on a new application head and hook it up to the DB to test it out |
| # | 20:14:54 | bshum | But script completed successfully on our production db from 2.0 -> 2.1 -> 2.1.1 -> 2.2 alpha2 |
| # | 20:15:12 | bshum | tsbere++ |
| # | 20:15:51 | tsbere | :D |
| # | 20:15:54 | bshum | I see a ton of notes about limit sets being created too |
| # | 20:16:01 | bshum | So I guess that's your handiwork |
| # | 20:16:12 | tsbere | Oh yea, lots of those if you have/had circ mod limits. |
| # | 20:16:42 | bshum | Yep. |
| # | 20:16:48 | bshum | Cool, cool |
| # | 20:23:52 | luisb has quit IRC |
| # | 20:37:07 | edoceo has quit IRC |
| # | 20:56:39 | eeevil | denials: re "all the infrastructure in the world", the actual browse interface in the opac uses the axis browse stored proc. I built the others so that other interfaces could use them, but the browse UI was what was funded. I'd love others interested in making authorities better to fund or code the improvement/replacement of the rest, or we could wait for me to have tuits and desire. |
| # | 21:02:34 | eeevil | denials: ha! I went back and looked. you got your wish, and that is, indeed, just dead code. we now use O::A::SuperCat::generic_new_authorities_method |
| # | 21:57:51 | hopkinsju has joined #evergreen |
| # | 23:00:59 | finnx has quit IRC |
| # | 23:56:14 | hopkinsju has quit IRC |
April 10-13