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
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
This commit reintroduce the feature.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
* 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
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
