Tom McCutchon
My feedback
24 results found
-
2 votesTom McCutchon
shared this idea
·
-
9 votesTom McCutchon
shared this idea
·
-
11 votesTom McCutchon
supported this idea
·
-
21 votesTom McCutchon
supported this idea
·
-
35 votesTom McCutchon
supported this idea
·
-
38 votesTom McCutchon
supported this idea
·
-
3 votesTom McCutchon
shared this idea
·
-
28 votesTom McCutchon
shared this idea
·
-
3 votesTom McCutchon
supported this idea
·
-
10 votesTom McCutchon
shared this idea
·
-
8 votes
An error occurred while saving the comment -
11 votesTom McCutchon
shared this idea
·
-
51 votes
An error occurred while saving the comment Tom McCutchon
commented
Hi Dustin,
This would create a way of kind of barcoding items without actually needing to barcode them. The concern from my end is less about duplicate requests, though that could be managed, too. What tends to be the problem is that two different users want the same item at overlapping times and it would be good to know of that before someone has gone to the shelf for that item, or when offsite scheduling overlaps in unfortunate ways (ie, when someone's offsite request finishes the day before someone else's is set to begin). This kind of virtual barcoding could really help simplify some of the tracking of items so that things didn't have to be all based around transaction numbers.
An error occurred while saving the comment Tom McCutchon
commented
One attractive solution to this, for me, would be to assign unique IDs to requests that match all of a particular/but configurable set of data fields with each other. So, if a request is created with a Collection Number, Title, Box Number, and author, for instance, and no other request yet has that same combination of particularities, it would be assigned a unique ID number. If there was another request already that had the same details, then it would adopt the same ID number as the previous request. This would help solve a lot of overlapping use issues for special collections items that don't have barcode numbers and aren't about to be assigned them.
Tom McCutchon
supported this idea
·
-
21 votes
An error occurred while saving the comment Tom McCutchon
commented
Could also make batch editing a more robust Clone Request tool so that the old requests were simply cancelled out and new requests were created. This could also make it possible to create multiple requests from one request more easy (for instance when someone makes a request for "Box 1-20" and we otherwise have to clone the request 20 times to fix for someone).
Tom McCutchon
supported this idea
·
An error occurred while saving the comment Tom McCutchon
commented
If part of a multiple request edit, perhaps the former settings could be bumped down to the notes field for future reference.
-
8 votesTom McCutchon
supported this idea
·
-
45 votesTom McCutchon
supported this idea
·
-
1 voteTom McCutchon
shared this idea
·
-
10 votesTom McCutchon
supported this idea
·
-
2 votesTom McCutchon
shared this idea
·
-
40 votes
An error occurred while saving the comment Tom McCutchon
commented
This is particularly important to look at for sending out notifications for multiple related transactions immediately, as well. In cases where we want to send a confirmation of a Scheduled Date or a Cancellation email, it's more common than not that a separate email is required for each transaction. We should be able to easily group all the relevant transaction details together in one email.
It's a major inconvenience to our users to get multiple emails, and a major inconvenience to our staff to have to manually craft emails for covering multiple transactions. This kind of functionality is very much expected from both ends of the service for software like this.
Tom McCutchon
supported this idea
·
We actually used the copy / paste functionality that was in 3.8 quite often and now miss it in version 4.0. Is there a way to make these live side-by-side.