This is a critical issue. Patrons expect their lists to be available to them whatever their barcode is or the reason for changing it. It is imperative that a solution to use the PATRON ID for lists or that a workaround to merge lists when a patron barcode is changed be implemented. Within a consortium with 32 member libraries, we update patron barcodes frequently for patrons who may move from one member library community to another, as well as many other reasons referenced in the original comment.

This is a critical blocker. Patron barcodes may legitimately change for any number of reasons. I was shocked when I learned patrons will lose their lists when this happens. I will second the earlier comment that if it is not possible to use the Polaris PatronID, then there needs to be some sort of transfer or migration service that could be run to merge the old lists into the new account.

This is a critical blocker. If it is not possible to use the Polaris patron id, then as a workaround, there should at least be some sort of transfer or migration service that could be run at least on an account by account basis to merge the old lists into the new account.

This issue honestly came as a surprise when we discovered it. Standard procedure is to link things such as bookmarks to a unique key that will never change. Barcodes can (and always have been) able to change in the database. As far as we are concerned this should be marked as a bug and not an enhancement request.

This is a huge issue. Lists should be tied to PatronID(polaris). This is something that never changes for the patron no matter their barcode.

In addition to the patron cards, we also use department/staff cards [based on position, not name] that we might need to reassign when someone 'accidentally' misplaces the library card. Since the showcases, lists and saved searches can't be transferred across accounts, we would need to recreate them.

This is a critical change that must be made. Patrons replace their cards CONSTANTLY and having lists tied to that number and NOT the UNCHANGING PATRON ID makes no sense.

Patrons lose cards/they get destroyed. We also do card campaigns and they want to replace their cards for fun. They need to be able to keep their patron account features and information without relying on it being attached to a card barcode that can easily be lost.

Or maybe it's a difference between Polaris and Sierra? We're a Polaris library and Vega is using the barcode, not the patron ID (primary key) from the Polaris database.

Ours is definitely based on barcode not pnnumber like some have suggested. We just tested it. So are there different releases operating differently on this issue?

I believe Vega accounts are tied to the pnumber. I tried to transfer one of my staff cards that had been used to create showcases early on by swapping out the barcode and it didn't work since the content was tied to the pnumber, not the barcode - which is good for the reasons noted in these comments!

I just tested this (in case I was remembering this wrong). I added a new barcode to an existing patron record. When I signed in to vega with the new barcode, I had access to previously created lists and still had showcase permissions.

We've also experienced a potential bug regarding misaligned patron barcodes from Polaris to LX starter which causes patrons to not receive outgoing notices. It would be excellent to see Polaris and Vega sync by Patron ID rather than barcode.

I agree with everything that's been said.

This is a vital service, for all the reasons already shared!

Any patron information shouldn't be attached to the barcode, but to the patron id number. That way it will move with the patron's account within our consortium, regardless of whether the patron moves or needs to replace a lost card.

Patrons lose or replace their cards all the time. We also give the patrons the option to get a new card when theirs wears out. Lists and other data should transfer with the patron without any staff involvement.