[Koha-bugs] [Bug 8007] Discharge management

bugzilla-daemon at bugs.koha-community.org bugzilla-daemon at bugs.koha-community.org
Tue Apr 28 02:27:37 CEST 2015


http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8007

Robin Sheat <robin at catalyst.net.nz> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Passed QA                   |Failed QA

--- Comment #107 from Robin Sheat <robin at catalyst.net.nz> ---
(In reply to Tomás Cohen Arazi from comment #106)
> Couldn't you just choose a PDF library that is shipped with Debian? :-D

Seconded!

> I successfully built both
> - libpdf-writer-perl
> - libpdf-fromhtml-perl
> on Jessie but I need to check with Robin. Maybe he would let me build those.
> I put this one on hold for a couple days (it works, I like it).

It'll need to build on Wheezy, too. That might be fine, or maybe it won't be.
I'll have a look when I get some other
people-wanting-dependencies-that-don't-exist issues sorted. I am curious why we
need multiple PDF writing things though, is it not possible to standardise
around one? (and fair enough if it's not, but I'd like it to be considered
before just adding in dependencies.)

Tomás: You can build the packages if you like, so long as they would get into
debian :) (or, to be honest, if they pass lintian with pedantic=yes and the
pkg-perl profile applied, that's usually 90% of the work done right there. It's
about time I started scripting more of the deploy process, and someone else
doing stuff with it would make that more necessary.)

> There's also a new non-Perl dependency python-pisa. It definitely needs to
> be added to control.in on the koha-deps section for this to be pushed.

Gar. We literally just removed python as a dependency. Like, a couple of weeks
ago. Oh well.

Unrelated to the packaging, and I'm not sure if this is a problem, but it looks
like files are generated as borrnum/borrnum+date.tar.gz, and this is a totally
predictable filename. Is this an OK thing to have?

Also, should paths be a system preference? Should library staff be able to
change the web paths and file paths on the system? That seems like something
that is out of the scope of library policy and well into the scope of systems
admin, and so defined in koha-conf.xml. My litmus test there is "does it make
sense for library staff to be able to change this.", and in a case like this, I
contend that it's meaningless. It also makes it harder for installation
processes to set it to something that suits the distribution.

Actually, the more I think about it, the more of a problem that last part is,
as it means there's no way to have a "default works" situation, and there's no
way you could expect library staff to fill out a path on the system.

Additionally, this should be creating directories under
/var/lib/koha/instancename/ as part of koha-create-dirs to put these files, and
alias to them in the appropriate apache template.

Other misc things:

* discharges.pl has no error handling, it just blindly attempts to open a file
and send it. What if the file doesn't exist? It looks like you'll then end up
with people saving those PDF files that really contain an error message that
confuses everyone.
* related, there are other places where files are opened and everything is
assumed to be OK. Can we stop assuming that everything is going to be OK? It
causes too many problems when it's not. Code defensively, handle errors
sensibly.
* the RFC talks about mailing things, but I can't see in the patches where that
happens, does it exist? I was trying to verify it was using the mailqueue, as
the RFC implies (but doesn't say) that it doesn't.

I'm going to make it failed because there's a good few things in here that need
to be considered.

-- 
You are receiving this mail because:
You are watching all bug changes.


More information about the Koha-bugs mailing list