Time |
S |
Nick |
Message |
12:03 |
|
brendan |
morning #koha |
12:08 |
|
soroush |
Hello all! |
12:09 |
|
soroush |
I can search the Koha library from the admin interface, but not the opac interface. Have I missed something? (I'm using nozebra) |
12:14 |
|
brendan |
did you check your system preference for nozebra? |
12:50 |
|
soroush |
hi brendan. This would be under System Preferences > Cataloguing? I have nozebra ON. |
12:52 |
|
brendan |
ok |
15:56 |
|
atz |
soroush: why can't you search on OPAC? do you get no results or can you not even view the page? |
16:04 |
|
soroush |
Hi atz. I can view the page, but get no search results. |
16:04 |
|
soroush |
I do however get search results from the admin interface (Intranet?). |
16:05 |
|
soroush |
also, I was using the wiki page for migrating from 2.2 to 3. |
17:44 |
|
danny |
hello everyone |
17:46 |
|
danny |
I am taking a look at amazon enhanced content, for another project I setup for my library I found that I was able to match a lot of music and video content based on UPC which in marc21 we catalog in the 024 tag |
17:51 |
|
danny |
does anyone know if this something non-US libraries would keep track of? |
17:52 |
|
danny |
although I should probably ask this earlier in the day to get some more non-US people hehe |
17:58 |
|
gmcharlt |
danny: or later :) |
17:58 |
|
gmcharlt |
danny: might want to check the UNIMARC manual to see if the EAN is recorded anywhere |
17:59 |
|
danny |
ok, let me check on that |
18:13 |
|
nicomo |
yep EAN is in UNIMARC field 073 |
18:16 |
|
nicomo |
but I'm not sure it was entered very often in the records until recently |
20:40 |
|
liz-nekls |
very quiet |
21:08 |
|
pianohacker |
Hello, does anyone feel like weighing in on a billing design problem (technical)? |
21:08 |
|
pianohacker |
Trying to decide whether to use a simple markup language or HTML for complex formatting in queued messages |
21:10 |
|
pianohacker |
Since this billing project requires print bills (and PDF would be the easiest way of accomplishing this), _some_ formatting is required, though currently all I need is a table (drawn by PDF::Table and represented in the markup language as "| Column | another column |") |
21:10 |
|
pianohacker |
thoughts? |
21:14 |
|
danny |
pianohacker: would this be something sys admins would be changing in a sys pref or something only changed by a developer? |
21:15 |
|
pianohacker |
danny: It's more a question of how bills are stored before they are emailed or printed as a batch |
21:15 |
|
pianohacker |
in the database |
21:16 |
|
danny |
oh I see, so only devs would see this code? |
21:17 |
|
danny |
if looking at the database |
21:19 |
|
danny |
if i understand correctly are the pros that html is more customizable but takes up more space? |
21:19 |
|
pianohacker |
That and its harder to parse |
21:22 |
|
danny |
how would you be parsing this field? like for what purpose other than to just flat display it |
21:23 |
|
pianohacker |
To turn it into a PDF |
21:24 |
|
pianohacker |
This field would be sent as a formatted email (no parsing, just sent) or a PDF |
21:31 |
|
danny |
ah what about using like PDF::FromHTML, would that take care of parsing? |
21:33 |
|
pianohacker |
Hmm |
21:33 |
|
pianohacker |
Might be worth looking into |
21:35 |
|
pianohacker |
Looks useful, at least, but doesn't allow letterheads (currently implemented in my code as another PDF that is placed in the document) |
21:35 |
|
danny |
ah ok, I've never tried it just need a little looking |
21:38 |
|
danny |
ok well I've never worked with PDF::Table so my 2 cents is for HTML just because it is more familiar to most people, more customizable, and easy to send formatted emails, but if you can't parse it to pdf easy then that is a problem |
21:38 |
|
danny |
i am heading out, good luck and see you all tomorrow |
21:39 |
|
Sharon |
Hello |
21:39 |
|
Sharon |
Does anyone know if Koha works with LibraryThing for Libraries? |
22:00 |
|
hdl |
gmcharlt: around ? |
22:01 |
|
gmcharlt |
hdl: pong |
22:01 |
|
hdl |
hi |
22:02 |
|
hdl |
I pushed for the first time today. |
22:02 |
|
gmcharlt |
Sharon: no reason Koha couldn't work with LTL; not sure if anybody has implemented it yet |
22:03 |
|
hdl |
But I have a problem with Reserves and the fixes that requires new fields or tables. |
22:04 |
|
gmcharlt |
is this stuff you're trying to pull from 3.2? |
22:04 |
|
hdl |
Same problem with some circulation. |
22:05 |
|
hdl |
In fact, it seems that it mixes some bug fixing and some new features. |
22:08 |
|
gmcharlt |
hdl: I suppose that was inevitable |
22:11 |
|
hdl |
I wanted to make sure that those "fixes" were not meant to be in 3.0.1. |
22:12 |
|
hdl |
bug fix 2522 |
22:13 |
|
gmcharlt |
well, that bug is marked as an enhancement |
22:14 |
|
hdl |
yes. |
22:14 |
|
hdl |
2503 also. |
22:15 |
|
hdl |
Both made quite heavy changes. |
22:15 |
|
hdl |
good to know it is there. |
22:16 |
|
hdl |
good also to see that pushing should really be easy. |
22:17 |
|
hdl |
Do you think my proposal for november 15th and December 1st could be OK |
22:17 |
|
Sharon |
Galen thanks, NEKLS will look into it. we might as well be the first to use LTFL |
22:18 |
|
hdl |
should we organize a bug squashing session on 3.0 ? Or is it just silly ? |
22:23 |
|
gmcharlt |
hdl: well, a bug squashing in general is a good idea |
22:23 |
|
gmcharlt |
and could be tied to one of the integration periods for 3.2 |
22:24 |
|
gmcharlt |
a bug squashing session for 3.0 per se |
22:24 |
|
gmcharlt |
depends on usage |
22:24 |
|
gmcharlt |
I notice that gitweb isn't updating for the 3.0.x branch |
22:24 |
|
gmcharlt |
so I'll do something to fix that |
22:25 |
|
hdl |
if 3.0 has better quality |
22:25 |
|
hdl |
then 3.2 can also benefits from that. |
22:26 |
|
hdl |
Will there be a meeting around RFCs and features in 3.2 so that ppl could tell which point they are at ? |
22:27 |
|
gmcharlt |
hdl: yes, I need to schedule it |
22:54 |
|
hdl |
good night |