Settings and activity
38 results found
-
6 votes
An error occurred while saving the comment An error occurred while saving the comment 
Wes Osborn
commented
In fairness, re-reading the latest documentation available (which in this case is for 7.6) they don't say it is SSO. It just works so similar to SSO without being SSO it is unnerving.
So, this request could probably be titled, allow Polaris and Web SA to authenticate via SSO.
Wes Osborn
shared this idea
·
-
3 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
·
-
5 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
·
-
27 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
·
-
2 votesWes Osborn
shared this idea
·
-
1 vote
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
·
-
11 votes
An error occurred while saving the comment Wes Osborn
commented
I am also totally in favor of a more comprehensive overview of the notes system for patron records that could include eliminating these two fields in favor a more robust and auditable system for tracking patron account notes.
An error occurred while saving the comment Wes Osborn
commented
I can't imagine the data that has been lost because of this behavior.
Wes Osborn
shared this idea
·
-
8 votesWes Osborn
supported this idea
·
An error occurred while saving the comment Wes Osborn
commented
This is a correct assumption, here is what we were told in 2015 (at that time we put in an enhancement to ask it to use the bib id # instead or the UPC):
Format
LCCN
Author
Title
Volume
Issue
Publication Year
ISBN (the system matches on the 1st ISBN in each record)In order for a request to be considered a duplicate, each of the above fields must match in both request workforms. For example, if the format listed in request A is DVD, the format in request B must also be DVD. Similarly, depending on how complete the record being used to create the request is, certain fields in the request workform may be blank. If this is the case, that field must be blank/null in both requests in order for it to qualify as a duplicate.
It is possible that two records with different, but similar, titles could be considered duplicates. An example of this would be if you had two DVD’s both released in 2014 and one was titled Le Chef, while the other was titled Chef. Should a patron place a request for these two titles, they would visibly match on the publication year and format. However, because the stored procedure used to check for duplicate requests checks both the Browse Title and the Sort Title of a record, it will also find a match there. While the Browse Title for these would not be a match (LE CHEF and CHEF), because the Sort Title drops the initial article of ‘Le’, requests for these two titles would be determined to be duplicates.
-
3 votesWes Osborn
shared this idea
·
-
16 votesWes Osborn
supported this idea
·
-
18 votesWes Osborn
supported this idea
·
An error occurred while saving the comment Wes Osborn
commented
This should also extend to the similar authority processing jobs. I didn't know those even existed and we have them back to 2009! We'll delete them through SQL, but it seems unfair not to extend this to other customers who don't have access to SQL.
-
61 votes
An error occurred while saving the comment Wes Osborn
commented
It would also be nice to see Authority records added to the view. If we want to go all out, maybe even an option in settings to determine which types of records go there for the user and an option for a compact view so you could get more entries in the list without scrolling.
Wes Osborn
supported this idea
·
-
15 votesWes Osborn
shared this idea
·
-
20 votes
An error occurred while saving the comment Wes Osborn
commented
We are evaluating discovery layers and having this in Vega would help put it on par with competitors (coming in Bibliocommons).
Wes Osborn
supported this idea
·
-
3 votes
An error occurred while saving the comment Wes Osborn
commented
You might also want to add this comment here on the product board: https://portal.productboard.com/iii/6-innovative-product-status-board-new/c/753-expresscheck-update
-
12 votes
An error occurred while saving the comment Wes Osborn
commented
Not forcing a log out of the identity provider is huge. Especially for organizations where the SSO is used to sign people in/out of the time keeping software is also SSO. So they sign out of leap, which signs them out of SSO, then they have to log back into SSO just to punch out for the day.
The option should be to sign out of Leap ONLY, just like non-SSOs sign out of Leap only.
Wes Osborn
supported this idea
·
-
4 votesWes Osborn
shared this idea
·
-
11 votesWes 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.
-
62 votes
An error occurred while saving the comment Wes Osborn
commented
This would be very important for any hosted customers who don't have direct access to SQL to perform record set cleanup.
Wes Osborn
supported this idea
·
-
48 votesWes Osborn
supported this idea
·
@Lynton I like the idea of SSRS support, but I think that is kind of on Microsoft to support on their end which they don't because I think they're trying to get people to switch to PowerBI instead :(