Settings and activity
32 results found
-
8 votes
Phil Agnew
supported this idea
·
-
6 votes
An error occurred while saving the comment 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
·
-
5 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
·
-
11 votesPhil Agnew
supported this idea
·
-
12 votesPhil Agnew
supported this idea
·
-
13 votes
An error occurred while saving the comment Phil Agnew
commented
While I would love the ability to make changes at the database level using SQL, I can understand Innovative's reservations. We were on Symphony once before and I think they had SQL access gated behind some internal certification (I think there was a paid training or something...) and there was all kinds of language to make it clear the SirsiDynix would not be liable for any damages caused by library staff. I'm not sure I want to see Innovative go completely down that path, but I do think there needs to be some guardrails, given what's at stake. With that in mind, I think allowing SQL jobs/changes to be made from the Web Based System Admin would be a mistake. The consequences of a leaked password or other breach to an administrative page available on the open web are simply too high... I think this is something that should probably be locked to Remote Desktop access or similarly restricted to whitelisted IP addresses. So... maybe this doesn't require "Development" so much as it would require specific training/agreements between Innovative and library staff to allow write access to the existing RD SQL Database tools? Innovative may think that's too open though and need to find a way to restrict write access to certain tables or something...
I'll mention that RegEx support in the bulk change tools would take care of a great many of the potential database changes, including the UPPER() example mentioned... not trying to diminish this idea, but just some additional food for thought... I desperately miss the RegEx find/replace tool in SirsiDynix Data Control...
-
30 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
·
-
16 votesPhil Agnew
supported this idea
·
An error occurred while saving the comment Phil Agnew
commented
Interesting... in our previous ILS, the Inventory Date was updated with every Check-In action, so I didn't initially understand where the problem was... Realizing now that Polaris doesn't update Inventory Date values with Check-In actions, I understand where you're coming from. That said, I think it would be easier to bypass the bulk edit action altogether and just have the Inventory Date updated at Check-In. I know there's a dedicated Inventory Check-In, but that could still be used for direct inventory processes (like loading scans from a file/buffer) where you don't want any other other action taken on the item. I'm not opposed to editing the items via a record set, but unless there are some circumstances where you don't want the Inventory Date updated at Check-In, that seems like another step that could be eliminated.
An error occurred while saving the comment Phil Agnew
commented
While I understand the notion, I'm curious about you're existing workflow. It seems like if you were scanning items for inventory, you would just use the Inventory workform. Alternatively, I would think any record set you might create would need to have been created either by scanning items directly or adding them using another report or file. In both cases, it seems like you should have a file you could load into the Inventory workform? We've only been live in Polaris for a month, so I haven't really had to work out our inventory procedures yet, but my plan had been to output locally stored scans from a barcode reader to a file and load that... It seemed simple enough, but I've not tested anything and am curious about whatever logistical challenges you or others have experienced.
-
2 votesPhil Agnew
supported this idea
·
-
7 votes
An error occurred while saving the comment Phil Agnew
commented
This would be especially helpful for Reminder notices, since they also control the auto-renew process. I was recently asked about adjusting the auto-renew policy to allow for more lead time and quickly realized that I could not realistically send the notices any earlier than 3-4 days before the due date because our video content checks our for 7 days. With the proposed notice configuration, we could have 7 day loans renew 2 days before the due date, 14 day loans renew 5 days before the due date, and 28 day loans renew 7 days before the due date. Those examples are a little off-the-cuff, but I think they illustrate things well.
Phil Agnew
supported this idea
·
-
18 votes
An error occurred while saving the comment Phil Agnew
commented
Agreed. Looks like there's plenty of space in the Statistics tab too!
Phil Agnew
supported this idea
·
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.