https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20256
--- Comment #344 from Katrin Fischer <[email protected]> --- =Testing restrictions= Test case 1: * edit_items = yes * edit_any_items = no * Independentbranches = NO * No library groups defined Only items from home branch can be edited. Test case 2: * edit_items = yes * edit_any_items = yes * Independentbranches = NO * No library groups defined All items can be edited. Test case 3: * edit_items = yes * edit_any_items = no * Independentbranches = YES * No library groups defined Only items from home branch can be edited. Same as with Indybranches off. Test case 4: * edit_items = yes * edit_any_items = yes * Independentbranches = YES * No library groups defined All items can be edited. Same as with Indybranches off. Test case 5: * edit_items = yes * edit_any_items = no * Independentbranches = YES or NO * Library group includes staff users home branch (MPL) and other library branch (CPL) Only items from home branch (CPL) and group library (MPL) can be edited. Test case 6: * edit_items = yes * edit_any_items = yes * Independentbranches = YES or NO * No library groups defined All items can be edited. Summary: ==> The new edit_any_items overwrites the Indybranches pref. In consequence it appears it no longer has any effect. Correct? Should we update the IndependantBranches description to reflect that? Currently reads: Prevent staff (but not superlibrarians) from modifying objects (holds, items, patrons, etc.) belonging to other libraries: [Yes|No] ==> We update all staff users to have edit_any_items, but we should possibly only update if IndependentBranches is set to off, to keep current behaviour! (blocker) =Edit buttons= Tested with configuration from Test case 5. 1) OK - detail page - holdings table 2) OK - detail page - items tab 3) NOT OK - item edit page The Edit link in the Actions menu always shows, but redirects to detail page, if no permission. It shoudl only show if editing is possible. (blocker) 4) OK - item search It could be improved later, so that if there is only "edit record" we show this option directly (no blocker). 5) NOT OK - Course reserves a) Use a barcode to add a reserve to a course from another branch, don't change home branch The edit link is removed, but something with the table structure is broken because of it and causes breakage of the datatable: Uncaught TypeError: Cannot set property '_DT_CellIndex' of undefined. (blocker) b) Use a barcode to add a reserve to a course from another branch, update home branch to an editable one The links are shown and the table keeps working. This one is tricky, I think for sure we need to fix the table to not be broken (minimum requirement). But this could be easily a thing where a patron 'traps' themselves with a reserve they can only 'remove' using the 'remove all' feature. Conclusion: An idea: As there sure is a use case for getting items from other branches for your course reserve, maybe we can do this: - Always show button to remove the item from the reserve (that's not editing right?) Also might fix the table issue. - Maybe: Allow editing of the item for this use case after the item has been added to the course reserve. If we allow on adding it... it would be consequential and it's only temporary changes. 6) OK - detail page - batch editing 7) NOT OK - tools - items batch edit - Added barcodes of one editable and a non-editable item. Exlosion (blocker) Can't locate object method "params" via package "Koha::UI::Table::Builder::Items" at /kohadevbox/koha/Koha/UI/Table/Builder/Items.pm line 75 -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
