Settings and activity
36 results found
-
3 votes
An error occurred while saving the comment 
Phil Agnew
supported this idea
·
-
4 votesPhil Agnew
supported this idea
·
-
6 votes
-
12 votesPhil Agnew
supported this idea
·
-
30 votesPhil Agnew
supported this idea
·
-
14 votesPhil Agnew
supported this idea
·
-
6 votes
An error occurred while saving the comment Phil Agnew
commented
I just dealt with this for the first time myself and I think it mostly boils down to the Authority Records not being removed from the Record Set before the "delete" action is passed. Item and Bibliographic Record Sets both appear to remove the record from the set, which I think is why we don't see the same problem there (this also helps prevent unintentional "double delete" actions, but that's another can of worms).
Fortunately, the Remote Desktop App Client (old school Polaris Client) doesn't have the same problem. It appears to remove the Authority Record from the Record Set before processing the "delete" action, just like the Item and Bib Record Sets. So, there's at least a workaround, but I think "fixing" the Authority Record Set "delete" workflow to include the "remove from record set" action in the Leap Client, like the Item and Bib Record Sets, would be a quick fix to this issue.
Phil Agnew
supported this idea
·
-
7 votesPhil Agnew
supported this idea
·
-
7 votes
An error occurred while saving the comment Phil Agnew
commented
First, let me clarify that you CAN log into any branch in Leap from any given "workstation", but you can only select from "workstations" that have been assigned to that branch. I think that's what "B" was talking about here, but that isn't quite how the post reads... please correct me if I'm mistaken.
Anyway, I think the current workstation limitation in Leap stems from the web client not retrieving the machine name for the workstation at login... I'm not sure if that's a technical limitation of the web authentication or just something that's presently missing, but I'm pretty sure that's why the generic "LEAP-(branch abbreviation)" workstations are configured for Leap. Actual machine name authentication would be great (for security and reporting purposes), but barring that, I think the best solution would be to tie workstations to staff instead of branches. Having EVERY workstation surface as a selectable option for staff when they log into any branch would be... problematic... even if the browser does cache your selection for future logins... And with staff often floating from one branch to another, sometimes with laptops/"mobile workstations", being able to surface their workstation for them regardless of their branch selection would be helpful.
Tying the workstation selection to the staff member would also allow us to potentially restrict staff to a specific group of workstations within a larger building. Staff that exclusively work a 2nd floor reference desk don't need to see workstations for the 1st floor circulation desk, and staff that work in the tech services department don't need to see workstations located in the children's department. Again, in a web accessible environment with non-stationary computers, connecting workstations to staff makes a lot more sense than connecting them to branches.
Phil Agnew
supported this idea
·
-
7 votes
An error occurred while saving the comment Phil Agnew
commented
I haven't found good documentation for this and I can't test it myself right now, but I think there MIGHT already be some config to support this. There are settings named "Barcodes: Item format definition" and "Barcodes: Patron format definition" that allow you to set prefixes and controlled lengths for your barcode formats. Now, I'm not sure if it's prescriptive or restrictive config, so it's possible it just defines formats for barcode generation and doesn't block barcodes that don't match the criteria, but it might be worth looking into.
There's also config named "Web app: Item barcode REGEX" and "Web app: Patron barcode REGEX" that might handle the same concept, only with the flexibility of Regular Expressions. You do need to know just a little bit of RegEx to make use of this, but I'd argue that basic RegEx is worthwhile skill for anyone working in libraries. As an example, I would configure ^0119[0-9]{9} for our own Item Barcodes, which translates to "Start of line, 0, 1, 1, 9, any value from 0 to 9 for 9 places" which totals to 13 characters. I think that's probably enough of an explanation for anyone to get started here... but again, I'm not entirely sure what the intent is for this config.
If all you're really trying to do is keep staff from accidentally scanning UPCs at checkout, then you have one other option that is honestly more reliable than configuring anything in the ILS. Your library barcodes are probably using either Codabar or Code39 symbologies (they're more or less the standard for libraries), so all you need to do is configure your barcode readers to not read the EAN/UPC symbology. This is much easier than you might think but will take a little bit of research for your specific barcode readers. You'll want to find the FULL manual for your barcode reader online (not that "Quick Start" guide they package with it) and search or navigate to the symbologies section of the document. There you should find configuration barcodes to enable or disable every symbology supported by your barcode reader. Find the barcode to disable EAN/UPC and print out the full page (trying to PRINT SCREEN just the barcode can mess with the scale and make it unreadable when printed, so save yourself the headache and just print the whole page) then scan that barcode with each of the barcode readers at your front desks where you don't want UPCs to be read. Note that one major advantage to doing things this way is that you can effectively control which workstations read UPCs and which ones don't. This is important because you probably don't want to disable UPC reading for your cataloging staff, who are likely searching for bibliographic records using UPCs. Again, it requires a little research, but once you find the configuration barcode you need, you can just pass/distribute it around to each of your workstations, provided they're using the same barcode readers... if not, you'll have a little more research to do for each manufacturer/model in use at your libraries.
-
5 votes
An error occurred while saving the comment Phil Agnew
commented
Agreed. Another default option could be "First X number of letters of last name", since I think that's one of the only fields required by default. If you want to take things one step further and generate random passwords that print a receipt on demand, that would be the most secure option. I wouldn't write off the DOB idea in favor of either of those though.
Phil Agnew
supported this idea
·
-
12 votesPhil Agnew
supported this idea
·
-
13 votesPhil Agnew
supported this idea
·
-
31 votes
An error occurred while saving the comment Phil Agnew
commented
Yes, please! I'll say the same should be true for Transit Item that might have gone missing... those being locked in Transit status is genuinely problematic from an item history perspective... our consortium would prefer to transition Long Transit Items to Missing before moving them to Withdrawn, so the Lost Item Transition doesn't really suit our purposes. I wouldn't be opposed to this having it's own permission too...
Phil Agnew
supported this idea
·
-
4 votes
An error occurred while saving the comment Phil Agnew
commented
While I'm not opposed to increasing the character limit, I think you might be better served by looking into the Dated Note functionality added in 8.0. If the limit were increased, you'd probably just find yourself in the same boat again later. If you shifted to using Date Notes for more historical purposes, you'll never run into this problem again, since each Dated Note is it's own entry. It is a little confusing having "Notes" AND "Dated Notes" though... the feature was added just before our Go Live date, so I was able to use some REGEXP_SUBSTR() queries targeting carriage returns to slice our existing note blocks into separate entries to add as "Dated Notes" (not perfect, but serviceable) and disabled the standard "Notes" in favor of "Dated Notes". I know something like that isn't a viable option for everyone, but you could conceivably start transitioning over to Date Notes by manually copying note data, starting with your most "robust" patron accounts... though it would be nice to be able to optionally change the "Date" value for "Dated Notes" created this way... That might be another "Idea"...
-
6 votes
An error occurred while saving the comment Phil Agnew
commented
I like this idea and will point out there are many other potential applications for this. In addition to having a Guardian field, we keep school name data for student cards in one of our UDFs. I'm sure other libraries have additional contextual fields they're simply relying on staff to manage manually. Off the top of my head, I can imagine university libraries with faculty accounts having a tenured field or other such field that only applies to them, membership status for Friends of the Library patrons, organization information for institutional cards, etc.. Being able to enforce requirement options per Patron Code could be useful in a lot of different contexts.
Phil Agnew
supported this idea
·
-
14 votes
An error occurred while saving the comment Phil Agnew
commented
I agree that things need to be made clearer (patrons simply don't pay close enough attention to things, even with clear signposts), but I'll point out that there is a Merge Tag already available in the LX Starter Reminder Notices (which may or may not be relevant to the original post). I made an HTML element in our Reminder Notices to surround the {{automatically_renewed}} tag in a colored pill shape in an effort to call attention to the "Renewed" or "Not Renewed" text, but I REALLY wanted to be able to change the color of the pill based on the renewal status. I'm sure people still would miss the message, but contextual color options would certainly make it easier for patrons to see which holds had been successfully auto-renewed.
Phil Agnew
supported this idea
·
-
2 votesPhil Agnew
shared this idea
·
-
7 votes
An error occurred while saving the comment Phil Agnew
commented
So, there is actually a TransactionSubType for "Modified via patron aging job" (336) that is associated with the "Patron registration modified" TransactionType (2003)... Seems like someone was already expecting someone would be interested in tracking/reporting on this! I don't know where you stand with SQL, but you can plug this into the SQL Search for Patron Records and create a Patron Record Set with the results:
SELECT [PatronID]
FROM [PolarisTransactions].[Polaris].[TransactionHeaders] AS hLEFT JOIN (SELECT [TransactionID], [numValue] AS [PatronID]
FROM [PolarisTransactions].[Polaris].[TransactionDetails]
WHERE [TransactionSubTypeID] = 6
) AS d1
ON d1.[TransactionID] = h.[TransactionID]LEFT JOIN (SELECT [TransactionID], [numValue] AS [PatronAssignedBranchID]
FROM [PolarisTransactions].[Polaris].[TransactionDetails]
WHERE [TransactionSubTypeID] = 123
) AS d2
ON d2.[TransactionID] = h.[TransactionID]INNER JOIN (SELECT [TransactionID], [numValue] AS [AgingBoolean]
FROM [PolarisTransactions].[Polaris].[TransactionDetails]
WHERE [TransactionSubTypeID] = 336
AND [numValue] = 1
) AS d3
ON d3.[TransactionID] = h.[TransactionID]WHERE [TransactionTypeID] = 2003
AND [PatronAssignedBranchID] IN (BranchIDs)Replace the BranchIDs with whatever branches you want or remove that AND statement altogether and you should be able to get what you're looking for. Of course, if you're comfortable digging into the SQL a little more, it's not difficult to connect data from the PatronRegistration table to get a real report. But a standard report delivered via SSRS for staff that aren't comfortable with SQL would still be nice.
Phil Agnew
supported this idea
·
-
12 votesPhil Agnew
supported this idea
·
Agreed. There was another post recently about the same thing, only with a slightly different flavor:
https://ideas.iii.com/forums/951742-ils-polaris/suggestions/50690078-automatic-posting-and-sending-of-overdues-to-libra