Settings and activity
115 results found
-
33 votes
An error occurred while saving the comment An error occurred while saving the comment
Wes Osborn
commented
Per "T's" comment - another option like sending an immediate test "Let us know if you got this text/email/phone call" could be another good approach that ensures that the notification method works without requiring the confirmation loop. And since it would be done by staff initiating something on the patron account it would allow for a more controlled rollout.
An error occurred while saving the comment
Wes Osborn
commented
Although I know this would be more steps than happen today, I think that it is not an unusual flow for most accounts that people establish these days and would ultimately benefit both the patron with being assured they can get their notices and the library for having a better reputation for sending notices and lower costs (SMS/texts) for making sure those notices get through.
Wes Osborn
shared this idea
·
-
19 votes
Wes Osborn
supported this idea
·
-
12 votes
An error occurred while saving the comment
Wes Osborn
commented
Agreed, we've seen similar issues with being able to "browser" authority records because it attempts to open the authority record in edit mode by default.
Wes Osborn
supported this idea
·
-
9 votes
An error occurred while saving the comment
Wes Osborn
commented
Yes, even something like the isINNReach:true that is offered in the Picklist would be a huge help!
-
9 votes
An error occurred while saving the comment
Wes Osborn
commented
Not being able to accurately rely on selecting the proper postal code when it has been supplied with this information is troublesome.
Wes Osborn
shared this idea
·
-
14 votes
An error occurred while saving the comment
Wes Osborn
commented
It would also be nice if the filter box had a way to narrow the column being searched, even if it were more like power searches.
Wes Osborn
supported this idea
·
-
20 votes
Wes Osborn
supported this idea
·
-
12 votes
Wes Osborn
shared this idea
·
-
97 votes
An error occurred while saving the comment
Wes Osborn
commented
This is something we do via SQL regularly; it would be a blocker for us moving to hosting with having someway to build a record set using an arbitrary list of bib ids.
Wes Osborn
supported this idea
·
-
48 votes
An error occurred while saving the comment
Wes Osborn
commented
Great suggestion @Alexis on being able to launch from the dup detection screen.
Wes Osborn
supported this idea
·
-
12 votes
An error occurred while saving the comment
Wes Osborn
commented
We haven't thought about giving this permission to staff directly but it would be a big improvement over them having to open a ticket, especially if we could give them a link to do it directly in WebSA.
Wes Osborn
supported this idea
·
-
11 votes
Wes Osborn
supported this idea
·
An error occurred while saving the comment
Wes Osborn
commented
This would be great as it would allow for new dedup processes to be explored while being able to safely merge the records and their holdings.
-
16 votes
An error occurred while saving the comment
Wes Osborn
commented
Would the first part of this request be similar to: https://ideas.iii.com/forums/951742-ils-polaris/suggestions/48105074-import-profile-rention-tag-020-shoudn-t-duplicat
-
11 votes
Wes Osborn
shared this idea
·
-
10 votes
An error occurred while saving the comment
Wes Osborn
commented
Another option just to put out there for consideration is this script that will sync the additional and deletion of holdings automatically: https://forum.innovativeusers.org/t/oclc-worldcat-data-sync-powershell-script/2754
-
7 votes
Wes Osborn
supported this idea
·
-
97 votes
An error occurred while saving the comment
Wes Osborn
commented
@Shaket printing all other held items out doesn't seem to match what I'm seeing the documentation for the notes field: https://documentation.iii.com/polaris/8.0/Default.htm#PolarisStaffHelp/Patron_Services_Admin/PDPreceipts/Set_hold_slip_options.htm
You've checked with support and confirmed that is expected behavior?
An error occurred while saving the comment
Wes Osborn
commented
Maybe one way of getting more delivery type information on the receipts would be to have a Printed Name in the branch record. Currently, there is a Display Name, if a Printed Name could be added that would be a helpful place to include the needed delivery/sorting information. That would mirror how InnReach works.
Wes Osborn
supported this idea
·
-
24 votes
An error occurred while saving the comment
Wes Osborn
commented
This came up again recently. Again, I would suggest that Leap have some information show on the screen that you have to select a registered branch. Even if it was just additional text on the screen near the patron code selector that would be helpful.
Wes Osborn
supported this idea
·
An error occurred while saving the comment
Wes Osborn
commented
If this can't be implemented, the Leap patron bulk change process should make it clearer that you must change the patron's registered branch. Right now that is pretty unclear, whereas in the client it would give you a more specific error message.
-
4 votes
Wes Osborn
shared this idea
·
-
44 votes
An error occurred while saving the comment
Wes Osborn
commented
We would need the normalized search to work through the PAPI as well as within the Leap client.
An error occurred while saving the comment
Wes Osborn
commented
Sigh. This came up again today. So wild, there is no phone number normalization going on for search.
An error occurred while saving the comment
Wes Osborn
commented
Specifically the issue here in leap seems to be looking for SOME sort of delimiter. So, 614.837.8533 will match 614-837-8533 but 6148378533 will NOT match either of those.
Wes Osborn
shared this idea
·
Maybe a good middle ground is not enabled notices on the patron account until the notification delivery method has been confirmed. So the account could be created but notices wouldn't go out and the account would be cleared labeled as having its notices not going out until a confirmation link was selected that established good working communication first.