---- Reported by email@example.com 2008-07-17 23:03:35 ----
The MARC21 nonpublic note is mapped to items.paidfor.
This field was used in early Koha for what I assume is/was an HLT-specific requirement, and as such, it is wiped out when a LOST item's charge is paid from a patron's account. I suggest that this behaviour is removed, and for 3.0 stable, we use items.paidfor as though it were items.nonpublicnote . In 3.x, we can rename the db column, but for the short term, we have two competing de-facto meanings, one being the original hlt- (or whoever originally added it) meaning, and the other being the as-mapped MARC21 meaning.
I propose that the MARC21 meaning win for now, and that the following changes be made:
1: items.paidfor seems to be lost when an item record is edited. This value should be fully editable in the item editor.
2: Accounts->returnlost() should be modified to no longer replace items.paidfor's value.
3: items.paidfor should be treated as non-public note, and displayed in 'normal view' in the staff interface, and prevented from displaying in the OPAC interface.
---- Additional Comments From firstname.lastname@example.org 2008-07-18 16:00:26 ----
Ryan and I discussed this and decided that items.paidfor shouldn't be linked to non-public note, but that the link should be simply removed. I've just sent through a patch that does this, as well as fixes display issues and hidden values for that field. However, getting the non-public note to display in the normal view on the staff side isn't easy to do as it's un-linked. I propose we just keep it viewable on the MARC view for now, and fix this in the future.
I'm going to keep this placeholder here, but lower the severity and change the Version to rel_3_2
---- Additional Comments From email@example.com 2009-06-25 22:00:31 ----
Some libraries that are migrating have used a non-public note in the past for a variety of internal reasons. We discovered that we could not just migrate these to the same "place" because it was being used in this non-MARC way.
However, some of our libraries still use the non-public note AFTER migration. Merely deleting it is going to lose their data therein.
Can the coding merely be changed to standard MARC uses and the whole use of items.paidfor be done without losing the display in the staff module?
---- Additional Comments From firstname.lastname@example.org 2009-07-02 19:23:25 ----
Based on advice from Liblime during our data migration from Follett to KOHA, all of our "non public notes" for material items were copied into the field that says "Paid for?:" in the material "items" tab (if you go in and edit the item, this field is called "x - Nonpublic note."
I have to admit - I do not completely understand Joshua Ferraro's comments (not his fault - just my lack of knowledge). But I would like to be clear that our library does not want to loose the information currently stored in this field - and we need to be able to view/edit it in the staff module.
This information should also not be deleted when a "lost" item is "found." I will have to test it and see if this is happening. We are storing info in this field that has nothing to do with lost/paid for.
If someone could explain the current status of this situation (in really simple terms) :) I would appreciate it. Thanks!
--- Bug imported by email@example.com 2010-05-21 00:50 UTC ---
This bug was previously known as _bug_ 2370 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2370
Actual time not defined. Setting to 0.0
The original reporter of this bug does not have
an account here. Reassigning to the person who moved
it here: firstname.lastname@example.org.
Previous reporter was email@example.com.
CC member firstname.lastname@example.org does not have an account here
CC member email@example.com does not have an account here
I did a quick check and items.paidfor is still mapped to internal note 952$x in current frameworks.
But I disagree with the original bug reporter on the way to fix this. I think we need a new column in items and deleteditems for internal notes as proposed in bug 4222. This bug is currently stuck in "Failed QA" because of issues with the update process for existing installations.
In order to move discussion there I am marking this bug as WONTFIX. Please reopen if I missed something.