| Time |
S |
Nick |
Message |
| 13:21 |
|
gmcharlt |
now to figure out why it randomly died |
| 13:29 |
|
owen |
Ah, so gmcharlt holds the secret reins to newlogbot! Good to know. Now if we could only get one of our regulars op status. |
| 13:37 |
|
slef |
owen: gmc is the clue |
| 13:41 |
|
slef |
the gmc@ bit in newlogbot's id |
| 13:49 |
|
ryan |
fbcit-away: ping |
| 13:50 |
|
owen |
By the way slef, thanks for the positive feedback on the changes to opac-topissues. I'm going to be looking for additional cases where that kind of change might be workable. |
| 14:12 |
|
fbcit |
ryan: can you point me to some docs/examples of loop context vars for TemplatePro? |
| 14:33 |
|
gmcharlt |
hdl or paul: about? |
| 14:33 |
|
paul |
yep |
| 14:33 |
|
paul |
hello gm |
| 14:34 |
|
paul |
hello gmcharlt |
| 14:34 |
|
gmcharlt |
hi paul |
| 14:34 |
|
gmcharlt |
could you take a quick look at bug 2000? I think ryan's proposal is the way to go, but it depends on people being comfortable with the smart-rules.pl interface |
| 14:35 |
|
paul |
bug 2000... sounds a nice number. I'll look |
| 14:35 |
|
slef |
owen: other type of widely-applicable change is jumping through to the details if a search returns only one result |
| 14:38 |
|
paul |
gmcharlt: i don't understand well the problem... |
| 14:38 |
|
gmcharlt |
paul: issue is this - if you are using the two separate interfaces |
| 14:38 |
|
gmcharlt |
e.g., fines admin & issuing rules admin |
| 14:39 |
|
gmcharlt |
you can define fine rules, but let's say your policies are simply and you're content to just default a default fine for all branches and each item type |
| 14:39 |
|
gmcharlt |
then when you go to add issuing rules in the older interface |
| 14:39 |
|
gmcharlt |
and define a specific one for a branch, itemtype, and patron cat |
| 14:39 |
|
paul |
older interface : the non smart one, right ? |
| 14:40 |
|
gmcharlt |
(right) |
| 14:40 |
|
gmcharlt |
it adds an empty value for the fine rules for that specific entry |
| 14:40 |
|
gmcharlt |
thus "hiding" the default fines rules you set up initially |
| 14:41 |
|
gmcharlt |
but because the fine entries are blank, going back to the fine rules interface won't show you that this (presumably unintended) override has taken place |
| 14:42 |
|
gmcharlt |
whereas if you use the smart rules interface, it's obvious from the UI that you've defined a more specific fine rule |
| 14:50 |
|
paul |
ok, I think I understand (although it's a complex situation...) |
| 14:51 |
|
paul |
Shouldn't we change the older interface behaviour more than do what rch suggest ? |
| 14:51 |
|
paul |
to save nothing when fine is empty ? |
| 14:52 |
|
gmcharlt |
but having the issuingrules interface save nothing in the fines column is exactly the problem |
| 14:52 |
|
paul |
so In don't have understood well... |
| 14:53 |
|
gmcharlt |
right now when looking for a fine or issuing rule to apply for a transaction |
| 14:53 |
|
gmcharlt |
it goes from most specific to least specific |
| 14:53 |
|
gmcharlt |
if the most specific entry has null or nothing in the fine columns |
| 14:53 |
|
gmcharlt |
it curently can't tell whether the policy *intentionally* overrides a default fine set at a less specific level |
| 14:54 |
|
gmcharlt |
or whether the override was accidental |
| 14:55 |
|
paul |
ah, ok, I understand now. |
| 14:55 |
|
paul |
does "0" mean "no opinion" or "set to 0" ... |
| 14:55 |
|
gmcharlt |
exactly |
| 14:56 |
|
paul |
I thought, in the old interface, that I had differentiated 0 and "" (empty) |
| 14:56 |
|
paul |
to avoid this problem |
| 14:56 |
|
paul |
mmm... I did this for issuing, not for fines... |
| 15:03 |
|
ryan |
the problem then is you are testing 0 vs '' on issuelength. Which column do you test on for fines, and then you are using two different rows from the able to specify circ params and fines params. |
| 15:03 |
|
ryan |
Seems to me that one row in the table should specify all the behaviors |
| 15:03 |
|
paul |
right. maybe having 1 table for both issuing & fines was a wrong ide |
| 15:03 |
|
paul |
idea |
| 15:05 |
|
ryan |
i think it's interface problem more than db problem |
| 15:06 |
|
gmcharlt |
I could see solving it by spliting the rules into two separate tables, but I think changing the UI is better (and certainly quicker, since we already have everything we need) |
| 15:45 |
|
fbcit |
any ideas on how to say this so that perl likes it: $debug ? (use Data::Dumper); |
| 15:45 |
|
atz |
fbcit: it's tricky, you have to do it in a BEGIN blick |
| 15:45 |
|
atz |
*block |
| 15:45 |
|
atz |
and you can't use use |
| 15:46 |
|
atz |
see the way C4::Context handles CGI::Carp |
| 15:47 |
|
atz |
basically it does "require" and then "import" |
| 15:47 |
|
fbcit |
so I'll need to require and then import the subs I want to use? |
| 15:48 |
|
atz |
right, because perl won't let you conditionalize a use statement |
| 15:48 |
|
fbcit |
k |
| 15:48 |
|
fbcit |
tnx atz |
| 15:48 |
|
atz |
np |
| 16:53 |
|
paul |
gmcharlt ? |
| 16:53 |
|
gmcharlt |
hi paul |
| 16:53 |
|
paul |
are you 3 patches "granular permissions - ..." related to the mail you've sent to koha-devel ? |
| 16:54 |
|
gmcharlt |
yes (actually 9, plus one I had to send to kados directly) |
| 16:54 |
|
paul |
OK, 3 more in my mailbox. |
| 16:55 |
|
paul |
seems the bot deliver them through boat or horse... |
| 16:56 |
|
gmcharlt |
paul: hopefully the general mechanism is small enough for 3.0. fully fleshing out the permissions for each module I would see as a longer-term project |
| 18:48 |
|
owen |
fbcit, do you know how the label item search works? Or anyone else? The results for a keyword search from that interface do not match those made from the catalog |
| 18:49 |
|
fbcit |
owen: it works in a very broken fashion |
| 18:49 |
|
fbcit |
I started into it a while back to attempt to *fix* it, but gave up due to lack of time |
| 18:50 |
|
fbcit |
it really needs to be refactored to use the search API |
| 18:53 |
|
owen |
Okay, so it uses it's very own searching method |
| 18:53 |
|
owen |
fbcit: Have you seen bug 1870? |
| 18:55 |
|
owen |
Those may be issues that should wait until someone tackles the search method problem |
| 18:55 |
|
fbcit |
how coincidental |
| 18:55 |
|
fbcit |
I just fixed that very thing |
| 18:55 |
|
fbcit |
actually it was there |
| 18:56 |
|
fbcit |
I think andrew added it |
| 18:56 |
|
fbcit |
but I broke it and then fixed it |
| 18:56 |
|
fbcit |
owen:did you notice if it appeared to work ok with the files I sent to you? |
| 18:57 |
|
fbcit |
opps... |
| 18:57 |
|
gmcharlt |
owen: re closing of 1809, I disagree unless it just changed - the horizontal scrollbar was justed moved to within the page |
| 18:57 |
|
fbcit |
owen: I see, it is the links that are broken |
| 18:57 |
|
acmoore |
It's better than it was, but it could use a lot of help. |
| 18:57 |
|
fbcit |
owen: your correct, that should probably wait until the search stuff is corrected |
| 18:57 |
|
owen |
gmcharlt: moved within the page, and the edit/delete links were moved to the beginning of the table so that you don't have to scroll to see them. |
| 18:58 |
|
fbcit |
acmoore: yea, the entire search code needs to be thrown out and rewritten |
| 18:58 |
|
owen |
I interpreted the scrolling to the links to be the core of the issue |
| 18:58 |
|
acmoore |
fbcit, should it not be using SimpleSearch? Should SimpleSearch even exist? |
| 18:59 |
|
acmoore |
besides that, even if it's using the right search stuff, there is a bunch of useless code in that script. |
| 18:59 |
|
fbcit |
acmoore: I looked at SimpleSearch some thinking it might work |
| 18:59 |
|
gmcharlt |
owen: I think a horizontal scrollbar within the page is still less than ideal, but obviously this isn't the most signficant bug |
| 19:00 |
|
fbcit |
acmoore: I agree |
| 19:01 |
|
fbcit |
no use re-inventing the wheel here |
| 19:01 |
|
owen |
gmcharlt: I think the best solution would be to be able to customize which columns show up in that additem table...perhaps by changing the framework? I think we've talked about that before. |
| 19:01 |
|
acmoore |
I just didn't really feel right ripping out dozens of lines of code that I didn't fully understand, considering that I'm a rather new kid on the block. |
| 19:02 |
|
gmcharlt |
owen: yeah, we did talk about it befoe |
| 19:02 |
|
acmoore |
fbcit, next time I do something in that file, though, I'm not going to be as reserved. |
| 19:02 |
|
fbcit |
hehe |
| 19:03 |
|
fbcit |
you see how much commenting I did to figure out what was going on originally in the results sub |
| 19:03 |
|
acmoore |
yup. me too. |
| 19:04 |
|
acmoore |
b |
| 19:04 |
|
fbcit |
b ? |
| 19:04 |
|
acmoore |
heh. wrong window. |
| 19:05 |
|
acmoore |
I thought I was in emacs and hit C-x b <return>. Nothing happened. |
| 19:20 |
|
atz |
how does "issuingbranch" in issues get set? |
| 19:20 |
|
ryan |
it doesn't. |
| 19:20 |
|
atz |
mine all appear to be NULL |
| 19:20 |
|
ryan |
vestigial column, i think |
| 19:20 |
|
ryan |
issuingbranch would never be different from branch |
| 19:21 |
|
atz |
ok, cool... i'll update bor_issues_top |
| 19:21 |
|
atz |
(still working on that) |
| 19:39 |
|
ryan |
atz: did you look at catalogue_stats ? |
| 19:40 |
|
atz |
i don't think so |
| 19:40 |
|
atz |
do you want me to shift to that one? |
| 19:41 |
|
ryan |
that and circ stats need the item-level itype fix |
| 19:41 |
|
atz |
yeah, in this case a main flaw was the separation of issues and old_issues |
| 19:41 |
|
atz |
and other outdated mappings |
| 19:42 |
|
ryan |
ah, right |
| 19:44 |
|
atz |
there may be other reports similarly affected |
| 19:45 |
|
gmcharlt |
alas, those reports were pretty much broken before the issues/old_issues split |
| 19:45 |
|
atz |
gmcharlt: true |
| 19:46 |
|
kados |
better get testing :-) |
| 19:51 |
|
fbcit |
ryan: can you confirm bug 1916 is still an issue? |
| 19:58 |
|
ryan |
fbcit: you are able to print accented characters with the labels module ? |
| 19:58 |
|
ryan |
i.e. pdf generation ? |
| 20:07 |
|
ryan |
fbcit: ok, just tested, and seems ok. |
| 20:07 |
|
ryan |
i was working with a backport of the labels code on a 2.2 system when I reported it. |
| 20:07 |
|
ryan |
must be specific to that installation, or have been otherwise fixed |
| 20:08 |
|
fbcit |
k |
| 20:08 |
|
fbcit |
I was trying to hunt up some data with accented chars |
| 20:08 |
|
fbcit |
I'll mark it fixed then. |
| 20:09 |
|
ryan |
cool, thx |
| 20:19 |
|
frapell |
hi guys, does anyone knows what happened with the skinning contest ? |
| 20:19 |
|
kados |
frapell: yes, it's proceeding, there were three submissions |
| 20:19 |
|
kados |
frapell: darci is back among the living and she should be announcing something very soon |
| 20:19 |
|
kados |
frapell: did you send in a submission? |
| 20:20 |
|
frapell |
kados: glad to hear about darci :) |
| 20:20 |
|
frapell |
kados: yes, i worked in the "Temita" product |
| 11:16 |
|
sylvain |
Hi all |
| 11:17 |
|
sylvain |
I have a little question about 2.2.9, when you search via isbn, dashes are stripped away from the query, and they should be too when you input isbn, but it seems it is not the case. is there a special config to enter ? |
| 11:32 |
|
fbcit |
g'morning #koha |
| 11:37 |
|
kados |
morning fbcit |
| 11:58 |
|
fbcit |
kados: why is it that during some db updates I am dumped back to the installer login rather than to the standard koha login page? |
| 11:58 |
|
fbcit |
perhaps its a cookie thing? |
| 11:59 |
|
fbcit |
ie. after the update from this last rebase I was sent back to http://biblios.campus.foundati[…]tep=3&op=finished |
| 11:59 |
|
fbcit |
logging in there results in being sent back to mainpage.pl to login again :\ |
