[Koha-bugs] [Bug 4222] Nonpublic note not appearing in the staff client

[bugzilla-daemon at bugs.koha-community.org]

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4222

Katrin Fischer <katrin.fischer at bsz-bw.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|Needs Signoff               |Failed QA

--- Comment #43 from Katrin Fischer <katrin.fischer at bsz-bw.de> ---
Hi all,

I have started testing this again, here is my test plan. 
Sorry for it being so much to read:

1) Check the mapping in the default framework for 952$x.

Starting testing functionality in current master, all sample data installed,
patch not yet applied. 

By default on a new installation "Koha link" is currently empty. This means, a
value entered for non-public notes will be saved in items.more_subfields.xml. 

Problem: The default FA framework still maps to items.paidfor and it's marked
as repeatable.

Note: In past versions of Koha the default mapping was set to items.paidfor. So
there is a difference here depending on how old the installation you are
looking at is. 

2) Add a record and items with non public notes to your catalog.

3) Verify the note was saved correctly:

a) items.more_subfields_xml in the database
b) edit item screen (table on top and when editing the item)

Note: In my memory the MARC and labelled MARC (viewLabeledMARC) view used to
show the items with all subfields according to the configuration of the
bibliographic framework. So that was the place it was possible to see custom
item fields. This seems to be no longer the case?

4) Apply patches and run database update

Note: HTML is not interpreted in the database update message so the bold
doesn't work here:

a) Upgrade to 3.09.00.XXX done (Make nonpublicnote easier to use. <b>If you
have mapped your items to a MARC field other than 952 system default), please
check your Koha to MARC mapping for items.nonpublicnote</b>)

All my frameworks have been updated to use items.nonpublicnote, except for the
FA framework, which still links to items.paidfor.

b) Changes done by updatedatabase and changes to kohastructure.sql match. The
existing non public notes are still stored in more_subfields_xml.

5) Verify I can still access existing data

a) When I edit the item, the information still shows up in subfield x in the
item table and in the subfield on editing

b) After saving the information in the database got moved out of
more_subfields_xml and into nonplublic note. So it turns out I was all wrong
about this and Koha is clever! Excellent!

c) BUG: Adding a new item to the fast add framework (FA) with a internal note
shows, that the note is still saved in items.paidfor, but it doesn't show up
when editing the item. You can't access the information. I don't know what's
different here and why it doesn't work.

6) Verify new field acts as expected

a) BUG: On adding a new item the non public note is not saved. There is no
error in the logs, information is not stored in the database.

b) When editing an existing item the non public note does save.

c) The staff detail page now shows the nonplublic note in a separate column of
the items table.

d) The non public note correctly shows on the items tab.

e) Note shows up on returning the book. Non public and public note showing up
in the same column in red script.

f) Note shows up during checkout. Both notes are added to the title column and
show up after the title and before the barcode.

--------------------------------------------

In all my testing I never managed to lose any data :)

Failing QA:

6 a) Adding a new item the non public note does not save.

(not sure 5 c) is related to this patch)

Follow ups needed:

- ALL (not missing FA this time) need to be updated to use the new mapping.

Worried, but leaving to QA team:

-  We have to expect installations with "mixed" mappings, because we already
have an inconsistency in our default frameworks (FA = paidfor, all others =
more_subfields_xml).

- The data is only moved into the new column when you update the item. I think
while no data is lost, this will cause confusion.
You can't tell from the edit screen where the note is pulled from. I think for
installations we are brave enough to update the frameworks, we should also move
the data accordingly?

This is not so much a problem, when the mapping was empty=more_subfields_xml
before, but could be a problem when it was paidfor, because this field is now
also used for handling lost items. 

  *  Find a way to move or copy the data safely into the new column.
  *  Don't update the mappings and leave it to the system administrator to make
use of the new field.

I am a bit stuck on what is the best option here.

-- 
You are receiving this mail because:
You are watching all bug changes.