| # | Time | Nick | Message |
|---|
| # | 00:12:36 | dbwells_ has joined #evergreen |
| # | 00:15:26 | dbwells has quit IRC |
| # | 00:16:53 | dkyle has quit IRC |
| # | 00:17:00 | dkyle has joined #evergreen |
| # | 00:39:34 | pranjal710 has joined #evergreen |
| # | 02:01:53 | ascii has joined #evergreen |
| # | 04:43:30 | Neil__ has joined #evergreen |
| # | 04:53:43 | Neil__ has left #evergreen |
| # | 05:03:19 | dkyle has quit IRC |
| # | 05:04:19 | _bott_1 has quit IRC |
| # | 05:16:37 | dkyle has joined #evergreen |
| # | 05:17:18 | _bott_ has joined #evergreen |
| # | 05:29:47 | pranjal710 has quit IRC |
| # | 05:37:33 | v1k1n has quit IRC |
| # | 05:37:47 | v1k1n has joined #evergreen |
| # | 06:54:13 | fortin has joined #evergreen |
| # | 07:09:04 | bhupendrasingh has joined #evergreen |
| # | 07:15:08 | bhupendrasingh | hi, i am inetersted in Create Android client for Evergreen for gsoc this year, how can i pursue that |
| # | 07:17:52 | collum has joined #evergreen |
| # | 07:18:13 | meenuh has quit IRC |
| # | 07:19:40 | tsbere | @tell bhupendrasingh ~gsoc |
| # | 07:19:52 | tsbere | meh. Thought that might work. |
| # | 07:19:57 | tsbere | ~gsoc |
| # | 07:19:57 | pinesol_green | Looking for information on Google Summer of Code and Evergreen? 2012 Project page: http://goo.gl/5tCHe Evergreen ideas page: http://goo.gl/kOZJd GSoC Student Guide: http://goo.gl/vlCtG GSoC 2012 and you Blog Post: http://goo.gl/gw8Dc |
| # | 07:20:07 | tsbere | bhupendrasingh: I suggest reading the above links ^^^ |
| # | 07:27:05 | bhupendrasingh | tsbere thanks |
| # | 07:32:53 | meenuh has joined #evergreen |
| # | 07:58:00 | akilsdonk has joined #evergreen |
| # | 08:05:14 | hassan1990 has joined #evergreen |
| # | 08:05:53 | hassan1990 | Just wanted to know what is the IDE used to develop Evergreen? |
| # | 08:06:33 | bhupendrasingh has quit IRC |
| # | 08:09:14 | kivilahtio | I just got a wild idea |
| # | 08:10:07 | kivilahtio | Would it be possible to have the whole production server datadump? or maybe even a virtual image of a working and running current Evergreen system? |
| # | 08:10:31 | kivilahtio | or are the test servers packed with the same data as real live servers? |
| # | 08:10:40 | timhome has joined #evergreen |
| # | 08:11:01 | kivilahtio | This might help my colleague to get these Serials figured out |
| # | 08:12:25 | kivilahtio | She got the predictions to work thanks to senator's script, but now there is a issue with attaching items/holdings to a predicted issue. |
| # | 08:14:34 | kivilahtio | Mainly with the issue used as a start issue for creating the predictions. The created predictions get issues received to them quite nicely. |
| # | 08:17:37 | denials | hassan1990: there is no particular IDE needed to develop Evergreen. many people use vim. Some use emacs. |
| # | 08:18:39 | hassan1990 | denials: thanks |
| # | 08:19:37 | hassan1990 | where can I get a look at the overall code and see how it is organized and how many modules are there? |
| # | 08:20:05 | tsbere | hassan1990: Download a tarball, or check it out via git? |
| # | 08:22:32 | Dyrcona has joined #evergreen |
| # | 08:22:53 | hassan1990 | So if I am to write a unit test where should I do that? |
| # | 08:26:09 | denials | hassan1990: it depends on what kind of unit test you want to write. there are currently Perl unit tests in Open-ILS/src/perlmods/t |
| # | 08:26:30 | hassan1990 | I want to write a unit test with Java |
| # | 08:32:24 | kivilahtio | hassan1990++ |
| # | 08:33:36 | kivilahtio | I would like to find out more about the software architecture, I haven't found any diagrams specifying how, for example how the http-request is processed throughout the apache-osrf-perl-psql -stack |
| # | 08:34:27 | tspindler has joined #evergreen |
| # | 08:35:15 | denials | hassan1990: then Open-ILS/src/java/org/open_ils/test seems like a good place to start (although those are not unit tests) |
| # | 08:35:25 | tsbere | kivilahtio: I don't think we *have* any diagrams like that. If we do I would like to see them too, though ;) |
| # | 08:35:43 | berick | ditto OpenSRF/src/java/org/opensrf/test |
| # | 08:36:05 | berick | best diagram I can find ;) http://evergreen-ils.org/documentation/OpenSRF_Server_Architecture.jpg |
| # | 08:36:18 | bwicksall has quit IRC |
| # | 08:36:27 | denials | it's a shame scott mckellar's opensrf presentation wasn't recorded |
| # | 08:38:08 | kivilahtio | berick: I tried to explain to our municipal IT the server structure and I don't get why we have two load balancers. I think one is supposed to use a hardware L4 router/load balancer, but doesn't osrf do load balancing as well? |
| # | 08:38:37 | denials | one load balancer for HTTP traffic, you mean? |
| # | 08:38:44 | berick | kivilahtio: yes, there are multiple levels of load balancing |
| # | 08:38:45 | kivilahtio | well yes |
| # | 08:39:22 | kivilahtio | isn't it inefficient to have extra load balancing? |
| # | 08:39:27 | tsbere | Unless you are like MVLC and go with "one DB server, one app server, one SIP server that runs nothing else as part of the overall system". Then there is basically no load balancing. :P |
| # | 08:39:52 | berick | kivilahtio: perhaps one is a backup load balancer? |
| # | 08:40:03 | kivilahtio | berick: :) |
| # | 08:40:23 | kivilahtio | how about the sql-server cluster? |
| # | 08:40:42 | berick | kivilahtio: pgpool handles the load balancing there |
| # | 08:40:43 | kivilahtio | anybody using postgresql cluster? |
| # | 08:42:10 | kivilahtio | ah sorry nevermind that |
| # | 09:02:55 | bwicksall has joined #evergreen |
| # | 09:03:38 | kmlussier has joined #evergreen |
| # | 09:11:25 | denials gave pgpool-II a shot a few weeks back, and it worked wonderfully for about 12 hours, until it locked up tight |
| # | 09:11:58 | denials | going to give it more exercise in a testing environment before throwing that into production again :) |
| # | 09:13:23 | raynerj has joined #evergreen |
| # | 09:13:25 | ascii | tsbere, berick: Yesterday I asked regarding Updating Patron data using open-ils.actor.patron.update method through http-translator in Java. I found solution for it. I just added "null, 1, null" at the end of Address Object to change address. Here values are for "Add, Update & Delete" operations respectivly. Any not null or "" value is treated as true. To change the user data i added "null,null,null,null,null,null,null,null,null,n |
| # | 09:15:33 | jeff | ascii: your message was truncated at 'i added "null,null' in mid-null :-) |
| # | 09:15:42 | ascii | ohh |
| # | 09:16:09 | ascii | continued.....To change the user data i added "null,null,null,null,null,null,null,null,null,null,1" at the end of Patron object. I am still working on it. Not getting what is the meaning of each null and 1. If any one know about this kindly share with me. Here is the request I am sending... http://pastie.org/3731398 |
| # | 09:16:11 | jeff idly wonders if the java fieldmapper bits don't know about adding the three special is_* fields |
| # | 09:17:24 | jeff | the is new/changed/deleted fields on each object used to be explicitly defined in fm_IDL.xml, but now are expected to be added automatically by the various fieldmapper libraries (perl, javascript, python, java...) |
| # | 09:17:51 | jeff | the change was made some time ago, and i just wonder if the java fieldmapper libraries were forgotten in the change. alas, i don't have time to look myself right now. |
| # | 09:18:02 | berick | jeff: ascii is not using the java IDL libs... |
| # | 09:18:30 | berick | tsbere and I tried to guide ascii in that direction yesterday |
| # | 09:18:37 | jeff | ah. |
| # | 09:18:43 | jeff | in that case... |
| # | 09:18:52 | berick | jeff: however.. how that you say it. the java libs may in fact not have those fields defined.. |
| # | 09:18:56 | berick looks closer |
| # | 09:19:00 | berick | s/how/now/ |
| # | 09:19:44 | berick | yeah, I missed that w/ my recent java updates |
| # | 09:19:48 | jeff | ascii: if you decide not to use the supplied java libraries for dealing with fieldmapper objects, the responsibility for handling some of the things that those libraries do falls on you -- though, while berick looks at the java libs, you might peek at one of the other implementations. |
| # | 09:20:33 | jeff | ascii: in short, objects are returned as arrays, and using the data in fm_IDL.xml you can determine which array position corresponds to which field. there are then three additional fields not defined in the fm_IDL.xml file |
| # | 09:20:59 | jeff | ascii: you need to account for those three fields when reading an object from the system, and also when creating a new object in your code. |
| # | 09:22:14 | ascii | actually i checked logs and got records of calls made by evergreen client.. i compared them with object that i received.. |
| # | 09:23:17 | ascii | n figured that 3 fields are getting added at the end of Address object.. 11 fields at the end of Patron object |
| # | 09:24:54 | thethomaseffect has joined #evergreen |
| # | 09:31:02 | jenny has joined #evergreen |
| # | 09:32:18 | tsbere | ascii: It may just be that those "empty" values aren't being handed to you in all cases. <_< I would hope that berick is now working to correct his oversight from his recent java updates, which would put me back at recommending you use the official libraries rather than rolling your own. |
| # | 09:32:32 | tsbere | Because if we add a new field to, say, patrons, your code will stop working again. |
| # | 09:35:36 | ascii | berick: could u please provide me link for Java libraries. |
| # | 09:38:24 | berick updated bug 942643 |
| # | 09:38:24 | pinesol_green | Launchpad bug 942643 in Evergreen "Remove deprecated array_index extraction in Java IDL parser" (affected: 1, heat: 6) [Undecided,New] https://launchpad.net/bugs/942643 |
| # | 09:38:56 | berick | ascii: you'll need the opensrf and evergreen libs. |
| # | 09:39:22 | berick | they're in the repositories under src/java. |
| # | 09:40:09 | ascii | berick: ok thanks... I will look into those.. |
| # | 09:40:14 | berick | well, Open-ILS/src/java for the Evergreen repo |
| # | 09:40:53 | berick | ascii: great. for Evergreen, I recommend using the code from this branch http://git.evergreen-ils.org/?p=working/Evergreen.git;a=shortlog;h=refs/heads/user/berick/update-java-idl-array-indexes until it gets merged into master |
| # | 09:51:33 | sal_ has joined #evergreen |
| # | 09:53:51 | berick | ascii: for talking to the server via http, there's also this (moderately tested) http client code at http://git.evergreen-ils.org/?p=working/OpenSRF.git;a=shortlog;h=refs/heads/collab/berick/java-http-gateway |
| # | 09:55:13 | ascii | ok |
| # | 10:03:59 | tsbere wonders how hard it would be to get the http stuff working with the translator too |
| # | 10:04:49 | dbwells_ is now known as dbwells |
| # | 10:04:58 | thethomaseffect has quit IRC |
| # | 10:07:34 | berick | tsbere: the code was all built w/ the translator in mind. all it needs is the multipart/mixed parsing and some header handling. |
| # | 10:08:00 | tsbere | berick: Aka, not too hard. I might look into that eventually. >_> |
| # | 10:08:14 | tsbere | If nobody else beats me to it and I want streaming support, anyway. |
| # | 10:09:46 | jeff | i still favor the gateway over the translator for simple requests -- is that wrong? is the gateway intended to go away in favor of the translator at some point? |
| # | 10:10:02 | berick | tsbere: exactly. just need to create TranslatorRequest.java, subclas HttpRequest, and fill in the gooey bits |
| # | 10:10:25 | tsbere | jeff: I am in favor of being able to use either. If only because streaming responses aren't simple :P |
| # | 10:10:50 | berick | jeff: i doubt the gateway is going anywhere |
| # | 10:11:12 | berick also likes the gateway, especially as a training tool |
| # | 10:11:19 | berick | http_get++ |
| # | 10:11:48 | berick | rather, http_get_no_headers++ (for learning) |
| # | 10:12:02 | mrpeters-isl | thoughts on https://bugs.launchpad.net/evergreen/+bug/973666 -- should I make my reccomendation into a patch? or should we just leave that up to libraries to customize on their own? |
| # | 10:12:02 | pinesol_green | Launchpad bug 973666 in Evergreen "Acq: "Print Purchase Order" does not print PO Name" (affected: 1, heat: 6) [Wishlist,New] |
| # | 10:12:32 | mrpeters-isl | not a bug, nor a wishlist -- but i described how A/T can be modified to accomodate this |
| # | 10:12:35 | jeff | good to hear. :-) |
| # | 10:13:05 | ascii has quit IRC |
| # | 10:14:22 | kmlussier | mrpeters-isl: IMO, it's resonable to expect PO Name to be part of the default action/trigger, so I would vote for patch. But I don't feel too strongly about that. |
| # | 10:14:39 | mrpeters-isl | cool. just finished applying it to our system, so ill branch it up in a second |
| # | 10:14:41 | pranjal710 has joined #evergreen |
| # | 10:14:44 | mrpeters-isl | i agree, btw |
| # | 10:14:53 | mrpeters-isl | <h2>Purchase Order: [% target.name %] ([% target.id %])</h2> |
| # | 10:14:56 | mrpeters-isl | that gives best of both worlds |
| # | 10:15:13 | tsbere | Just be careful about upgrade scripts. If any. >_> |
| # | 10:15:54 | mrpeters-isl | ah, yeah, how should i handle that? modified 950.data.seed-values, 0189 and 1.6-2.0-upgrade-db.sql |
| # | 10:16:01 | mrpeters-isl | should i only modify 950? |
| # | 10:16:12 | tsbere | I dunno about touching 0189 |
| # | 10:16:23 | tsbere isn't a fan of altering upgrade scripts like that |
| # | 10:16:25 | mrpeters-isl | yeah, you're probably right |
| # | 10:16:49 | tsbere | mrpeters-isl: My main concern is "if you overwrite the copy in someone's system, what customizations are you possibly erasing? |
| # | 10:17:16 | mrpeters-isl | yeah...thats tricky |
| # | 10:18:22 | jeff | debconf! |
| # | 10:18:24 | jeff ducks |
| # | 10:18:40 | mrpeters-isl | so, thoughts on what status to give the bug? |
| # | 10:18:50 | mrpeters-isl | Opinion? |
| # | 10:18:52 | tsbere isn't a fan of overwriting A/T templates unless the template output is being handed as input to something else as, say, XML or something |
| # | 10:19:22 | mrpeters-isl | yeah, ill skip the patch. the bug/comments can serve as the solution. |
| # | 10:19:41 | tsbere | mrpeters-isl: I don't object to changing 950 |
| # | 10:20:19 | mrpeters-isl | ok, i can do that |
| # | 10:22:28 | dbwells | kivilahtio: To answer your question earlier about attaching items to the "Starter", my general advice is that you do not. The "starter" should instead be set to represent the last issue you received in your old system, then let the predictions create all of your expected issues. |
| # | 10:25:09 | mrpeters-isl | ok, user/mrpeters-isl/print_po_include_name is up |
| # | 10:25:58 | thethomaseffect has joined #evergreen |
| # | 10:26:42 | bshum | dbwells: senator: Since this looked serials related, curious if you had any opinions on this error I encountered upgrading through 2.1-2.2-beta1 script: http://pastie.org/3733252 |
| # | 10:30:27 | dbwells | bshum: yes, there has been one other report of that on the list. I am pretty sure it is a simple matter of bad data with inadequate exception handling, but haven't gotten a chance to verify that and fix it. |
| # | 10:33:11 | jeff | dbwells: have you put any thought into retro-conversion of existing non-serials copies? i believe we're working on that here, and i may wish to bounce a draft "here's one way to do it" off of you at some point. |
| # | 10:34:24 | bshum | dbwells: Ah okay. Well, I'll poke at it a bit today. I'm hoping this is the last stumbler I'll have to solve before we upgrade things tonight. Thanks! |
| # | 10:35:03 | akilsdonk has quit IRC |
| # | 10:36:16 | tsbere | mrpeters-isl: "In Progress" and "Assigned to X" means "nobody else should touch this right now, pullrequest or no" - You may want to change those ;) |
| # | 10:37:03 | mrpeters-isl | ok |
| # | 10:37:05 | mrpeters-isl | fixed |
| # | 10:40:29 | dbwells | jeff: I'd love to see what you work out. I've put plenty of thought into it, but alas, I have no real data to convert. I've had no problem concocting both test data that is workable and test data which isn't ;) |
| # | 10:42:38 | senator | bshum: i think i can fix your problem with materialize_holding_code |
| # | 10:42:40 | senator | is there an lp bug yet? |
| # | 10:43:08 | bshum | senator: I'm not sure, dbwells pointed me out to something reported earlier than I, but I didn't get to check LP yet. |
| # | 10:43:30 | kmlussier | bshum: I don't think she reported it through LP, just through the lists. |
| # | 10:44:11 | dbwells | senator: I didn't see a bug for it, either. |
| # | 10:47:59 | dbwells | senator: the list message was titled "Upgrade problem with 2.2-beta1", but it doesn't say anything beyond what bshum said. I am sure you see the problem already anyway. |
| # | 10:49:06 | bshum | Sorry I went db diving to figure out why we had serials data without using serials… and it looks like some people went "playing" without our knowledge. |
| # | 10:49:29 | senator | dbwells: so for some reason i thought we had an is_json constraint on serial.issuance.holding_code. since we don't, we just need materialize_holding_code to bail early in case of invalid json, maybe warn but no error |
| # | 10:54:29 | dbwells | senator: exactly. is_json constraint seems like a really good idea, too. Verifying on input is world's better than needing to verify everywhere we use the data. |
| # | 10:56:06 | senator | agreed. of course that leads to the question of what to do with data that's no good in the upgrade script |
| # | 10:56:21 | tsbere wonders if we should play with something like this before deleting plperl in the upgrade script: UPDATE pg_catalog.pg_proc SET prolang = (select oid from pg_catalog.pg_language where lanname = 'plperlu') WHERE prolang = (select oid from pg_catalog.pg_language where lanname = 'plperl'); |
| # | 10:56:45 | tsbere | I have no clue if that is going to do things we don't want, but I believe all plperl functions should be valid plperlu functions (but not the other way around) |
| # | 11:00:45 | senator | dbwells / bshum: how about this? so a row in serial.issuance with holding_code that isn't valid json probably isn't good for anything, but to avoid being heavy-handed and dropping the row entirely, we set holding_code to null where it's not json, then add an is_json or null constraint for the column, then make sure that serial.materialize_holding_code handles null gracefully |
| # | 11:01:10 | dbwells | senator: hmmm, good question. Maybe we could turn whatever is there into a string literal. It's still going to break anything which tries to turn that data into a field, but at least no data would be lost. |
| # | 11:02:00 | dbwells | senator: sorry, that doesn't go with your latest proposal |
| # | 11:02:45 | senator | right. your proposal saves more data than mine... but i'm not sure what the value of invalid data in that field could be anyway.. |
| # | 11:03:00 | bshum | senator: Since it's junk for us, I was tempted to use a heavy-handed approach anyways, but I'm willing to try whichever approach you suggest. |
| # | 11:03:35 | senator | dbwells: can you get a count on the rows in your production serial.issuance where evergreen.is_json(holding_code) is false? |
| # | 11:03:37 | bshum | Maybe the question is better for libraries who have real serials data. |
| # | 11:03:40 | senator | i would expect nearly 0 |
| # | 11:05:34 | bshum | Ha, every row for us fails that test, awesome. |
| # | 11:05:52 | dbwells | senator: we have 4 out of 13,086 |
| # | 11:06:04 | denials | tsbere: if the only reason we want all plplerlu is to make it easier to install (in particular on BSD), maybe we don't need to drop PLPERL in the upgrade script at all? |
| # | 11:06:17 | senator | bshum: experimenting with the interfaces without reference to tutorials could probably lead to that easily. we need more bumper rails there. so i guess i'm not surprised |
| # | 11:06:58 | bshum | senator: Sounds like what probably ended up happening. |
| # | 11:08:20 | denials | senator: we have 0. Of course we're still entirely MFHD-based, so we have 0 serial.issuance rows. |
| # | 11:08:51 | senator | denials: :-) thanks |
| # | 11:09:05 | senator | dbwells: so my set-the-broken-fields-to-null proposal wouldn't wreck you? |
| # | 11:09:19 | denials | if dbwells or jeff or anyone else wants legacy MFHD data to test with conversions, I can supply lots :) |
| # | 11:12:24 | dbwells | senator: in all four cases we are missing quotes from month values which start with a '0', e.g. 06. I am going to see if these issues have other, uh, "issues", and see if I can spot any pattern. |
| # | 11:12:35 | berkleeintern has joined #evergreen |
| # | 11:24:27 | dbwells | senator: as expected, those 4 issuances don't work properly. As for determining how widespread the problem is, I am not sure how typical we are, given that we have a "serial killer" on staff. That said, this data isn't exactly the one-of-a-kind stuff worth saving, so I say null away! |
| # | 11:25:02 | senator | dbwells++ |
| # | 11:25:09 | senator | thanks |
| # | 11:25:51 | mrpeters-isl | curious why http://git.evergreen-ils.org/?p=Evergreen.git;a=commitdiff;h=e4bb24703fe6a73a649691761b2df308dd21bbbf doesn't have it's upgrade script tagged? |
| # | 11:26:05 | mrpeters-isl | it shouldn't be XXXX.... if it's in master, right? |
| # | 11:26:40 | senator | mrpeters-isl: the commit right after it fixed that |
| # | 11:26:47 | senator | that'll happen sometimes |
| # | 11:26:55 | mrpeters-isl | aha |
| # | 11:28:03 | mrpeters-isl | thanks senator |
| # | 11:28:10 | senator | no prob |
| # | 11:28:33 | mrpeters-isl | kind of puzzled why i dont have this code with 2.1.1 |
| # | 11:28:54 | mrpeters-isl | it was committed way before 2.1, i think....October? |
| # | 11:34:00 | tsbere | denials: Also to make it harder for devs of various kinds to add plperl functions that don't play nicely later |
| # | 11:34:17 | raynerj1 has joined #evergreen |
| # | 11:34:21 | hassan1990 has quit IRC |
| # | 11:37:31 | raynerj has quit IRC |
| # | 11:39:53 | senator | dbwells: i think i'm catching a closely related but distinct bug at the same time: |
| # | 11:40:25 | denials | tsbere: sure, but as it's a nice-to-have rather than a must-have in the upgrade, I would shy away from globally modifying other functions and keep the DROP statement out of the big transaction. I'm happy to commit a change for the latter |
| # | 11:40:51 | senator | 210.schema.serials.sql was missing your changes (present in 0700 upgrade script) to simplify the smhc table. can you confirm i'm not just confused? |
| # | 11:41:14 | tsbere | denials: Perhaps include the mass edit statement in a comment before it in case people want to give it a shot anyway? |
| # | 11:41:44 | tsbere wonders how the "audience_group" coded value map entries would work....as he has no examples |
| # | 11:42:05 | Dyrcona has quit IRC |
| # | 11:43:51 | tsbere | If anyone wonders what I am talking about, looks like tpac will grab audience_group if there instead of the regular audience stuff |
| # | 11:48:04 | kmlussier | tsbere: I don't know the answer to your question, but I wonder if it's similar to the mattype attribute that can be used for item types. Basically, something that can be used for systems using a local field to store audience information instead of using the fixed fields. |
| # | 11:49:03 | dbwells | senator: yes, darn, you're right |
| # | 11:49:30 | senator | dbwells: no problem. fixing at same time |
| # | 11:49:55 | tsbere | kmlussier: I know how mattype works. This implies that it would select multiple entries with one by virtue of being named _group |
| # | 11:53:59 | sal_ has quit IRC |
| # | 11:55:49 | denials | tsbere: sounds like a plan (including a description of what we're attempting to do, and how one could go further via a mass change) |
| # | 11:57:50 | tsbere | denials: You happen to know anything about the audience_group bit and how that would work? As in would it be a custom area in MARC, or would it be a grouping of the existing audience information? (If the latter, that invalidates my afternoon project of coding in a way to do groupings) |
| # | 11:58:48 | tsbere | Well, unless I say "I want groupings first, but non-grouped entries afterwards" anyway |
| # | 11:59:58 | akilsdonk has joined #evergreen |
| # | 12:01:01 | berick | tsbere: the purpose is for grouping existing audience data from config.coded_value_map |
| # | 12:01:07 | berick | (where ctype = 'audience') |
| # | 12:01:45 | berick | you have to create a config.record_attr_index_norm_map using the 'Coded Value Map Normalizer' config.index_normalizer |
| # | 12:03:23 | berick | tsbere: mapping example: http://paste.lisp.org/display/128783 |
| # | 12:03:32 | tsbere | berick++ |
| # | 12:03:41 | tsbere | for invalidating my question before I could ask it with the example |
| # | 12:03:45 | berick | then, well, re-index or manually insert the record_attr values |
| # | 12:04:09 | tsbere | re-index? |
| # | 12:04:14 | tsbere | gah |
| # | 12:04:18 | tsbere hates reindexing |
| # | 12:05:32 | berick | in that example, the two "A" mappings are for NULL and g, e, f. NULL has to be mapped w/ it's own entry |
| # | 12:05:46 | Dyrcona has joined #evergreen |
| # | 12:06:18 | tsbere | Yea, that looked like what was going on. I assume that I would choose things like "A = Adult, C = Child, T = Teen" for labeling what those end up actually meaning, right? |
| # | 12:07:16 | berick | tsbere: exactly |
| # | 12:07:31 | berick | .. in config.coded_value_map |
| # | 12:08:21 | tsbere | berick: There any desire (from other than me) for a "lets make actual groupings that don't require their own indexes" variant that can live *with* the non-grouped variants? So that a table could say "for audience we have an Adult grouping that includes the following audience values..." with a split between the grouped and non-grouped entries in the selector box? |
| # | 12:09:44 | denials was away trying to respond to GSoC proposals that had no response yet, wouldn't have been able to help with "config.coded_value_map" Q anyway |
| # | 12:10:03 | tsbere | denials++ |
| # | 12:11:37 | berick | tsbere: sounds a lot like how the jspac used to offer an 'advanced' version |
| # | 12:15:47 | berick | tsbere: something i'm going to propose to LP soon, that might affect what you're talking about, is the concept of named org-unit saved search filter groups. |
| # | 12:16:02 | tsbere | berick: JSPac was my inspiration. Partially. My thought was "put grouped ones first, then a 'disabled' ----- entry, then the non-grouped ones (if any are set to opac visible) |
| # | 12:16:43 | tsbere | berick: "Named org-unit saved search filter groups" sounds a lot like some MassLNC stuff that I wasn't sure we had put out publically yet. |
| # | 12:16:46 | tsbere pokes kmlussier |
| # | 12:16:55 | berick | for example, you may have a group called Audience and an entry for Adult (etc.). the entry would specify its contents via query_parser string instead of via raw SVF, etc. so Adult might be audience(a,b,c) && location(1,2,3) |
| # | 12:16:57 | kmlussier | tsbere: No, I don't think that's us. |
| # | 12:17:23 | kmlussier | berick: Is that part of the kids pac project? |
| # | 12:17:25 | berick | tsbere: well, it's related to the kids pac project.. |
| # | 12:17:26 | berick | :) |
| # | 12:17:34 | berick | kmlussier: indeed |
| # | 12:17:42 | tsbere | kmlussier: I said "sounds a lot like" |
| # | 12:17:48 | kmlussier | berick: Knew I had seen it somewhere before. |
| # | 12:18:02 | tsbere | kmlussier: My thought was "perhaps usable *instead* of what MassLNC was throwing around" |
| # | 12:18:08 | kmlussier | tsbere: Which project does that sound like? My brains a little dead from working with numbers all morning. |
| # | 12:18:19 | denials | kid spank project |
| # | 12:18:31 | tsbere | kmlussier: Item types based on more than just the bib type |
| # | 12:19:11 | berick | tsbere: yep, that came up as an example when we were kicking this around |
| # | 12:19:31 | berick | it would work for both |
| # | 12:20:58 | tsbere still thinks "grouped" coded value map entries would be nice for, say, "I generally want kids stuff" compared to "I want only things for this one audience" but has no clue how he would need to implement that yet |
| # | 12:21:05 | kmlussier | I think I woudl have to see it to understand how it could fit in. |
| # | 12:22:26 | tsbere | kmlussier: I can mock my thought up very quickly |
| # | 12:24:43 | James has joined #evergreen |
| # | 12:25:09 | James is now known as Guest52349 |
| # | 12:26:04 | Guest52349 | Hello! Can someone tell me more about the Android client for EvergreeN? |
| # | 12:26:17 | tsbere | kmlussier: I mocked up the "Audience" box: http://tomtrunk.mvlcstaff.org/mockup.html |
| # | 12:26:48 | phasefx | Guest52349: there is none :D |
| # | 12:27:31 | Guest52349 | Mmm. All the more reason to make one? |
| # | 12:28:10 | tsbere | We put it on our GSoC list for a reason. Though I am thinking I may take a crack at it if we don't pick a conflicting GSoC proposal. |
| # | 12:28:46 | phasefx wants to try his hand at ios dev |
| # | 12:29:02 | Guest52349 | I'm a 'late GSoC' applicant. :P |
| # | 12:29:13 | Guest52349 | Didn't think I was good enough to apply, until just recently. |
| # | 12:29:44 | Guest52349 | I'm interested in Android app development, so I was thinking I could try applying for that project. |
| # | 12:29:52 | tsbere | Guest52349: You aren't late yet. Running out of time if you haven't submitted yet, but not late ;) |
| # | 12:30:52 | Guest52349 | ヽ(*⌒∇⌒*)ﾉ |
| # | 12:31:34 | kmlussier | tsbere: I kind of liked the "advanced" links used in jspac. Are you looking at this approach to avoid javascript? |
| # | 12:31:52 | tsbere | kmlussier: Yes. Hard to swap things out without javascript. |
| # | 12:32:39 | Guest52349 | Great! So is this Android app supposed to be a library search engine? |
| # | 12:32:59 | tsbere | Guest52349: I think you are supposed to tell us what it would be. Lots of options. ;) |
| # | 12:33:52 | tsbere | Guest52349: In general, though, I see there being a split. "Patron" and "Staff" apps will have very different uses. |
| # | 12:34:31 | Guest52349 | Wow, that's a lot of freedom. xD |
| # | 12:35:01 | tsbere | Patrons want to check/update their accounts, place holds, search the catalog...... staff may want things that are more task specific, like pulling holds or doing inventory. |
| # | 12:36:11 | Guest52349 | I can definitely see all those things done a tablet, but I'm not so sure if some cell phones have the processing power to do some things like that. |
| # | 12:36:33 | tsbere | My cell phone is more powerful than any android tablet I have had my hands on |
| # | 12:36:43 | tsbere | Smaller screen, but more powerful ;) |
| # | 12:37:26 | Guest52349 | Me too! But it's incredibly buggy. G2x phones, meh. But I like it nevertheless. :D |
| # | 12:37:43 | tsbere | Most of the patron-side stuff would be "get data from server, display on screen". Placing holds or editing account settings would be one of the few "save data" things. |
| # | 12:37:57 | tsbere | Staff side would likely involve a lot more back and forth with specific entries |
| # | 12:38:36 | tsbere has a pile of notes on how *he* would implement some staff side stuff, but isn't sharing those until at minimum after the weekend |
| # | 12:38:38 | Guest52349 | What about the bar code scanning? How process intensive can that be? I realize there's unique barcode scanner, like the square things. |
| # | 12:40:10 | tsbere | Guest52349: Depends on how that is done. It could be as simple as "you don't worry about it, the barcode scanner acts like a keyboard", it could be as complicated as "you need to embed camera routines yourself". Depends on a lot of factors. |
| # | 12:42:33 | tsbere | Guest52349: May I suggest picking a better irc nick? Guest##### isn't all that identifying. I suspect you can just type: /nick newnick |
| # | 12:43:04 | Guest52349 | Thanks! I didn't really know how to change an irc nickname. This is really the first time I've actually used IRC |
| # | 12:43:16 | Guest52349 is now known as jamesk41 |
| # | 12:44:07 | jamesk41 | Could this project possibly go off on a tangent? I feel like writing a bar code scanner for the app could be a huge obstacle. |
| # | 12:44:49 | jamesk41 | Or are we allowed to use other code that's been publically available online? Is there anything about citing code? |
| # | 12:45:18 | denials | jamesk41: it's open source. You follow the open source license(s) involved. |
| # | 12:45:59 | denials | for example, you can (and would be a fool not to) use http://code.google.com/p/zxing/ |
| # | 12:46:16 | tsbere has notes on how to use that code without including any of the code |
| # | 12:46:22 | tsbere | Intents! <_< |
| # | 12:46:36 | denials | and it makes a whole lot of sense to use http://www.openintents.org/en/libraries |
| # | 12:46:52 | denials | tsbere: well, yeah |
| # | 12:47:09 | tsbere has no code to show for all of his notes |
| # | 12:47:20 | denials | You're using other code via intents, too |
| # | 12:47:36 | jamesk41 | I think I need to read up on all these licences... |
| # | 12:47:36 | tsbere | I do have multiple barcode scanners installed on my phone, though ;) |
| # | 12:47:56 | denials | intents are definitely the way to go |
| # | 12:48:46 | jamesk41 | What is Intents exactly? It just looks like a list of apis that require developer licences... or is that it? |
| # | 12:49:12 | denials | jamesk41: if you don't know what intents are, then you probably aren't in a good position to tackle an Android app at this point |
| # | 12:49:58 | denials | (short version: it's like "http://" tells your system that it needs something that has registered itself as being able to handle "http://" requests) |
| # | 12:53:54 | swills_ has joined #evergreen |
| # | 12:55:33 | jamesk41 | Well, I'm a quick learner, if that's worth anything. |
| # | 12:55:40 | denials | Definitely! |
| # | 12:56:21 | tsbere | A week ago I didn't know what intents were either. >_> |
| # | 12:57:24 | jamesk41 | I've mostly been a programmer, sheltered behind preset installations of linux and case study programming assignments. |
| # | 12:57:58 | denials | jamesk41: you'll want to scope your proposal accordingly, to be realistic. Learning OpenSRF & Evergreen & Android all at once is a pretty big load in and of itself |
| # | 12:58:21 | denials | this is a good opportunity to step out from behind that shelter :) |
| # | 12:58:58 | alexlazar has joined #evergreen |
| # | 13:01:30 | tsbere wonders if berick has any opinions on his mockup |
| # | 13:02:06 | tsbere | I would rather not work on making it happen if it is disliked ;) |
| # | 13:03:58 | swills_ is now known as StephenGWills |
| # | 13:04:45 | jamesk41 | Well, Android is java based. I have java experience, so I think Android will come naturally. |
| # | 13:05:21 | jamesk41 | What is there to learn about Evergreen? It looks mostly like an interface, like frontend and opensrf being backend. |
| # | 13:05:30 | danielR has joined #evergreen |
| # | 13:07:40 | jamesrf has quit IRC |
| # | 13:08:45 | tsbere | OpenSRF is the communication layer. Evergreen itself comes with frontend and backend. |
| # | 13:09:16 | jeff muses again on 'fixating' circ stats by way of (approximately) "every circ is an aged circ" |
| # | 13:10:21 | tsbere | jeff: And how do you plan on doing "every circ is an aged circ"? |
| # | 13:10:28 | jeff | there is no plan yet. |
| # | 13:11:14 | jeff | just a musing along the lines of "make it so that changing a patron stat cat the month after the circ doesn't change the totals for the previous month's 'circ by $that_stat_cat' report." |
| # | 13:11:36 | tsbere | jeff: I already solved that problem. >_> |
| # | 13:11:40 | jeff | it of course gets complicated quickly, such as when you start caring about a new circ stat. |
| # | 13:11:45 | jeff | tsbere: cool! how? |
| # | 13:11:54 | tsbere | jeff: Archive with circs flags on stat cats |
| # | 13:12:13 | tsbere | Gets archived at the circ creation, stays with it when the circ ages |
| # | 13:12:20 | jeff | superb. |
| # | 13:12:32 | jeff | sounds like just the thing. where should I look for more? |
| # | 13:12:53 | tsbere | master/2.2 has it. If you want I can dig up the original branch if you want to look at backport options. |
| # | 13:12:54 | jeff | and did you go after any of the complex bits like "when you start caring about a new circ stat"? |
| # | 13:13:11 | jeff | tsbere: was there a launchpad bug on it? |
| # | 13:13:13 | tsbere | jeff: If the stat cat doesn't exist at circ time then it doesn't get archived. |
| # | 13:13:23 | tsbere | jeff: Yes. Let me dig that up for ya ;) |
| # | 13:13:26 | jeff | thanks. |
| # | 13:13:57 | tsbere | jeff: See the end of https://bugs.launchpad.net/evergreen/+bug/798255 |
| # | 13:13:57 | pinesol_green | Launchpad bug 798255 in Evergreen master "archiving stat cats with aged circulation" (affected: 2, heat: 14) [Medium,Fix released] |
| # | 13:14:05 | jamesrf has joined #evergreen |
| # | 13:14:15 | berick | tsbere: the audience group mockup? seems reasonable to me |
| # | 13:16:10 | jamesk41 | So, I know that I should start off with learning more about Android, OpenSRF, and Evergreen. Is there anything else I should prepare for this project? |
| # | 13:16:19 | jamesk41 | (Assuming if I can think I can do it.) |
| # | 13:16:39 | jeff | tsbere: okay, so we have stat cats and copy location... looks like nothing for patron profile group / age / etc. am i reading that correctly? |
| # | 13:17:38 | kmlussier | berick: The "Named org-unit saved search filter groups"; I understand those canned searches will be available on the Kids PAC page. Will they also be available for use as an advanced search filter or will that require additional development? |
| # | 13:17:44 | tsbere | jamesk41: You will need to submit a code fix, you can check our bitesize bugs on launchpad |
| # | 13:17:46 | kmlussier is hoping to scratch a dev project off my list. |
| # | 13:18:17 | denials | jamesk41: http://evergreen-ils.org/blog/?p=750 is a pretty good overview |
| # | 13:18:25 | tsbere | jeff: I do not currently get the profile group / age/ etc.....though if the patron's age is changing unpredictably between circs I am worried ;) |
| # | 13:19:08 | Gentlecat has quit IRC |
| # | 13:19:22 | tsbere | jeff: I could see arguments for profile group, but I can also see arguments against it. |
| # | 13:20:48 | jeff | tsbere: re: age ... i was thinking "record the patron age in years not the DOB" as a means to ensure aged circs have less specific data -- i thought aged circs already did that, but i could be wrong. |
| # | 13:21:10 | tsbere | jeff: I was thinking "no need to keep that with the not-yet-aged circs" ;) |
| # | 13:21:22 | tsbere | AKA, age is predictable. You can get it based on the circ date easily. |
| # | 13:21:32 | jeff | tsbere: because they would be dob->aged at time the circ was aged |
| # | 13:22:32 | jeff | tsbere: the other bit, aside from fixating some of this data was to have it all in one place so that a "report on circs both aged and not" didn't become/have-to-be a big ugly UNION / reporter view. |
| # | 13:22:51 | jeff | but i could be thinking of fixing the problem in the wrong place. |
| # | 13:23:25 | tsbere | jeff: It could be argued that aged circs using the aged date instead of the circ date for dob->age is a bug. |
| # | 13:24:10 | jeff | does it do that now? because yes, i would agree that we would consider that a bug. |
| # | 13:24:45 | tsbere | I can check |
| # | 13:25:20 | jeff | launchpad bug type "i wonder if this is a bug" |
| # | 13:25:21 | jeff | :P |
| # | 13:25:44 | tsbere | jeff: Looks like it isn't storing age at all. Just birth year if it exists. |
| # | 13:26:07 | jeff | got it. that's... somewhat reasonable. |
| # | 13:26:42 | berick | kmlussier: it would still require a little bit of tpac template work |
| # | 13:26:51 | berick | should be minor, though |
| # | 13:27:11 | kmlussier | berick++ minor is good. Can't wait to see it! |
| # | 13:27:13 | tsbere | jeff: So profile group isn't being archived as of the circ, and birth years shouldn't be wandering. What else ya got? :P |
| # | 13:27:14 | jeff | i appreciate the "don't store it if you can calculate it" philosophy, but start to question it in some specific cases when reporting over time comes into play. had similar topic arise with our public computing stats this morning. |
| # | 13:28:50 | jeff | tsbere: that's mostly it, though i wonder if we'll have anyone caring about circ_lib of the copy at time of circ... i believe we plan to do a lot more shuffling of copies around the district, and it's likely they'll be transferred rather than getting new barcode values and new circ objects. |
| # | 13:29:31 | tsbere | jeff: I don't think that gets aged either way. |
| # | 13:29:36 | jeff | tsbere: but i haven't put enough thought into it to determine if we can get "circ of other library's item" aka "incoming 'ILL'" for those |
| # | 13:30:08 | tsbere believes the original item stays associated either way, so none of that is aged |
| # | 13:30:36 | jamesk41 | Is it difficult to submit a code fix? I'm not sure I have the background to fix a bug. |
| # | 13:30:56 | jeff | tsbere: if i report today on "count of circs at SYS2 libs of items with a circ_lib of a SYS1 lib" and then i transfer some copies around, i could run that same report and get different data now. that's the kind of think i'm thinking about. |
| # | 13:31:44 | tsbere | jeff: I fully understand that. Otherwise I wouldn't have done the stat cat work there. But I am pointing out that aged or not doesn't help with that case right now, so insta-aging circs won't help. |
| # | 13:31:54 | jeff | tsbere: because transferring copies from a a volume at a SYS1 lib to a volume at a SYS2 lib will not result in a new copy being created. |
| # | 13:32:03 | jeff | tsbere: ah, yes. i wasn't trying to say that. sorry. :-) |
| # | 13:33:06 | jeff | the idea of archiving everything (let's not call it aging in this case) was combined with the idea of preserving a wider range of values from the item/patron, above and beyond what current aging or the new stat cat / copy location archiving does. |
| # | 13:33:22 | jeff | two things in my brain, i probably didn't make that clear. |
| # | 13:33:26 | jeff | anyway... |
| # | 13:33:28 | jeff | brainstorming++ |
| # | 13:33:30 | jeff | tsbere++ |
| # | 13:33:31 | jeff | thanks |
| # | 13:34:06 | tsbere | jeff: Assign auditors and use "blah as of date" type functions that query the auditor information. |
| # | 13:34:10 | tsbere | :P |
| # | 13:38:07 | jeff | yeah. auditor tables for anything other than debugging/troubleshooting makes me frown. |
| # | 13:38:43 | tsbere | Well, they give you a full history of whatever you slap them on. So if you want to argue for having a full history available...... |
| # | 13:39:46 | jeff | okay, any folk in the channel with Syndetic experience enough to know if the current AC handler for Syndetic Solutions uses their "Classic" interface for pulling reviews/toc/etc? They have "classic", and "plus", and I believe that "classic" is what we want. |
| # | 13:39:58 | jeff | Plus seems to be "insert this iframe / javascript" |
| # | 13:40:43 | jeff | While Classic is (they claim) "you have to open a new window to get to the content" -- I believe this is incorrect in the case of how Evergreen ties in and proxies and caches the AC data. |
| # | 13:41:16 | tsbere | jeff: I have no clue, but I suspect classic. Note that they have asked at one point if we wanted html or xml..... |
| # | 13:43:42 | rsoulliere has joined #evergreen |
| # | 13:46:15 | mtcarlson has joined #evergreen |
| # | 13:48:46 | alexlazar has quit IRC |
| # | 13:51:47 | jamesk41 | Can anyone provide any insights for trying to find improvements for the Evergreen code? |
| # | 13:52:12 | jamesk41 | I'm still very lost about submitting a code fix for something I don't know how to look for. |
| # | 13:52:34 | tsbere | jamesk41, https://bugs.launchpad.net/evergreen/+bugs?field.tag=bitesize |
| # | 13:52:52 | yboston has joined #evergreen |
| # | 13:56:13 | jamesk41 | Just a quick question. Since I'm probably not going to have time to apply for GSoC, can I just work on these project ideas anyways? |
| # | 13:56:45 | denials | jamesk41: absolutely! |
| # | 13:57:14 | jamesk41 | Even if other GSoC students may be working on the same topic? |
| # | 13:57:52 | yboston | heads up everyone, the DIG meeting will be starting at 2 PM EST |
| # | 13:58:10 | jamesk41 | I'm assuming that for those students that have created a proposal for a certain topic, the topic of interest is limited to the student and mentor. |
| # | 13:58:47 | denials | jamesk41: I think we'd generally prefer to avoid a duplication of effort in the project |
| # | 13:58:53 | denials | (GSoC or not) |
| # | 13:59:13 | denials | but it should be possible to carve out defined but related opportunities in the same area |
| # | 14:00:02 | jamesk41 | Sweet! |
| # | 14:00:35 | egotsev has joined #evergreen |
| # | 14:00:52 | egotsev has left #evergreen |
| # | 14:02:20 | yboston | Welcome to the Evergreen Documentation Interest Group (DIG) Monthly Meeting. The agenda can be found here http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting_20120405-agenda |
| # | 14:02:36 | yboston | If you are here looking for help with Evergreen, please gives us time to first finish this IRC meeting, and then please restate your question again |
| # | 14:02:46 | yboston | Please feel free to start introducing yourselves... |
| # | 14:02:53 | yboston Yamil Suarez - Berklee College of Music |
| # | 14:02:56 | jenny is Jenny Turner, PALS |
| # | 14:03:01 | rsoulliere is Robert Soulliere, Mohawk College |
| # | 14:03:02 | tspindler Tim Spindler - C/W MARS |
| # | 14:03:08 | raynerj1 | raynerj is june rayner at eiNetwork |
| # | 14:03:13 | kmlussier is Kathy Lussier, MassLNC |
| # | 14:03:20 | yboston | At this point I would like to find a volunteer to take minutes, but continue introducing yourselves |
| # | 14:03:28 | raynerj1 | I'll do minutes |
| # | 14:03:34 | fortin Sally Fortin - Equinox Software |
| # | 14:03:40 | kmlussier | raynerj1++ |
| # | 14:03:43 | yboston | thanks June!!!! |
| # | 14:03:49 | jenny | raynerj1++ - beat me to it. : ) |
| # | 14:04:00 | tspindler | yboston: isn't there a chat bot or something to do it? jenny++ |
| # | 14:04:16 | jenny | I've used the bot |
| # | 14:04:26 | jenny | it works well, if you remember the commands... |
| # | 14:04:36 | yboston | yes there is, but I wanted to prepare ourselves first before using it |
| # | 14:05:00 | kmlussier | http://www.open-ils.org/dokuwiki/doku.php?id=community:using-meetbot&s[]=meetbot |
| # | 14:05:06 | yboston | I can send out an email about it after the meetign with more details |
| # | 14:05:18 | mtcarlson has quit IRC |
| # | 14:05:51 | yboston | Thnaks kmlussier |
| # | 14:06:01 | yboston | I did not know that page existed |
| # | 14:06:31 | jenny | me neither! kmlussier++ |
| # | 14:06:42 | kmlussier | I think bshum pulled it together. bshum++ |
| # | 14:07:02 | yboston | Lets postpone using this automatic minutes taker for our next monthly meeting, but I am very glad to hear several of us had heard about "Meetbot" |
| # | 14:07:09 | yboston | (that is only a suggestion) |
| # | 14:07:48 | raynerj1 | agree |
| # | 14:07:54 | tspindler | yboston: makes sense and the thanks june for volunteering |
| # | 14:08:03 | raynerj1 | you're welcome! |
| # | 14:08:25 | tsbere is Thomas Berezansky, MVLC, but may not say anything else for the duration of the meeting >_> |
| # | 14:08:37 | yboston | Lets move on to the content coordinator reports, if that is OK. |
| # | 14:08:42 | yboston | Who wants to go first? |
| # | 14:08:53 | jenny can get her report out of the way |
| # | 14:09:03 | yboston | go ahead :) |
| # | 14:09:35 | jenny | The reports taskforce has had a volunteer step forward to look at the reports documentation and add a bit more |
| # | 14:09:49 | jenny | however, she's been rather busy over the past few months |
| # | 14:10:21 | jenny | otherwise, it's been really quiet. I am hoping to lead a discussion about reports documentation during our interest group meeting at the conference (the reports IG) |
| # | 14:10:39 | jenny | and hopefully identify needs and get VOLUNTEERS : ) |
| # | 14:10:50 | jenny | that's all from me |
| # | 14:11:03 | yboston | thanks |
| # | 14:11:15 | yboston | if there are no comments to this report, we can go to the next report |
| # | 14:11:19 | rsoulliere | I can go next |
| # | 14:11:27 | rsoulliere | For updating the outline, I have added a color/progress indicator reference to help guide folks when updating documentation status. |
| # | 14:11:37 | rsoulliere | See: http://open-ils.org/dokuwiki/doku.php?id=evergreen-docs_2.2:outline |
| # | 14:11:57 | rsoulliere | tspindler has sent me lots of documentation to be included in 2.2. and 2.1. |
| # | 14:12:03 | rsoulliere | tspindler++ |
| # | 14:12:21 | rsoulliere | Remember to use the outlines to indicate if you are currently working on documentation or if you are aware of existing documentaton. Point us to the existing docs. |
| # | 14:12:21 | kmlussier | tspindler++ |
| # | 14:12:35 | rsoulliere | Thanks to all the folks who have been expanding the 2.2 outline! |
| # | 14:12:43 | rsoulliere | thats all from me. |
| # | 14:12:50 | jenny | rsoulliere++ |
| # | 14:12:56 | tspindler | i have been looking a lot at acq and serials because its important to us, but it would be good if content coordinators could get existings docs upgraded for 2.2 |
| # | 14:13:02 | yboston | tspindler++ rsoulliere++ |
| # | 14:13:59 | jenny | I'm working on getting volunteers to test. Seems like most of our group isn't on 2.2 , so it's been slow going. |
| # | 14:14:17 | jenny | but, I agree tspindler++ |
| # | 14:14:52 | tspindler | i would encourage using one of the test servers out there if you don't have your own, I was using the Indiana one mrpeters set up |
| # | 14:15:47 | jenny | I'm trying to encourage that, too - and do it myself - it's just a bit easier to work in to the day, when it is your system. : ) |
| # | 14:16:26 | yboston | Btw, I want to have my laptop set up to run 2.2 during the conference so we can look at 2.2 while face to face |
| # | 14:16:43 | tspindler | yboston: good idea |
| # | 14:16:44 | jenny | yboston++ |
| # | 14:16:50 | rsoulliere | yboston++ |
| # | 14:17:21 | yboston | btw, I am not sure if Robert is totally done reporting, and/or Tim has started his report :) |
| # | 14:17:33 | rsoulliere | I was done. |
| # | 14:18:31 | yboston | Anything else to add Tim? or comments on Tim's comments? |
| # | 14:18:36 | tspindler | i'm assuming we are still on content coordinators, but I have been trying to fill in the outline but I think it would be good if the coordinators could look closed at rsoulliere's outline |
| # | 14:18:58 | tspindler | done |
| # | 14:19:09 | yboston | I assume you mean the 2.2 outline? |
| # | 14:19:14 | tspindler | yes |
| # | 14:20:04 | yboston | as the DIG co-release coordinator I will add a short report |
| # | 14:20:52 | GayashanNA has joined #evergreen |
| # | 14:20:53 | yboston | I have been learning ASCIIDoc with the help of my intern, and preparing to create an ASCIIDoc introduction presentation for the DIG meeting/hackfest |
| # | 14:21:28 | yboston | that is all for me) |
| # | 14:21:31 | raynerj1 | sounds great! |
| # | 14:21:31 | KN2W has joined #evergreen |
| # | 14:21:37 | yboston | who would like to go next? |
| # | 14:21:41 | tspindler | yboston++ i need to sit in that |
| # | 14:21:49 | raynerj1 | I can go next |
| # | 14:21:53 | rsoulliere | yboston++ Asciidoc training++ |
| # | 14:22:02 | yboston | go ahead June |
| # | 14:22:59 | raynerj1 | I have one piece of doc that was sent in response to my general query, but it needs some editing and formatting to fit in with the style and I haven't had time. Hoping to catch up on some things at the conference. |
| # | 14:23:17 | raynerj1 | As Kathy said last meeting, I never have enough time to work on docs |
| # | 14:23:30 | raynerj1 | That is it for me now. |
| # | 14:23:53 | kmlussier | I can go next. |
| # | 14:24:02 | yboston | go ahead |
| # | 14:24:44 | kmlussier | As rsouilliere metnioned, tspindler has done a lot with end-user documentation. I also did a review of staff client dosc, most of which could be moved up. |
| # | 14:25:07 | kmlussier | I'll need to convert some of those staff client docs into asciidoc so that they can be moved to 2.2 |
| # | 14:25:31 | kmlussier | sfortin just announced today that she has released some docs for ESI developemnt. sfortin++ |
| # | 14:25:50 | yboston | sfortin++ |
| # | 14:26:20 | kmlussier | I would like to take a look at them before moving them to the official docs. I'm assuming something like this - http://www.esilibrary.com/esi/docs/?p=962 - just needs to be incorporated in the staff client docs while some of the other docs can have their own section. |
| # | 14:26:46 | kmlussier | And I'll definitely follow up on tspindler's suggestion to do some further work on the 2.2 outline. :-) |
| # | 14:26:55 | kmlussier | That's it for me. |
| # | 14:27:10 | yboston | thanks |
| # | 14:27:25 | yboston | are there any coordinators left? |
| # | 14:27:46 | kmlussier | sfortin: The ESI docs are all available in asciidoc format too, is that right? |
| # | 14:28:43 | fortin | yes |
| # | 14:29:03 | fortin | everything that i have in blog format will be in asciidoc by the end of this meeting |
| # | 14:29:30 | fortin | and available on ESI website |
| # | 14:29:36 | kmlussier | fortin++ Thanks! |
| # | 14:29:41 | fortin | will post link in before we leave today |
| # | 14:29:50 | jenny | fortin++ |
| # | 14:30:12 | yboston | I think we could start moving to old then new business, as we reach the 30 minute mark |
| # | 14:30:23 | yboston | and fortin++ |
| # | 14:31:05 | yboston | old business: phasefx porposed ... |
| # | 14:31:08 | danielR_ has joined #evergreen |
| # | 14:31:27 | yboston | starting an “official” and actively maintained list of things (software, hardware, etc.) compatible with EG? Policy for managing the list? |
| # | 14:31:41 | yboston | http://georgialibraries.markmail.org/thread/vd5nfg75fiyeu22o |
| # | 14:31:55 | berkleeintern_ has joined #evergreen |
| # | 14:32:25 | tspindler | yboston: i'm a little fuzzy on what he means, is this like EZ Proxy, envisionware etc.? |
| # | 14:32:31 | berkleeintern has quit IRC |
| # | 14:32:32 | yboston | Not sure if he is active on chat now, but his idea makes sense |
| # | 14:32:48 | berkleeintern_ has quit IRC |
| # | 14:32:53 | jenny | I like the idea...there is something like it here: http://evergreen-ils.org/dokuwiki/doku.php?id=faqs:evergreen_compatible_products_results_survey, but I don't know that it is "actively maintained" |
| # | 14:33:05 | yboston | tspindler: as I understand it if I start using a new kind of spine label printer |
| # | 14:33:07 | jenny | and it is pretty vague...his google form gets into more detail |
| # | 14:33:21 | enhancin has quit IRC |
| # | 14:33:43 | yboston | I would report to this Google form what model worked on what version of EG |
| # | 14:33:46 | danielR has quit IRC |
| # | 14:33:48 | fortin | jenny: that survey is not actively maintained. It's about two years old |
| # | 14:33:51 | tspindler | that makes sense then |
| # | 14:33:58 | fortin | definitely time for a new one :) |
| # | 14:34:03 | jenny | indeed! |
| # | 14:34:11 | KN2W has quit IRC |
| # | 14:34:44 | tspindler | is it something that we need to do a survey once a year ? |
| # | 14:34:58 | tspindler | or just ongoing? |
| # | 14:35:11 | yboston | that is one of the questiosn we phase |
| # | 14:35:21 | yboston | s/phase/face/ |
| # | 14:35:51 | kmlussier | If it's ongoing, it would be helpful to send out reminders on a regular basis. |
| # | 14:36:07 | kmlussier | So that it doesn't get stale like the last one. |
| # | 14:36:08 | jenny | perhaps put it somewhere that is visible? I think - and my memory is fuzzy on this - that the old survey was left open for quite a while, but you'd need to know to look for it. |
| # | 14:36:22 | jenny | kmlussier++ |
| # | 14:37:01 | tspindler | could use the drupal survey module or webform, openils is on drupal right? |
| # | 14:37:22 | kmlussier | tspindler: no, it's dokuwiki |
| # | 14:37:28 | yboston | I believe phasefx was hoping that DIG members would recap the raw form data and create a basic report to be added as an index to each new version of the docs we put out |
| # | 14:37:30 | tspindler | nm |
| # | 14:38:07 | tspindler | yboston: so documentation for 2.2 might show what people are using with 2.2? |
| # | 14:38:15 | yboston | sorry, I meant to say appendix not index |
| # | 14:38:39 | yboston | tspindler: correct |
| # | 14:38:53 | tspindler | makes sense, more timely and valuable that way |
| # | 14:39:29 | kmlussier | Looks like the old survey could only be found through the FAQ page. I wonder where a good fit would be on the web site. |
| # | 14:40:09 | yboston | In the interest of time, perhaps we should continue this topic on the mailing list and/or the next meeting |
| # | 14:40:25 | jenny | Maybe linked on the documentation site? and/or near the client downloads for each version? Just throwing out a few places I might either look for it or notice it. |
| # | 14:40:26 | yboston | but I think we are making progress on this suggestion |
| # | 14:41:38 | raynerj1 | I think we're looking for - where to put a survey on the web site, how to publicize it, guidelines on what info to collect, and someone to prepare a report. |
| # | 14:41:40 | KN2W has joined #evergreen |
| # | 14:42:09 | jenny | raynerj1: good summary. |
| # | 14:42:25 | GayashanNA has quit IRC |
| # | 14:42:31 | yboston | very good |
| # | 14:42:37 | fortin | raynerj1:++ |
| # | 14:42:41 | tspindler | raynerj1++ |
| # | 14:43:06 | raynerj1 | Maybe a proposal for that to send to the group for comments? |
| # | 14:43:11 | raynerj1 | I can do that |
| # | 14:43:27 | tspindler | raynerj1++ |
| # | 14:43:29 | jenny | raynerj1++ |
| # | 14:44:11 | yboston | Would it be OK to switch to conference related discussions? |
| # | 14:44:41 | raynerj1 | conference++ |
| # | 14:45:02 | yboston | Here is the current suggestions for the meeting agenda http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_meeting |
| # | 14:45:47 | tspindler | how long do we have? |
| # | 14:46:14 | jenny | 1.5 hours? |
| # | 14:46:25 | yboston | I will be facilitating the meeting, and I wondered if I focus more on welcome new people or working on ongoing DIG topics, or both? |
| # | 14:46:47 | yboston | jenny: yes an hour and a half |
| # | 14:46:54 | kmlussier | 1-2:30 |
| # | 14:47:18 | tspindler | it might be nice to try and rope in more content coordinators |
| # | 14:47:26 | yboston | there is also a "break time" right after our meeting |
| # | 14:49:11 | yboston | I will take into consideration if the meeting is only attended by veteran DIG members, that I can focus more on our current topics |
| # | 14:49:49 | yboston | but if we have a large number of non-DIG members I can focus more on recruiting |
| # | 14:49:59 | tspindler | yboston++ |
| # | 14:50:35 | kmlussier | I would prefer to see more documentors to content coordinators. But any additional volunteers will be appreciated! |
| # | 14:50:41 | jenny | If the meeting is heavily veterans, but there are a few newbies, will someone else be there that could move to the side with the newbies to give them an intro? |
| # | 14:50:56 | jenny | kmlussier: I agree |
| # | 14:51:34 | tspindler | kmlussier++ |
| # | 14:52:19 | yboston | I can work with the newvies, but the veterans would need their own facilitator |
| # | 14:52:52 | yboston | also, my ASCIIDoc presentation would apply to both veterans and newbies |
| # | 14:53:03 | kmlussier | This is where I'm confused. Will the hackfest be happening at the same time, and, if so, is this where the veterans will be? |
| # | 14:53:14 | kmlussier | I should say the documentation hackfest. |
| # | 14:53:36 | jenny | the documentation hackfest and the interest group are usually the same thing, I think |
| # | 14:53:52 | tspindler | that's what i was thinking |
| # | 14:54:13 | jenny | http://evergreen2012.org/schedule/ there is a general hackfest and a doc interest group |
| # | 14:54:43 | kmlussier | Yeah, I know the general hackfest is for the developers. But I also thought we were setting aside time to work on documentation. |
| # | 14:55:01 | yboston | kmlussier: officially we have an hour and a half assigned to DIG |
| # | 14:55:10 | tspindler | it might be good to have the ascii docs presentation before the voluntters on the agenda |
| # | 14:55:27 | jenny | I think we'd discussed using some/all of the interest group time for that...or have one group do that and another do the intro...or... |
| # | 14:56:32 | jenny | (my comment was for the hackfest). tspinder: good thought. |
| # | 14:56:38 | kmlussier | Last year, I think the plan was to do docuementation after a short meeting, but the meeting took up all the interest group time. I'm just worried the same thing might happen again. |
| # | 14:56:40 | yboston | but I wanted to crash the developer hackfest area or pick our own spot somewhere else during the rest of the hackfest day to work on documentation. then we would officially get together from 1-2:30 |
| # | 14:56:48 | tspindler | 1. intro, 2. what does dig do, 3. ascii docs 4. volunteers |
| # | 14:57:27 | rsoulliere | My hope would be a general meeting/intro and then break into groups of interest. Newbies can join smaller groups (mentoring opportunity) |
| # | 14:58:04 | jenny | mentoring++ |
| # | 14:58:06 | fortin | rsoulliere++ |
| # | 14:58:10 | tspindler | i agree, i think it partly depends on the attendence level |
| # | 14:58:52 | kmlussier | So 5 would be small groups/mentoring/documenting? Works for me. |
| # | 14:59:31 | raynerj1 | I agree++ |
| # | 14:59:49 | rsoulliere | The challenge, as mentioned, is getting through the intro part with enough time for hacking in groups. ;-) |
| # | 14:59:51 | kmlussier | And those who want to can do what yboston plans to do? i.e. crash the developer hackfest (or find another spot) and document there. |
| # | 15:00:52 | yboston | so far I see this as a rough outline: 1. intro, 2. what does dig do, 3. ascii docs 4. volunteers 5. small groups/mentoring/documenting |
| # | 15:01:03 | tspindler | ybost++ |
| # | 15:01:21 | jenny | yboston++ |
| # | 15:01:35 | yboston | that means that we could use people to volunteer if we have multiple groups formed at the end. |
| # | 15:01:41 | yboston | content coordinators in attendance? |
| # | 15:01:51 | tspindler | yboston++ |
| # | 15:02:03 | kmlussier | yboston++ |
| # | 15:02:26 | rsoulliere | yboston++ would be great to have content coordinators lead the groups. |
| # | 15:02:44 | Gentlecat has joined #evergreen |
| # | 15:02:50 | alexlazar has joined #evergreen |
| # | 15:02:58 | jenny | not me...have to facilitate the Reports IG at the same time. But I will look for volunteers for documentation there! |
| # | 15:03:10 | yboston | also, if we run out of allotted meeting time, there is a break right after |
| # | 15:03:28 | yboston | for those that can stay a bit longer |
| # | 15:04:10 | yboston | I also will send out an email asking for volunteers to meet up in the earlier hours of the hackfest to try to chip away at something that morning |
| # | 15:04:20 | fortin | I can't help this time as I'm just back from maternity leave and won't be at the Evergreen conference this year. It sounds like it will be a great session. |
| # | 15:04:21 | kmlussier | I'm not attending any of the late afternoon interest group meetings, so I think I'll just keep working on documentation for the rest of the afternoon. |
| # | 15:04:45 | raynerj1 | I'm planning on that also |
| # | 15:04:46 | kmlussier | fortin++ Congrats! |
| # | 15:04:46 | yboston | Note: we have reached the 1 hour mark |
| # | 15:04:52 | fortin | thank you! |
| # | 15:04:54 | yboston | congrats |
| # | 15:05:21 | tspindler | fortin++ |
| # | 15:05:23 | kmlussier | yboston: I just wanted to mention something about the DIG hackfest ideas page http://evergreen-ils.org/dokuwiki/doku.php?id=evergreen-docs:dig_hackfest |
| # | 15:05:36 | fortin | yboston: when you're ready to wrap up, let me know and I will paste the link to the asciidoc |
| # | 15:06:09 | kmlussier | It didn't occur to me until about a week ago, but in addition to thinking about new documentation, we also need to manually convert all of the existing docs to asciidoc. Is that right? |
| # | 15:06:43 | yboston | yes, but we should eliminate sections that do not apply to the newer versions :( |
| # | 15:07:11 | kmlussier | Yes, but there are some sections that can be moved up, but it just didn't click with me that those would need some care and feeding as well. |
| # | 15:07:56 | tspindler | i think some can be reordered but the copy doesn't necessarily need to be rewritten |
| # | 15:08:39 | yboston | stepping back, I suspect our conference goals should be get new volunteers, introduce ASCIIDoc to all, and try to work face to face on documentation??? |
| # | 15:08:51 | kmlussier | No, I wasn't thinking it needed to be rewritten, but it does take a little time to put it in asciidoc. |
| # | 15:09:37 | kmlussier | yboston: sounds about right to me. |
| # | 15:10:19 | yboston | should we wrap up for today? |
| # | 15:10:21 | denials is Dan Scott, Laurentian, and he just posted a long-delayed response to rsoulliere's question about release notes & readme & upgrade doc single-sourcing at http://markmail.org/message/5rym5hmrlezpbuzz |
| # | 15:10:52 | denials | Doesn't need to be discussed today, but I didn't want to let that thread dangle any longer than I already had |
| # | 15:11:37 | kmlussier | denials++ |
| # | 15:11:39 | rsoulliere | denials++ |
| # | 15:12:02 | yboston | that ties in nicely with our only "new business" agenda item about the role of the DIG release coordinators, but I think we should postpone that until next meeting??? |
| # | 15:12:13 | fortin | The link to the asciidoc and html formats of the 2.2 documentation that I posted earlier is: http://www.esilibrary.com/esi/availableDocs.php |
| # | 15:12:27 | kmlussier | fortin++ |
| # | 15:12:44 | fortin | The new docs in this list are: Auto_Suggest_in_Catalog_Search |
| # | 15:12:52 | fortin | Copy_Location_Groups |
| # | 15:12:55 | jenny | fortin++ |
| # | 15:13:00 | fortin | Line_Numbers_for_Display_Screens |
| # | 15:13:05 | fortin | SMS_Text_Messaging |
| # | 15:13:11 | fortin | Target_Copies_for_Holds_at_Closed_Libraries |
| # | 15:13:19 | fortin | Vandelay_Integration_into_Acquisitions |
| # | 15:13:39 | fortin | I'll post more docs as they're completed |
| # | 15:13:51 | yboston | fortin++ |
| # | 15:14:00 | rsoulliere | fortin++ |
| # | 15:14:15 | jeff | i have a question about the images in the asciidoc files -- for example, image::/esi/docs/wp-content/uploads/2012/03/SMS_Text_Messaging13.jpg[SMS_Text_Messaging13] |
| # | 15:14:37 | jeff | i suppose a simple search/replace would do there, but are there plans to make the urls public-facing by default? |
| # | 15:15:08 | yboston | jeff: let me wrap up the meeting first if that is OK |
| # | 15:15:13 | jeff | actually, nevermind me. they're relative to the doc location. http://www.esilibrary.com/esi/docs/wp-content/uploads/2012/03/SMS_Text_Messaging13.jpg works. |
| # | 15:15:22 | msmith1 has joined #evergreen |
| # | 15:15:25 | jeff | yboston: sorry, didn't mean to interject! |
| # | 15:15:34 | yboston | no problem at all :) |
| # | 15:15:55 | yboston | any final thoughts before we wrap up? |
| # | 15:17:11 | yboston | well thanks everybody, have a great day! |
| # | 15:17:15 | jenny | yboston++ |
| # | 15:17:23 | rsoulliere | yboston++ |
| # | 15:17:33 | fortin | yboston++ |
| # | 15:17:40 | kmlussier | yboston++ |
| # | 15:17:44 | kmlussier | See you all at the conference! |
| # | 15:17:45 | tspindler | yboston++ |
| # | 15:17:55 | raynerj1 | yboston++ |
| # | 15:18:40 | msmith1 has left #evergreen |
| # | 15:19:03 | rsoulliere has quit IRC |
| # | 15:23:31 | enhancin has joined #evergreen |
| # | 15:25:34 | enhancin | I'm having a fun issue with Serial Control. When I go into Alternate Serial Control and click Make Predictions, it sits for a minute and then brings up an error "Can't call method \"strftime\" on an undefined value at /usr/local/share/perl/5.10.1/OpenILS/Application/Serial.pm" and when I go into the normal Serial Control and click New Subscription and it brings up the box but the Owning Library dropdown is empty and says anything |
| # | 15:29:04 | tsbere | http://tomtrunk.mvlcstaff.org/eg/opac/advanced :D |
| # | 15:29:09 | tsbere pokes kmlussier ^ |
| # | 15:29:32 | tsbere pokes berick too, for that matter, if he wants to look |
| # | 15:29:49 | tsbere | I also found an issue with the coded value map selector generator and fixed it while I was in there >_> |
| # | 15:36:11 | kmlussier | Probably more of a quibble with MARC than with tsbere, but will an average user know what general is? |
| # | 15:36:34 | kmlussier is not sure I know what general means. :-P |
| # | 15:37:53 | tsbere | kmlussier: I stole the basic entries from JSPac, but didn't check what the language strings say. >_> |
| # | 15:38:07 | tsbere | kmlussier: Given that they won't exist at all by default normally I am not too concerned either ;) |
| # | 15:39:14 | kmlussier | Aside from my quibbling, tsbere++. I'm sure I know some other people who will like the idea of grouping them. |
| # | 15:39:59 | kmlussier | tsbere: Will this just be a local customization then? |
| # | 15:40:20 | tsbere | kmlussier: Getting ready to force push a rebased branch. |
| # | 15:40:28 | jamesk41 has quit IRC |
| # | 15:40:47 | kmlussier | tsbere++ |
| # | 15:41:20 | jamesk41 has joined #evergreen |
| # | 15:43:26 | shopkins has joined #evergreen |
| # | 15:43:56 | tsbere should probably test something quick |
| # | 15:49:39 | tsbere | kmlussier: https://bugs.launchpad.net/evergreen/+bug/968556 |
| # | 15:49:39 | pinesol_green | Launchpad bug 968556 in Evergreen "TPac shows too many MARC field values" (affected: 1, heat: 6) [Wishlist,New] |
| # | 15:51:33 | tsbere points berick at that LP entry in case there are complaints about how he did it ^^^ |
| # | 15:52:38 | shopkins has quit IRC |
| # | 15:53:20 | tspindler has quit IRC |
| # | 15:56:41 | enhancin | Aparently in line 933 is where it is occuring which is the line : $issuance->date_published($prediction->{date_published}->strftime('%F')); |
| # | 15:56:50 | enhancin | Apparently the date_published is returning an undefined value... |
| # | 15:56:56 | KN2W has quit IRC |
| # | 16:06:28 | Neil__ has joined #evergreen |
| # | 16:06:42 | raynerj1 has left #evergreen |
| # | 16:09:08 | jenny has quit IRC |
| # | 16:09:56 | tsbere | Heh, looks like some of the "this is likely pure spam" proposals on GSoC were sent to other orgs. I suspected that would be the case. |
| # | 16:11:02 | kmlussier | Just realized there was no mention of a future dev meeting date at the last dev meeting. Is there interest in another dev meeting before the conference? |
| # | 16:11:19 | kmlussier won't be around the week before the conference, but is happy to schedule something. |
| # | 16:13:03 | denials | Easter Monday? |
| # | 16:13:34 | tsbere is likely building a beta2 then |
| # | 16:14:45 | Gentlecat has quit IRC |
| # | 16:15:15 | denials strongly hopes to have finished upgrading their test server to -beta1 by then, won't be able to get any useful testing feedback from anyone though |
| # | 16:19:11 | Dyrcona1 has joined #evergreen |
| # | 16:19:21 | Dyrcona1 has quit IRC |
| # | 16:22:55 | serg has joined #evergreen |
| # | 16:23:11 | serg | hello |
| # | 16:23:23 | akilsdonk has quit IRC |
| # | 16:23:27 | serg is now known as Guest39733 |
| # | 16:25:03 | enhancin | anyone have an idea why the prediction->{date_published} would be returning an undefined value, and maybe a way to fix it? |
| # | 16:28:00 | Dyrcona has quit IRC |
| # | 16:31:52 | Dyrcona has joined #evergreen |
| # | 16:36:02 | Guest39733 has quit IRC |
| # | 16:36:03 | phasefx | a line like this in publisher/asset.pm, $call_number->record->fixed_fields( $cn->record->record_descriptor->next->to_fieldmapper ); what is that ->next? an iterator? |
| # | 16:40:19 | collum has quit IRC |
| # | 16:46:20 | bshum | Question |
| # | 16:46:42 | bshum | Should our Evergreen db be using evergreen.is_json function? Ours is apparently public.is_json...? |
| # | 16:47:36 | bshum | And that breaks senator's fix for bug 974410 for us |
| # | 16:47:36 | pinesol_green | Launchpad bug 974410 in Evergreen 2.2 "Avoid upgrade error with serial.materialize_holding_code()" (affected: 2, heat: 10) [Medium,New] https://launchpad.net/bugs/974410 |
| # | 16:47:46 | bshum | I'm trying it again without the specific evergreen.is_json and just doing is_json |
| # | 16:48:19 | jamesk41 | Well, goodbye everyone! Thanks for the advice! |
| # | 16:48:52 | jamesk41 has quit IRC |
| # | 16:48:54 | phasefx | bshum: if you don't specify, it'll use whichever comes first in the search_path, evergreen or public. I think the move was from public to evergreen |
| # | 16:49:12 | phasefx | so evergreen.is_json should be the right one |
| # | 16:49:50 | bshum | Well, I'm not sure when that move was made, but I guess our system doesn't have it yet :S |
| # | 16:50:55 | tsbere | phasefx: is_json was created in public in older versions, so upgrades have a public copy, not an evergreen copy ... so upgrade scripts should probably not schema-qualify it. |
| # | 16:51:21 | denials | bshum: it will move to evergreen.is_json as part of the 2.1-2.2 upgrade script IIRC |
| # | 16:51:50 | bshum | denials: Eh, doesn't seem to, unless I'm doing something really wrong here. |
| # | 16:51:55 | denials | bah, it doesn't |
| # | 16:52:25 | denials says "huzzah" as the 2.1-2.2 upgrade completes after 485 minutes |
| # | 16:53:22 | bshum | denials: Whoo! |
| # | 16:53:29 | bshum | I'm starting the process again for the third time today :) |
| # | 16:53:59 | bshum | Upside, I'm getting a good idea of how long it takes before it fails |
| # | 16:56:22 | tsbere | phasefx: Gonna be honest, I dunno what that next is. <_< |
| # | 16:57:37 | tsbere is curious now |
| # | 16:57:58 | phasefx | me neither. the hold targeter is calling open-ils.storage.asset.call_number.ranged_tree for a volume hold, and getting a null from that ->next, and thus crapping out on the subsequent ->to_fieldmapper |
| # | 16:59:02 | phasefx | s/null/undefined/ |
| # | 17:02:10 | denials | it's only been there since 2006. |
| # | 17:02:37 | denials | give it a chance to settle in |
| # | 17:03:03 | tsbere votes to poke eeevil about it as a result, see if he knows |
| # | 17:04:51 | tsbere | Looks failry common in publisher stuff, but I can't find where it is defined. MFHD seems to have a sub next that would explain the use there. |
| # | 17:04:54 | tsbere | er |
| # | 17:04:57 | tsbere | fairly |
| # | 17:05:11 | tsbere | although if it is invalid I might have been right the first time. <_< |
| # | 17:05:44 | kmlussier has left #evergreen |
| # | 17:07:10 | denials | heh |
| # | 17:07:29 | tsbere wonders if it was something that slipped in from the C code, where ->next is fairly common to get the next thing |
| # | 17:08:00 | denials goes home |
| # | 17:11:02 | yboston has quit IRC |
| # | 17:14:08 | phasefx | so I guess that code needs to be robustified, however ->next works, since fixed_fields is "might_have" and not "has_a" |
| # | 17:14:46 | phasefx | no, brain fart |
| # | 17:15:17 | tsbere | If ->next does anything I would expect it to be "grab the first array member" but I can't find anything that SAYS that..... |
| # | 17:16:29 | phasefx | I don't know how it goes from ->record to ->record_descriptor, there is no field for bre called that, though there are linked fields that point to mrd's |
| # | 17:18:36 | tsbere | phasefx: I suspect that most/all ->next are supposed to be ->[0] on the publisher front. |
| # | 17:19:00 | phasefx | tsbere: that sounds plausible |
| # | 17:19:21 | tsbere | phasefx: And assuming "we got an array back with at least one value" like that is, IMO, bad.... |
| # | 17:19:59 | phasefx | the bib for this problem hold apparently is missing a metabib.rec_descriptor |
| # | 17:20:06 | tsbere bets Dyrcona would agree with him on the "don't assume you got something" front <_< |
| # | 17:20:56 | Dyrcona agrees most strenuously. |
| # | 17:21:23 | phasefx | thanks guys |
| # | 17:23:32 | senator | that ->next comes from Class::DBI, for what it's worth |
| # | 17:24:12 | senator enters the conversation very late, and then leaves for now :-/ |
| # | 17:25:44 | phasefx | senator++ |
| # | 17:26:16 | tsbere wishes it were easier to find docs on that |
| # | 17:30:01 | danielR_ has quit IRC |
| # | 17:30:19 | Dyrcona has quit IRC |
| # | 17:30:19 | denials | abstractions on abstractions |
| # | 17:31:05 | denials peers at http://laurentian-test.concat.ca/eg/opac/record/690820?query=philosophy%20journal;qtype=keyword;locg=105;detail_record_view=1 and notes that we have some work to do to fix up the style of the optional stuff in config.tt2 to match current design |
| # | 17:31:15 | denials really goes home |
| # | 18:13:11 | finnx has joined #evergreen |
| # | 18:20:01 | alexlazar has quit IRC |
| # | 18:26:33 | fortin has quit IRC |
| # | 21:13:45 | StephenGWills has quit IRC |
| # | 21:33:55 | Neil__ has quit IRC |
| # | 22:46:58 | thethomaseffect has quit IRC |
| # | 22:47:13 | thethomaseffect has joined #evergreen |
| # | 23:00:01 | Lasindu has joined #evergreen |
| # | 23:00:43 | Lasindu | helo |
| # | 23:01:35 | Lasindu | I was looking forward to make an android app for Evergreen |
| # | 23:01:55 | Lasindu | Now I'm trying to submit a proposal |
| # | 23:02:56 | Lasindu | can I have some of the ideas from mentors |
| # | 23:20:56 | thethomaseffect has quit IRC |
| # | 23:26:24 | finnx has quit IRC |
| # | 23:48:18 | Neil__ has joined #evergreen |
| # | 23:49:36 | Neil__ has joined #evergreen |
| # | 23:58:26 | mostlyharmless26 has joined #evergreen |
April 10-13