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

403 Forbidden After dev installation !
by Karam Qubsi 16 Apr '13

16 Apr '13

Hi All I installed koha ( master ) using git installation instructions here : http://wiki.koha-community.org/wiki/Koha_on_ubuntu_-_git and this is not the first time I do this ,I installed it before , but at this time there is something wrong after all the instructions and when I arrived to the web installation the web page gives me this : Forbidden You don't have permission to access / on this server. Additionally, a 403 Forbidden error was encountered while trying to use an ErrorDocument to handle the request. ------------------------------ Apache/2.2.22 (Ubuntu) Server at 127.0.1.1 Port 8080 ---------------------------------- I have access to the files , and I'm not sure where is the problem located any one have an idea about this ? Thanks a lot -- *Karam Qubsi*

4 6

Accounting System Rewrite
by Kyle Hall 15 Apr '13

15 Apr '13

Hello all! I've been given the green light to invest some time into a full rewrite of Koha's accounts system. I've been wanting to do this for a while now and am really looking forward to it! I've created an RFC here: http://wiki.koha-community.org/wiki/Accounting_system_rewrite Please let me know what you think, suggestions for improvements, and most importantly, easy to overlook behaviors in the existing accounts system we need to keep. Thanks! Kyle http://www.kylehall.info ByWater Solutions ( http://bywatersolutions.com ) Meadville Public Library ( http://www.meadvillelibrary.org ) Crawford County Federated Library System ( http://www.ccfls.org ) Mill Run Technology Solutions ( http://millruntech.com )

1 0

Re: [Koha-devel] Koha.next: Consolidate OPAC themes?
by Paul 15 Apr '13

15 Apr '13

At 11:20 AM 4/11/2013 -0400, Kyle Hall wrote: >I think the biggest issue with just ditching the prog opac theme is >everyone who upgrades will lose their customizations, and have to re-do >them. However, if the prog theme has a specific sunset release, it will >give everyone time to re-customize and hopefully patch the theme for any >customizations that currently work on prog but not on ccsr due to lack of >id's or classes. Is it a good guess that just about every library (including CSSR) has their *own* customization of the OPAC interface? And that they all started with "prog"? If so, why ditch the common denominator? Not having 3.10 installed here, is there a "write up" on what the differences are? I've tried searching for 'cssr' on the bugs page but can only find snippets, and elsewhere have found: <jcamins at cpbibliography.com> wrote: >> > Administration > System Preferences > OPAC > opacthemes > ccsr >> Is ccsr supposed to be default in 3.10? > No. The default remains prog. ccsr is an alternative for those who want it. Plus some references to mobile apps. I had a look at https://sherbrooke.koha.ccsr.qc.ca/ but obviously that doesn't show what the underlying changes are. So I'm looking for pointers, please? tnx and br - Paul >http://www.kylehall.info >ByWater Solutions ( http://bywatersolutions.com ) >Meadville Public Library ( http://www.meadvillelibrary.org ) >Crawford County Federated Library System ( http://www.ccfls.org ) >Mill Run Technology Solutions ( http://millruntech.com ) > > >On Thu, Apr 11, 2013 at 9:04 AM, Owen Leonard <oleonard(a)myacpl.org> wrote: >Is there anyone who disagrees that we should merge the two themes and >have only one in the future? > >Is the CCSR theme design the one every one likes better? > >If not, what features of each should be preferred? > > -- Owen > >-- >Web Developer >Athens County Public Libraries >http://www.myacpl.org

5 8

Re: [Koha-devel] Koha.next: Consolidate OPAC themes?
by Paul 13 Apr '13

13 Apr '13

At 05:59 PM 4/12/2013 -0400, Owen Leonard wrote: >On Fri, Apr 12, 2013 at 5:45 PM, Kyle Hall <kyle.m.hall(a)gmail.com> wrote: > > Essentially, because it support mobile devices better than prog. > >But this whole discussion is about merging CCSR and prog! We don't >have to pick one if we make one that is the best of both! +1 ... and that is backwards compatible. P.

1 0

Re: [Koha-devel] Koha.next: Consolidate OPAC themes?
by Paul 12 Apr '13

12 Apr '13

