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
Owen Leonard [Tue, 1 Apr 2008 20:58:23 +0000 (15:58 -0500)]
Changes to allow librarian to turn off item-level holds in the OPAC. Requires the addition of OPACItemHolds system pref ("Allow OPAC users to place hold on specific items. If OFF, users can only request next available copy." Type: YesNo). Also modifying redirect to show Holds tab in opac-user.pl.
Note: I question the use of GROUP_CONCAT(... SEPARATOR '<br/>'),
because that puts knowledge of the output mechanism (currently HTML)
into the SQL query. However, I am not fixing this right now.
* use Date::Calc to perform date arithmetic
* use Date::Calc::Today to consistently format the current date
* format date per syspref in overdue report
[1] did some "Reserve" => "Hold" to keep language consistent
[2] Moved hold ratios report and billing report on circ
home page to group with related reports
All patches to Koha 3 beta to date. All work with branches.
Billing.pl -- new, gives bills that occur in a range, works
pendingreserves.pl -- fixed, works now, with branches also
reserveratios.pl -- indicates distressed reserves
itemslost.pl -- Fix to this to make it more useful and fix bugs
Itmes.pm -- small change to work for itemslost, should not affect
anything else
and all tmpl files.
Galen Charlton [Mon, 31 Mar 2008 16:57:18 +0000 (11:57 -0500)]
work around issue in MARC::Charset
Because of a bug in MARC::Charset 0.98, if a string to convert from
MARC-8 to UTF-8 has (a) one or more diacritics that (b) are only in character positions
128 to 255 inclusive, the resulting converted string is not in
UTF-8, but the legacy 8-bit encoding (e.g., ISO-8859-1). As a result,
when such a record is converted to XML using ->as_xml_record(), the resulting
XML can be truncated at the offending character. An example of such a record
is one that has a price in Briish pounds in the 260$c but no other diacritics.