Settings and activity
106 results found
-
16 votes
Wes Osborn
shared this idea
·
-
13 votesWes Osborn
supported this idea
·
-
32 votesWes Osborn
supported this idea
·
-
27 votesWes Osborn
shared this idea
·
-
18 votesWes Osborn
supported this idea
·
-
16 votes
We will be adding a permission to address the issue of users with general access being able to reach the PAPI keys. There are some other comments here that could be considered separate enhancements, so please open new ideas for changes beyond a PAPI Key Management permission.
An error occurred while saving the comment Wes Osborn
supported this idea
·
An error occurred while saving the comment Wes Osborn
commented
Also, the API key itself shouldn't be visible to ANYONE.
Modern security practice is that you get ONE chance to see the actual key during the creation step and then after that all you can do is disable/delete it.
-
32 votes
An error occurred while saving the comment Wes Osborn
commented
It is wild to think that this date could be updated by anything other than a SQL Update. It shouldn't be exposed in any API or 3rd party integration.
Wes Osborn
supported this idea
·
-
31 votesWes Osborn
supported this idea
·
-
24 votes
An error occurred while saving the comment Wes Osborn
commented
Yes, this would be a time saver for us as well. It would also be nice that if it wasn't going to work that it would provide a better error message. Right now I think it just says system or internal error, something really generic.
Wes Osborn
supported this idea
·
-
14 votes
An error occurred while saving the comment Wes Osborn
commented
This would be SOOOO nice for all date pickers! Or use the OS/browser date picker, which would have this by default.
Wes Osborn
supported this idea
·
-
53 votesWes Osborn
supported this idea
·
-
12 votesWes Osborn
shared this idea
·
-
10 votes
An error occurred while saving the comment Wes Osborn
commented
This also means that you can end up with overlapping side bars when you go into the settings area.
Wes Osborn
shared this idea
·
-
18 votes
An error occurred while saving the comment Wes Osborn
commented
Our workaround is using the desktop client to populate this field or to make changes to staff accounts with this field (since you cannot save the account either).
Wes Osborn
shared this idea
·
-
10 votes
An error occurred while saving the comment Wes Osborn
commented
I imagine this was set up as a generic message because it would otherwise "leak" information as to if this was a valid barcode making it easier to compromise an account. See this Open Worldwide Application Security Project guidelines for their recommendations: https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#authentication-and-error-messages
-
8 votes
An error occurred while saving the comment Wes Osborn
commented
Even allowing the parameters to be defined like you would normally in SQL with the variables at the top of the statement would be helpful. Though I think these might get wrapped as CTEs which might not allow for that.
An error occurred while saving the comment Wes Osborn
commented
Just curious are you normally inputting branch and/or library ids? Forever, I have wanted the ability for us to put in a variable like $LOGGED-IN-BRANCHID into Find Tool sql and it would swap it out for the user's branch. Same with LIBRARYID too.
(sorry, I'm now seeing in your screenshot that your example is a barcode search)
Though your option could be more veristable for other Find Tool searches. It might be cool if the staff person could *optionally* save the parameters they've used for each different search as well.
Wes Osborn
supported this idea
·
-
16 votes
An error occurred while saving the comment Wes Osborn
commented
I commend the attempt to shoot for the moon on this one, but I'd also be happy with just a way to get a push notification when something is added to the Known Issues list - you used to have that option, but I don't think it works in the new supportal anymore.
Given that Polaris has never really been self-patchable and with more libraries moving to hosting I feel like that only becomes more so, it feels like finding another middle ground is likely needed.
Wes Osborn
supported this idea
·
-
30 votes
An error occurred while saving the comment Wes Osborn
commented
We had an instance recently where a staff member was attempting to log into another library's Leap instance because they'd done a google search and picked the first one and "they looked the same" so they just typed their information into the wrong system and then opened a ticket with us when they couldn't login.
Wes Osborn
supported this idea
·
-
9 votesWes Osborn
shared this idea
·
-
4 votes
An error occurred while saving the comment Wes Osborn
commented
This is very important for us to gain full support of pickup areas. Without this support, we likely will have to continue to create branch locations in Polaris.
Wes Osborn
supported this idea
·
In addition to hampering our ability to move away from the staff client and making us less secure, we also have to find another way to actively prevent people with client admin access from getting to the PolarisSA on the web. There is no separate permission for the web interface. So, if you have access to desktop SA in any form, you have access to Web SA which means you have access to and can manipulate PAPI keys. Which means that even if we don't want people to use it, we can't really prevent them without using another tool/method and still give them access to the desktop client. Those without more sophisticated tooling will then have to forgo the Polaris web SA altogether or risk exposing their API keys to anyone with any level of SA access (even if you preferred they stayed on the desktop).