[Koha] report generation-Till Reconciliation for each branchlibraries

Joshua Ferraro jmf at liblime.com
Thu Dec 11 05:05:35 NZDT 2008


On Wed, Dec 10, 2008 at 10:49 AM, BWS Johnson
<mhelman at illinoisalumni.org> wrote:
> Salvete!
>
>>That report has been discussed before and was purposefully commented out in
>> 3.0 (I argue should have
>>been deleted) becuase it is not reliable in a multi-branch situation. At
>> present, the branch where the
>>transaction took place is not logged, so you cannot possibly create a
>> report to extract that information.
>>
>>Developers are fairly aware of this problem and are working to totally
>> overhaul fines data structure.
>
>
> I don't mean to be abrasive here, but will that overhaul include a solution
> that is palatable to both single branch Libraries and multi branch? I'd
> rather not see things tilt towards larger institutions in terms of deleting
> functions that used to exist. I know that many people were turned off by
> Nomarc getting removed without warning from the code. I would submit that it
> ought to be an option again in the next release, much as I hate the thought
> of folks not cataloguing in MARC.
> I think it's quite possible to poll folks and figure out which reports are
> used most frequently and just have those included out of the box. There is
> some of this done already, I realise, and I also know that folks are working
> on improving reports.
I'm curious if you also propose that the people responding to that
poll fund the development in line with what their requirements are.
One of the challenges we have in this community is that us developers
have to develop things in line with what the libraries that are paying
us ask us to do.

> Is it possible in future to send out a note that the developers are going to
> comment a feature out or remove it entirely when that code isn't going to be
> reworked or included? Code changes and bugs need fixing, but one of the most
> attractive things about Koha to me was that the product was tailored to
> match the community's needs, and that generally once a feature was added, it
> wouldn't go away until just about everyone agreed that it was deprecated. It
> was an ILS that wasn't like other ILSs. I'm really starting to feel like the
> usability and innovation present in 2.x is taking a back seat to an
> interface that is increasingly resembling Horizon.
Well, there's nothing preventing you from continuing to use 2.x if you
feel that way.

The reasons behind taking out that report WERE WIDELY DISCUSSED on
koha-devel, and ultimately the decision to remove it was made by me,
the RM for 3.0, primarily because it represented a serious security
and load vulnerability in 3.0, and because it didn't accurately
represent things for most of the libraries running Koha.

Based on usability testing and feedback from the users that I've seen
upgrade from 2.2 to 3.0, I'm hearing nothing but praise for the
improvements in interface and workflow, so I'm puzzled to hear that
you aren't happy with it. Could you provide some specific examples of
interface paradigms that you liked in 2.2 that aren't present or have
changed in a bad way in 3.0?

Cheers,

-- 
Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
CEO                         migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS


More information about the Koha mailing list