Bug 28743 - With IndependentBranches block changes to biblio records shared with other libraries
Summary: With IndependentBranches block changes to biblio records shared with other li...
Status: In Discussion
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: unspecified
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
: 10263 (view as bug list)
Depends on:
Blocks:
 
Reported: 2021-07-22 23:06 UTC by Michael Hafen
Modified: 2023-07-08 15:33 UTC (History)
4 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
Proposed fix (4.24 KB, patch)
2021-07-22 23:08 UTC, Michael Hafen
Details | Diff | Splinter Review
Proposed patch (4.24 KB, patch)
2021-08-04 19:46 UTC, Michael Hafen
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Hafen 2021-07-22 23:06:27 UTC

    
Comment 1 Michael Hafen 2021-07-22 23:08:45 UTC
Created attachment 123068 [details] [review]
Proposed fix
Comment 2 David Cook 2021-07-22 23:52:56 UTC
The title of this report doesn't make sense. Bibliographic records don't belong to library branches. 

Also, blocking based on homebranch of items that belong to the record doesn't make sense. You'd block modifications of bib records as soon as an item is added for another branch. Branch A might add the bib record, but then if Branch B adds an item, Branch A won't be able to edit the bib record that they added. I could see that being frustrating.

But I can also see it being frustrating to have a different branch change a bib record that you're using. Hmm...
Comment 3 Michael Hafen 2021-08-04 19:45:35 UTC
Comment on attachment 123068 [details] [review]
Proposed fix

