Cindy Bowen
My feedback
26 results found
-
34 votesCindy Bowen
supported this idea
·
-
48 votesCindy Bowen
supported this idea
·
-
112 votesCindy Bowen
supported this idea
·
-
84 votesCindy Bowen
supported this idea
·
-
391 votes
An error occurred while saving the comment An error occurred while saving the comment Cindy Bowen
commented
The shortcomings of the OTB search rules are especially obvious and have a dire impact on search usefulness now that the 'Equals Exact Phrase' search operator has been introduced. For example, properly qualified LC Name Authority headings are impossible to search using the new operator because the OTB indexing uses only subfield $a for Author/Creator fields. For our cataloged titles, this has the ludicrous result of effectively only searching "Henry" from the name heading of King Henry VIII of England: $a Henry $b VIII, $c King of England, $d 1491-1547. If you search the full heading, the only results you receive are from the CDI, which misrepresents available resources.
We are able to adjust search functionality for our hypertext linking definitions because of the ability to edit field normalization for that purpose, but there is currently no way to affect the OTB search more broadly. We need to be able to edit the OTB search rules to support local needs and allow our search results to better match user expectations.
Cindy Bowen
supported this idea
·
-
24 votes
An error occurred while saving the comment Cindy Bowen
commented
For what it's worth, it's feasible to use CSS to hide all the elements that you don't want patrons to modify. I asked Ex Libris for the coding to suppress the email and phone number portions (below), so I'm sure it's possible to do the same for the physical address...
#prm_mypref\.label\.my_email {
display:none;
}label[translate="mypref.label.my_email"] {
display: none;
}input#prm_contact\.telephone_1 {
display:none;
}label[translate="contact.telephone_1"] {
display: none;
} -
14 votesCindy Bowen
shared this idea
·
-
88 votesCindy Bowen
supported this idea
·
An error occurred while saving the comment Cindy Bowen
commented
"What is needed is some mechanism for bookings to expire automatically once the exclusion period is reached."
YES PLEASE. Our Booking Release Time setting is currently 12 hours (we book by day, not by hour), in the hopes that the overnight Handle Expired Booking Requests job would catch items not picked up on the first day of the (three-day) booking, but alas that's not how it works. This job only considers a booking "expired" if the entire booking period has elapsed without the item having been checked out to the requesting patron. And, of course, a once-daily job cannot ever properly address the scenario in the description above.
In short, we need some automatic mechanism to expire the entire booking request once the Booking Release Time configured has elapsed. The only way to handle these right now is to manually cancel each 'released' request, and our staff time would be far better spent on other tasks.
-
62 votes
An error occurred while saving the comment Cindy Bowen
commented
Yes, please!! The Resource Requests Monitoring page is virtually useless for monitoring and managing Booking requests as the page currently operates. After selecting "Booking request" from the Request/Process Type facet, none of the rest of the facets are any help for trying to review what items have bookings coming up in the near future. Sure, we can find out what was requested recently, but we currently allow bookings to be placed up to 90 days in advance, so the Request Date means nothing to us.
Instead, our staff have to export the list of Booking Requests and use Excel to sort the requests by start time. This is ridiculous and introduces the possibility of missing new requests that are placed for tomorrow, which is a problem when the list is being generated so items for upcoming bookings can be prepped. This functionality should already be possible in Alma and the fact that it isn't is extremely frustrating.
Cindy Bowen
supported this idea
·
-
14 votes
An error occurred while saving the comment Cindy Bowen
commented
If it helps anyone: We do bookings on a date basis only (i.e., the patron selects only the dates, not the times) to help address this issue. That plus a 1-hour preview period has the effect of requiring patrons to book at least one day in advance. From what I can tell, the preview period does two things: controls when the request appears in the pick-from-shelf list, and operates as a buffer between bookings. So using a longer preview period may also work if you still want to allow patrons to choose date-and-time...
-
38 votesCindy Bowen
supported this idea
·
-
201 votesCindy Bowen
supported this idea
·
-
94 votes
This is currently not planned to be developed. We might evaluate it again in the future.
Currently we are removing the "Under review" status.
Cindy Bowen
supported this idea
·
-
96 votesCindy Bowen
supported this idea
·
-
27 votes
An error occurred while saving the comment Cindy Bowen
commented
Yes, please! New order import profiles offer a checkbox for this ("Do not create electronic activation task"), so not having an equivalent option for GOBI API orders is especially vexing. Our workflow takes care of activating the resource without use of the activation task list, so the task list entries serve only to prevent the POL from automatically closing. This is a waste of staff time and effort to handle when Alma could easily automate the process if we could prevent the creation of the task list entries.
Cindy Bowen
supported this idea
·
-
135 votesCindy Bowen
supported this idea
·
-
145 votesCindy Bowen
supported this idea
·
-
57 votesCindy Bowen
supported this idea
·
-
50 votesCindy Bowen
supported this idea
·
-
98 votesCindy Bowen
shared this idea
·
NERS 9000, open for voting now.