[Koha-bugs] [Bug 20256] Add ability to limit editing of items to home library or library group

[bugzilla-daemon at bugs.koha-community.org]

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20256

--- Comment #344 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
=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.