Settings and activity
16 results found
-
2 votes
Phil Agnew
supported this idea
·
-
2 votes
An error occurred while saving the comment Phil Agnew
supported this idea
·
-
11 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
·
-
12 votes
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.
-
7 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
·
-
61 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
·
-
67 votesPhil Agnew
supported this idea
·
-
86 votesPhil Agnew
supported this idea
·
-
82 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
·
-
39 votes
An error occurred while saving the comment Phil Agnew
commented
It might be nice for the system to define a local phone number formatting standard and normalize the actual data... Even without such an option, it would be pretty easy to do manually if Bulk Changes supported RegEx...
Phil Agnew
supported this idea
·
-
18 votesPhil Agnew
supported this idea
·
-
9 votesPhil Agnew
supported this idea
·
An error occurred while saving the comment Phil Agnew
commented
I agree. Preferred names are nothing more than how a patron would like to be addressed and should be controlled by the patron.
Beyond the aforementioned anonymity and general politeness, staff can also be impacted if the patron record doesn't match the preferred name. If "**** Grayson" asked a staff member to place a hold on book about the history of Bludhaven, but his account only included the name "Richard", the account isn't going to surface in their initial search. Since **** is a common nickname for Richard (for reasons I still don't comprehend), they would probably figure it out, but it would be better if the patron had been able to updated their preferred name on their own.
I can understand why some libraries might prefer to mediate account name changes though, so this feature should probably have a configuration option that can be toggled on or off. I know of one instance where a teen used a similar feature in another ILS to change their preferred name to their gamer tag... it confused staff for a bit, but the teen was able to clarify things and their parent insisted the name be changed back on the account. Rather comical in hindsight, but it illustrates why this should be an optional configuration and why changes should probably be logged on the account.
-
23 votesPhil Agnew
shared this idea
·
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.