At 06:35 PM 4/11/2013 -0400, Kyle Hall wrote: >I think in the long run making ccsr the primary theme will be the most >healthy decision. We'll just have to go through some growing pains to phase >out the prog theme. Can it be backed into 3.8? If someone can give me some pointers, I'll try it. Best - Paul

1 0

Koha.next: Consolidate OPAC themes?
by Galen Charlton 11 Apr '13

11 Apr '13

Hi, At present we distribute two OPAC themes with Koha, "prog" and CCSR. I like both of them, though it is nice having a mobile theme in the shape of CCSR. That said: in my view having two stock themes is going to present us with a long-term maintenance problem, even nightmare. Any template change to one *must* be applied to the other. Inevitably, one theme (most likely prog) will fall off the radar of most Koha developers. Also inevitably, functionality differences will creep in between the two themes. Furthermore the prog theme will continue to have users who will justifiably complain if a stock theme becomes a second-class citizen. How do I know this will happen? The Evergreen community went through a similar experience with its old-style OPAC, which at one point had a stock theme and a visually more modern theme called Craftsman. Since the underlying templates were duplicated, a point came where Craftsman accrued functionality gaps, but still had its adherents who preferred how it looked. I would like to avoid that risk. Consequently, I think the next version of Koha should unify the templates of the prog and CCSR themes. If we decide to continue offering both appearances as stock options, the visual and layout differences between the two should be managed strictly through the use of CSS. One way to do that would be to offer stylesheets that can be managed via the opaccolorstylesheet sysprefs. We could also decide to add support for skins (which would be a named set of stylesheets) or perhaps redefine OPAC themes to be just named sets of stylesheets, not separate sets of templates. Thoughts? Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

7 7

Mysql error
by Scott Kushner 11 Apr '13

11 Apr '13

Hello, Has anyone else seen this error? Apparently, my SIP server fails from time to time and has to be restarted. I have no idea why. Any help is greatly appreciated. Thanks, Scott Kushner Middletown Library DBD::mysql::st execute failed: MySQL server has gone away at /home/koha/kohaclone/C4/Letters.pm line 540. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /home/koha/kohaclone/C4/Letters.pm line 542. DBD::mysql::st execute failed: MySQL server has gone away at /home/koha/kohaclone/C4/Letters.pm line 540. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /home/koha/kohaclone/C4/Letters.pm line 542. DBD::mysql::st execute failed: MySQL server has gone away at /home/koha/kohaclone/C4/Letters.pm line 540. DBD::mysql::st fetchrow_hashref failed: fetch() without execute() at /home/koha/kohaclone/C4/Letters.pm line 542.

2 1

Proposal to be RM for 3.14
by Galen Charlton 10 Apr '13

10 Apr '13

