Evergreen

Bug #1527342
Comment #2

Comment 2 for bug 1527342

Revision history for this message

Kathy Lussier (klussier) wrote on 2015-12-18:

I think we should only include the data that might be useful to the end user and nothing more, so I agree that mimicking action.circulation is excessive. The columns you identified for feature parity look good.

I'm not terribly excited about circ_lib and checkin_lib, but I'm not necessarily opposed to it either. I could see a use case where a patron is trying to track down a title of a book they read and can only remember that they checked it out/in from a certain location in a certain timeframe. The circ_lib / checkin_lib might be useful here. A downside might be that if somebody did gain unauthorized access to the person's account, they will not only see a history of their reading, but would also get a general idea of which libraries they visit and when.

I can't think of any other fields we would need here.

In terms of maintaining static copy/call number/bib data (I know you're not addressing it, but I'll give my two cents anyway), I tried to think of a reason why a user would want the call number/barcode information in their reading history. Call number could be useful if they want to find an item to check out again, but, without the copy location, they may still need to click through to the bib record anyway f. In this instance, then, they would want to see the existing call number for the copy, not what the call number was when they checked it out. I can't think of any reason why they would want to see what the call number was at the time it was in their hands.

I don't know why anyone would want to see the barcode after they've returned the item. If we were building this from scratch, I might suggest that we don't need the call number and barcode to display, but, if we're going for feature parity, I prefer that the data not be static.

For those deleted call numbers, copies, bibs, would it be useful here to check for that and add styling or a notation that says the item is no longer available? I don't feel strongly about it, but it might be one way to address the issue.

Thanks Bill! I definitely think this enhancement is a step in the right direction!

I'm not terribly excited about circ_lib and checkin_lib, but I'm not necessarily opposed to it either. I could see a use case where a patron is trying to track down a title of a book they read and can only remember that  they checked it out/in from a certain location in a certain timeframe. The circ_lib / checkin_lib might be useful here. A downside might be that if somebody did gain unauthorized access to the person's account, they will not only see a history of their reading, but would also get a general idea of which libraries they visit and when.

I can't think of any other fields we would need here.

In terms of maintaining static copy/call number/bib data (I know you're not addressing it, but I'll give my two cents anyway), I tried to think of a reason why a user would want the call number/barcode information in their reading history. Call number could be useful if they want to find an item to check out again, but, without the copy location, they may still need to click through to the bib record anyway f. In this instance, then, they would want to see the existing call number for the copy, not what the call number was when they checked it out.  I can't think of any reason why they would want to see what the call number was at the time it was in their hands.

For those deleted call numbers, copies, bibs, would it be useful here to check for that and add styling or a notation that says the item is no longer available? I  don't feel strongly about it, but it might be one way to address the issue.

Thanks Bill! I definitely think this enhancement is a step in the right direction!