Duplicate Record Entries in My List/Bookbag Record Buckets

[Jason Stephenson]

Evergreen can create duplicate entries in patron book bags. The simplest way to make them is to request to add the same record multiple times in the OPAC. There is no duplicate check and the buckets interface used to store this information in the database currently allows multiple entries for the same bibliographic record.

A patron may unwittingly create these duplicates because of a complete lack of feedback in the OPAC when adding a record to a bookbag. The patron is not notified of success, nor apparently of failure. This could lead patrons expecting feedback to add the record multiple times. There is already a Launchpad bug concerning this lack of feedback. See, https://bugs.launchpad.net/evergreen/+bug/1182547.

The duplicates don't show up in the OPAC because the retrieval code uses a multiclass bib search to sort the results. The duplicates disappear when the sort is applied.

One can only see these duplicates in the database. However, I suspect that they might cause problems some unforeseen problems. Patrons have complained of having to delete things from their lists multiple times before they actually disappear.

The duplicate entries interfere with implementing a faster method of downloading patron lists as a CSV file. If one bypasses the multiclass search to speed things up, the duplicate entries appear, necessitating additional code to strip them out.

Notes also pose a problem because the note gets added to one of the entries and not to all of them. There are no guarantees that this entry with the note is the one that will always be retrieved when a patron's list or public list is displayed in the OPAC. It has only turned out that this entry shows up because of how the database stores data and retrieves data. If that changes, then the record with the note may no longer show up. The upshot is that a patron may wonder where their note went if one of the other duplicate records shows up.

In IRC (http://irc.evergreen-ils.org/evergreen/2014-06-11#i_104540), a solution was arrived at to add a unique constraint on book bag item entries where the position is null, i.e. empty. This leaves the ability to add duplicates in the future for something like a queue of things to request or whatever, similar to a Netflix queue. (In this case, someone might want the same thing more than once.) Nothing in Evergreen currently uses the position (cbrebi.pos in the IDL/database).

[James Fournie (jfournie)]

See also 1771568

[Shula Link (slink-g)]

Just adding a note to this since I spoke to a patron yesterday who was having issues deleting items from his list.