cvs.savannah.nongnu.org:/sources/koha co -r rel_2_2 koha← Previous day | Today | Next day → | Search | Index
All times shown according to UTC.
| Time | Nick | Message |
|---|---|---|
| 13:47 | kados | owen: so we've got this: |
| 13:47 | <!-- TMPL_LOOP NAME="facets" --> | |
| 13:47 | <li><a href="<!-- TMPL_VAR NAME=link -->"><!-- TMPL_VAR NAME="label" --></a>(<!-- TMPL_VAR NAME="count" -->)</li> | |
| 13:47 | <!-- /TMPL_LOOP --> | |
| 13:47 | the inner facets loop | |
| 13:47 | I'll just add a new var there | |
| 13:47 | called 'class' | |
| 13:47 | so you can wrap each <li> in a span | |
| 13:47 | with a class of 'class' | |
| 13:48 | or just do <li class=<!-- TMPL_VAR NAME="class" -->> | |
| 13:48 | etc. | |
| 13:48 | owen | Right |
| 13:48 | kados | and you have a css rule |
| 13:48 | for the hidden class | |
| 13:48 | owen | And the script passes "class" as visible or not based on... |
| 13:48 | kados | yea |
| 13:48 | then you have a link below | |
| 13:49 | that lets you unhide them | |
| 13:49 | using js | |
| 13:49 | will that work? | |
| 13:50 | owen | possibly |
| 13:50 | I'm thinking it gets tricky when you try to re-hide. | |
| 13:51 | kados | hmmm |
| 13:51 | ncsu doesn't have that option | |
| 13:51 | :-) | |
| 13:51 | owen | Do you have any knowledge of how the Pines folks are deciding what tech to require for their opac? Are they requiring javascript? |
| 13:52 | kados | yes, unfortunately |
| 13:52 | owen | So you do see that as a disadvantage. |
| 13:52 | kados | definitely |
| 13:52 | but it's an architectural decision | |
| 13:53 | they basically build the entire system to use an RPC framework | |
| 13:53 | s/build/built/ | |
| 13:54 | so any of the clients have to make multiple calls to the system to retrieve each element of data | |
| 13:54 | it's very scalable | |
| 13:54 | but requires RPC for every client | |
| 13:55 | they made some of the same mistakes Koha made along the lines of MARC in SQL and a few new ones :-) | |
| 13:55 | but every system has it's flaws | |
| 13:55 | anyway ... | |
| 14:02 | owen | NCSU doesn't have an un-hide option because they reload the page evertime someone clicks a 'more' link...so if someone clicks /another/ 'more' link the previously expanded section is contracted again. |
| 14:02 | kados | right |
| 14:02 | what do you suggest? | |
| 14:02 | owen | It gets sticky when you hide something with CSS and then try to show it with Javascript |
| 14:03 | People with no CSS will see everything anyway, so they're fine. | |
| 14:03 | kados | prefer a page reload? |
| 14:03 | owen | But people with CSS but no Javascript won't have a way to expand the tree |
| 14:03 | kados | right |
| 14:03 | you could test for js, then apply the hide only if they had js | |
| 14:04 | or a page reload is ok too | |
| 14:04 | btw: they are hidden now | |
| 14:05 | just let me know how you want to do it and I'll make it so :-) | |
| 14:05 | owen | I'm wavering... I guess I'm leaning towards a page reload. Partly because I'm starting to worry about the total page size with all those trees loaded automatically |
| 14:05 | kados | right |
| 14:05 | ok, lets do that then | |
| 14:06 | owen | What would you think of dropdowns for the "further limit search" options? |
| 14:06 | kados | how would that work? |
| 14:07 | owen | Instead of having a link that would limit search results to "Branch -> Chauncey," have a drop-down list that resubmits the query when you select a branch |
| 14:08 | kados | sounds like a good idea |
| 14:09 | kind of like ncsu's 'send search to'? | |
| 14:09 | owen | Yeah |
| 14:11 | kados | I'll add that right now too |
| 14:19 | owen: ok ... if you add expand=su to your cgi query, it will expand the subject list | |
| 14:19 | I'll add that as a link to the template | |
| 14:29 | owen: ok ... the 'Show More' is working for ccl queries and subjects | |
| 14:30 | owen | Cool |
| 14:49 | kados | ok, I think the expandable part is working with ccl queries and all three types of facets |
| 14:49 | wonder if we should give each of them an id and have that be the #link | |
| 14:52 | yea, that seems to work well | |
| 14:55 | ok, now there's a type and a typeid | |
| 14:56 | owen: committed | |
| 14:59 | owen: so the branch drop-down ... should that be where we allow the user to continue the search in worldcat, etc.? | |
| 15:00 | owen: or is it strictly a branch limit? | |
| 15:04 | owen | I was just thinking we could replace the little js tree with the branch limiters, content limiters, etc. |
| 15:04 | kados | js tree? |
| 15:04 | owen | The tigra menus you had before |
| 15:05 | I was just trying to think of an alternative solution that wouldn't involve pushing a list further down the screen | |
| 15:05 | kados | right |
| 15:05 | well ... | |
| 15:05 | I guess my assumption is that now that we've only got 5 of each facet displaying | |
| 15:06 | the new design will shrink the total height of the three facets we have now | |
| 15:06 | is that what you had in mind? | |
| 15:06 | (for instance, I like the size of worldcat's facets) | |
| 15:06 | then ... we could add some new facets ... | |
| 15:07 | I guess the question is, is the branch limit going to be a facet? or is it separate from the facets? | |
| 15:08 | I can whip it out in about 10 minutes ... we just need to decide how we want it to work | |
| 15:10 | owen | It could go either way. If the branch (content, audience, etc) limits are as "primary" as the subject, author, etc. limiters, then we should create new facets just like the existing ones. If they're a less-important feature then we could "compress" them into drop-down menus for brevity. |
| 15:10 | kados | seems like they're primary ones |
| 15:11 | to me anyway | |
| 15:11 | but I can see branch limits being separated | |
| 15:11 | owen | Yes--particularly if you can get those facets to reflect the contents of that particular result set |
| 15:11 | kados | yep, I can |
| 15:11 | owen | Yes to them being primary |
| 15:11 | kados | ok ... I'll just add them to the facets for now then |
| 15:12 | we can always change it later if we want | |
| 15:16 | owen | One thing we need to be careful about... |
| 15:17 | The subject, series, author links expand or re-focus the search... | |
| 15:17 | while the branch, content, audience links refine it | |
| 15:17 | kados | ahh ... good point |
| 15:17 | hmmm | |
| 15:18 | they should be visually separated I suppose | |
| 15:18 | any ideas? | |
| 15:18 | owen | If you can simply put the two sets into two different loops we'll be able to style them separately |
| 15:19 | kados | i guess one question is, _should_ the subject, series, author links limit or expand the search? |
| 15:19 | because at NCSU they limit it | |
| 15:19 | at worldcat too | |
| 15:19 | owen | Yeah... |
| 15:20 | Seems like we talked about this before | |
| 15:20 | kados | :-) |
| 15:20 | well ... | |
| 15:21 | is there any visual mechanism we can use to signal either inclusion or exclusion of the original search term? | |
| 15:22 | owen | Is it more important to offer the opac user a means of narrowing their search or of discovering more related information? |
| 15:22 | kados | good question |
| 15:23 | for the opac I think 'discovery' is better than 'limiting' in most cases | |
| 15:23 | but ... really both are useful | |
| 15:24 | owen | What if limiting is the default for facets, and discovery is an option that takes you away from your original result set? A new page with a full list of the facets that can be used to branch off the original search? |
| 15:25 | kados | hmmm |
| 15:25 | yea, it might be confusing | |
| 15:25 | well ... | |
| 15:26 | if we kept the facets as 'expand' and added the 'limits' somewhere else on the page | |
| 15:26 | would that work? | |
| 15:27 | owen | I'm leaning towards thinking that users expect to be able to narrow their results first |
| 15:28 | Think about how Amazon allows you take your original search term and look for it in a particular category (books, dvds, electrics, etc) | |
| 15:28 | kados | right |
| 15:28 | ok, so we limit then | |
| 15:29 | then all the facets can go together | |
| 15:29 | and maybe we could allow the user to [X] the original search term on the next page | |
| 15:29 | to expand the search using just the facet | |
| 15:29 | owen | I think that would be very cool |
| 15:30 | kados | alright ... give me a few minutes :-) |
| 15:38 | owen: have you started on a new design yet? | |
| 15:39 | owen | I've been working on tweks here and there |
| 15:39 | Actually, I'd like to talk it through with you again, because I wasn't taking good notes the last time we talked about it. | |
| 15:39 | kados | ok |
| 15:39 | well ... | |
| 15:39 | owen | I'm about to head out here, so it'll have to be later |
| 15:40 | kados | ok, we can chat about it tomorrow |
| 15:40 | maybe I'll even write up a spec :-) | |
| 15:41 | owen | Now that I'm out of Chauncey I can be a lot more flexible with my time. If you ever feel like we need to meet face to face it's a lot easier for me now to make that happen |
| 15:41 | kados | cool |
| 15:41 | yea, that might be useufl | |
| 15:41 | useful even | |
| 17:20 | chris: k ... back | |
| 17:20 | still no http tho :( | |
| 17:20 | chris | bummer |
| 17:20 | can u tunnel it thru ssh? | |
| 17:21 | kados | I should be doing that anyway :-) |
| 17:21 | chris | ud need a squid proxy set up somewhere :) |
| 17:21 | kados | using tor or sth |
| 17:21 | yea | |
| 17:21 | well strangely, I can't even open any _new_ ssh connections | |
| 17:21 | something funky going on with the local ISP I hink | |
| 17:21 | they're realy wankers :-) | |
| 17:22 | their official position is that 'viruses' are causing the wireless outages at this coffee shop :-) | |
| 17:24 | chris: http://wiki.koha.org/doku.php?[…]e#field_weighting | |
| 17:24 | chris: there's a brief explaination of what I need to do there ... my two options | |
| 17:24 | under 'how can I map a single search query (like title) to a pqf string like the above?' | |
| 17:25 | chris | sorry was on phone |
| 17:25 | looking now | |
| 17:28 | kados | there's this: http://search.cpan.org/irk/Net[…]r/SimpleServer.pm |
| 17:28 | which has something called an RPN tree | |
| 17:28 | which I've been trying to understand since I started with perl :- | |
| 17:28 | ) | |
| 17:29 | the basic problem is | |
| 17:29 | I have incoming cgi | |
| 17:29 | which I can pretty easily transform to CCL | |
| 17:29 | chris | right |
| 17:30 | kados | then I want to transform that CCL into PQF but it's not a one to one mapping |
| 17:30 | each leaf node will be branched | |
| 17:30 | to incorporate all the fancy field weighting | |
| 17:30 | chris | k |
| 17:31 | kados | so the CCL syntax in pretty simple: |
| 17:31 | http://indexdata.dk/yaz/doc/tools.tkl#CCL | |
| 17:31 | you basically have Operands and Operators | |
| 17:31 | and the Operands can be an either query | |
| 17:31 | s/either/entire/ | |
| 17:32 | chris | yep |
| 17:33 | kados | of course, the other option may actually turn out to be simpler ... just turn a PQF query into XML, parse it with a stylesheet, then turn it back into PQF |
| 17:35 | chris | hmmm |
| 17:35 | probably | |
| 17:35 | but perhaps slower | |
| 17:35 | altho probably more easily extensible | |
| 17:35 | kados | hmmm |
| 17:36 | slower isn't that bad I don't think | |
| 17:37 | since I can't imagine it would really slow things down that much ... given how fast the actual query is now | |
| 17:37 | chris | yep |
| 17:38 | so the idea is .. take you ccl made from your cgi | |
| 17:38 | convert to pqf | |
| 17:38 | convert to pqf - xml | |
| 17:39 | transform with xlst | |
| 17:39 | convert back to pqf (now with weightings) | |
| 17:39 | for idea 2? | |
| 17:40 | kados | well ... |
| 17:40 | mostly, yes | |
| 17:40 | though it begs the question, what's the point of using ccl in the first place | |
| 17:40 | chris | yep |
| 17:40 | cgi -> pqf | |
| 17:40 | pqf -> pqf-xml | |
| 17:40 | transform | |
| 17:40 | pqf-xml -> pqf | |
| 17:40 | run query | |
| 17:41 | kados | yea |
| 17:41 | I think it'll be more like: | |
| 17:41 | chris | that allows us to change the weightings |
| 17:41 | kados | 1. cgi -> kohaquerysyntax |
| 17:41 | chris | without havning to hack at our ccl parser |
| 17:41 | kados | kohaquerysyntax -> pqf |
| 17:41 | etc. | |
| 17:41 | chris | right |
| 17:41 | could we make kohaquerysyntax = openurl | |
| 17:42 | kados | this is frustrating though |
| 17:42 | hmmm | |
| 17:42 | does openurl have a fully-described query syntax? | |
| 17:42 | chris | not sure, i havent read about it properly, would be good if it did |
| 17:42 | kados | I doubt it does |
| 17:43 | chris | no worries then .. a openurl resolver isnt hard to write |
| 17:43 | kados | well what I've got |
| 17:44 | is something that looks like this: | |
| 17:45 | search?q=query&op=operator&offset=&count=&sort_by=&server | |
| 17:45 | q is repeatable | |
| 17:45 | as is op | |
| 17:45 | as is server | |
| 17:45 | as is sort by | |
| 17:46 | chris | right |
| 17:46 | kados | right now, q can be a valid CCL query |
| 17:46 | so you can do something like: | |
| 17:46 | q=su=cats and au=tom | |
| 17:46 | or you could go: | |
| 17:46 | q=su=cats&q=au=tom | |
| 17:47 | chris | k |
| 17:47 | well, i think the answer might be .. restrict the syntax the form/cgi can hand data back as | |
| 17:48 | kados | how so? |
| 17:49 | chris | if you are allowing a free text type in the query one, handle that with one cgi script |
| 17:50 | and for the other one, like the advanced search page, where you have an input for author, one for subject etc .. treat each input as a term, not a query | |
| 17:50 | kados | hmmm ... |
| 17:50 | well I like that idea | |
| 17:50 | but the problem is, the results page for both simple and advanced searches has to have the same options | |
| 17:51 | ie, facets, limits, resorting, query history, etc. | |
| 17:51 | hmmm | |
| 17:51 | chris | could that not be in the form of one input per term tho? |
| 17:52 | i think what im thinking is | |
| 17:52 | for the simple search we do a double parse | |
| 17:52 | first parse, convert it to the same syntax as the advanced search expects | |
| 17:52 | then deal with it the same | |
| 17:52 | kados | hmmm |
| 17:52 | chris | just thinking aloud |
| 17:53 | kados | sure |
| 17:53 | yea, that might work | |
| 17:54 | chris | could be a just a script that parses, and redirect to the script that does the search and displays the results |
| 00:16 | thd | kados: are you still up? |
| 02:23 | toins | hi all |
| 02:33 | hdl | hi |
| 04:30 | toins : paul est avec toi ? | |
| 04:30 | toins | non, il est allé faire des courses |
| 04:31 | hdl | OK. |
| 04:31 | toins | je pense qu'il sera la cet après midi. |
| 04:31 | hdl | kados ? |
| 04:31 | dewey | kados is becoming a true Perl Monger... |
| 06:09 | kados | hdl: I'm here |
| 06:11 | hdl: should I test your bugfixes to 1024/1025? | |
| 06:17 | hdl: I have a new problem, along with the old ones | |
| 06:17 | hdl: 'date expected' is not filled, but 'published on' is instead | |
| 06:17 | hdl: that is, the 'published on' date is filled with the expected date | |
| 06:18 | hdl: and another new prob: | |
| 06:19 | hdl: subscriptions are now listed like: | |
| 06:19 | ,Vol 1 No 1,Vol 2 No 2,Vol 3 No 3 | |
| 06:19 | so both Vol and No are incremented (the rules are set up properly) | |
| 06:19 | wait ... | |
| 06:19 | that may be my fault | |
| 06:24 | hdl: are you there? | |
| 07:16 | osmoze | hello #koha |
| 07:20 | hdl | kados : i am here |
| 07:22 | kados: now, dateexpected is not filled any longer since what is supposed to be calculated is the next issue date rather than the next reception. | |
| 07:22 | kados | hdl: are you working on serials bugs? |
| 07:22 | hmmm | |
| 07:22 | hdl | But we may discuss. |
| 07:22 | kados | yes, I think that's a problem |
| 07:22 | hdl | why. |
| 07:22 | kados | issue date means publication date? |
| 07:23 | hdl | kados : now, there are two dates. |
| 07:23 | publication date is one. | |
| 07:23 | receivedate is two. | |
| 07:23 | kados | ok |
| 07:23 | hdl | publication date is the most important for users. |
| 07:23 | So this is the one that is now calcultaed. | |
| 07:24 | kados | so as I described, currently, when you receive issues, the publication date is auto-calculated, not the receivedate |
| 07:24 | hdl | So this is the one that is now calculated. |
| 07:24 | kados | sigh |
| 07:24 | but that's a major function change | |
| 07:24 | it completely breaks any previous serials installation! | |
| 07:24 | hdl | If you like, I can copy the dates into both fields. |
| 07:25 | It also add a new column into the database !!!! | |
| 07:26 | kados | it should be an option in the series creation screen, 'calculate by pub date or by receive date' |
| 07:26 | yes, I upgraded using upgradedatabase, and the new column was added I believe | |
| 07:26 | hdl | yes. |
| 07:27 | you can esayliy update the data so that receivedate comes into publisheddate. | |
| 07:27 | kados | hdl: http://bugs.koha.org/cgi-bin/b[…]w_bug.cgi?id=1142 |
| 07:27 | hdl: a user contributed this bug report | |
| 07:27 | hdl: they were running on the previous version of serials | |
| 07:27 | hdl: and I upgraded them to rel_2_2 | |
| 07:28 | hdl: do plugins work with item adding and serials? | |
| 07:28 | hdl: s/and/in/ | |
| 07:29 | hdl | For me Yes. |
| 07:29 | on production | |
| 07:29 | kados | and acquisition date is filled? |
| 07:30 | hdl | That must be a preference or marc problem |
| 07:30 | kados | ?? |
| 07:30 | hdl: serials were working fine ... I upgraded them to rel_2-2, now they report bugs | |
| 07:31 | hdl: how is it a preference or marc prob? | |
| 07:31 | hdl | Did they use serialsitemization before ? |
| 07:31 | kados | no |
| 07:31 | hdl | They file bugs from itemization. |
| 07:32 | Have you tried to know how the code work ? Did you investigate how their frameworks look like ? | |
| 07:32 | My code | |
| 07:33 | is relying on framework as such. | |
| 07:33 | kados | same with me |
| 07:33 | hdl | It takes the items.barcode marc field, the items.note marc field and then fills them. |
| 07:34 | kados | so it doesn't consult the marc frameworks? |
| 07:34 | hdl | YES IT DOES. |
| 07:34 | kados | for plugins, etc.? |
| 07:34 | hmmm | |
| 07:34 | our plugins aren't working, for barcodes for instance | |
| 07:35 | hdl | pls donot mix all things. |
| 07:35 | let us focus on this bug. | |
| 07:35 | kados | ok, one bug at a time |
| 07:35 | hdl | They tell taht it doesnot update record. |
| 07:35 | OK ? | |
| 07:36 | What they have to know IS taht serialsitemization relies on frameworks. | |
| 07:36 | kados | hdl: of course, they already have frameworks for items set up |
| 07:36 | hdl: and the frameworks work fine in item editing | |
| 07:37 | hdl | It looks in the framework which marc field is linked to items.barcode, AND which marc field is linked to items.note |
| 07:37 | kados | hdl: but in serials, item editing doesn't use frameworks in rel_2_2 in either default or npl templates |
| 07:37 | ok | |
| 07:38 | hdl | since items.note SHOULD BE the place where the issue number is stored. |
| 07:38 | BUT.... | |
| 07:38 | Surely, most of the time, ppl donot use items.note. | |
| 07:38 | kados | ?? what do they use? |
| 07:38 | hdl | OR they may have linked it to more than one field. |
| 07:39 | (I assume that they use Note fields in bibliographic data.) | |
| 07:39 | kados | yes |
| 07:40 | hdl | So I think that THEIR problem comes from that. |
| 07:40 | kados | ?? |
| 07:40 | hdl | But without peering into their code, i cannot confirm. |
| 07:41 | kados | they don't use 'itemnotes' for bibliographic data |
| 07:41 | hdl | For serials itemization they MUST. |
| 07:41 | s/MUST/HAVE TO/ | |
| 07:41 | kados | but that is not the bug they are reporting |
| 07:42 | I agree that Vol. No is stored in itemnotes | |
| 07:42 | that is fine | |
| 07:42 | what is not fine is: | |
| 07:42 | 1. plugins don't work in the serials item editor | |
| 07:42 | 2. no barcode checking (for duplicates) | |
| 07:43 | 3. Serials is not adding a date to the record (acquisition date) | |
| 07:43 | hdl | it is not saving the |
| 07:43 | barcode information etc. to our record. Once again, it simply checks the issue | |
| 07:43 | in, but doesn't update our record. | |
| 07:43 | kados | barcode |
| 07:43 | hdl | They say :the problem I was speaking about. |
| 07:43 | kados | no ... barcode is stored in items.barcode, not items.note |
| 07:43 | ? | |
| 07:43 | hdl | Yes. |
| 07:44 | kados | so it's different |
| 07:44 | hdl | But I store a whole marcrecord. |
| 07:44 | I build it from the framework. | |
| 07:44 | And to store the number information, I HAVE to have a field. | |
| 07:45 | I took itemnotes field. | |
| 07:45 | kados | that is fine |
| 07:45 | hdl | If there are no itemnotes... |
| 07:45 | kados | they are fine with the number in itemnotes |
| 07:45 | that is not the bug they reported | |
| 07:45 | what they have a problem with is the other items fields aren't working | |
| 07:45 | for instance, a plugin for their barcode isn't working | |
| 07:46 | the acquisition date isn't available as a field | |
| 07:46 | (and no plugin for it of course) | |
| 07:46 | no warnings for duplicate barcodes | |
| 07:47 | manual issues don't save barcodes, etc. | |
| 07:47 | plus they don't like the display of the last 5 issues | |
| 07:47 | hdl: does that make sense now? | |
| 07:47 | hdl | No. |
| 07:48 | pls. | |
| 07:48 | calm down. | |
| 07:48 | kados | :-) |
| 07:48 | I'm calm | |
| 07:48 | hdl | does not seem. |
| 07:48 | kados | sorry ... |
| 07:49 | ok ... I will begin again | |
| 07:49 | hdl | plugin for acquisition |
| 07:49 | (let me go. | |
| 07:49 | ) | |
| 07:49 | kados | (OK) |
| 07:50 | hdl | plugin for acquisition was not asked and not coded. |
| 07:50 | kados | ahh ... |
| 07:50 | hdl | So if anyone fells like. |
| 07:50 | It's ok for me. | |
| 07:50 | plugin for itemization. | |
| 07:51 | It may go far further. But we can now manage the minimum. | |
| 07:52 | kados | (you mean serials itemization?) |
| 07:52 | hdl | yes. |
| 07:52 | kados | so you mean that if I have a plugin defined for the items.barcode MARC field (in biblio framework) it should work in serials check in? |
| 07:53 | hdl | taht is : barcode, location, branch, and status. |
| 07:53 | kados | (I have plugin defined for items.barcode, but it doesn't appear in the serials check-in) |
| 07:55 | hdl | I say taht if you have a Koha link defined for items.barcode, a Koha link for items.homebranch and items.holding, a Koha link for items.itemnotes, it should work. |
| 07:55 | kados | ahh ... so you mean it will save it in the MARC field linked to items.barcode |
| 07:56 | afaik, this works except for manual issues | |
| 07:57 | I just tested in default templates | |
| 07:57 | manual issue doesn't save item information to record | |
| 07:58 | hdl | ok. |
| 07:59 | THAT IS a bug. | |
| 07:59 | (will fix it now.) | |
| 08:00 | kados | hdl: i will file a new bug report |
| 08:00 | hdl | for ? |
| 08:00 | kados | for 'manual issue doesn't save item information to record' :-) |
| 08:01 | if it's fixed today we can close it | |
| 08:01 | just to keep track of bugs :-) | |
| 08:01 | slef | someone made a passing reference to mailing again about bug tracking... was it someone here and did they mail it? |
| 08:01 | kados | not me ... |
| 08:06 | slef | I conclude that I dreamt it. |
| 08:08 | hdl | kados : Is it ok for 1124 and 1125 ? Can I close them for good ? |
| 08:09 | kados : Have you understood what I told you for the bug filed by your client ? | |
| 08:09 | That they HAVE to have an items.itmenotes linked to a marc field. | |
| 08:10 | kados | hdl: it is linked |
| 08:32 | hdl: bug 1124 is fixed i think | |
| 08:32 | hdl: but for 1125, I think we need to create a syspref to show/hide the last 5 issues | |
| 08:35 | hdl: still there? | |
| 08:35 | dewey | there is a minor diff in <div>s, that I missed |
| 08:36 | hdl | yes. |
| 08:36 | kados | what do you think about my suggestion re:1125? |
| 08:38 | hdl | what do YOU think about designing a true serial management based on full-serial-issue |
| 08:38 | ? | |
| 08:38 | kados | how would it work? |
| 08:38 | hdl | It could allYou could have all issue on the page. |
| 08:38 | kados | hmmm |
| 08:38 | hdl | you could clik on an issue to modify it. |
| 08:39 | And you would have a table to add one. | |
| 08:39 | or the next expected one. | |
| 08:39 | kados | it's a good idea |
| 08:39 | but maybe we should have two pages: | |
| 08:39 | hdl | (table would be a div) panel. |
| 08:39 | kados | 1. for current expected/late issues |
| 08:40 | 2. for all issues | |
| 08:40 | hdl | what if they were gathered in a expected issues tab ? |
| 08:41 | kados | that would be ok |
| 08:41 | hdl | But THIS is a major change. |
| 08:41 | kados | (more than ok, great! :-)) |
| 08:41 | yep | |
| 08:41 | hdl | we may have to refer to katipo and paul as well. |
| 08:41 | When is the next meeting ? | |
| 08:41 | kados | katipo has their own serials module |
| 08:41 | hdl | Could it be on agenda ? |
| 08:41 | kados | they are ok with any change you make |
| 08:42 | as it doesn't affect them :-) | |
| 08:42 | is paul around now? | |
| 08:42 | (I'm not sure about next meeting, maybe tomorrow?) | |
| 08:43 | hdl: something else to consider: I think for serials itemization to work for my clients, they will need: | |
| 08:43 | 1. all item.* data avaialble | |
| 08:44 | 2. plugins to work | |
| 08:44 | otherwise, itemization won't be possible for them as they require all items to have all fields (in some cases) and some fields, like barcode, rely on a specific plugin | |
| 08:46 | hdl | kados : the problem is that relying on items table is not satisfactory for ppl. since they would like to input all the items data for serials on the same page. |
| 08:47 | kados | hmmm |
| 08:47 | hdl | But since we rely on koha items table, all the item subfields cannot be used. (I supposed when I coded that Katipo would use that code.) |
| 08:47 | kados | I don't understand completely |
| 08:47 | what if we had two columns: | |
| 08:47 | hdl | A second problem would be to keep up the link with items. |
| 08:47 | kados | 1. for serials information |
| 08:48 | 2. for items information | |
| 08:48 | when an item was checked in a library can fill out both columns | |
| 08:48 | or just the serials one | |
| 08:48 | saving an issue would mean: | |
| 08:49 | 1. creating an item (using item column) | |
| 08:49 | 2. working the subscription magic | |
| 08:50 | hdl | some information (serialseq for instance) you input for an issue ppl donot want to input it twice for an item. |
| 08:51 | kados | right |
| 08:51 | does it have to be? | |
| 08:52 | serialseq is in the serials table, right? | |
| 08:52 | not items table? | |
| 08:52 | hdl | you have to know which marc field to put serialseq |
| 08:52 | kados | ahh |
| 08:52 | hdl | It is duplicated in items.itemnotes. |
| 08:52 | kados | and now it's in item.notes |
| 08:52 | duplicated? | |
| 08:52 | hmmm | |
| 08:53 | hdl | the information is both in items.itmenotes and serial.serialseq |
| 08:53 | kados | ahh, ok |
| 08:53 | that's ok by me | |
| 08:54 | hdl | And we have no other link between items and serial but serialseq |
| 08:54 | kados | hmmm |
| 08:54 | itemnumber is not stored in the serials table? | |
| 08:55 | wow ... so if you delete a subscription, it doesn't delete the items? | |
| 08:55 | hdl | not yet. need a new column. |
| 08:55 | Unfortunately. | |
| 08:55 | But if you delete a subscription. | |
| 08:55 | You keep the items. | |
| 08:56 | kados | hmmm |
| 08:56 | I worry that this serials module is not ready for a stable system | |
| 08:56 | is it sponsored by one of your libraries? | |
| 08:57 | hdl | when you unsubscribe a list, you keep tracks of the emails you received. Same for items received. |
| 08:57 | IEP Lyon is now using it. | |
| 08:58 | kados | so they didn't notice all the bugs? |
| 08:58 | hdl | They are on vacation. |
| 08:59 | kados | :-) |
| 08:59 | before vacation, they were using it? | |
| 08:59 | hdl | I set it up on late june. |
| 09:00 | kados | did they perform an acceptance test on it before they went on vacation? |
| 09:00 | hdl | yes. |
| 09:00 | All went wel. | |
| 09:00 | kados | is the cvs version the same as Lyon's version? |
| 09:04 | hdl | not yet. |
| 09:04 | I coded serials itemization for them. | |
| 09:05 | kados | hdl: can you update cvs to be bug-free like Lyon's version is? |
| 09:06 | hdl | There are the same bugs as you detected them. |
| 09:06 | But their base was OK. | |
| 09:06 | kados | their base? you mean the database? |
| 09:06 | hdl | Yes. |
| 09:06 | kados | what do you mean it was 'OK'? |
| 09:07 | hdl | It was well aranged so that items were created. |
| 09:08 | kados | so manual issues work for Lyon? |
| 09:08 | items are created? | |
| 09:08 | hdl | I hope so. |
| 09:09 | kados | you haven't tested? |
| 09:09 | hdl | I had tested. |
| 09:10 | But it is long ago. And I had to modify things so taht dates were well displayed. | |
| 09:10 | then i did not retest EVERY thing. | |
| 09:14 | kados | hdl: do you think Lyon will notice the bugs that exist for serials in rel_2_2? |
| 09:19 | hdl | about acquisition history bug. I cannot reporduce it myself. |
| 09:24 | kados | hdl: which bug number? |
| 09:24 | 1136? | |
| 09:27 | hdl | yes. |
| 09:33 | qiqo | ei anybody awake? |
| 09:34 | hdl | kados : about 1136 : can you try a hsit search commenting lines 790 and 821 in C4/Acquisition.pm |
| 09:34 | to see if histsearch can provide you with data. | |
| 09:34 | kados | hdl: first i try to acquisition something ... can't get it to work :( |
| 09:34 | qiqo | i would just want to ask about printing barcodes |
| 09:35 | when i generate the barcodes i get other numbers other than what i assigned to a monograph | |
| 09:36 | what may seem to be the problem? | |
| 09:37 | kados | hdl: ok, histsearch seems to work now |
| 09:38 | hdl: some columns are missing, but i can detail them later | |
| 09:38 | maybe it shows received and non-received items in the history? | |
| 09:38 | hdl | kados : have you change sthg in histsearch ? |
| 09:38 | yes. | |
| 09:38 | kados | hdl: no ... I think paul's commit to Acquisitions must have fixed it |
| 09:39 | (maybe the problem was simply that I couldn't acquisition anything in the first place) | |
| 09:39 | (before) | |
| 09:39 | so we can close bug 1136 I think | |
| 09:46 | qiqo | ermm.. |
| 09:49 | anybody who could help me with the barcode printing stuff? | |
| 09:49 | kados | qiqo: what barcodes system are you using? |
| 09:49 | qiqo: what version of Koha, etc.? | |
| 09:49 | qiqo | 2.2.5 |
| 09:49 | barcode system? | |
| 09:49 | kados | barcodes on 2.2.5 is broken badly |
| 09:49 | it doesn't work | |
| 09:49 | qiqo | ahh man... |
| 09:50 | kados | there is a new system that will be in 2.2.6 |
| 09:50 | that works very well | |
| 09:50 | qiqo | so what version do you suggest? |
| 09:50 | when will that be out? | |
| 09:50 | kados | 2.2.6 should be out very soon |
| 09:50 | qiqo | you thing 2.2.4 is ok with barcodes? |
| 09:50 | kados | nope |
| 09:50 | qiqo | how bout updating 2.2.5's barcode via cvs? |
| 09:51 | kados | yep, that will work |
| 09:51 | qiqo | you think that''ll fix my problem? |
| 09:51 | kados | it should help |
| 09:51 | I have three libraries using the new barcodes system in production | |
| 09:51 | and it's working well for them | |
| 09:51 | qiqo | cus i already install 2.2.6rc2 and i also got the same problem |
| 09:51 | you think cvs got the new barcode system? | |
| 09:52 | kados | yea, IIRC the install script for 2.2.6rc2 doesn't create the table properly for the new barcode system |
| 09:52 | qiqo | so what shall I do |
| 09:52 | kados | yea, cvs definitely does |
| 09:52 | qiqo | sorry im not really that familiar with cvs |
| 09:52 | kados | one thing ... |
| 09:52 | qiqo | but i already downloaded the cvs |
| 09:52 | but dont know what to do now | |
| 09:52 | kados | the new system currently requires a specific barcode/spine label |
| 09:52 | it's the gaylord 8851 | |
| 09:53 | we're working on a more flexible system that won't appear in 2.2.6 | |
| 09:53 | qiqo | ei.. will i just overwrite the files from cvs/barcode to the current/barcode? |
| 09:53 | kados | but will be in 2.4 and 3.0 |
| 09:53 | no | |
| 09:53 | qiqo | what shall i do? please tell me.. |
| 09:53 | kados | unless you're using gaylord 8851, I think you'll need to print barcodes outside of Koha |
| 09:54 | unless you want to sponsor development of this feature | |
| 09:54 | I'm sorry :( | |
| 09:54 | qiqo | so i wont be able to use the barcode system? |
| 09:54 | kados | Koha 2.2.6 will be different -- no advertised features that don't work |
| 09:54 | qiqo | ever? unless i look for a sponsor |
| 09:54 | kados | you will be able to use the barcode system in 2.4 and 3.0 |
| 09:55 | qiqo | i badly need the feature right now.. |
| 09:55 | kados | hmmm |
| 09:55 | qiqo | argghh// |
| 09:55 | so you think the cvs thing wont fix my problem? | |
| 09:55 | kados | we could finish the development quite quickly and you could install it |
| 09:55 | qiqo | really? how long shall it take? |
| 09:55 | kados | but it wouldn't be a priority without sponsorship |
| 09:55 | qiqo | ermm.. ok |
| 09:55 | kados | i can check our current schedule to see when it's supposed to be done |
| 09:56 | slef | I may have a sponsor for working on barcodes, but I'm snowed. :-( |
| 09:56 | kados | hmmm ... we don't even have a timeline |
| 09:56 | qiqo | armmmm.. |
| 09:56 | slef | tomorrow is koha day here at towers |
| 09:56 | kados | it could be done very quickly if we had a sponsor |
| 09:56 | slef: :-) | |
| 09:56 | qiqo | im gonna try the cvs thing first |
| 09:57 | kados | qiqo: that will only work if you have gaylord 8851 barcodes |
| 09:57 | qiqo: try it on the demo first to see how it works: | |
| 09:57 | qiqo: koha.liblime.com | |
| 09:57 | qiqo | so i will install the gaylord? |
| 09:57 | kados | gaylord is a label type |
| 09:57 | it has: | |
| 09:57 | spine labels and barcodes on the same line | |
| 09:58 | qiqo: http://koha.liblime.com/cgi-bi[…]ox=1&op=save_conf | |
| 09:58 | qiqo: or just: http://koha.liblime.com/cgi-bi[…]oha/label-home.pl | |
| 09:58 | qiqo: then click on 'add labels' and then finally 'generate PDF' | |
| 09:59 | qiqo: the new system we speced out would allow you to define label types of your own | |
| 09:59 | qiqo | :( |
| 09:59 | kados | qiqo: with measurements based on what you need |
| 09:59 | but for now, only the gaylord is supported | |
| 09:59 | qiqo | but its taking up time,, i need to label my collection.. |
| 10:00 | kados | this is an open source project |
| 10:00 | we rely on sponsored development for features | |
| 10:00 | slef | qiqo: what labels do you use? |
| 10:01 | qiqo | the manually made labels |
| 10:01 | slef | print onto paper and then sticky-film them to the books? |
| 10:02 | kados | qiqo: do you have pre-printed spine labels? |
| 10:03 | qiqo | nope i dont |
| 10:03 | kados | so maybe the gaylord _is_ the right choice for you |
| 10:03 | did you see the demo? | |
| 10:03 | qiqo | how do i install that? |
| 10:03 | yes | |
| 10:03 | kados | that's running stock cvs |
| 10:04 | check kohadocs.org for the 'Updating Koha' document | |
| 10:07 | qiqo | updating koha? |
| 10:07 | kados | qiqo: did you look on kohadocs.org? |
| 10:07 | qiqo | yes |
| 10:08 | kados | qiqo: there is a document called 'Updating Koha ' |
| 10:08 | it has a step by step guide for how to use cvs | |
| 10:08 | hdl: are you still around? | |
| 10:08 | qiqo | yes.. so what release are we talking about now |
| 10:09 | cvs -z3 -d:pserver:anonymouscvs.savannah.nongnu.org:/sources/koha co -r rel_2_2 koha |
|
| 10:09 | hdl | yes. |
| 10:09 | kados | qiqo: rel_2_2 |
| 10:09 | qiqo | still 2_2? |
| 10:09 | ok | |
| 10:10 | kados | hdl: are you working on a bug? if so, which one? |
| 10:10 | I can look at it if you are | |
| 10:14 | slef | anyone know where telephone numbers starting +234 are? |
| 10:14 | kados | not me |
| 10:15 | Burgwork | slef, nigeria or ohio (within NA) |
| 10:15 | owen | Google suggests Nigeria |
| 10:15 | Burgwork | morning kados |
| 10:16 | hdl | kados : bug 1240 |
| 10:16 | sorry 1140 | |
| 10:16 | Burgwork | slef, http://decoder.americom.com/main.html |
| 10:17 | slef | Burgwork: thanks will bookmark |
| 10:17 | www.itu.int seems down | |
| 10:17 | http://www.ukphoneinfo.com/sec[…]tci/locator.shtml if anyone ever wants a UK one | |
| 10:18 | hdl | kados : see if it is OK now ? |
| 10:19 | kados | hdl: 1140? |
| 10:19 | hdl | opac serials. |
| 10:19 | kados | hdl: I don't see a commit for 1140 ... but for 1136 |
| 10:19 | hdl | Yes I mistook numbers.. |
| 10:19 | kados | ok |
| 10:19 | I will update and test | |
| 10:26 | qiqo | i cant seem to find the opac module |
| 10:26 | with the cvs | |
| 10:26 | kados | hdl: I discovered a new bug |
| 10:27 | hdl: i created a new subscription | |
| 10:27 | hdl: and received 6 issues | |
| 10:27 | hdl: subscription-detail.pl now shows: | |
| 10:27 | Vol 12 No 6 08/08/2006 Arrived | |
| 10:27 | Vol 12 No 5 08/08/2006 Arrived | |
| 10:27 | Vol 12 No 4 08/08/2006 Arrived | |
| 10:27 | Vol 12 No 3 08/08/2006 Arrived | |
| 10:27 | Vol 12 No 2 08/08/2006 Arrived | |
| 10:27 | Vol 12 No 7 Waited | |
| 10:27 | so Vol 12 No 1 is missing from there | |
| 10:28 | hdl: but to answer your original question ... is bug 1140 fixed ... almost | |
| 10:28 | hdl: after checking in 6 issues it now shows: | |
| 10:28 | Vol 12 No 2 08/08/2006 Arrived | |
| 10:28 | Vol 12 No 3 08/08/2006 Arrived | |
| 10:28 | Vol 12 No 4 08/08/2006 Arrived | |
| 10:28 | so it is not the 'latest checked in' but the 'first checked in' | |
| 10:29 | (also note that it seems that Vol 12 No 1 was deleted ) | |
| 10:30 | hdl: (but it displays in serial-issues.pl) | |
| 10:30 | hdl | Is it a problem in serial table or in the search ? |
| 10:30 | kados | i will check the db |
| 10:31 | select * from serial: | |
| 10:31 | has issues 1-7 listed | |
| 10:32 | select * from subscriptionhistory also has Vol 12 No 1. listed | |
| 10:32 | so maybe it's just a search prob? or display prob? | |
| 10:35 | hdl: http://opac.smfpl.org/cgi-bin/[…]4&selectview=full | |
| 10:35 | hdl: what is the '1900' tab? | |
| 10:36 | hdl: only the biblio detail page is missing subscription listings | |
| 10:36 | hdl: the opac-serial-issues.pl seems to have them all ... even if 1900 is a strange tag | |
| 10:36 | hdl | 1900 : is the name of the no Publication date. |
| 10:37 | I hope ppl will not enter serials up to 1900. | |
| 10:37 | I should have change the name. | |
| 10:37 | kados | hmmm |
| 10:37 | hdl | return to biblio... I bet it is behind your lefttab. |
| 10:38 | kados | left tab? |
| 10:38 | hdl | (left column.) |
| 10:38 | kados | http://koha.smfpl.org/cgi-bin/[…]?subscriptionid=1 |
| 10:38 | I don't see it ... maybe npl templates are missing a link? | |
| 10:38 | hdl | <h1 class="catalogue">Subscription information for American girl.</h1> |
| 10:39 | <a href="opac-detail.pl?bib=59614" class="button catalogue">Back to biblio</a> | |
| 10:39 | in your html code of the page. | |
| 10:39 | kados | hdl: that's css template |
| 10:39 | hdl: for opac | |
| 10:40 | hdl: http://opac.smfpl.org/cgi-bin/[…]tail.pl?bib=59614 | |
| 10:40 | hdl: also css template | |
| 10:40 | so in opac-detail.pl, serials listed are not 'most recent' but are 'first' | |
| 10:41 | in opac-serial-issues.pl? it seems to be fixed | |
| 10:41 | hdl: does that answer your question? | |
| 10:41 | hdl | only 3 of them are displayed. |
| 10:42 | kados | in opac-detail.pl? |
| 10:42 | hdl | yes. |
| 10:42 | kados | it says 'latest issues' but they are not the 'latest' but the 'first' |
| 10:42 | hdl | In subscription-detail, it takes the 5 "latest" ones. |
| 10:42 | kados | do you see that? |
| 10:43 | it is viewed here for instance: | |
| 10:43 | http://opac.smfpl.org/cgi-bin/[…]tail.pl?bib=59614 | |
| 10:43 | 2, 3, 4 ... I think it should be 4, 5, 6 ... right? | |
| 10:43 | (since I checked in 6 issues?) | |
| 10:44 | but maybe I missunderstand this description | |
| 10:57 | hdl: I updated bug 1125 with the new information | |
| 10:57 | hdl: | |
| 10:57 | oosp | |
| 11:02 | owen: got a sec? | |
| 11:02 | quick question about acquisitions ordering | |
| 11:03 | it was my understanding that when you search for a vendor, then click 'add order' it took you to a page with a blank order form | |
| 11:03 | then you would add items to that new order | |
| 11:03 | but it seems like the behavior is to open an existing order form (basket I guess) | |
| 11:04 | even in default templates | |
| 11:04 | http://koha.smfpl.org/cgi-bin/[…]qui/acqui-home.pl | |
| 11:04 | (just click on 'OK' for the supplier name search | |
| 11:04 | you will see several baskets for 'Josh Book Supplies' | |
| 11:05 | one is open, the others are closed | |
| 11:05 | or ... is it understood that you have one order at a time per supplier? | |
| 11:06 | owen | I would think not |
| 11:06 | kados | hdl: can you shed light on this question |
| 11:06 | paul: or you if you're around? | |
| 11:06 | owen | I would expect the order link to create a whole new empty order, regardless of how many other open orders there are |
| 11:06 | kados | yea, me too |
| 11:06 | if we're right, it's another bug with acquisitions :-) | |
| 11:07 | I guess I just file a bug and if it's invalid, paul or hdl will comment on it | |
| 11:09 | even if all the baskets are closed | |
| 11:09 | it still opens up an existing one when I click on 'order' | |
| 11:30 | owen | kados: about Bug 1137... |
| 11:30 | The basket screen looks the same to me in npl and default | |
| 11:30 | I'm not sure what you're seeing | |
| 11:30 | kados | let me find a link |
| 11:31 | actually ... | |
| 11:31 | i suspect that bug 1146 is to blame here | |
| 11:31 | if I can't create a new basket, I can't really test 1137 :-) | |
| 11:32 | I'll add a note and dependency on 1137 to 1146 | |
| 11:33 | owen: does that make sense? | |
| 11:33 | owen | Yes |
| 11:36 | By the way, I found some new (to me) bugs on zoomopac and added some notes to the NPL wiki about them | |
| 11:36 | kados | cool, thx |
| 11:37 | yea, that parentheses thing is annoying | |
| 11:41 | hdl | kados: I'm off for dinner. |
| 11:41 | I will come back. | |
| 11:41 | kados | hdl: ok, thx |
| 11:42 | bs | |
| 11:42 | bbs even :-) |
← Previous day | Today | Next day → | Search | Index
