I can’t find a way to do this but figured I would check - is anyone aware of a way to set blocks (or notes, or messages) on a patron account to expire automatically? That is, a date can be set during block creation when the block would automatically be removed from the patron account instead of the block remaining forever/until someone deletes it.
If all else fails, I suppose I can get staff to write the expiration date of the block in the text and then we can use SQL/search to identify and manually remove them. With the number of times jobs are failing to run lately, that might be the safest method anyway…
However, from a SQL perspective, tables like: PatronFreeTextBlocks & PatronStops (library assigned blocks) already have a CreationDate column, so you would be able to key off of that rather than having staff manually enter in dates.
What are you trying to achieve with the expiration dates? Maybe there is another solution from the community.
We are trying to move away from using patron codes to indicate that patrons are barred from the library, because they weren’t being applied (or removed) consistently. But some staff still want some of the functions of the patron code change - so we have been working on getting the block to work like the patron code currently does with some of our third-party software, with the additional thought that having a built-in field to enter notes (e.g. barred from city libraries from 11/1/24 to 12/1/24) could be helpful in preventing patrons from lingering in barred status long past the actual end of their barring.
When chatting with our admin for library operations, she wondered if there was any way to get the block to expire on a schedule to further streamline this process. I don’t think it would change our decision-making one way or the other, but I wanted to confirm whether it’s an option.
Depending on the combination of dates involved, you could create a series of library assigned blocks:
Barred from city libraries until 12/1/2024
Barred from city libraries until 1/1/2025
Barred from city libraries until 2/1/2025
Barred from city libraries until 1/1/2026
etc., etc.
That way you’d have consistent data entry (select from drop down) and then they could also be removed via a patron bulk change.
It could be challenging if you’re having 3rd party vendors only block on specific library assigned blocks, but if you have them block on any library assigned block on the account, it might work.
Another way to do this would be to use Library-Assigned blocks with block length instead of dates, and run a query based on block creation date for each one that outputs to a patron record set. Ex. run a query for any patrons with the “barred for thee months” block where the block creation date was >3 months ago. If you have write access to your database, you could even have a stored procedure that automatically removed the block from all the accounts in the record set, rather than having a staff member go in and perform a bulk change each day/week/month.
I like this idea, I didn’t realize the block creation date was in the Leap UI!
These “generic” blocks do mean the library staff would have to do a little date math to answer the question of when the block would be lifted, but if this is a regular occurance it would certainly be tidier than my suggested method.