* All configuration and run-time files created during
a test suite run now live under t/run
* made sure scripts copied to t/run/bin are executable
* added t/run and t/test-config.txt to .gitignore
Signed-off-by: Andrew Moore <andrew.moore@liblime.com> Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Andrew Moore [Fri, 18 Apr 2008 15:58:30 +0000 (10:58 -0500)]
improvements to automated tests, including a testing database
I'm adding a bunch of additions to the test suite. There is now a test
database that is created, and a test instance of the zebra server and
daemon that are run before the tests in t/database-dependent.pl are
run. This means that you can test things that insert (or destroy)
things in the database.
To use these tests, after you 'make' your koha installation, you can
change to the 't' directory and 'make test' there.
There is now an additional question asked during installation. It asks
whether you would like to run the data-dependent tests. If so, It asks
you for some login information to a test database. I recommend that
you do not not use your production database here. It will delete all
of the data in it.
Things that need improvement:
* I suspect that there are large parts that are not very platform
independent, so they will need to be improved.
* There are some parts of the installer that will probably be
refactored to let this work a little bit better, including being run
directly from a main-level 'make' target at some point.
* Lots more tests to add. Be bold! (see the t/lib directory)
* other tests in t/*.t can possibly benefit from being included in here.
There are two required perl modules for this part of the test suite. I
use:
'Test::Class' => 0.028,
'Test::Class::Load' => 0.02,
They are not listed as requirements in the top-level Makefile.PL
because they're not actually required to install or use Koha, but if
you want to run the test suite, you can install them from CPAN.
refactor web installer code to created C4::Installer
Created a new module, C4::Installer, which embodies
most of the code from installer/install.pl that handles
identifying and loading SQL scripts and setting the
Version, marcflavour, FrameworksLoad, and NoZebra
system preferences.
With C4::Installer, it is now easier to automate
initializing and populating a Koha database. This will
help allow the test suite to set up a test database
in order to run DB-dependent tests, as well as write
a command-line installer which may be of use to hosts
that need to support multiple Koha databases.
Check verifies that all subfields for each tag
are assigned to the same editor tab (or are ignored).
This situation can lead to data corruption, because
if an incoming MARC record has a field whose subfields
are assigned to different tabs, the first time that
record is saved in the bib editor, the field
will be split into multiple versions, each containing
the subfields assigned to a given tab.
Errors identified by this test known
in the MARC21 frameworks - I'm working on a patch to
correct those.
kohabug 2022 - fixed fine and issuing rules editors
Because of the way that the older fine and issuing
rule editors generate the HTML form, if a branch code,
patron category code, or item type code happened to have a
'-' or '.', the HTML form would not be parsed properly, thus
adding an implicit (rather than explicit) limit on the
characters allowed in one of those codes.
This fix removes this limitation by Base64-encoding the codes
when constructing the names for the <input> elements.
Two functions are added to C4::Koha:
str_to_base64() - UTF-8 string to Base64
base64_to_str() - reverse
rebuild_zebra.pl will now mark all zebraqueue entries
of the affected record type(s) done when run in
normal mode to index all records (as opposed to running
it with -z to just process the zebraqueue). This prevents
any running zebraqueue_daemon processes from attempting
to reindex the same records, redundantly.
The new -y swtich overrides this new behavior; in other words, if
running rebuild_zebra.pl without -z, you can specify
-y to *not* mark zebraqueue done.
disabled values are not passed to CGI.
So that if you disable entry, values and subfield codes are mixed up.
I changed disabled=tru to readonly and it fixes the bug.
* Add a new parameter -o to begin importing input file after skiping
n records.
* Enclose input file reading in an eval directive to avoid abording
import if few records are corrupted: they are now skipped.
* Help formating.
Owen Leonard [Tue, 15 Apr 2008 18:49:29 +0000 (13:49 -0500)]
Correction to cat-search.inc to avoid focus-stealing problem; Change to detail.tmpl to play nice with moredetail.tmpl; Minor changes to search pages to allow greater flexibility with background customizations.
Improving workflow : A suggestion can be edited and status can be changed if mistaken as soon as it is not deleted or acquired.
Adding dates display.
Adding deletion of suggestions.
Two fixes to speed up (a little bit) installation process
Add a explanation on DBD::mysql installation without test suite.
Add /misc/translator/install-code.pl script that creates templates
for specified language codes.
In the list of bibs for an import batch, the sequence
number is now a link to a preview of the original
MARC record - uses the same JavaScript widget as the
preview for Z39.50 search results.
Andrew Moore [Fri, 11 Apr 2008 16:32:58 +0000 (11:32 -0500)]
bug 1953: removing possible SQL injections from C4::Acquisition::GetHistory
I think this is the last sub in this module that needs to be changed.
there should be no functionality or no documentation changes with this patch.
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1953
using as_xml uses default MARC::File::XML format which is UNIMARC for marcflavour UNIMARC
And thus, causing a problem when encoding simple items marc records.
Andrew Moore [Thu, 10 Apr 2008 19:49:39 +0000 (14:49 -0500)]
bug 1953: removing possible SQL injections from C4::Acquisition::GetLateOrders
I decided to not make chagnes the the query that's executed on databases other than MySQL as I have no good way to test that.
This change provides no functinality change and requires no documentation change.
This plugin by Jörn Zaeffererr handles creating an
expandable and collapsible tree from an unordered list, and
will initially be used for the enhanced user permissions page.
The plugin is dual-licensed: MIT and GPL.
Updated all scripts appearing on the tools page
to respect a granular permission defined for
each of them.
The tools menu and home page have been changed so
that only the specific tools that a user has
access are displayed. This is simple, but depending on
the module and circumstance, it may be better to
display functions that the user has does not have
access to, but disable the links and do some sort
of visual styling to indicate that a function exists
but requires additional privileges to access.
Adjusted the user permissions editing page as follows:
* Replaced table with a list
* Implemented a tree control using the jQuery Treeview plugin
* When CheckSpecificUserPermissions is ON, if a module
flag has specific (i.e., children) permissions, allow
them to be edited - this is where the tree control
comes in.
* Added some hooks and an initial stab at the CSS
to style the permissions editor tree.
Enhanced the permission-checking functions in C4::Auth
(e.g., get_template_and_user, checkauth, check_api_auth, etc.).
If the CheckSpecificUserPermissions syspref is OFF, the behavior
of those APIs is unchanged.
If CheckSpecificUserPermissions is ON, then the value of each
key in the flagsrequired hash is considered during
the permissions check:
1. if the value is 1, the staff user must have
all privileges for the userflags flag (or module)
referred to by the hash key, e.g.,
{ flaqsrequired => { tools => 1 } }
In terms of the database, this means that the
corresponding bit must be set in borrowers.flags.
2. If the value is '*', the staff user must
have at least one of the permissions for the
userflag/module, but it doesn't matter which one.
In terms of the database, this means ether that the
corresponding bit must be set in borrowers.flags or
that there at least is one row in user_permissions
for the staff user and bit/module combination.
3. If the value is any other string, it must be
a permissions code defined in the permissions table.
The staff user must have that specific permission
or have access to all functions of the module
In terms of the database, this means ether that the
corresponding bit must be set in borrowers.flags or
that there is a matching row in user_permissions
for the staff user, bit/module, subpermission
code combination.
In addition, get_template_and_user is modified so that the
CAN_user_XXX variables that it sets also includes the
subpermissions available (CAN_user_XXX_YYY, e.g.,
CAN_user_tools_import_patrons). The template variables
for the specific permissions are set regardless of whether
CheckSpecificUserPermissions is ON or OFF so that the templates
don't have to test for that syspref explicitly.
In addition, the meaning of CAN_user_XXX has changed slightly -
CAN_user_tools, for example, is set to 1 in the template if the
user has access to *any* of the tools functions. This was done
to simply the logic for deciding whether to display a menu
item in the staff interface are not. This does mean that
when specific subpermissions are added to (say) the circulate
module, each use of CAN_user_circulate will need to be examined
to see if the intent is to allow the user to get at a circ
menu or page or if the user really should be required to have
all circulate functions.
First big commit in a project to add more granular
staff user permissions to Koha.
* Created two new database tables
permissions:
stores a list of defined permissions; each
permission is to be interpreted as a child
of a top-level permission defined in the
existing user flags. For example, Tools (bit 13)
now has a separate sub-permission for each
individual tool.
The columns are
module_bit = FK referencing userflags.bit
code = code, e.g., import_patrons
description = e.g., "Import patron data"
user_permissions:
stores a list of the specific permissions that
a staff user actually has. For example, if
staff user 123 has only the 'import_patrons' subpermission
of 'Tools' (module_bit = 13), that would be represented
by having (123, 13, 'import_patrons' in user_permissions.
user_permissions and borrowers.flags are now interpreted
as follows (assuming the CheckSpecificUserPermissions syspref
is ON):
* If the appropriate bit (e.g., bit 13 for Tools) is set
in borrowers.flags, the staff user can access all
Tools functions. There should be no rows in user_permissions
for that staff user and userflag bit combination.
* If the bit is not set in borrowers.flags, but one or
more rows are present in user_permissions for that
staff user and bit combination, the staff user can
access the specified sub-functions.
* If the bit is not set in borrower.flags and there are
no rows in user_permissions for that staff user and
bit combination, the user cannot access any of the functions.
Note that this means that if a staff user can access all
functions for a module (because the bit is set in borrowers.flags),
the user will automatically be able access any new subfunctions
added to permissions by a database update.
The columns are:
borrowernumber = FK referencing borrowers.borrowernumber
module_bit, code = FK referencing permissions
* Added a new system preference, CheckSpecificUserPermissions
If this system preference is ON, staff users can be assigned
specific permissions which will be respected during
authorization checks. If this system preference is OFF, the
current userflags semantics will continue to apply.
* Defined sub-permissions for Tools. The list of specific
tools permissions is now:
edit_news Write news for the OPAC and staff interfaces
label_creator Create printable labels and barcodes from catalog and patron data
edit_calendar Define days when the library is closed
moderate_comments Moderate patron comments
edit_notices Define notices
edit_notice_status_triggers Set notice/status triggers for overdue items
view_system_logs Browse the system logs
inventory Perform inventory (stocktaking) of your catalogue
stage_marc_import Stage MARC records into the reservoir
manage_staged_marc Manage staged MARC records, including completing and reversing imports
export_catalog Export bibliographic and holdings data
import_patrons Import patron data
delete_anonymize_patrons Delete old borrowers and anonymize circulation history (deletes borrower reading history)
batch_upload_patron_images Upload patron images in batch or one at a time
schedule_tasks Schedule tasks to run
bug 2006: do not crash when paying a lost item fine
Qualified call to MarkIssueReturned with 'C4::Circulation'.
It looks like there is still a subtle bug with exporting
subs between modules that use each other.
Owen Leonard [Wed, 9 Apr 2008 13:58:52 +0000 (08:58 -0500)]
Changes to "Most Popular" interface: adding some default parameters to link so that page displays results right away. When results are shown, search form is moved into side bar, like facets. Adding tablesorter and 'place hold' links.
Paul POULAIN [Tue, 8 Apr 2008 20:14:13 +0000 (22:14 +0200)]
BiblioAddsAuthorities improvement/fix
this commit restore a better behaviour :
- if ON : the librarian can enter manually an authority-linked marc field. and if it does not exist in the authorities file, it will be created automatically
- if OFF : the authority must exist in the authority file, and the librarian can't enter if manually in the MARC editor
This patch just deals with the OFF case (the ON was already here). With OFF the behaviour is now the same as in 2.2
Paul POULAIN [Fri, 4 Apr 2008 09:15:59 +0000 (11:15 +0200)]
reintroducing history manual modification feature
The history start date and enddate is also useful to modify manually for the same reason : your serial collection may be older than your Koha serial management.
paul [Tue, 1 Apr 2008 14:01:36 +0000 (16:01 +0200)]
use HomeOrHoldingBranch to determine if a return is valid or not
in fact, i'm not 100% sure of this bugfix : I don't see the case where a return should be done directly to homebranch, when the check out has been done at holdingbranch
so maybe we could hardcode 'holdingbranch' instead of using HomeOrHoldingBranch
the patch as written won't break anything existing.
* Added items.location and items.ccode to list of
columns available for limiting
* choice of item type column (i.e., biblioitems.itemtype
or items.itype) to limit by now respects
item-level_itypes syspref
projects / koha.git / log