Found a bug in the patch.
Will replace the patch shortly.
Comment 4 Michael Hafen 2021-08-04 19:46:14 UTC
Created attachment 123463 [details] [review]
Proposed patch
Comment 5 Michael Hafen 2021-08-04 19:49:36 UTC
(In reply to David Cook from comment #2)
> The title of this report doesn't make sense. Bibliographic records don't
> belong to library branches. 
> 
> Also, blocking based on homebranch of items that belong to the record
> doesn't make sense. You'd block modifications of bib records as soon as an
> item is added for another branch. Branch A might add the bib record, but
> then if Branch B adds an item, Branch A won't be able to edit the bib record
> that they added. I could see that being frustrating.
> 
> But I can also see it being frustrating to have a different branch change a
> bib record that you're using. Hmm...

This is a pit-fall with IndependantBranches.  As you observe it is frustrating to not be able to change a record, but also frustrating to have someone else change a record you are using.

I have a little fork (patch submitted on another enhancement) that hides items from other libraries, so we don't even know when someone else is using a record.  Our solution was this; since we can't see when a record is shared we will block changes to those records.
Comment 6 Katrin Fischer 2021-08-07 00:15:06 UTC
Hi Michael,

as David pointed out, currently with IndependentBranches the records are shared and there are no limitations to editing them. A record doesn't belong to any library, everyone can edit. I think this is a too big change to existing behavior that will be unwanted by many, so it should be made strictly optional.

I also believe we might not want to add a new concept like this on top of IndependentBranches. In my opinion it needs more hashing out and it would look better in the new library group settings that I hope will replace IndependentBranches at some point in the not too soon future. 

Also there are a lot of edge cases here I am not sure about:

* If shared records cannot be edited by libraries using it, who can edit it to fix issues?
* What about records for electronics, serials etc. that don't need to necessarily have items?
* What about the Advanced cataloguing editor?

There is also no test plan here, please add one to your commit message. Also take a look at how the subject etc. should look like:
https://wiki.koha-community.org/wiki/Commit_messages
Comment 7 Michael Hafen 2021-08-13 22:15:51 UTC
(In reply to Katrin Fischer from comment #6)
> Hi Michael,
> 
> as David pointed out, currently with IndependentBranches the records are
> shared and there are no limitations to editing them. A record doesn't belong
> to any library, everyone can edit. I think this is a too big change to
> existing behavior that will be unwanted by many, so it should be made
> strictly optional.
> 
> I also believe we might not want to add a new concept like this on top of
> IndependentBranches. In my opinion it needs more hashing out and it would
> look better in the new library group settings that I hope will replace
> IndependentBranches at some point in the not too soon future. 
> 
> Also there are a lot of edge cases here I am not sure about:
> 
> * If shared records cannot be edited by libraries using it, who can edit it
> to fix issues?
> * What about records for electronics, serials etc. that don't need to
> necessarily have items?
> * What about the Advanced cataloguing editor?
> 
> There is also no test plan here, please add one to your commit message. Also
> take a look at how the subject etc. should look like:
> https://wiki.koha-community.org/wiki/Commit_messages

Should be easy to implement this with a new type of library group.  I haven't done that before though, so I'd have to go through the code to figure that out.

The point of a record not belonging to any library (or library group) is pivotal here.  The best I can think of would be adding a column to the biblio(items) table to hold either the branch or branch group claiming the record, or maybe that could be added through the biblio_metadata.  This would cover your second edge case too, as electronics and serials could be given an owner that way.

I used C4::Context->only_my_library() in the patch, so SuperLibrarians would still be able to edit shared records, which addresses your first edge case.

The third edge case is also a bit sticky for me.  It would mean, to me, greatly increasing the size of the patch, as I would also want to expand this to the cataloging search and import batch record matching.  I figure once we start declaring that a branch group owns a record, then we'd want to limit cataloging to only records owned by the group or with no owner.  That would pretty much eliminate the cases of shared records between library groups, but also reduce the ability to reuse records.  Or, in cataloging, limit actions on records owned by another library group to just duplicating the record.  I feel that to fully flesh-out the feature that would be the way to go, but maybe I'm over-thinking it.

If there is some interest in the feature I could work on the library groups and advanced editor points, at least.  I'm also willing to withdraw the bug (I don't see a "Won't Fix" status, so push it to "In Discussion" I guess), if there isn't any interest.
Comment 8 Katrin Fischer 2021-08-16 12:59:42 UTC
I am not sure a db column would work, unless we only store the "first library to add a record", because library groups can overlap by definition.

For your intended use case... would we need to store it on record level? Or could we get away with looking at the items attached to a record?

How hard should the limit be on editing the records? Because I think if you just added an item to a record, you could edit the record and then delete it... still seems like no hard "lock".
Comment 9 Michael Hafen 2021-09-10 22:19:24 UTC
The use case is that we have records with multiple libraries using the record, but they can't see each other's items (because of a local patch) so they don't know it's a shared record.  We came up with the hard lock as a way to prevent libraries from changing records which other libraries are also using in that case.

I'd be fine with recording the "first library to use a record" in the biblio_metadata, or doing as the original patch does, which is to check if other branches are using it.

And maybe it would be fine to go from this hard lock to just the warning (and add that warning to the advanced editor too).  I can see wording such as "Warning: this is a shared record and should not be changed with out consulting the other libraries: [list of other libraries]".

That may be the optimum compromise here, taking out the hard lock, and having that warning on the relevant pages.  I'd have to discuss it with my librarians, but I don't think that will be a hard sell for most of them.

I welcome your thoughts on this idea as well, of course.
Comment 10 verolencinas 2023-03-05 16:53:32 UTC
Maybe we could implement this as part of the permissions of the librarians: Librarians that can change only the records of their own library (if it is not used by other libraries), librarians that can add data to all records (record enhancement), librarians that can change (add,modify,delete) access points of their own records, librarians that can change access points of all records, librarians that can change all records. It would be possible to have libraries with more permissions than others. Data changes could be added to a local field and be visible in the intranet.
Comment 11 Michael Hafen 2023-03-07 20:12:56 UTC
That's a little beyond the scope of what I need, but sounds like a cool enhancement.
It would take adding many sub-permissions to support it.  If you take super-librarian as the one that can change anything, then there would be four additional permissions to add.
Plus the code would have to be added to the marc editor and advanced marc editor to support that granularity of operations instead of just all-or-nothing like we have now.
Comment 12 Katrin Fischer 2023-07-08 15:33:20 UTC
*** Bug 10263 has been marked as a duplicate of this bug. ***