Cindy Bowen
My feedback
37 results found
-
25 votes
An error occurred while saving the comment -
14 votesCindy Bowen
shared this idea
·
-
87 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.
-
69 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
·
-
38 votesCindy Bowen
supported this idea
·
-
209 votesCindy Bowen
supported this idea
·
-
95 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
·
-
107 votesCindy Bowen
supported this idea
·
-
40 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
·
-
145 votesCindy Bowen
supported this idea
·
-
60 votesCindy Bowen
supported this idea
·
-
115 votesCindy Bowen
shared this idea
·
-
121 votesCindy Bowen
supported this idea
·
-
76 votesCindy Bowen
supported this idea
·
-
173 votesCindy Bowen
supported this idea
·
-
50 votesCindy Bowen
supported this idea
·
-
328 votesCindy Bowen
supported this idea
·
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;
}