Settings and activity
283 results found
-
10 votes
An error occurred while saving the comment -
13 votes
Margaret Rose O'Keefe
supported this idea
·
-
94 votes
An error occurred while saving the comment Margaret Rose O'Keefe
commented
This would be extremely helpful for our consortium! (We might even be ok with an In Transit to Withdrawn transition instead.)
Margaret Rose O'Keefe
supported this idea
·
-
21 votes
An error occurred while saving the comment Margaret Rose O'Keefe
commented
I should have noted that the name of this Circulation Status in Polaris is "In-Repair" (we changed it to display as "Being Repaired")
Margaret Rose O'Keefe
shared this idea
·
-
12 votesMargaret Rose O'Keefe
supported this idea
·
-
41 votes
An error occurred while saving the comment Margaret Rose O'Keefe
commented
After reading this again after some time has gone by, it seems to me that we need to EXCLUDE items with certain suppressed statuses from generating the On Order message (not INCLUDE them).
Basically if all items on a bib. are Being Acquired or In-Process, then fine, it's On Order, but if all items on a bib. are Lost, Withdrawn, Missing, etc. then it should NOT say On Order. To me, that's an EXCLUDE in the logic, since right now ALL those statuses are resulting in On Order displaying, which is misleading to patrons.
As for records with NO linked items, that should probably be up to the library whether or not they want it to display as On Order, since there might be different views on that scenario.
Margaret Rose O'Keefe
supported this idea
·
-
11 votes
Secured patrons are patrons with a record status = 3. It is possible through SimplyReports content administration to add the RecordStatusID column from the Patrons table to the list of output columns.
I'm putting this idea under review because the RecordStatusID isn't exactly what was requested here. But I wanted to share that it may provide a workaround.
Margaret Rose O'Keefe
supported this idea
·
-
11 votesMargaret Rose O'Keefe
supported this idea
·
-
53 votesMargaret Rose O'Keefe
supported this idea
·
-
16 votesMargaret Rose O'Keefe
supported this idea
·
-
16 votesMargaret Rose O'Keefe
supported this idea
·
-
36 votesMargaret Rose O'Keefe
supported this idea
·
-
23 votesMargaret Rose O'Keefe
supported this idea
·
-
7 votesMargaret Rose O'Keefe
shared this idea
·
An error occurred while saving the comment Margaret Rose O'Keefe
commented
Several of our libraries collect materials in Hebrew, and almost all of those items have a danacode as a unique identifier. Some also have an ISBN but many don't, and their only identifier is the danacode, which is found in the 024 (with first indicator 7 in most cases, but sometimes 8 when the 'scannable' danacode is listed also).
However, when you try to search Vega by danacode, it doesn't work. It works without any problems in Polaris and in the old PAC.
A previous idea that was completed (for 024 3) stated: "As we see it, the obvious solution would be to let Vega map against 024 regardless of what comes after."
That would be one approach, but if for some reason the decision was made to only index the field for certain indicators, then we are making the request to add 7 as an acceptable indicator for 024 that would make the danacodes searchable in Vega.
-
40 votesMargaret Rose O'Keefe
supported this idea
·
-
36 votesMargaret Rose O'Keefe
supported this idea
·
-
12 votesMargaret Rose O'Keefe
shared this idea
·
-
13 votesMargaret Rose O'Keefe
shared this idea
·
-
37 votes
An error occurred while saving the comment Margaret Rose O'Keefe
commented
Just to add more clarity to this request - we are a consortium of 78 libraries with over 1300 staffers of varying levels of expertise. Most of them have never heard of SQL nor would we introduce it to them as part of their workflow. However, it might be great for other libraries/systems, so I’m glad it’s an option. For us, however, the initial request remains, and we need this process to work for the average user in our system in a way that they can understand, which ultimately means having an option to select the last checkout/renewal date as a parameter.
Regarding the last circ date, we probably should have been more clear in our write-up, so let me provide more context for those reviewing this idea. We are not referring to last activity date or any other such ‘catch-all’ date - we are looking for the equivalent of the date parameter our libraries use for weeding in SimplyReports called ‘last checkout or renewal date’ which does limit successfully to just checkouts and renewals. Last check-in dates would unfortunately not provide the results we need, although it might work quite well for others.
Margaret Rose O'Keefe
shared this idea
·
-
19 votesMargaret Rose O'Keefe
supported this idea
·
Another idea here might be to allow the 130 field to be considered in the roll-up logic for JUST movies (240/130 was removed from consideration in roll-up logic because of issues it caused with print titles) so that catalogers could enter the "uniform" movie title there and trigger the roll-up that way. (The 130 field does provide disambiguation for works with the same name by including the year.)