| Time |
S |
Nick |
Message |
| 00:02 |
|
chris_n |
so which images are athorized value images? |
| 00:03 |
|
chris_n |
authorized even |
| 00:03 |
|
rangi |
hmmm |
| 00:03 |
|
rangi |
pass |
| 00:03 |
|
* chris_n |
tested the patches for 5687 |
| 00:03 |
|
chris_n |
they apply |
| 00:04 |
|
rangi |
but not sure how to test them? |
| 00:04 |
|
chris_n |
not exactly |
| 00:04 |
|
rhcl |
is wahanui1 a bot? |
| 00:04 |
|
rangi |
maybe update the bug and ask marcel to explain more |
| 00:04 |
|
chris_n |
apparently these images were there before |
| 00:04 |
|
rangi |
rhcl: yep |
| 00:04 |
|
chris_n |
now they just are conditional based on the new syspref |
| 00:04 |
|
rangi |
ah right |
| 00:04 |
|
|
rhcl is now known as rhcl_away |
| 00:04 |
|
chris_n |
but nothing changes with my test data |
| 00:05 |
|
chris_n |
so I probably don't have these images setup |
| 00:05 |
|
* chris_n |
goes to dig through the code a bit |
| 00:27 |
|
chris_n |
well the bug is updated at any rate |
| 00:28 |
|
hudsonbot |
Starting build 341 for job Koha_Master (previous build: SUCCESS) |
| 00:32 |
|
huginn |
New commit(s) kohagit: Fix for Bug 5115, Tags JavaScript includes many untranslatable strings <http://git.koha-community.org/[…]2cdeb7019fbfadeb6> / Merge branch 'new/bug_5690' into kcmaster <http://git.koha-community.org/[…]454251d16b9d5ce0e> / Bug 5690 <http://git.koha-community.org/[…]5b5c230249581a973 |
| 00:40 |
|
|
Nate_ left #koha |
| 00:42 |
|
huginn |
New commit(s) kohagit: Fix for Bug 5532 - sysprefs editor should show names of saved prefs <http://git.koha-community.org/[…]2c93c96d6894ff821> / Fix for Bug 5689 - System preference notifications are not translatable <http://git.koha-community.org/[…]4c76629020c392bca> |
| 00:52 |
|
hudsonbot |
Project Koha_Master build #341: SUCCESS in 24 min: http://hudson.koha-community.o[…]/Koha_Master/341/ |
| 00:52 |
|
hudsonbot |
* Chris Cormack: Updating history docs |
| 00:52 |
|
hudsonbot |
* Henri-Damien LAURENT: Bug 5690 |
| 00:52 |
|
hudsonbot |
* Owen Leonard: Fix for Bug 5115, Tags JavaScript includes many untranslatable strings |
| 00:53 |
|
hudsonbot |
Starting build 342 for job Koha_Master (previous build: SUCCESS) |
| 01:15 |
|
chris_n |
@later tell atz http://librarypolice.com/wiki.[…]ngscratchpad.html |
| 01:15 |
|
huginn |
chris_n: The operation succeeded. |
| 01:18 |
|
chris_n |
@later tell jwagner http://librarypolice.com/wiki.[…]t:hard_coded.html |
| 01:18 |
|
huginn |
chris_n: The operation succeeded. |
| 01:18 |
|
chris_n |
@later tell jwagner but I don't think that helps much as what they mean apparently never got filled in |
| 01:18 |
|
huginn |
chris_n: The operation succeeded. |
| 01:21 |
|
hudsonbot |
Project Koha_Master build #342: SUCCESS in 28 min: http://hudson.koha-community.o[…]/Koha_Master/342/ |
| 01:21 |
|
hudsonbot |
* Owen Leonard: Fix for Bug 5689 - System preference notifications are not translatable |
| 01:21 |
|
hudsonbot |
* Owen Leonard: Fix for Bug 5532 - sysprefs editor should show names of saved prefs |
| 01:39 |
|
|
thd-away left #koha |
| 01:40 |
|
|
druthb joined #koha |
| 01:49 |
|
chris_n |
@later tell jwagner here is an updated version based on my parsing through irc logs and code |
| 01:49 |
|
huginn |
chris_n: The operation succeeded. |
| 01:49 |
|
chris_n |
@later tell jwagner http://wiki.koha-community.org[…]Hard_Coded_Values |
| 01:49 |
|
huginn |
chris_n: The operation succeeded. |
| 02:04 |
|
|
thd-away joined #koha |
| 02:04 |
|
|
thd-away is now known as thd |
| 02:04 |
|
|
thd is now known as thd-away |
| 02:06 |
|
|
zpinhead joined #koha |
| 02:07 |
|
zpinhead |
interested in using koha for 'special collections'. |
| 02:07 |
|
zpinhead |
see the product 'aeon' by atlas systems. |
| 02:08 |
|
zpinhead |
1) preserve user information for ever. |
| 02:08 |
|
zpinhead |
2) items always stay in room -- user gives back at end of day |
| 02:08 |
|
zpinhead |
uses next day, or for several days. |
| 02:09 |
|
zpinhead |
request items from ead files -- request at level of 'box' or 'folder' |
| 02:09 |
|
zpinhead |
depending on configuration of 'collection'. |
| 02:09 |
|
zpinhead |
anyone have any clues as to if this might have been done before? |
| 02:09 |
|
zpinhead |
thanks. |
| 02:11 |
|
zpinhead |
here is a url for the 'aeon' product. |
| 02:11 |
|
zpinhead |
http://www.atlas-sys.com/products/aeon/ |
| 02:11 |
|
druthb |
.... |
| 02:13 |
|
druthb |
I suspect *something* could be done, although Koha is pretty MARC21/UNIMARC-centric. |
| 02:13 |
|
druthb |
EAD records would be something unexpected for it, so some hacking would likely be needed. |
| 02:14 |
|
zpinhead |
i think maybe one key is that you don't have a whole thing. |
| 02:15 |
|
zpinhead |
you (the patron) borrow a part of a thing -- like, from a particular collection, |
| 02:15 |
|
druthb |
yah, how you define *item* is something kind of incompatible with Koha's notion of *item.* |
| 02:15 |
|
zpinhead |
like 'Ezra Cornell's paper' box 32 -- folder 12 -- it's kind of like |
| 02:16 |
|
zpinhead |
borrowing one volume of a serial. |
| 02:16 |
|
druthb |
If you designated a folder as the item, and have a herd of items hooked to the bib, which could be a box or a whole collection, you could make it work. Loading the data would be a little gnarly, but do-able. |
| 02:17 |
|
zpinhead |
there is also a scheduling aspect. folks come from far away to use |
| 02:17 |
|
zpinhead |
a thing for a few days -- so you need to have check-out's queued up. |
| 02:17 |
|
druthb |
could maybe use the holds mechanism for part of that, with a little hacking. |
| 02:18 |
|
zpinhead |
need to make sure schedules don't conflict. |
| 02:18 |
|
zpinhead |
also some items are also in library catalog -- and need to be fetched |
| 02:18 |
|
zpinhead |
from 'library annex', but some (many) are of the EAD type. |
| 02:18 |
|
zpinhead |
and many users are not actually registered at the university -- |
| 02:19 |
|
zpinhead |
so you need to create users on the spot. |
| 02:19 |
|
druthb |
Easy enough, that. |
| 02:19 |
|
druthb |
The Really Big Stinker, as I see it, is the EAD format...Koha knows nothing whatever about that. |
| 02:21 |
|
zpinhead |
is there a 'call slip' mechanism for koha? |
| 02:22 |
|
druthb |
no, though I think it's been talked about. |
| 02:23 |
|
zpinhead |
fetch this item from the stacks, and deliver it to a particular |
| 02:23 |
|
zpinhead |
circ place? |
| 02:26 |
|
druthb |
yeah, I've seen 'em before. But Koha has no tool for that. |
| 02:29 |
|
zpinhead |
this:http://www.librarytechnology.o[…]ytext.pl?RC=14230 |
| 02:29 |
|
zpinhead |
says koha has call slips. but i don't see anything |
| 02:30 |
|
zpinhead |
on koha.org |
| 02:30 |
|
druthb |
If you're looking at koha.org, you're looking in the wrong place. |
| 02:30 |
|
zpinhead |
as for EAD, like you said -- each EAD would be one bib record, |
| 02:31 |
|
zpinhead |
and then, some how connect the boxes, and folders as holding info. |
| 02:31 |
|
druthb |
LibLime Enterprise Koha is a product supported by PTFS/LibLime, based on an older Koha base... The Koha that's talked about here is based at www.koha-community.org |
| 02:32 |
|
druthb |
might use the item enum-chron field for box-folder info. |
| 02:33 |
|
zpinhead |
tricky bit is: if someone has borrowed a box -- which contains |
| 02:34 |
|
druthb |
yah, could be tedious to check out all the folders in the box. |
| 02:35 |
|
zpinhead |
some folders -- need to know that those folders are checked out. |
| 02:35 |
|
zpinhead |
need some sort of 'enclosed' or 'dependency' relations between |
| 02:35 |
|
zpinhead |
things, entities. |
| 02:36 |
|
druthb |
yep. |
| 02:46 |
|
zpinhead |
ead is really hard to parse also -- lots of options, lots of levels |
| 02:47 |
|
zpinhead |
of nesting -- but i guess we could tailor it to our own needs. |
| 02:47 |
|
druthb |
mhm |
| 02:48 |
|
zpinhead |
you can have boxes in boxes in boxes in folders in folders. |
| 02:49 |
|
zpinhead |
-- one can do that. but one institution usually has one set of |
| 02:49 |
|
zpinhead |
conventions -- so could tailor to that. |
| 02:51 |
|
druthb |
If you build the notion of "Container" right, then it'll work for any level of nesting. |
| 02:54 |
|
druthb |
"A biblio may hold a Container, which may, in turn, hold, zero-or-more other containers. |
| 02:54 |
|
druthb |
(If a container holds zero others, then it's a folder, the lowest level of stuff you'll put over the circ desk. |
| 02:55 |
|
druthb |
Then when you check out any container, it should check out all nested objects contained by it, as deep as needed. |
| 02:57 |
|
* druthb |
looks to the "digital space" in her head... |
| 02:58 |
|
druthb |
That could be done by adding one field to the Koha items table, which would contain the itemnumber of the parent item. a NULL there indicates a top-level item, and an item with no children pointing at it is a bottom-level. |
| 02:59 |
|
druthb |
There'd be lots of display, editing, circ hacks to be done, but the change to the data structures would not be insane for that. |
| 03:00 |
|
druthb |
Such a hack would have some value in other contexts, such as kits--barcode the individual objects, and the box they're in. |
| 03:05 |
|
druthb |
I'm gonna head out for the evening. zpinhead, please do come back by during US working hours--lotsa folks here and talking, then. Someone may have other ideas that could help. |
| 03:05 |
|
zpinhead |
thanks druthb. |
| 03:06 |
|
zpinhead |
i will sign on tomorrow in working hours. my library is |
| 03:06 |
|
druthb |
you bet. Some interesting ideas that jump off the screen at me... |
| 03:06 |
|
zpinhead |
looking at aeon -- i would really like to have something else but i |
| 03:06 |
|
zpinhead |
cannot find anything else in the space. |
| 03:06 |
|
zpinhead |
cheers. |
| 03:06 |
|
zpinhead |
tty. |
| 03:06 |
|
zpinhead |
ttyl. |
| 03:06 |
|
druthb |
Koha would require a fair bit of hacking to get there. It's not un-do-able, but it's non-trivial |
| 03:06 |
|
|
zpinhead left #koha |
| 03:08 |
|
|
druthb left #koha |
| 03:12 |
|
|
kmkale_a joined #koha |
| 03:12 |
|
|
kmkale_a is now known as kmkale |
| 03:13 |
|
kmkale |
Namaskar #koha |
| 03:17 |
|
kmkale |
@weather Mumbai |
| 03:17 |
|
huginn |
kmkale: The current temperature in Mumbai, India is 25.0�C (8:10 AM IST on February 04, 2011). Conditions: Smoke. Humidity: 54%. Dew Point: 15.0�C. Pressure: 29.95 in 1014 hPa (Rising). |
| 03:27 |
|
brendan__ |
@wunder 93109 |
| 03:27 |
|
huginn |
brendan__: The current temperature in K6LCM - Westside / Mesa, Santa Barbara, California is 9.5�C (7:28 PM PST on February 03, 2011). Conditions: Clear. Humidity: 88%. Dew Point: 8.0�C. Windchill: 9.0�C. Pressure: 30.31 in 1026.3 hPa (Falling). |
| 03:48 |
|
|
darling131 left #koha |
| 05:28 |
|
kmkale |
@quote random |
| 05:28 |
|
huginn |
kmkale: Quote #28: "<owen> I'm glad munin doesn't follow me around all day remembering *everything* I say." (added by jdavidb at 01:14 PM, September 01, 2009) |
| 06:31 |
|
rangi |
@wunder wellington nz |
| 06:31 |
|
huginn |
rangi: The current temperature in Wellington, New Zealand is 20.0�C (7:00 PM NZDT on February 04, 2011). Conditions: Mostly Cloudy. Humidity: 94%. Dew Point: 19.0�C. Pressure: 29.92 in 1013 hPa (Steady). |
| 06:31 |
|
rangi |
sticky |
| 06:43 |
|
|
kf joined #koha |
| 06:43 |
|
kf |
good morning #koha |
| 06:44 |
|
rangi |
hi kf |
| 06:47 |
|
kf |
hi chris |
| 06:53 |
|
kmkale |
hi chris kf |
| 06:55 |
|
|
francharb joined #koha |
| 06:56 |
|
francharb |
morning #koha |
| 06:56 |
|
rangi |
hi francharb |
| 06:57 |
|
kf |
hi francharb and kmkale |
| 07:07 |
|
kf |
rangi++ |
| 07:07 |
|
kf |
lots of messages from git in my inbox |
| 07:07 |
|
kf |
chris_n++ |
| 07:07 |
|
|
brendan__ left #koha |
| 07:30 |
|
rangi |
Yep, getting the biblibre stuff attached to bugs, signed off and merged in |
| 07:30 |
|
rangi |
chris_n has been a big help |
| 07:39 |
|
kf |
you both are great |
| 07:44 |
|
kf |
chris_hall++ |
| 07:44 |
|
kf |
for his template work :) |
| 07:47 |
|
|
Brooke_ joined #koha |
| 07:47 |
|
Brooke_ |
kia ora |
| 07:50 |
|
kf |
hi Brooke_ |
| 07:50 |
|
Brooke_ |
:) |
| 07:57 |
|
kmkale |
namaste Brooke_ |
| 07:57 |
|
Brooke_ |
namaste :D |
| 07:59 |
|
* Brooke_ |
is going to try and relax then go to sleep. Not like... |
| 07:59 |
|
|
Brooke_ left #koha |
| 08:06 |
|
|
sophie_m joined #koha |
| 08:06 |
|
|
hdl joined #koha |
| 08:14 |
|
|
hdl1 joined #koha |
| 08:15 |
|
|
hdl left #koha |
| 09:02 |
|
kf |
h hdl1 |
| 09:15 |
|
|
kmkale left #koha |
| 09:17 |
|
|
druthb joined #koha |
| 09:26 |
|
|
kmkale joined #koha |
| 09:47 |
|
kmkale |
I am trying to figure out which marc tag information is available in opac-results.tmpl. Cant figure out where <!-- TMPL_VAR name="pages" --> is getting populated in search.pm Any hints? |
| 09:51 |
|
|
thd-away is now known as thd |
| 09:51 |
|
kmkale |
I want to know which marc tags are available in addition to author, title etc in opac-results.tmpl. And if I need a particular tag, say 653$a, how to get it to display. Please help.. |
| 09:52 |
|
thd |
kmkale: I should be asleep but perhaps I can help. |
| 09:52 |
|
thd |
Are you using the XSLT view or the standard record detail view? |
| 09:52 |
|
kmkale |
thd: please |
| 09:53 |
|
kmkale |
thd: standard |
| 09:54 |
|
thd |
kmkale: I assume that you do not mean the MARC view. |
| 09:54 |
|
kmkale |
thd: no. the opac-search.pl?q=sheldon view |
| 09:56 |
|
thd |
kmkale: In the standard view for one record I think that you need to alter how the subject field is stored in the SQL database or alter the template to grab the data from another place. |
| 09:57 |
|
thd |
s/another place/additional field/ |
| 09:58 |
|
kmkale |
thd: I am looking into search.pm sub searchResults {. Cant figure how stuff like <!-- TMPL_IF name="pages" etc is getting populated |
| 10:00 |
|
kf |
kmkale: I don't hink it's search om |
| 10:00 |
|
kf |
pm |
| 10:01 |
|
kf |
or not sure, when i added the Controlnumber to the opacsearchtitlein I added it to biblio.pm |
| 10:01 |
|
kf |
there are methods to get things like subjects |
| 10:01 |
|
thd |
kmkale: Do you mean one record or a set of brief records? |
| 10:01 |
|
kmkale |
opac-search.pl calls @newresults = searchResults( then populates $template->param(SEARCH_RESULTS => \@newresults, |
| 10:02 |
|
kmkale |
kf: so I should use biblio.pm directly in opac-search.pl? |
| 10:03 |
|
kf |
I think the opac detail view gets the information from the methods in biblio.pm |
| 10:04 |
|
kf |
so I thought you might want to look there and check |
| 10:04 |
|
kmkale |
kf i am on opac results page |
| 10:04 |
|
kmkale |
ok |
| 10:05 |
|
kf |
we are using the xslt views, but there is none for results in staff |
| 10:07 |
|
thd |
kmkale: kf is correct that you should look at opac-detail.pl |
| 10:08 |
|
kmkale |
thd: looking. |
| 10:08 |
|
thd |
GetMarcSubjects |
| 10:08 |
|
kmkale |
GetMarcBiblio from biblio.pm |
| 10:15 |
|
thd |
kmkale: yes in biblio.pm you were right |
| 10:16 |
|
thd |
kmkale: subjects in opac-detail do not use the Koha SQL database anymore. |
| 10:17 |
|
thd |
kmkale: Perhaps the framework hidden value for 653 $a is hiding the data from the OPAC. |
| 10:21 |
|
thd |
kmkale: the hidden value is 0 which should make 653 $a visible in the OPAC. |
| 10:24 |
|
thd |
kmkale are you certain that the record which you are expecting to see something from 653 $a has a value in 653 $a? |
| 10:24 |
|
kmkale |
thd: yes |
| 10:24 |
|
kmkale |
also I am trying to get this value in the search page. Not the detail page |
| 10:25 |
|
kmkale |
fpr that I will need to populate the template->param(SEARCH_RESULTS in opac-search.pl ( I think ) |
| 10:26 |
|
kmkale |
which gets its values from @newresults = searchResults( method in Search.pm ( I think ) |
| 10:31 |
|
thd |
kmkale: The design of the result set page makes my wince when I see it. |
| 10:32 |
|
kmkale |
thd: For a non perl person like me its a code nightmare |
| 10:33 |
|
kmkale |
I have no clue whats going on in Search.pm |
| 10:34 |
|
thd |
kmkale: Search.pm is complicated and has been the source of much contention in the wake of KohaCon with BibLibre rewriting it for Solr/Lucene instead of Zebra support. |
| 10:35 |
|
kmkale |
I have read those threads with interest |
| 10:35 |
|
thd |
kmkale: However, you only need to find what happens when the result set is returned not when the query is sent which is the more complicated part. |
| 10:36 |
|
kmkale |
thd: yup |
| 10:36 |
|
thd |
The query formation is the most complicated part. |
| 10:36 |
|
kmkale |
# loop through all of the records we've retrieved |
| 10:36 |
|
kmkale |
for ( my $i = $offset ; $i <= $times - 1 ; $i++ ) { |
| 10:36 |
|
kmkale |
my $marcrecord = MARC::File::USMARC::decode( $marcresults[$i] ); |
| 10:37 |
|
mtj |
kmkale: use XSLT for opac, its better |
| 10:38 |
|
mtj |
better = easier for you to customize |
| 10:38 |
|
thd |
mtj: kmkale is trying to change the result set with multiple records which is unaffected by the XSLT stylesheets |
| 10:40 |
|
mtj |
if he turned on xslt syspref for opac, it *would* be affected |
| 10:40 |
|
mtj |
… by the xslt stylesheets |
| 10:42 |
|
mtj |
http://git.koha-community.org/[…]cfa1770bb;hb=HEAD |
| 10:43 |
|
thd |
mtj: I had not realised that the result set was affected. |
| 10:44 |
|
kmkale |
In the searchResults( ) method in Search.pm, does the my $marcrecord object contain ALL the marc tags for the record? |
| 10:45 |
|
mtj |
kmkale: add your 653 stuff to MARC21slim2OPACResults.xsl file |
| 10:45 |
|
thd |
kmkale: It should contain everything in the record |
| 10:45 |
|
kmkale |
mtj: never used xslt. will have a look. Thanks for the info |
| 10:46 |
|
thd |
kmkale: most libraries using MARC 21 prefer to use XSLT for the ease of making changes. |
| 10:46 |
|
mtj |
xslt makes the opac look much prettier too |
| 10:47 |
|
mtj |
[[citation needed]] |
| 10:47 |
|
mtj |
;) pass, i dont know that... |
| 10:47 |
|
kmkale |
:) |
| 10:47 |
|
thd |
kmkale: You should be warned that the XSLT work in Koha is very incomplete and maximally inefficient if your goal is to report very complete record information. |
| 10:48 |
|
mtj |
most libraries using MARC21 dont know about xslt? |
| 10:48 |
|
kmkale |
thd: mtj any idea if xslt *might* have any issues with Unicode stuff like India scripts? |
| 10:48 |
|
mtj |
nah, its more complete than the other option |
| 10:49 |
|
kmkale |
s/India/Indic/ |
| 10:49 |
|
thd |
mtj: Almost all of LibLime's customers had XSLT turned on for them. |
| 10:49 |
|
mtj |
meaning more of your bib info is displayed using xslt, than the no-xslt option |
| 10:49 |
|
thd |
kmkale: Unicode should display fine for any option. |
| 10:50 |
|
kmkale |
ok. WIll have a look see. |
| 10:51 |
|
mtj |
well, most liblime customers didnt make changes to their XSLT files ;) |
| 10:51 |
|
thd |
mtj: If you want to display any arbitrary record data with the XSLT design you have to add the entire MARC standard to the XSLT filter. |
| 10:51 |
|
mtj |
but hey, a silly topic... :) |
| 10:52 |
|
kmkale |
thd: you are scring me |
| 10:52 |
|
kmkale |
s/scring/scaring/ |
| 10:52 |
|
thd |
kmkale: It is not scary. |
| 10:53 |
|
thd |
kmkale: record display in Koha is weak either way. |
| 10:53 |
|
mtj |
koha's xslt marc stuff references xmlns:marc="http://www.loc.gov/MARC21/slim" |
| 10:53 |
|
mtj |
so its gonna be pretty complete? |
| 10:54 |
|
mtj |
hah, a dead url :/ |
| 10:54 |
|
thd |
kmkale: The problem with XSLT efficiency is that the Koha implementation is actually merely a feature of YAZ with no concern for anything other than a minimal display. |
| 10:55 |
|
kmkale |
thd: I did not understand anything from the above statement ;) |
| 10:55 |
|
kf |
kmkale: don't be scared - xslt is changeable |
| 10:56 |
|
kf |
kmkale: if you need some help to make it show something, perhaps I can help you sometime |
| 10:56 |
|
kmkale |
<quote> add the entire MARC standard to the XSLT filter.</quote> sounds scary |
| 10:56 |
|
thd |
kmkale: YAZ is from IndexData and the Koha XSLT filters are essentially copied from YAZ. |
| 10:56 |
|
thd |
kmkale: The goal of the filters was to show very little information. |
| 10:57 |
|
* kmkale |
is aware of YAZ. In the form of yaz-client |
| 10:57 |
|
thd |
kmkale: YAZ can also convert records using XSLT filters. |
| 10:57 |
|
kmkale |
kf thanks. May take you up on that help offer |
| 10:59 |
|
thd |
kmkale: The problem from an efficiency point of view is that the XSLT filters search the record for a list of fields and subfields. |
| 10:59 |
|
mtj |
i guess my point is, if you dont use XSLT to have to make a nasty mod in opac-results.pl, *and* opac-results.tmpl |
| 10:59 |
|
mtj |
if you use XSLT , you just have to make a mod to MARC21slim2OPACResults.xsl |
| 11:00 |
|
thd |
kmkale: The XSLT filters should be reading the record sequentially and only doing something for actual record content. |
| 11:00 |
|
kf |
mtj: good point :) |
| 11:00 |
|
kf |
I like xslt |
| 11:00 |
|
mtj |
and your XSLT mod is more likely to not break when you upgrade your koha |
| 11:01 |
|
thd |
kf: XSLT is good. The implementation in Koha is weak. |
| 11:01 |
|
mtj |
i like XSLT for making my system easier to upgrade, for custom display-mods |
| 11:02 |
|
mtj |
yep, so add the stuff thats missing ;) |
| 11:02 |
|
mtj |
… for at least your clients koha |
| 11:02 |
|
mtj |
like a 652 block |
| 11:02 |
|
mtj |
s/652/653/ |
| 11:02 |
|
thd |
mtj: The problem with adding what is missing is that it would require parsing the entire MARC standard to be complete. |
| 11:03 |
|
thd |
mtj: That is why I mean that the XSLT implementation is written backwards. |
| 11:03 |
|
mtj |
pass, that hasn't been my experience yet |
| 11:03 |
|
thd |
mtj: There should be no need to parse anything not in the record. |
| 11:04 |
|
thd |
mtj: The evidence is there in the code. |
| 11:04 |
|
mtj |
im curious, which file/s ? |
| 11:05 |
|
thd |
mtj: The exact ones which you have identified |
| 11:05 |
|
mtj |
theres a *lot* of stuff re: xslt i dont understand yet, |
| 11:06 |
|
mtj |
but ive manged to display any bib subfield i want, so far |
| 11:06 |
|
thd |
mtj: The files for OPAC detail are the most problematic. |
| 11:06 |
|
mtj |
by modding the .xsl file |
| 11:07 |
|
thd |
mtj: Yes you can have it display anything you want by specifying what you want. |
| 11:07 |
|
mtj |
yep, that works ok for me |
| 11:07 |
|
kmkale |
changed to xslt and 1st tghing is subjests are NOT displayed in the results page |
| 11:07 |
|
kmkale |
but are displayed in the details [page |
| 11:07 |
|
thd |
mtj: However, if you want to display everything which might ever be in any record then the design inefficiency is revealed. |
| 11:08 |
|
mtj |
aaaahhh, a speed issue |
| 11:08 |
|
thd |
mtj: yes I only refer to speed and precious CPU cycles |
| 11:10 |
|
mtj |
i imagine the xslt parsing stuff hasnt had a speed tweak yet , tho |
| 11:10 |
|
mtj |
both things are know problems with workarounds |
| 11:10 |
|
thd |
mtj: No mere tweak required. It is written backwards. |
| 11:11 |
|
thd |
mtj: It should parse the record content against what you want to do with the content. |
| 11:11 |
|
mtj |
add more content to your .xsl file and get a faster box |
| 11:12 |
|
thd |
mtj: In contrast, it parses what you want to do with the content against the record content. |
| 11:13 |
|
mtj |
are you saying koha does this the wrong/slow way? |
| 11:13 |
|
thd |
mtj: It simply does not scale for presenting all possible record information even if faster boxes are cheap. Enough users displaying enough records will slow anything. |
| 11:13 |
|
thd |
mtj: Yes backwards. |
| 11:14 |
|
mtj |
ah, ok |
| 11:14 |
|
thd |
mtj: The parsing logic reversed. |
| 11:15 |
|
mtj |
ok, sounds like a good thing to fix in the future |
| 11:15 |
|
thd |
mtj: If the list of fields you want to display is small the issue is moot. |
| 11:15 |
|
thd |
mtj: I have discussed fixing the issue with fredericd. |
| 11:16 |
|
thd |
mtj: There is a general problem that most of the XSLT files only work with MARC 21 and not UNIMARC. |
| 11:17 |
|
mtj |
ok, yes, i only run marc21 kohas |
| 11:19 |
|
thd |
kmkale: The problem may be that the record prepared for the result set page may already be a subset of the record. |
| 11:20 |
|
kmkale |
thats what I suspect. That was the reason of the ALL marc question above |
| 11:20 |
|
mtj |
thd: its great to hear you have been doing work in this xslt area, those problems are all new to me |
| 11:21 |
|
thd |
mtj: fredericd had asked me about XSLT a couple of years ago and so I investigated deeply. |
| 11:23 |
|
thd |
mtj: There has never been substantial effort on XSLT specifically for Koha. The functionality was essentially invoked from YAZ. |
| 11:24 |
|
|
druthb left #koha |
| 11:25 |
|
mtj |
yeah, it works well enuff for most usage |
| 11:25 |
|
mtj |
it just needs improvement, to make it complete and faster |
| 11:26 |
|
thd |
mtj: Yes, I am one of the unreasonable people never satisfied with what most people find acceptable. |
| 11:26 |
|
thd |
mtj: The trouble is that fixing it would not be a minor tweak. |
| 11:27 |
|
thd |
mtj: Fixing the problem would mean redesigning how it functions. |
| 11:28 |
|
kmkale |
uncommenting use Data::Dumper; print STDERR "-" x 25, "\n", Dumper($results_hashref); in opac-search.pl seems to indicate that all marc info is retrieved |
| 11:28 |
|
thd |
mtj: XSLT needs to call its own version of a MARC framework. |
| 11:28 |
|
kmkale |
will verify this |
| 11:30 |
|
thd |
kmkale: all the data is retrieved for search.pl, however, it may be subsequently filtered before being handed for result set display processing. |
| 11:32 |
|
mtj |
thd: so the catch with a complete (read: HUGE) marc.xsl file, is that all of teh xsl needs to be evaluated, even if the bib is tiny? |
| 11:33 |
|
thd |
mtj: exactly |
| 11:33 |
|
mtj |
and its all that extra evaluating that the performance killer? |
| 11:33 |
|
mtj |
ah |
| 11:33 |
|
thd |
mtj: exactly |
| 11:33 |
|
mtj |
ok, i get it :/ |
| 11:35 |
|
mtj |
so thats the cost of a complete marc.xsl file, the execution of the .xsl is a killer |
| 11:35 |
|
thd |
mtj: a few users may not notice but given enough users and enough useful features yet to be written also taking the CPU, then the CPU needs to be used more efficiently. to be used better. |
| 11:37 |
|
thd |
mtj: This issue is trivial compared to some looping problems people are fixing for Koha 3.4 |
| 11:37 |
|
mtj |
hmm, i wonder if there are hacks/tricks to optimise an .xsl file |
| 11:37 |
|
mtj |
argreed there |
| 11:38 |
|
thd |
mtj: Not writing to MARC for circulation is the easiest fix for performance people are implementing. |
| 11:39 |
|
|
hdl1 left #koha |
| 11:40 |
|
mtj |
well, heres a good point, the .xsl for search results should be pretty brief |
| 11:41 |
|
mtj |
ultimately it could be complete, but mostly commented-out |
| 11:42 |
|
mtj |
so a speed win there for results display |
| 11:44 |
|
thd |
mtj:Yes the result set should be brief in the OPAC. |
| 11:44 |
|
mtj |
ok, i am off guys, cheers for the info |
| 11:44 |
|
thd |
mtj: Where are you from? |
| 11:44 |
|
mtj |
NZ, mtj = mason.t.james |
| 11:45 |
|
thd |
Hello mason |
| 11:45 |
|
mtj |
i have a new nick |
| 11:45 |
|
kf |
and you are awake at odd hours :) |
| 11:46 |
|
thd |
I chose uniquely enough not to need a new nick. |
| 11:46 |
|
kf |
my nick seems to be too short to be registered |
| 11:46 |
|
thd |
kf: That is what Koha will do to you |
| 11:46 |
|
mtj |
someone already had wasabi :/ |
| 11:46 |
|
thd |
kf: Koha keeps people awake forever. |
| 11:47 |
|
mtj |
kf: nah, 1am isnt that late |
| 11:47 |
|
kf |
my trick is multiple personalities... hides the fact that I am almost always here a bit better |
| 11:47 |
|
thd |
6.50 AM where I am is late :) |
| 11:47 |
|
kf |
12:50 pm |
| 11:47 |
|
kf |
still a lot of friday left for me |
| 11:48 |
|
mtj |
12:51am here |
| 12:00 |
|
thd |
kmkale: I hope you solve the problem, I have to sleep. |
| 12:00 |
|
kmkale |
search.pm getRecords seems to return complete marc set ( may be wrong as the dumper does not display mark tag numbers but the data is displayed.) but the search.pm searchResults method returns a subset. This subset is pushed in template param. so I think I need to change searchResults method in search.pm :( |
| 12:00 |
|
kmkale |
by thd |
| 12:01 |
|
kf |
xslt doesn't work? |
| 12:02 |
|
thd |
kf: XSLT needs the data to be in the record parsed |
| 12:02 |
|
kmkale |
kf: no 6xx displayed in results with xslt |
| 12:02 |
|
kmkale |
its displayed in details |
| 12:03 |
|
kf |
ah |
| 12:03 |
|
thd |
kf: prefiltered records are the problem |
| 12:03 |
|
* thd |
sleeps |
| 12:03 |
|
|
thd is now known as thd-away |
| 12:03 |
|
kf |
I understand |
| 12:09 |
|
|
Nate__ joined #koha |
| 12:19 |
|
|
jwagner joined #koha |
| 12:20 |
|
kmkale |
kf using Biblio.pm seems to be the way |
| 12:25 |
|
|
tcohen joined #koha |
| 12:28 |
|
|
hdl joined #koha |
| 12:42 |
|
Nate__ |
morning #koha! |
| 12:44 |
|
slef |
hi Nate__ |
| 12:44 |
|
kf |
kmkale: oh :( |
| 12:44 |
|
Nate__ |
hiya slef |
| 12:44 |
|
kmkale |
kf: I dont dxare touch search.pm |
| 12:47 |
|
kf |
understandable |
| 12:50 |
|
|
jcamins_away is now known as jcamins |
| 12:53 |
|
paul_p |
'morning americans south & north ! |
| 12:55 |
|
jwagner |
morning/afternoon/evening, the rest of the world.... |
| 13:08 |
|
hdl |
hi |
| 13:08 |
|
wahanui1 |
hola, hdl |
| 13:09 |
|
* kf |
waves |
| 13:11 |
|
|
oleonard joined #koha |
| 13:13 |
|
kf |
hi oleonard :) |
| 13:13 |
|
oleonard |
Hi |
| 13:13 |
|
wahanui1 |
hello, oleonard |
| 13:15 |
|
|
tcohen left #koha |
| 13:20 |
|
|
tcohen joined #koha |
| 13:29 |
|
kf |
wahanui_1_? |
| 13:35 |
|
jwagner |
The bots are cloning? |
| 13:39 |
|
kf |
that would be scary |
| 13:40 |
|
jwagner |
World domination is next on their agenda!!! |
| 13:41 |
|
oleonard |
chris_n: Thanks for the signoffs yesterday |
| 13:41 |
|
chris_n |
oleonard: yw |
| 13:48 |
|
kf |
hehe |
| 13:48 |
|
kf |
wahanui1 botsnack cookies |
| 13:48 |
|
wahanui1 |
:) |
| 13:49 |
|
kf |
better be nice to the bots |
| 13:51 |
|
|
jcamins is now known as jcamins_away |
| 14:13 |
|
|
sekjal joined #koha |
| 14:15 |
|
oleonard |
*sigh* The perennial 3.2 question... Why can't I place a hold... |
| 14:15 |
|
oleonard |
You'd think I've been through this enough times |
| 14:17 |
|
* oleonard |
finds the errant pref |
| 14:18 |
|
oleonard |
Okay, as per Bug 4806 holds now have a unique id in the reserves table |
| 14:18 |
|
huginn |
Bug http://bugs.koha-community.org[…]w_bug.cgi?id=4806 critical, PATCH-Sent, ---, gmcharlt, NEW, circ/circulation.tmpl: Add "reservenumber" in the reserved table |
| 14:18 |
|
oleonard |
But it looks like the hold deletion process hasn't been updated to use it? |
| 14:18 |
|
oleonard |
Duplicate holds are still deleted all together |
| 14:19 |
|
* oleonard |
thought this was one of the primary motivations for adding the unique id |
| 14:22 |
|
oleonard |
paul_p or hdl, Might this be a change Biblibre has made in one of your branches? |
| 14:24 |
|
hdl |
oleonard: there are some work to be sent about that |
| 14:28 |
|
tcohen |
wahanui1: hi there |
| 14:28 |
|
wahanui1 |
salut, tcohen |
| 14:28 |
|
oleonard |
hdl: I've created a new bug report for that: Bug 5696. It would be great if you could attach a patch to that when it's ready |
| 14:28 |
|
huginn |
Bug http://bugs.koha-community.org[…]w_bug.cgi?id=5696 normal, P5, ---, kyle.m.hall, NEW, Hold deletion should use reservenumber |
| 14:41 |
|
oleonard |
Does anyone know how Bug 3929 works? |
| 14:41 |
|
huginn |
Bug http://bugs.koha-community.org[…]w_bug.cgi?id=3929 enhancement, PATCH-Sent, ---, paul.poulain, NEW, parameters in guided reports |
| 14:56 |
|
kmkale |
bye all. have a nice weekend |
| 14:56 |
|
|
kmkale left #koha |
| 14:57 |
|
* oleonard |
finds info on reports parameters in the help file of all places ;) |
| 15:03 |
|
oleonard |
paul_p++ # for guided reports runtime paramters |
| 15:03 |
|
paul_p |
thx oleonard |
| 15:04 |
|
oleonard |
It's a very thoughtful implementation. I like the option to use authorised values |
| 15:04 |
|
wizzyrea |
paul_p++ for thoughtful implementations |
| 15:06 |
|
kf |
oleonard: do branches work for you? |
| 15:07 |
|
oleonard |
Using branches as a parameter? |
| 15:07 |
|
kf |
yep |
| 15:07 |
|
kf |
i have a note here somewhere... to retest that |
| 15:07 |
|
oleonard |
It worked for querying items.homebranch |
| 15:09 |
|
kf |
ah cool |
| 15:10 |
|
kf |
can you share the syntax? |
| 15:10 |
|
kf |
perhaps I had a mistake there |
| 15:11 |
|
kf |
oleonard: I found that if you use it to put in an integer valuse, like x days ago |
| 15:11 |
|
kf |
it does not work without an additional trick |
| 15:11 |
|
kf |
because of the ' ' aroudn the value |
| 15:11 |
|
oleonard |
Good point, I didn't test that. I tested with strings and dates. |
| 15:12 |
|
kf |
those work fine |
| 15:12 |
|
kf |
I did a trick in sql to make it work |
| 15:12 |
|
kf |
cast(<<Days ago>> as decimal) |
| 15:13 |
|
kf |
this worked - but I am sure there are better ways to do it |
| 15:13 |
|
oleonard |
I obviously don't have pastebot0's ear. |
| 15:13 |
|
oleonard |
http://paste.koha-community.org/138 |
| 15:13 |
|
|
druthb joined #koha |
| 15:13 |
|
oleonard |
Sorry for the CONCATs in that, I just tested the last query I'd used |
| 15:13 |
|
oleonard |
Good morning druthb |
| 15:14 |
|
kf |
it's perfect, thx |
| 15:14 |
|
wizzyrea |
oleonard did you tell pastebot which channel to send your paste to? |
| 15:14 |
|
oleonard |
Tricky pastebot0! |
| 15:14 |
|
druthb |
hi, oleonard! :) |
| 15:14 |
|
wizzyrea |
(I sometimes forget and have the same problem you just did) |
| 15:16 |
|
* oleonard |
thinks that when it comes to channels there is only one |
| 15:16 |
|
wizzyrea |
:) |
| 15:16 |
|
wizzyrea |
I never really understood why it defaulted to "none" |
| 15:19 |
|
kf |
hm, so you don't accidently share the wrong things? |
| 15:20 |
|
wizzyrea |
i suppose if you're using the koha paste to share naughty literature with your clandestine online love interest you might not want it to default to the channel |
| 15:20 |
|
wizzyrea |
so I suppose you have a point there |
| 15:20 |
|
wizzyrea |
;) |
| 15:20 |
|
kf |
lol |
| 15:21 |
|
* druthb |
chuckles. |
| 15:23 |
|
tcohen |
wahanui1: is bug 3929 important? |
| 15:23 |
|
huginn |
Bug http://bugs.koha-community.org[…]w_bug.cgi?id=3929 enhancement, PATCH-Sent, ---, paul.poulain, RESOLVED FIXED, parameters in guided reports |
| 15:24 |
|
tcohen |
wahanui1: you lost the magic |
| 15:24 |
|
wahanui1 |
tcohen: huh? |
| 15:24 |
|
druthb |
wahanui1: wizzyrea? |
| 15:24 |
|
wahanui1 |
hmmm... wizzyrea is a nerd |
| 15:24 |
|
druthb |
hasn't lost all its' marbles, apparently. |
| 15:25 |
|
oleonard |
I wonder how difficult it would be to get guided reports screen output to automatically link to biblios (for biblio.title, biblio.biblionumber), patrons (for borrowers.surname) etc. |
| 15:25 |
|
druthb |
oleonard++ |
| 15:25 |
|
rhcl_away |
wahanui1: wahanui1? |
| 15:25 |
|
wahanui1 |
i am onboard I think |
| 15:26 |
|
oleonard |
Let's hear some real enthusiasm wahanui1! |
| 15:26 |
|
rhcl_away |
dude needs some coffee |
| 15:26 |
|
|
rhcl_away is now known as rhcl |
| 15:27 |
|
oleonard |
wahanui1: forget wahanui1 |
| 15:27 |
|
wahanui1 |
oleonard: I forgot wahanui1 |
| 15:27 |
|
oleonard |
wahanui1 is excited and ready for anything! |
| 15:27 |
|
rhcl |
he probably just needs some training |
| 15:27 |
|
oleonard |
wahanui1: wahanui1? |
| 15:27 |
|
wahanui1 |
i am excited and ready for anything! or ready to help! |
| 15:28 |
|
wizzyrea |
oleonard: LOL @ dalek |
| 15:29 |
|
oleonard |
wizzyrea: Except your friends now think I want him to be exterminated! |
| 15:29 |
|
wizzyrea |
hehe unlikely :) |
| 15:35 |
|
oleonard |
kf: Can you describe the kind of query you were doing where a numeric parameter failed? |
| 15:35 |
|
oleonard |
I tried doing one with AND items.itemlost = <<Number>> and it worked |
| 15:42 |
|
kf |
one second |
| 15:44 |
|
pastebot0 |
"kf" at 193.197.29.135 pasted "select concat('<a href="/cgi-b" (12 lines) at http://paste.koha-community.org/139 |
| 15:45 |
|
kf |
it's one of my reports related to fines and notices |
| 15:45 |
|
kf |
for finding borrowers with things overdue since x days |
| 15:45 |
|
kf |
so you can write them another mail or letter |
| 15:46 |
|
oleonard |
"Seit" ? |
| 15:50 |
|
kf |
Since |
| 15:50 |
|
kf |
sorry, thought I had translated everything |
| 15:51 |
|
kf |
oh, translated to much |
| 15:51 |
|
kf |
OD since = Seit column |
| 16:00 |
|
|
druthb left #koha |
| 16:00 |
|
kf |
bye all and have a nice weekend |
| 16:00 |
|
|
kf left #koha |
| 16:02 |
|
chris_n |
is there a way to mass renew patron accounts from the staff interface? |
| 16:06 |
|
paul_p |
chris_n, not that I know. |
| 16:06 |
|
oleonard |
If there is it must be a closely-guarded secret |
| 16:06 |
|
* chris_n |
thinks there should be |
| 16:06 |
|
paul_p |
but in our queue (sponsored by a new customer) there is a "bulkedit" of patrons ;-) |
| 16:06 |
|
chris_n |
especially for schools :) |
| 16:06 |
|
chris_n |
that might work |
| 16:07 |
|
jwagner |
Our Bug 3468 is patron batch edit as well |
| 16:07 |
|
huginn |
Bug http://bugs.koha-community.org[…]w_bug.cgi?id=3468 enhancement, PATCH-Sent, ---, jwagner, ASSIGNED, Enhanced patron searching, patron batch edit/delete |
| 16:13 |
|
* chris_n |
resorts to a little sql magick on the back end |
| 16:14 |
|
chris_n |
basically we are coordinating our patron accounts with the student id card expiration date |
| 16:14 |
|
chris_n |
makes life easier administratively |
| 16:14 |
|
oleonard |
Sounds like paul_p's batch edit might work well for that |
| 16:14 |
|
chris_n |
yup |
| 16:18 |
|
|
zpinhead joined #koha |
| 16:18 |
|
oleonard |
Hi zpinhead |
| 16:19 |
|
zpinhead |
hi. |
| 16:19 |
|
zpinhead |
druthb suggested i ask about this. |
| 16:19 |
|
zpinhead |
interested in using koha for 'special collections'. |
| 16:19 |
|
zpinhead |
lots of weird requirements. |
| 16:19 |
|
zpinhead |
1) preserve user information for ever. |
| 16:19 |
|
zpinhead |
(traceability in case of theft, damage) |
| 16:19 |
|
zpinhead |
items always stay in room -- user gives back at end of day |
| 16:20 |
|
zpinhead |
then borrows in room next day. |
| 16:20 |
|
zpinhead |
request items from ead files -- request at level of 'box' or 'folder' |
| 16:20 |
|
zpinhead |
or item. |
| 16:20 |
|
zpinhead |
like this product -- aeon from atlas systems. |
| 16:20 |
|
zpinhead |
http://www.atlas-sys.com/products/aeon/ |
| 16:22 |
|
zpinhead |
druthb suggested: "If you build the notion of "Container" right, then it'll work for any level of nesting." |
| 16:22 |
|
zpinhead |
folks are talking about buying aeon -- very closed architecture. |
| 16:22 |
|
zpinhead |
windows specific clients. |
| 16:22 |
|
zpinhead |
would much prefer open source, but have no ready alternative. |
| 16:22 |
|
zpinhead |
wondering how hard to do with koha. |
| 16:24 |
|
oleonard |
zpinhead: Would your organization be willing to spend some of the money they'd have spent on Aeon to develop the required functionality for Koha? |
| 16:24 |
|
oleonard |
That may be what is required. |
| 16:24 |
|
wizzyrea |
short term outlay for long term benefit |
| 16:24 |
|
wizzyrea |
and benefits to libraries like yours |
| 16:24 |
|
oleonard |
http://wiki.koha-community.org[…]/Hourly_Loans_RFC |
| 16:25 |
|
zpinhead |
well, i don't know. but there is a budget, and a non-trivial one, for yearly maintenance, and initial cost. |
| 16:25 |
|
zpinhead |
aeon is non-trivial cost -- it's more down to how 1) time -- not sure anyone want to wait for dev. |
| 16:26 |
|
zpinhead |
(they have been waiting, like, 30 years, for an adequate solution). |
| 16:26 |
|
zpinhead |
so, from my perspective, what's a few more months. |
| 16:26 |
|
zpinhead |
and 2) can i be persuasive about open source. |
| 16:27 |
|
zpinhead |
my experience with atlas is: flashy windows interface -- poor integration with other tools, very |
| 16:27 |
|
zpinhead |
little api -- sometimes none, and no interest in any. |
| 16:28 |
|
wizzyrea |
sounds like all the worst things about a proprietary ILS |
| 16:29 |
|
wizzyrea |
well, hourly loans are indeed on the horizon, that would help you. Patron records can be kept indefinitely (though probably you'd want to archive them periodically |
| 16:30 |
|
* oleonard |
wonders if hourly loans are delayed or if they're being tested by the sponsor |
| 16:31 |
|
wizzyrea |
wasn't that a sekjal thing? |
| 16:31 |
|
wizzyrea |
or, it is now, anyway? |
| 16:32 |
|
sekjal |
I've got to talk to my funding body, and get some wheels in motion as to implementation plan |
| 16:32 |
|
jwagner |
oleonard, was that directed at me? Our hourly loans feature has still not been approved by the sponsor |
| 16:33 |
|
zpinhead |
oleonard -- not sure they actually have fines for these things -- it's more like, they walk up |
| 16:33 |
|
zpinhead |
to you and ask for it back. the items never leave the guarded room, they have a map that shows |
| 16:33 |
|
zpinhead |
where each person is sitting, and what that person has borrowed. |
| 16:34 |
|
zpinhead |
@wizzyrea -- exactly. |
| 16:34 |
|
huginn |
zpinhead: I'll give you the answer just as soon as RDA is ready |
| 16:34 |
|
wahanui1 |
i already had it that way, huginn. |
| 16:34 |
|
zpinhead |
and buying something like that now -- what a step back, except that there is no ready alternative. |
| 16:35 |
|
wizzyrea |
well |
| 16:35 |
|
wizzyrea |
you can either pay to be locked in, or pay (maybe a little less overall) to be free |
| 16:36 |
|
wizzyrea |
free to modify, free to migrate, free. |
| 16:36 |
|
wizzyrea |
and, you get an excuse to hang out with us :) |
| 16:37 |
|
wizzyrea |
there is no system in place now |
| 16:37 |
|
wizzyrea |
? |
| 16:37 |
|
|
brendan__ joined #koha |
| 16:37 |
|
oleonard |
jwagner: No, it wasn't directed at you. I don't expect to ever see any of the LEK stuff out in the wild |
| 16:38 |
|
jwagner |
we haven't given up hope.... |
| 16:38 |
|
oleonard |
Two years on? |
| 16:38 |
|
jwagner |
Not quite one year with us |
| 16:38 |
|
zpinhead |
@wizzyrea -- right now for special collections, they have three part forms -- pink, yellow, white, |
| 16:38 |
|
huginn |
zpinhead: downloading the Perl source |
| 16:38 |
|
wizzyrea |
!! paper! |
| 16:39 |
|
wizzyrea |
ignore huginn, he's on a rampage today (he's a bot) |
| 16:39 |
|
zpinhead |
the pink form goes on the shelf (in the vault) to show the item is out, the yellow goes in a box, |
| 16:39 |
|
wizzyrea |
ah, so you'd need additional receipts (or the ability to dupe print receipts) as well |
| 16:39 |
|
zpinhead |
and the white goes in a pocket type organizer that matches the chair numbers where people sit. |
| 16:39 |
|
wizzyrea |
or triplicate paper :P |
| 16:40 |
|
wizzyrea |
for your receipt printer |
| 16:40 |
|
zpinhead |
definitely need to keep the pink for -- very important to have |
| 16:40 |
|
zpinhead |
the shelf form. |
| 16:40 |
|
wizzyrea |
and an impact receipt printer, since the heat ones won't do multicopy receipts |
| 16:40 |
|
* wizzyrea |
goes off on the practicalities of this for a moment... sorry |
| 16:40 |
|
zpinhead |
and they like their 'organizer' shows at a glance what is where by who. |
| 16:41 |
|
zpinhead |
also need a sort of call slip mechanism -- users request items, and they get 'paged' from |
| 16:41 |
|
|
tcohen left #koha |
| 16:41 |
|
zpinhead |
the vault. |
| 16:42 |
|
wizzyrea |
like holds, but someone gets notified that something needs to be fetched |
| 16:42 |
|
wizzyrea |
? |
| 16:42 |
|
zpinhead |
right. |
| 16:42 |
|
wizzyrea |
koha can email a librarian every time a hold is placed, iirc |
| 16:42 |
|
wizzyrea |
that, mostly, would depend on how you cataloged your items into koha |
| 16:43 |
|
wizzyrea |
which might take some trial and error |
| 16:43 |
|
zpinhead |
i think, maybe the biggest deal is treating EAD files like giant multi part MARC records. |
| 16:45 |
|
wizzyrea |
yea, that's probably your worst challenge re:koha. |
| 16:46 |
|
|
cait joined #koha |
| 16:51 |
|
|
paul_p left #koha |
| 17:00 |
|
|
zpinhead left #koha |
| 17:03 |
|
|
sophie_m left #koha |
| 17:10 |
|
|
snail joined #koha |
| 17:11 |
|
snail |
morning all |
| 17:29 |
|
|
jwagner is now known as jwagner_away |
| 17:30 |
|
|
sekjal is now known as sekjal_away |
| 17:36 |
|
|
hdl left #koha |
| 17:57 |
|
|
druthb joined #koha |
| 18:31 |
|
rangi |
morning |
| 18:33 |
|
cait |
hi rangi |
| 18:33 |
|
|
cait left #koha |
| 18:35 |
|
|
brendan__ left #koha |
| 18:43 |
|
hudsonbot |
Starting build 343 for job Koha_Master (previous build: SUCCESS) |
| 18:46 |
|
rangi |
does this work for people http://bugs.koha-community.org[…]med&namedcmd=5574 |
| 18:49 |
|
huginn |
New commit(s) kohagit: Bug 5691 - Delete all items respects independentbranches system preferences <http://git.koha-community.org/[…]04dfbac882744c3df> |
| 18:49 |
|
|
cait joined #koha |
| 18:50 |
|
rangi |
yay cait |
| 18:50 |
|
cait |
? |
| 18:50 |
|
rangi |
can you check something for me please? |
| 18:50 |
|
rangi |
does this work for people http://bugs.koha-community.org[…]med&namedcmd=5574 |
| 18:50 |
|
cait |
and I thought you were happy to see me... ;) |
| 18:51 |
|
rangi |
of course, i always am |
| 18:51 |
|
cait |
There is no saved search named '5574'. |
| 18:52 |
|
cait |
what are you working on? |
| 18:52 |
|
rangi |
dang |
| 18:52 |
|
rangi |
trying to figure out how to do public saved searches |
| 18:53 |
|
|
jcamins_away is now known as jcamins |
| 18:54 |
|
cait |
hm |
| 18:55 |
|
cait |
have you checked your preferences page? |
| 18:55 |
|
cait |
oh |
| 18:55 |
|
cait |
i see your shared search there |
| 18:58 |
|
rangi |
ah yeah i just switched it on |
| 18:58 |
|
rangi |
so if you click on it does ti work? |
| 18:59 |
|
rangi |
http://bugs.koha-community.org[…]med&namedcmd=5574 hopefully pasting this url now works too |
| 19:00 |
|
oleonard |
Clicking "run" on the "needs signoff" saved search works |
| 19:00 |
|
rangi |
yay |
| 19:01 |
|
rangi |
and the 5574? if so ill send it to biblibre |
| 19:01 |
|
oleonard |
I don't see a 5574 search |
| 19:01 |
|
oleonard |
That link doesn't work for me either. |
| 19:01 |
|
cait |
rangi: no |
| 19:01 |
|
rangi |
ohh interesting |
| 19:01 |
|
rangi |
i wonder why one does but the other doesnt |
| 19:01 |
|
cait |
the link you pasted does not work |
| 19:02 |
|
rangi |
is there a no status one showing? |
| 19:02 |
|
cait |
he same as before |
| 19:02 |
|
cait |
unknown search |
| 19:02 |
|
rangi |
how odd |
| 19:02 |
|
cait |
in the preferences I see 2 saved public searches: needs sign-off and Koha 3.4 enhancemants from paul |
| 19:03 |
|
oleonard |
And I see, in addition, a "signed off" one from cait |
| 19:03 |
|
cait |
:) |
| 19:04 |
|
cait |
i logged out/in - no change |
| 19:09 |
|
rangi |
wow, mohan is persistent .. .and wrong |
| 19:09 |
|
hudsonbot |
Project Koha_Master build #343: SUCCESS in 26 min: http://hudson.koha-community.o[…]/Koha_Master/343/ |
| 19:09 |
|
hudsonbot |
Chris Cormack: Bug 5691 - Delete all items respects independentbranches system preferences |
| 19:13 |
|
rangi |
eek and he uses boxbe |
| 19:13 |
|
jcamins |
What? |
| 19:13 |
|
jcamins |
Sorry, I'm with you now. |
| 19:13 |
|
jcamins |
I thought that was your response to your latest commit. ;) |
| 19:15 |
|
cait |
boxbe? |
| 19:15 |
|
rangi |
means if you send him mail you have to go fill in an online form before he gets it, with a captcha |
| 19:16 |
|
rangi |
tis a pretty over the top anti spam thing, also means that boxbe reads all your mail |
| 19:16 |
|
jcamins |
Oh, I never fill those out when people ask for help on a mailing list. |
| 19:17 |
|
rangi |
yeah |
| 19:17 |
|
jcamins |
They can do without my advice. |
| 19:33 |
|
|
sekjal_away is now known as sekjal |
| 20:01 |
|
jcamins |
Where would I look to find out who the staff person who checked a book out was? |
| 20:02 |
|
cait |
statistics or action_logs |
| 20:02 |
|
cait |
I am quite sure you can see it in the log viewer |
| 20:02 |
|
cait |
I used it to check the self check in the beginning |
| 20:04 |
|
jcamins |
Yeah, that's what I need to do. |
| 20:06 |
|
jcamins |
describe statistics; |
| 20:06 |
|
jcamins |
That's the third time I've done that this week. |
| 20:07 |
|
|
brendan__ joined #koha |
| 20:08 |
|
jcamins |
cait: any chance you have the report you used? |
| 20:09 |
|
cait |
no report |
| 20:09 |
|
cait |
only the log viewer from tools |
| 20:09 |
|
jcamins |
Aww. |
| 20:09 |
|
jcamins |
Oh, I see. |
| 20:09 |
|
cait |
but it should not be hard to find out |
| 20:09 |
|
jcamins |
No, I just figured it out, I think. |
| 20:10 |
|
jcamins |
Oops. |
| 20:10 |
|
jcamins |
Don't do a SELECT DISTINCT on a TEXT field. |
| 20:10 |
|
jcamins |
Just don't. |
| 20:10 |
|
jcamins |
;) |
| 20:13 |
|
jcamins |
Why is action_logs.action a TEXT field? |
| 20:22 |
|
cait |
don't ask me |
| 20:22 |
|
cait |
I tried to clean up borrowers |
| 20:22 |
|
cait |
but it's an unfinished project :( |
| 20:24 |
|
cait |
and lots of unused columns |
| 20:24 |
|
cait |
ok, time to read a book :) |
| 20:25 |
|
cait |
bye all :) |
| 20:27 |
|
|
cait left #koha |
| 20:33 |
|
|
Nate__ left #koha |
| 20:43 |
|
|
jwagner_away is now known as jwagner |
| 20:43 |
|
|
jwagner left #koha |
| 20:49 |
|
|
hdl joined #koha |
| 20:50 |
|
|
hdl1 joined #koha |
| 20:50 |
|
|
hdl left #koha |
| 20:58 |
|
|
oleonard left #koha |
| 21:05 |
|
|
Brooke_ joined #koha |
| 21:05 |
|
Brooke_ |
kia ora |
| 21:16 |
|
wizzyrea |
hi brooke |
| 21:17 |
|
Brooke_ |
:) |
| 21:26 |
|
jcamins |
Does anyone know anything about translated XSLTs not working? |
| 21:26 |
|
jcamins |
We're getting this error, and it seems like I should remember why: /home/koha/kohaclone/koha-tmpl/opac-tmpl/prog/hi/xslt/MARC21slim2OPACResults.xsl:264: |
| 21:26 |
|
jcamins |
parser error : Opening and ending tag mismatch: img line 263 and xsl:if </xsl:if> |
| 21:26 |
|
jcamins |
Oops, sorry, I meant that to be on one line. |
| 21:43 |
|
jcamins |
Is it safe to run perl translate fr-FR |
| 21:43 |
|
jcamins |
on a live system? |
| 21:47 |
|
snail |
rolled back COI edit on the LibLime page https://secure.wikimedia.org/w[…]me&action=history |
| 21:50 |
|
snail |
jcamins looking at that error, it suggests that unclosed images tags, which work fine in HTML but not XSLT |
| 21:50 |
|
jcamins |
snail: I think the problem is that we need to re-run the translate script. |
| 21:50 |
|
snail |
the img tag needs to look like: <img ...... /> |
| 21:50 |
|
gmcharlt |
snail: actually, I think it's a mismatch in the XSLT itself, not an an image tag generated by it |
| 21:51 |
|
gmcharlt |
jcamins: and that sounds plausible |
| 21:51 |
|
snail |
oh, ok, sorry |
| 21:51 |
|
|
hdl1 left #koha |
| 22:00 |
|
|
Brooke_ left #koha |
| 22:02 |
|
|
sekjal left #koha |
| 22:06 |
|
|
jcamins is now known as jcamins_away |
| 22:18 |
|
|
francharb left #koha |
| 22:20 |
|
|
druthb left #koha |
| 23:04 |
|
|
brendan__ left #koha |
