Koha 22.11: New List Ownership Options

by Hebah Amin-Headley on May 19, 2023

More Options for Transfer of Ownership of Lists

Lists are a great way for libraries to create virtual displays in the OPAC, but maintenance of those lists when staff leave has always been a sticking point. Several new bugs add list transfer functionality from the staff client.

Bug 25498 introduces the ability to transfer ownership of a shared, public list. In order to transfer ownership of lists, staff will need at least the edit_public_lists permission if they do not already have top-level list permission. With that permission, the option to transfer ownership appears in the public lists display of the staff intranet on the far right side of list actions.

Lists can be transferred to another staff member, as in the case of staff pick list, or to a non-staff account, with the ability to search for an account by name. This opens up the possibilities for customized readers advisory lists, for example, where staff create a customized reading list for a patron and then transfer ownership to the the patron once staff have completed it.

New Options for Lists When Accounts Are Deleted

Content created by accounts disappearing when the owner of that list has been deleted has been another frustration of lists, especially readers advisory content that might still be relevant. Two new system preferences introduced by bug 11889 and bug 30933 provide options for libraries for how to handle public lists associated with an account when it is deleted. The current default behavior is that deleted accounts will have their lists deleted as well, which will continue to be the default setting and behavior.

The new system preference, ListOwnershipUponPatronDeletion, provides a new option to transfer ownership of a list upon account deletion. If the library does wish to retain lists at account deletion, a second preference, ListOwnerDesignated, determines which account, by borrowernumber, those lists should be transferred to. This account could be any administrative, persistent account that will not itself be deleted, which may mean some decision-making for large consortia interested in this feature since only one account can be the default target for transferred lists.

If ListOwnershipUponPatronDeletion is set to "change owner of these lists" and ListOwnerDesignated is not set, the list will transfer to the account that performs the patron deletion. (Note: it is currently possible that this situation could result in a public list being transferred to a staff account that does not otherwise have lists permissions, as noted in bug 33440.)