On bottom of each OPAC pages, a languages selector is displayed
(depending of syspref). But this selector wasn't available
on OPAC home page.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
Adjusted so that there wasn't a difference between
the 'permissions' code in userflags.flag and the
template variable.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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.
Signed-off-by: Joshua Ferraro <jmf@liblime.com>
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>
