Settings and activity
24 results found
-
12 votes
An error occurred while saving the comment -
15 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
·
-
2 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"...
-
5 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
·
-
6 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
·
-
4 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
·
-
10 votesPhil Agnew
supported this idea
·
-
14 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
·
-
6 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
·
-
15 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
·
-
10 votesPhil Agnew
shared this idea
·
-
24 votes
An error occurred while saving the comment Phil Agnew
commented
There are a few different permissions that I think should have more granular configuration, but this is the biggest one. There is a major difference between "Marked for deletion" and "Removed from the database" and the fact that there isn't a way to assign those permissions separately is... problematic. Furthermore, there isn't even much visual distinction between the two actions, leading to those accidental "double delete" actions others have described. It would be helpful if, at the very least, the text in the action menu changed from "Delete" to "Remove from database" for items that have already been "Marked for deletion" (RecordStatusID = 4).
But separate permissions would be best. Case and point, I had a branch manager call me after approving a weeding record set because they changed their mind about one of the items on the list. Because they didn't have the Delete/Undelete Item records permission, they were unable to add it back into the collection. If there were separate permissions for the initial Delete/Undelete action and the second Delete/Purge action, I wouldn't have any concerns or reservations over allowing a broader group of staff to have access to that first permission, which would have prevented this problem from ever occurring.
Fortunately, it appears the Delete/Undelete Item Records permission applies to Bulk Change actions, so we can effectively prevent staff from purging a large amount of items... but only if we don't allow access to the Delete/Undelete permission. On the other hand, any staff with access to the Delete/Undelete permissions have the potential to perform highly destructive, irreversible damage to database records on a large scale... Granted it requires more intentional actions and a higher degree of technical expertise to execute, but the scope is much broader. Hypothetically, if a staff member has both the Delete/Undelete Item Records and Bulk Change Item Records, there is nothing preventing them from purging every item record in the database, except perhaps a couple alerts for "Last copy" or other configured item deletion blocks... I mention this only to express the significance of separating the Delete/Purge permissions.
Phil Agnew
supported this idea
·
-
11 votes
An error occurred while saving the comment Phil Agnew
commented
All of our libraries stopped printing postal notices during COVID closures and partial opening. When things were finally back to normal (or the "new normal"), the cost in labor, logistics, materials and actual postage led most to believe print notices not to be worth the trouble. Instead, patrons who don't have an email address associated with their account are informed by staff of their lost materials when they log into their account online or visit a branch. With the workflow dependent on staff to "Print" (but not actually print) and "Post" these fees manually, it is almost inevitable that bills won't be posted to patron account within the expected period 100% of the time. And in an environment increasingly ruled by ILS authenticated e-content, this also means the libraries could be paying for services to accounts that would have otherwise been blocked.
Phil Agnew
supported this idea
·
-
7 votesPhil Agnew
shared this idea
·
-
63 votes
An error occurred while saving the comment Phil Agnew
commented
I understand the technical limitation of using a browser-based application and trying to manage offline transactions. Like Laura suggested, I could see a dedicated offline application being useful (perhaps a basic executable that doesn't require an installer?... really just needs to store numbers in a few columns...) or a button that allows staff to export the cached data to a file that could be saved and uploaded later? All the data should be pretty anonymous already, so the potential security risk of exporting offline transactions seems minimal.
Phil Agnew
supported this idea
·
-
71 votesPhil Agnew
supported this idea
·
-
88 votesPhil Agnew
supported this idea
·
-
83 votes
An error occurred while saving the comment Phil Agnew
commented
Agreed. There would need to be some local database updates to change current "Lost" items that have been paid to "Lost-paid" (though that could probably be done locally using Bulk Changes once the new status is available?... might be dangerous to have that as a regular option though...) and some logic to automatically update the status of "Lost" items as they are paid moving forward.
Phil Agnew
supported this idea
·
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...