We are seeing two problems with the box. First, the koha web pages take a loooong time to load. I suspect this is a DNS problem, but I'm not sure.
I'm usre now. I removed bind from the system and made it just use our regular DNS server. The slowness problem went away.
The second problem is enough to make my wife question the feasibility of using Koha - after she enters a new book into the catalog, she cannot modify it to correct any typos. She finds the modify page OK, but the machine just ignores the modify button. The cursor doesn't change when she positions it over the button - it's as if shes clicking a non-button.
Rachel Hamilton-Williams wrote:
Hi Jim
As always it's a bit tricky to figure this out without being able to see it - but is there a chance if we can't have access to the box that your wife could do some screen shots so we know were she "is" when it stops working?
Here are the steps we can take to see the problem: Bring up the admin page (/usr/local/koha/intranet/htdocs) Search for a book in the "Catalog" box by typing in a keyword and pressing enter. Click on a book title. That brings me to a page that has non-functional Modify and Delete buttons: /usr/local/koha/intranet/cgi-bin/koha/detail.pl? I have omitted the search criteria following the "detail.pl?" because I doubt that it's relevant.
I'm assuming she is using simple acquisitions to get stuff into the system?
I dunno. How could I tell? -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (703) 779-7770 There's a fine line between clever and stupid
Jim Thomas a écrit:
I'm assuming she is using simple acquisitions to get stuff into the system?
I dunno. How could I tell?
The acquisitions parameter in table parameters can be set to normal (acquisition through booksellers) or simple (direct entering of biblios) -- Paul, koha 2.0 release manager
paul POULAIN wrote:
The acquisitions parameter in table parameters can be set to normal (acquisition through booksellers) or simple (direct entering of biblios)
OK Thanks. Right now I've only got shell access to the system, so I can't easily check that. But I did some digging around, and I have a question that might lead me to an answer. In /usr/local/koha/intranet/cgi-bin/detail.pl, starting at line 89 I see: if ($type ne 'opac'){ print "<INPUT TYPE=\"image\" name=\"submit\" VALUE=\"modify\" height=42 WIDTH=93 BORDER=0 src=\"/images/modify-mem.gif\"> <INPUT TYPE=\"image\" name=\"delete\" VALUE=\"delete\" height=42 WIDTH=93 BORDER=0 src=\"/images/delete-mem.gif\">"; } Hmmm... as I recall, the last time I tried this, I was not asked for a password. This leaves me to believe that ($type eq 'opac'), which I'm guessing would render the buttons unresponsive. Am I on the right track? If so, why am I not prompted for a password? -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (703) 779-7770 There's a fine line between clever and stupid
Hi Jim On Tue, Nov 26, 2002 at 03:09:19PM -0500, Jim Thomas said:
paul POULAIN wrote:
The acquisitions parameter in table parameters can be set to normal (acquisition through booksellers) or simple (direct entering of biblios)
OK Thanks. Right now I've only got shell access to the system, so I can't easily check that. But I did some digging around, and I have a question that might lead me to an answer.
You can check in the db Jim, if you jump into the database from the commandline. mysql -uusername -ppassword Koha then SELECT * from systempreferences; That should show you what acquisitions is set to.
In /usr/local/koha/intranet/cgi-bin/detail.pl, starting at line 89 I see:
if ($type ne 'opac'){ print "<INPUT TYPE=\"image\" name=\"submit\" VALUE=\"modify\" height=42 WIDTH=93 BORDER=0 src=\"/images/modify-mem.gif\"> <INPUT TYPE=\"image\" name=\"delete\" VALUE=\"delete\" height=42 WIDTH=93 BORDER=0 src=\"/images/delete-mem.gif\">"; }
Hmmm... as I recall, the last time I tried this, I was not asked for a password. This leaves me to believe that ($type eq 'opac'), which I'm guessing would render the buttons unresponsive.
Am I on the right track? If so, why am I not prompted for a password?
Not really im afraid :-) If you were viewing the page from the opac you wouldnt even get modify and delete buttons displaying. What we really need to see, is a screen shot of the page, and/or the source of the offending page. That should let us spot whats going on. Hope this is of some help Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris@katipo.co.nz www.katipo.co.nz
On Tue, 26 Nov 2002, Jim Thomas wrote:
OK Thanks. Right now I've only got shell access to the system, so I can't easily check that. But I did some digging around, and I have a question that might lead me to an answer.
What browser (and version of browser) is she using to access Koha? Is it a fairly recent one?
Hmmm... as I recall, the last time I tried this, I was not asked for a password. This leaves me to believe that ($type eq 'opac'), which I'm guessing would render the buttons unresponsive.
Koha 1.2.2 has no internal authentication mechanism, but relies on Apache authentication. If apache was not configured to require authentication for the intranet (librarian) interface then you will not be required to enter a password to access the site. If your koha server is accessible to anybody other than your wife (ie over the internet) this might be a bad situation. Let me know if you need information about setting up Basic Authentication in Apache. Steve.
Tonnesen Steve wrote:
What browser (and version of browser) is she using to access Koha? Is it a fairly recent one?
This is the question that lead to an answer! I was using Konqueror (part of the KDE package). But after you asked, I tried Netscape instead - and it works! It still does not work with Konqueror though. I had created a "link to URL" on the KDE desktop, and by default, it uses Konquerer. I'd be interested in knowing if anyone else can reproduce this behavior. Here's the version of KDE/konqueror I was using: jthomas@dewey:~$ konqueror -v Qt: 2.3.1 KDE: 2.2.2 Konqueror: 2.2.2 -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas@bittware.com http://www.bittware.com (703) 779-7770 There's a fine line between clever and stupid
participants (4)
-
Chris Cormack -
Jim Thomas -
paul POULAIN -
Tonnesen Steve