Settings and activity
49 results found
-
4 votes
Phil Agnew
supported this idea
·
-
29 votesPhil Agnew
supported this idea
·
-
4 votesPhil Agnew
supported this idea
·
-
7 votesPhil Agnew
supported this idea
·
-
30 votes
An error occurred while saving the comment Phil Agnew
supported this idea
·
-
15 votesPhil Agnew
supported this idea
·
-
9 votesPhil Agnew
supported this idea
·
An error occurred while saving the comment Phil Agnew
commented
Is this really not available in Leap? I haven't really looked into the PDF417 configuration much, but I didn't realize it was only supported by the desktop client... I guess Leap probably just needs a separate "Get Data From Barcode" button on the Registration workform that prepares it to receive the segmented/delimited data from the barcode reader... This is a feature I've always wanted to try implementing, so I'm a little disappointed to hear it isn't supported in Leap...
-
10 votesPhil Agnew
supported this idea
·
-
6 votes
An error occurred while saving the comment Phil Agnew
commented
Yeah... I'm not sure how much of this is a Leap problem and how much is a browser problem, but the staff password field for Leap login should be made distinct in some way from the patron password field that surfaces with the "Reset Password" button. Built in password managers may still recognize it as a password field and attempt to save it for you, but it would be helpful if it at least didn't overwrite the staff login password... though that might be tricky if the passwords are only being managed by the browser per domain...
Phil Agnew
supported this idea
·
-
8 votes
An error occurred while saving the comment Phil Agnew
commented
I see how this could be useful, but want to stress that this would need to have some sort of "Reset Unclaimed Holds Count" similar to the "Reset Claim Count" for claims returns. I can just foresee a situation where a patron has 20 picture books they requested go unclaimed after an unexpected personal tragedy being blocked from holds by an automated process like this. Staff need a way to remedy that without the patron having to wait 6 months (or whatever configured time period) for the block to drop off.
Phil Agnew
supported this idea
·
-
5 votes
An error occurred while saving the comment Phil Agnew
commented
I agree with Lynn, that this should be enabled as a configurable option. While I'm personally on team "Opt-Out" (I just think that most people prefer to have access to their own reading history), I understand and appreciate the needs of people on team "Opt-In". So, yes please, allow Polaris libraries to configure default behaviors reading history (or any field, really) in new patron registrations.
Phil Agnew
supported this idea
·
-
4 votes
An error occurred while saving the comment Phil Agnew
commented
I think this indicative of the broader need to have have better CSS for dynamic scaling of the Leap web client. I'm sure this is something that would also affect anyone trying to view patron account information on a tablet with a smaller screen/resolution... Not directly related, but I'd love to see us eventually get a genuinely "mobile friendly" version of Leap. There are a lot of interesting applications for running the web app on a phone/phablet sized device.
Phil Agnew
supported this idea
·
-
6 votesPhil Agnew
shared this idea
·
-
12 votesPhil Agnew
supported this idea
·
-
10 votes
An error occurred while saving the comment Phil Agnew
commented
Agreed. There was another post recently about the same thing, only with a slightly different flavor:
Phil Agnew
supported this idea
·
-
10 votesPhil Agnew
supported this idea
·
An error occurred while saving the comment Phil Agnew
commented
I do think this could be useful and I think it could be implemented pretty easily by essentially cloning the "Located" tab (only not have it clear automatically). That way, you have a "Unable to Locate" tab that staff could return to for a second pass later without gumming up the "Pending" requests with items that are probably a little out of place. It would also be nice to have a counter that could be incremented with each "search", since I know libraries have lots of different ideas/policies on how many times they should look for something before declaring it "Missing".
Speaking of which, I know "Missing" is intended to serve this function in theory, but in practice, many libraries prefer not to mark items "Missing" until they've done a more thorough search... many items are only off by a shelf or two... often the result of "good Samaritan re-shelving" or volunteers/staff still familiarizing themselves with local item placement.
-
17 votesPhil Agnew
supported this idea
·
-
31 votes
An error occurred while saving the comment Phil Agnew
commented
I'll vote for making almost any field editable via bulk changes. Ideally, everything except things like control numbers should be able to be edited in bulk.
Phil Agnew
supported this idea
·
-
18 votes
An error occurred while saving the comment Phil Agnew
commented
Could have sworn I commented here already, but yes, this would certainly have it's uses. Though, in interest of flexibility, I think it would be nice if the feature could support .csv file loads in addition to Excel. I just personally prefer text files for lists of ItemRecordIDs or Barcodes, but to each their own.
In the meantime, you can TECHNICALLY accomplish this by using a SQL query to create a NEW Record Set that excludes Items in one Record Set from another. You'll need to know the RecordSetID for your two starting Record Sets, but that's easily found in the top right corner of the Record Set display in Leap. The query is also slightly different for each type of Record Set, but here's a template for Item Record Sets:
SELECT [ItemRecordID]
FROM [Polaris].[Polaris].[ItemRecordSets]
WHERE [RecordSetID] = /*Starting RecordSetID*/
AND [ItemRecordID] NOT IN (
SELECT [ItemRecordID]
FROM [Polaris].[Polaris].[ItemRecordSets]
WHERE [RecordSetID] = /*RecordSetID of Items to exclude*/
)Again, you'll need to change the query up a little for different types of Record Sets, but it's pretty obvious stuff. Here's a template for Bibliographic Record Sets:
SELECT [BibliographicRecordID]
FROM [Polaris].[Polaris].[BibRecordSets]
WHERE [RecordSetID] = /*Starting RecordSetID*/
AND [BibliographicRecordID] NOT IN (
SELECT [BibliographicRecordID]
FROM [Polaris].[Polaris].[BibRecordSets]
WHERE [RecordSetID] = /*RecordSetID of Items to exclude*/
)I won't bother with templates for Patron or Weeding Record Sets, but I think you get the idea. I do think this would be a useful feature to add, but hopefully this can make your workflow a little easier for now.
An error occurred while saving the comment Phil Agnew
commented
I can certainly see how this could be useful, though I'll make a plug for support for .csv uploads as well, for flexibility's sake.
I'll also mention that you can TECHNICALLY do something like this already, though it requires a little bit of SQL searching and you end up with 3 different Record Sets instead of 2. If we're talking about Item Record Sets, the SQL isn't too bad... I actually worked out the bones when I was putting all but a few hundred items at a branch that was closing for renovation into the Storage status:
SELECT [ItemRecordID]
FROM [Polaris].[Polaris].[CircItemRecords]
WHERE [ItemRecordID] IN (SELECT [ItemRecordID] FROM [ItemRecordSets] WHERE [RecordSetID] = *Original Record Set ID)
AND [ItemRecordID] NOT IN (SELECT [ItemRecordID] FROM [ItemRecordSets] WHERE [RecordSetID] = *Record Set ID of Records to Exclude/Remove)The RecordSetID displays prominently in the top right corner of the Record Set in Leap, so you shouldn't have any trouble finding those there... In the Desktop Client, you have to open the Record Set Properties, which it a little less convenient, but still doable. If you're dealing with 10K+ entries, I expect you're probably dealing with Items, so I'll leave it at this for now... but if you'd like me to to work out a similar query for Bibs, just let me know.
Phil Agnew
supported this idea
·
-
7 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
·
.png){kind=link}
.png){kind=link}
Honestly, we went live with Dated Notes, so I didn't even realize the merged patron data was being stored in a field that we had suppressed from view... I would still say the merged account logging is lacking (why do notes only include library card number when the Delete Patron transaction only logs PatronID?), but at the very least, these notes should be entered as Dated Notes as a configuration option. I might go even further to say that ANY system generated note should be optionally (only because some people aren't using Dated Notes) entered as a Dated Note. They already include timestamps on them, so it's like they were practically engineered for this application.