February 2003 - Koha-devel - lists.koha-community.org

[Bug 202] Branch dropbox always empty even if 2 branches defined
by bugzilla-daemon＠wilbur.katipo.co.nz 05 Feb '03

05 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=202 a.c.li(a)ieee.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 202] Branch dropbox always empty even if 2 branches defined
by bugzilla-daemon＠wilbur.katipo.co.nz 05 Feb '03

05 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=202 ------- Additional Comments From a.c.li(a)ieee.org 2003-02-05 21:49 ------- The branch dropbox in branch transfers seems to be also always empty. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 202] New: Branch dropbox always empty even if 2 branches defined
by bugzilla-daemon＠wilbur.katipo.co.nz 05 Feb '03

05 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=202 Summary: Branch dropbox always empty even if 2 branches defined Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net In the branch/printer selection screen, the branch selector seems to always contain 0 branches, even if 2 branches have been defined. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 201] New: Doing a transfer results in item with null branch
by bugzilla-daemon＠wilbur.katipo.co.nz 05 Feb '03

05 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=201 Summary: Doing a transfer results in item with null branch Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net If only a main branch is selected, but the user tries to do a branch transfer, the transferred item ends up with a holdingbranch of NULL. 1. The Circ2 function that does transfers should have thrown an exception or otherwise refuse to do such a thing 2. The user should not have the option to attempt this (preferably) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

standardizing tab size in the Koha source code
by Ambrose LI <acli＠ada.dhs.org> via forwarder 05 Feb '03

05 Feb '03

Hi, sorry for bringing up such a "trivial" thing as the correct tab size in source code. It seems that originally the source uses 4-character indents but 8-character tabs, but it seems that later source uses 4-character tabs. People don't seem to realize this, and as a result some files (e.g., returns.pl) have ended up in a messy state where some tabs are 4-character but some 8-character, so the source looks wrong no matter whether I set the tab size to 4 or 8 characters. Would someone second me in setting a standard tab size? So that all tabs would either mean 4 or 8 spaces. (Personally, I like 8-character tabs more, since the code will look right when I "less" (or even "cat") it in an xterm.) My rationale of standardizing the tab size are the following: 1. When the tab size is inconsistent, the code is difficult to read. There are a couple of bugs that I feel are very likely to be the result of having a difficulty in reading the code (in particular inconsistent indentation); i.e., IMHO, an inconsistent tab size is detrimental to our goal of making Koha stable. 2. Sometimes, to debug a problem you need to reformat the source to a consistent indentation. If the apparently-inconsistent indentation is actually consistent when a different tab size is used, effort is wasted and useless check-ins result. 3. It is a nuisance to constantly switch tab sizes editing different files (unless one use emacs, but the Koha source is not set up with emacs Local variables). 4. When the tab size is inconsistent, the code looks uglier than it really is. Someone (I forgot which developer) mentioned something to the effect that Koha code looks sort of ugly. I think ugly code would turn off people who wants to join the programming effort. I hope I haven't offended anyone; I just wish to avoid having different files having different tab sizes, or, worse, the same file having different tab sizes in different places. Best regards, -- Ambrose LI Cheuk-Wing <a.c.li(a)ieee.org>

1 0

[Bug 200] Returning withdrawn item doesn't show error message
by bugzilla-daemon＠wilbur.katipo.co.nz 05 Feb '03

05 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=200 a.c.li(a)ieee.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution| |FIXED ------- Additional Comments From a.c.li(a)ieee.org 2003-02-05 20:58 ------- Caused by incorrect placement of "last" statement in a multi-exit loop. Fixed in CVS. ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 200] New: Returning withdrawn item doesn't show error message
by bugzilla-daemon＠wilbur.katipo.co.nz 04 Feb '03

04 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=200 Summary: Returning withdrawn item doesn't show error message Product: Koha Version: CVS Platform: All OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Circulation AssignedTo: chris(a)katipo.co.nz ReportedBy: a.c.li(a)ieee.org QAContact: koha-devel(a)lists.sourceforge.net In the templates there is a TMPL_IF for withdrawn items; an error message should be shown. However, when I try to test returning withdrawn items, the error message does not actually appear (nothing shows up in the "messages" box). ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

[Bug 170] Returning a book reduces item count to zero
by bugzilla-daemon＠wilbur.katipo.co.nz 04 Feb '03

04 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=170 a.c.li(a)ieee.org changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |RESOLVED Resolution| |FIXED ------- Additional Comments From a.c.li(a)ieee.org 2003-02-05 19:29 ------- Fixed in CVS ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0

Logging on
by Tom Albrecht 04 Feb '03

04 Feb '03

Ok... it's been a while since I installed Koha. I ran a version a few months ago, as a demo to our church, and we're going to be rolling it out for our church library. So, I've communicated that there is going to be a final release in the next couple of months (I gleaned that from the dev list), so we put the "real" install off until then, but they wanted me to create an install so they can demo it to others in the church. Fine and good. So, I see that 1.9.0 is released today, I download it, and install it manually, the way I remember. Everything seems to come up fine, but there is this nifty new login feature on the OPAC interface. Hmmm, thinks I... very interesting. Then, I bring up the Koha website. There is a very imposing login screen sitting in front of me. This wasn't here before. I can't seem to find any documentation describing a login screen. Could someone please point me in the right direction to create a user, login, etc.? Tom Albrecht III

2 1

[Bug 199] categoryitems never update except for charges
by bugzilla-daemon＠wilbur.katipo.co.nz 04 Feb '03

04 Feb '03

http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=199 ------- Additional Comments From a.c.li(a)ieee.org 2003-02-05 17:25 ------- Added workaround to itemtypes.pl (counting biblioitems in addition to categoryitem) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.

1 0