Hi, I propose to serve as Release Manager for Koha 3.14.0. My primary goals, if elected, are: 1. Continuing our tradition of solid, well-tested releases. 2. Experimenting with the structure of the release team to spread the work and knowledge around. 3. Dealing with and finalizing long-outstanding patches and feature requests 4. Broadening Koha's appeal and making it ready for a post-MARC world. I have the support of my employer to commit significant time to this role. Organization of the release team ----------------------------------------------- The Koha Release Manager has traditionally been the sole individual (at any given point in time) authorized to push patches to the master branch. This has given us some advantages: it allows for a unity of architectural vision, it gives us an additional level of patch review after the sign-off and QA process, and empowers to RM to push back on patches that are not quite ready for prime time. I also think that giving the RM a personal stake in the success and quality of a particular release provides good motivation. However, the unitary RM model also has some disadvantages. Having only one RM can contribute to a backlog of patches. It puts a lot of work and responsibility on one person, leading to the distinct possibility of RM burnout. And given the breadth of Koha's functionality, it's increasingly unlikely that any one individual can be equipped to personally test in depth each and every patch. To lay the groundwork for spreading the release work around, I intend to try the following experiments during my tenure as RM: 1. Naming module maintainers. By module maintainer, I mean somebody who is an expert in an area of functionality (e.g., reports) and who agrees to actively maintain a Git tree of vetted patches related to that module. If a module maintainer does a good job, it opens up the possibility of the RM being able to pull it a group of branches from the maintainer's tree in one fell swoop, confident that the module maintainer has thoroughly tested it. Over time, it might be possible that a trusted module maintainer would get authorization to push patches for their module directly to master. 2. Naming master branch committers. These would be folks who share in the day-to-day work of reviewing QAed patches and pushing them to master. Committers would be expected to use their best judgment when applying patches, but also to follow guidelines discussed by the current RM and the Koha development community as whole. In time, this model might evolve to one where the release manager is just a named "first among equals" among the master branch committers whose primary responsibility is to be a final decision-maker in the case of dispute. These experiments may or may not work, but with any luck during 3.14 we will succeed in laying some groundwork for the release management load to be shared. If any folks are interested in becoming a module maintainer, please let me know. Major architectural and feature goals ----------------------------------------------------- My primary goal for 3.14 will be to significantly reduce the backlog of patches that has accumulated over the past few years. However, I also have some specific architectural goals: 1. Improve sharing of code with other projects. In particular, I'd like fold Koha's custom fork of SIPServer back into the standalone SIPServer project, and work with packages to have SIPServer become available as a stand-alone package. Another project I'd like to at least start is folding in the MFHD-handling code from Evergreen and spinning that out of as an indepdent Perl module. 2. Building on the Solr and Zebra DOM work and efforts to rewrite the search-subsystem, with the goal of having true pluggable search backend support in 3.14.0. 3. Adding support for non-MARC metadata. Communication ---------------------- I will continue to practice of a writing a monthly RM newsletter to be sent out via email to the mailing lists. I will also do a (roughly) weekly RM summary blog. To help encourage the spread of knowledge about the mechanics of performing the RM and RMaint roles, I also intend to do targeted blog posts and/or videos going into some depth. Examples of topics I might present include: * How to resolve a merge conflict. * Techniques for managing large topic branches. * A video showing the mechanics of cutting a release tarball. Timeline ------------ I propose the following general timeline: * 23 May 2013: we start (blearily) the push to 3.14.0 * 30 August 2013: release of pre-pre-alpha 3.14 - after this point, major architectural changes will be discouraged * 25 September 2013: feature slush * 3 October 2013: feature freeze * 31 October 2013: string freeze * 21 November 2013: release of 3.14.0 Regards, Galen -- Galen Charlton Manager of Implementation Equinox Software, Inc. / The Open Source Experts email: gmc(a)esilibrary.com direct: +1 770-709-5581 cell: +1 404-984-4366 skype: gmcharlt web: http://www.esilibrary.com/ Supporting Koha and Evergreen: http://koha-community.org & http://evergreen-ils.org

4 4

Call for news for the April newsletter
by Daniel Grobani 09 Apr '13

09 Apr '13

Dear Koha kommunitarians, I'm harvesting news for this month's newsletter. Please send me by the 18th anything you think your fellow community members might like to know about. "News" can be as short as a sentence or as long as a paper. I especially encourage you to send me a line or two for the gossip/society column about what you're currently working on. And if you know of a go-live not announced on the list, please be sure to let me know about it. Thanks, Daniel Grobani

2 1

Old bugs to check
by MJ Ray 09 Apr '13

09 Apr '13

Would you check some of these rather old bugs to suggest what to do, please? Maybe some can be RESOLVED FIXED by now or need a question. Please leave your reply on the bug web page - I might not see replies to this mail. Ideally, tell irc.oftc.net #koha know that you're looking at a bug. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5969 Add News Item displays all installed languages http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2069 Label Example Image http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5925 Authorities search in opac : Facets broken http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6041 Errors from _koha_modify_item are ignored in ModItem (C4/Items) http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4013 road type missing on search results http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4115 print a batch of patron cards from an import http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2964 warning running commit_biblios_file.pl http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4363 Support the patron internet resources field in Sip2 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3298 Independent item "Status Check" functionality needed http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3673 Pazpar2 integration http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4800 Disable book cover image in the title view if the feature is on in the OPAC. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4373 Placing and Processing Items Simultaneously causes multiple issues http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5779 can't add funds to budget that has past http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4269 Module DBD::SQLite2 requirement will cause problems http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4249 can't place hold if one item not avail for hold http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5324 "bring out the dead!" in C4 http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2533 Send OPAC user record change requests to branch email address http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5732 Adding permissions on viewlog http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3367 Overdue Rules not processed for patrons with checkouts more than 90 days overdue. -- Email robot driven by MJ Ray (slef), member of www.software.coop, http://koha-community.org supporter, web and library systems developer. Available for hire (including development) at http://www.software.coop/

1 0