Bug 4222 - Nonpublic note not appearing in the staff client
Summary: Nonpublic note not appearing in the staff client
Status: RESOLVED MOVED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: master
Hardware: PC All
: P2 major (vote)
Assignee: Srdjan Jankovic
QA Contact: Ian Walls
URL: cgi-bin/koha/serials/serials-collecti...
Keywords:
Depends on:
Blocks: 2370 6748
  Show dependency treegraph
 
Reported: 2010-02-18 08:25 UTC by Nicole C. Engard
Modified: 2014-10-02 14:57 UTC (History)
10 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
serial collections screen (62.90 KB, image/png)
2010-02-18 20:25 UTC, Chris Cormack
Details
Proposed patch (6.19 KB, patch)
2010-11-12 03:24 UTC, Robin Sheat
Details | Diff | Splinter Review
Bug 4222 - allow nonpublicnote to be a mapped DB column (5.74 KB, patch)
2011-06-03 01:50 UTC, Jesse Weaver
Details | Diff | Splinter Review
Bug 4222 - Also add non-public note to checkin/out screens (9.61 KB, patch)
2011-06-03 01:50 UTC, Jesse Weaver
Details | Diff | Splinter Review
data is in the database (81.56 KB, image/png)
2011-07-27 01:36 UTC, Nicole C. Engard
Details
patch (14.51 KB, patch)
2011-07-28 05:49 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
non public note on staff client (147.96 KB, image/png)
2011-07-28 11:45 UTC, Nicole C. Engard
Details
patch (14.55 KB, patch)
2011-07-29 05:10 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
patch (14.80 KB, patch)
2011-08-04 02:10 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
Script to rebuild items after a mapping change (2.05 KB, text/x-perl)
2011-08-04 11:25 UTC, Paul Poulain
Details
patch (15.68 KB, patch)
2012-03-07 07:39 UTC, Srdjan Jankovic
Details | Diff | Splinter Review
Bug 4222 - allow nonpublicnote to be a mapped DB column (15.83 KB, patch)
2012-06-10 02:05 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review
Bug 4222 followup: Do not update mappings unless we ought (1.98 KB, patch)
2012-06-10 02:06 UTC, Jared Camins-Esakov
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:24:35 UTC


---- Reported by nengard@gmail.com 2010-02-18 20:25:47 ----

Created an attachment
serial collections screen

The nonpublic note is for the staff and yet only the public note appears on the serial collection page.



--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:24 UTC  ---

This bug was previously known as _bug_ 4222 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4222
Imported an attachment (id=1918)

Actual time not defined. Setting to 0.0
The original submitter of attachment 1918 [details] is unknown.
   Reassigning to the person who moved it here: chris@bigballofwax.co.nz.

Comment 1 Nicole C. Engard 2010-09-08 22:56:48 UTC
This also applies to bib records, the non public note on the item record does not appear on the bib record detail.
Comment 2 Robin Sheat 2010-11-12 00:23:29 UTC
I hope to have a look into this today.
Comment 3 Robin Sheat 2010-11-12 03:24:52 UTC Comment hidden (obsolete)
Comment 4 Robin Sheat 2010-11-12 03:27:22 UTC
This patch:
* Creates a new column in items
* Adds a mapping for that column to 952$x (Non-public note)
* Adds the template stuff to make it show up on the details and moredetails screens.

Note: after this patch is applied and the DB updated, the display will only happen on newly added or resaved records, before this happens the 952$x field isn't populated.
Comment 5 MJ Ray (software.coop) 2010-12-12 19:16:07 UTC
This bug is mentioned in:
Bug 4222 - allow nonpublicnote to be a	mapped DB column http://lists.koha-community.org/pipermail/koha-patches/2010-November/012927.html
Bug 4222 - allow nonpublicnote to be a mapped DB column http://lists.koha-community.org/pipermail/koha-patches/2010-November/012975.html
Bug 4222 - allow nonpublicnote to be a mapped DB column http://lists.koha-community.org/pipermail/koha-patches/2010-November/012976.html
Bug 4222 - allow nonpublicnote to be a mapped DB column http://lists.koha-community.org/pipermail/koha-patches/2010-November/012991.html
Bug 4222 - allow nonpublicnote to be a mapped DB column http://lists.koha-community.org/pipermail/koha-patches/2010-November/013003.html
Comment 6 Chris Cormack 2010-12-13 03:51:23 UTC
Awaiting a revised version of this.
Comment 7 Nicole C. Engard 2011-02-20 13:29:45 UTC
I'd add that the non public note should appear not only on moredetail but on the checking and checkout screens as well (since the public note shows there).
Comment 8 Nicole C. Engard 2011-04-25 13:58:12 UTC
Any word on an updated patch for this?
Comment 9 Robin Sheat 2011-04-26 01:51:13 UTC
I suppose I'm going to have to update it when I upgrade our hosted stuff, so I'll try to remember to attach it here then.
Comment 10 Nicole C. Engard 2011-05-20 12:31:09 UTC
Robin, Just a reminder (in case you forgot - since you said you'd "try" to remember) :)
Comment 11 Jesse Weaver 2011-06-03 01:50:25 UTC Comment hidden (obsolete)
Comment 12 Jesse Weaver 2011-06-03 01:50:28 UTC Comment hidden (obsolete)
Comment 13 Katrin Fischer 2011-06-03 05:14:40 UTC
I was looking at the code of the patches and see some problems:

- It's missing changes to kohastructure.sql
- The new fields is not added to deleteditems
- Will old internal notes still be shown after changing the field mapping with the update? I think if we do that, we need a way to keep the old internal notes accessible. The problem I see is that they can probably be in paidfor or in moresubfields_xml. Not sure what's the best way to do this.
Comment 14 Nicole C. Engard 2011-07-27 01:36:34 UTC
Created attachment 4746 [details]
data is in the database

Just for reference, the data is in the database, just not in it's own field and not showing on the screens.
Comment 15 Srdjan Jankovic 2011-07-28 05:49:08 UTC Comment hidden (obsolete)
Comment 16 Nicole C. Engard 2011-07-28 11:45:44 UTC
Created attachment 4765 [details]
non public note on staff client

Ooops - I signed off and then saw this.  If there is no note it should be blank and if there is a note it should print - but right now it's just a column of ones printing.

Nicole
Comment 17 Srdjan Jankovic 2011-07-29 05:10:06 UTC Comment hidden (obsolete)
Comment 18 Paul Poulain 2011-08-03 09:46:55 UTC
Some QA comments :

The database update says :
+    $dbh->do("ALTER TABLE items ADD COLUMN nonpublicnote MEDIUMTEXT");
+    $dbh->do("ALTER TABLE deleteditems ADD COLUMN nonpublicnote MEDIUMTEXT");

and the mySQL adds the field at the end of the items table :
   `stocknumber` varchar(32) default NULL,
+  `nonpublicnote` mediumtext default NULL,

There is already a field called itemnotes in the items table.
For consistency/clarity I would prefer to have the nonpublicnote next to the itemnotes, so :
+    $dbh->do("ALTER TABLE items ADD COLUMN nonpublicnote MEDIUMTEXT AFTER itemnotes");
+    $dbh->do("ALTER TABLE deleteditems ADD COLUMN nonpublicnote MEDIUMTEXT AFTER itemnotes");

and kohastructure modified accordingly.

2nd topic :
+    $dbh->do("UPDATE marc_subfield_structure SET kohafield='items.nonpublicnote' WHERE (kohafield IS NULL OR kohafield = '') AND tagfield='952' AND tagsubfield='x'");

=> in UNIMARC, there is non-public note, so nothing specific to do here.
=> I feel the UPDATE can be dangerous = if someone has items mapped to something different than 952, or 952$x used for something else (i've seen the kohafield IS NULL OR kohafield = '', ++ for this security), there may be side effect.

I would prefer to have :
* nothing done in the database
* a clear warning in the "print "Upgrade to $DBversion done (...)", like "Upgrade to $DBversion done (<b>New field : items.nonpublicnotes. Please go to admin > frameworks > and map this field to your MARC non public note. It will appear on circ desc</b>)"
* a visible explanation in the release notes

Ian/chris/Srdjan your opinion ?
Comment 19 Paul Poulain 2011-08-03 09:51:06 UTC
(2nd point being more important than the 1st one I think)
Comment 20 Ian Walls 2011-08-03 20:16:09 UTC
Paul,


The first issue is purely cosmetic, in my opinion, and should not delay this patch.  Srdjan, if you want to alter the database update portion to place this column after "itemnotes", go ahead, but it's not required.

For the alteration of the marc_subfield_structure, I think that benefit of automatically inserting this bit of data in order to complete the feature outweighs the slight chance of someone having mapped items to a different MARC field.  For safety sake, perhaps an added note to the updatedatabase.pl line saying:

"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"

Thank you, Paul, for catching this fringe case.
Comment 21 Srdjan Jankovic 2011-08-04 02:10:45 UTC Comment hidden (obsolete)
Comment 22 Nicole C. Engard 2011-08-04 04:11:52 UTC
Updated patch signed off on.
Comment 23 Katrin Fischer 2011-08-04 04:41:19 UTC
I am a bit worried about this patch because when you have not mapped the nonpublicnote to any field, your data is saved into more_subfields_xml. 
After the frameworks are updated with this patch, you will not be able to access the data. The information will still be stored in the xml field, but your frameworks will be pointing to the new column.
I am not sure how to prevent this.
Would it be possible to move the data from the XML field into the new subfield on update? What would the risks be?
Comment 24 Paul Poulain 2011-08-04 08:13:00 UTC
Well spotted Katrin !
This is a MAJOR problem. We already had it for some of our customers, when he asked for some mapping changes. The result is really annoying, Koha is highly confused by this case.
We've made a script. iirc, it was specific to this customer, but maybe it could be adapted easily (and maybe it's not specific)

Will investigate ASAP
Comment 25 Paul Poulain 2011-08-04 11:25:15 UTC Comment hidden (obsolete)
Comment 26 Ian Walls 2011-08-05 12:24:11 UTC
Since Koha 3.4, the item information is no longer stored in biblioitems.marcxml, so I don't believe this script will work on current databases.

What needs to happen:
1) identify all items with an unmapped 952$x in more_subfields_xml
2) for each of those items, move the content of the more_subfields_xml 952$x to items.nonpublicnote
3) add the biblio for the items to zebraqueue for reindexing
Comment 27 Paul Poulain 2011-08-11 16:43:38 UTC
Marking "failed QA" until a proper solution has been found for comment 23 from Katrin
Comment 28 Katrin Fischer 2012-01-06 15:44:59 UTC
I think one of the problems here is, that we can not assume people have been using x for internal notes. 

So perhaps one solution would be:

- Change the mappig only for new installs, don't make any updates to existing installs and their frameworks

- Provide a script or some SQL and a short documentation how to move over existing internal notes into the new field from the xml field.

Could this work?
Comment 29 Katrin Fischer 2012-02-19 12:33:13 UTC
This patch is not related to serials - changing the module to Cataloguing.
Please reassign if you think another module is a better fit.
Comment 30 Srdjan Jankovic 2012-03-07 07:39:33 UTC Comment hidden (obsolete)
Comment 31 Katrin Fischer 2012-03-07 07:49:26 UTC
Hi Srdjan, 
I checked the updatedatabase - you update the mappings. I don't think this is a good idea, becaue it will break existing mappings and will make data non-accessible. Please check the comments.
Comment 32 Katrin Fischer 2012-03-07 07:50:49 UTC
(kohafield IS NULL OR kohafield = '') means the data is saved to more_subfields_xml.
Comment 33 Jared Camins-Esakov 2012-06-10 01:46:44 UTC
Katrin,

(In reply to comment #32)
> (kohafield IS NULL OR kohafield = '') means the data is saved to
> more_subfields_xml.

I disagree with failing the patch because of the mapping update. It very carefully makes sure not to clobber any existing mappings. The only case where an existing mapping might be clobbered is if someone has manually created an items.nonpublicnote column and mapped something other than 952$x to it. If someone already has non-public notes in their item records, adding the mapping will not make it any more inaccessible than it already is.

To restate the following SQL in English:
  UPDATE marc_subfield_structure SET kohafield='items.nonpublicnote' WHERE
  (kohafield IS NULL OR kohafield = '') AND tagfield='952' AND tagsubfield='x'

"Map 952$x to items.nonpublicnote if and only if 952$x is not mapped to anything else."

The updatedatabase is MARC21/NORMARC-specific, though, and doesn't check that the flavour is MARC21 or NORMARC before updating. I will add a follow-up adjusting it to check the marcflavour, and also not remap items.nonpublicnote if it has already been mapped to a field.

I think it's much better to have non-public notes accessible in some cases than none, which is our current situation. I can already edit non-public item notes.

Also, it's worth noting that if someone has changed their mappings for the 952 field, they will have had to redo the Zebra configuration files, so they clearly know what they are doing.
Comment 34 Jared Camins-Esakov 2012-06-10 02:05:50 UTC
Created attachment 10056 [details] [review]
Bug 4222 - allow nonpublicnote to be a mapped DB column

This means that it's possible (and easy) to put non-public notes
(usually 952$x) on a template, same as public notes. It creates a
mapping between the 952$x field and the new database column.

Note that when this is applied, it will only work on newly saved
records.

It is possible this will need to be altered to allow for UNIMARC etc. if
they use 952 differently.
Comment 35 Jared Camins-Esakov 2012-06-10 02:06:03 UTC
Created attachment 10057 [details] [review]
Bug 4222 followup: Do not update mappings unless we ought

This follow-up modifies the database update for 4222 to only modify
mappings if the installation is not UNIMARC, and nothing else has
been mapped to the items.nonpublicnotes column (which did not exist
before the patch for bug 4222).
Comment 36 Katrin Fischer 2012-06-10 06:49:22 UTC
Hi Jared, 
I might be wrong here, because I can't remember disagreeing with you. :)

 But I think maybe I didn't explain it well before? If you leave the mapping empty (which yes, we did...) the value will be saved into the more_subfields_xml column in XML format. So after updating the mapping, the value will still be there, but you will not be able to access the information from the interface. So I was suggesting that there should be a way to copy that information into the new field or give at least a warning, that you might have to do so.
So it's not only when people created a new column, but also when they were using the methods Koha provides to add additional subfields.
Comment 37 Jared Camins-Esakov 2012-06-10 12:22:32 UTC
Katrin,

(In reply to comment #36)
> Hi Jared, 
> I might be wrong here, because I can't remember disagreeing with you. :)
> 
>  But I think maybe I didn't explain it well before? If you leave the mapping
> empty (which yes, we did...) the value will be saved into the
> more_subfields_xml column in XML format. So after updating the mapping, the
> value will still be there, but you will not be able to access the
> information from the interface. So I was suggesting that there should be a
> way to copy that information into the new field or give at least a warning,
> that you might have to do so.
> So it's not only when people created a new column, but also when they were
> using the methods Koha provides to add additional subfields.

As far as I can tell, the situation is no worse after applying the patch than it was before applying the patch. Are you able to find a situation where the patch makes things worse than they already are?
Comment 38 Chris Cormack 2012-06-16 10:05:22 UTC
(In reply to comment #37)
> Katrin,
> 
> (In reply to comment #36)
> > Hi Jared, 
> > I might be wrong here, because I can't remember disagreeing with you. :)
> > 
> >  But I think maybe I didn't explain it well before? If you leave the mapping
> > empty (which yes, we did...) the value will be saved into the
> > more_subfields_xml column in XML format. So after updating the mapping, the
> > value will still be there, but you will not be able to access the
> > information from the interface. So I was suggesting that there should be a
> > way to copy that information into the new field or give at least a warning,
> > that you might have to do so.
> > So it's not only when people created a new column, but also when they were
> > using the methods Koha provides to add additional subfields.
> 
> As far as I can tell, the situation is no worse after applying the patch
> than it was before applying the patch. Are you able to find a situation
> where the patch makes things worse than they already are?

I think it is worse, because now you have data stored, you can no longer edit or even access. It will stay in the more_subfields_xml column until you edit an item and at that point it will get deleted.
Comment 39 Jared Camins-Esakov 2012-06-16 11:24:01 UTC
(In reply to comment #38)
> I think it is worse, because now you have data stored, you can no longer
> edit or even access. It will stay in the more_subfields_xml column until you
> edit an item and at that point it will get deleted.

I must have had something misconfigured, because when I tried editing a record with data in the subfield $x, the data showed up in the edit item screen.
Comment 40 Chris Cormack 2012-07-01 00:55:14 UTC
If someone else could test this that would be good. Would be great to get it fixed, and it might well be that I was testing wrong
Comment 41 Kyle M Hall 2012-08-06 15:01:36 UTC
Can someone provide a test plan for this? I created a magazine with a nonpublic note. Then I applied the patch and ran updatedatabase. I then rebuilt my zebra index, and ran touch_all_items and touch_all_biblios. The new nonpublicnote is still null.
Comment 42 Katrin Fischer 2012-08-12 11:59:27 UTC
Comment on attachment 4836 [details]
Script to rebuild items after a mapping change

Obsoleting the script, because it will not work with newer versions of Koha where the items information is no longer stored in the XML.
Comment 43 Katrin Fischer 2012-08-12 13:53:59 UTC
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.
Comment 44 Nicole C. Engard 2013-05-14 16:43:34 UTC
This is still a big issue - are we in a state of discussion on this? do we need a new patch?
Comment 45 Chris Cormack 2013-05-14 17:32:33 UTC
(In reply to comment #44)
> This is still a big issue - are we in a state of discussion on this? do we
> need a new patch?

Nope its in failed qa, it needs a follow fixing the things that make it fail qa. Most importantly
6a, and updating all the frameworks.

Then a proposal of how to deal with the fact for lots of libraries that column was used for paidfor for a long and will contain that data. And a patch to deal with that cleanly
Comment 46 David Cook 2013-08-14 06:33:54 UTC
Maybe it's worth teasing apart what needs to happen here...

Architecture:
1) Add nonpublicnote to the items and deleteditems tables for all installs using updatebase.pl (it shouldn't matter if the column is in the items table for old installs). 
2) Change kohastructure and default framework SQL so that new installs map 952$x (and the other flavour equivalents) to the nonpublicnote DB column.

Display (Show on):
1) detail page
2) moredetail page
3) circulation pages
4) returns pages
5) serial collections pages?


Utilities:
1) Iterate through all frameworks
-> If a mapping for item Non-public note is found, copy the data into the nonpublicnote column. 
-> If no mapping is found, use the subfield in the framework (probably X) to interrogate the more_subfield_xml for an element with that subfield, and copy that data into the publicnote column.
2) Set the mapping for all frameworks for Non-public note to nonpublicnote DB column.

--

Concerns:

When iterating through the frameworks, we need to have a way of defining the entry for which we're looking. I don't think it's enough to look for the string "Non-public note" as that might be changed (or translated?).

Is it enough to look for the 952$x? This probably only applies to MARC21 so we'll need to take into account the other marc tags used for the other MARC flavours.

It might be an idea to make the utility interactive to make sure that the 952$x (or whatever) is the right framework entry to be analyzing...although if the script is interactive, it might make it more difficult for some people to do upgrades.

Thoughts anyone?
Comment 47 David Cook 2013-08-14 06:35:31 UTC
Another idea would be to just parse the data from more_subfields_xml (rather than changing the architecture of the database), but I think that would bring us back to the possibility that we might not necessarily know for sure that 952$x is always the MARC21 field/subfield for the non-public note. 

I'd be happy for someone to prove me wrong on that one though, as that might just be the easiest way to do this.
Comment 48 David Cook 2014-02-12 23:20:06 UTC
What do folks think about trying to resolve this issue in stages?

1) Add new non-public item note column to items and deleteditems

2) Add template stuff for the new column (even if the column is empty, which would be the default, this wouldn't change any default system behaviour)

That's it. The responsibility of updating frameworks and migrating data can be left up to Koha administrators. It's not ideal, but it would be progress. 

Perhaps we could update the frameworks for a fresh install to show that's how things should go in the future, but I don't see an automatic way of fixing this for everyone and I don't think it makes sense to stop working on this because it can't be perfect.




P.S. If I understand koha2marclinks.pl correctly, it is a frightening script. On a test instance, it will say that "paidfor" is mapped to 952$x, but it's not really...or rather...it's mapped to 952$x for the FA framework but none of the others. That's incredibly misleading...
Comment 49 Kyle M Hall 2014-10-02 14:27:46 UTC
I completely agree. I think the best course of action is to have notes in the release that they will need to map the non-public note in each framework, then run misc/maintenance/touch_all_items.pl to pull the note into the db column.


(In reply to David Cook from comment #48)
> What do folks think about trying to resolve this issue in stages?
> 
> 1) Add new non-public item note column to items and deleteditems
> 
> 2) Add template stuff for the new column (even if the column is empty, which
> would be the default, this wouldn't change any default system behaviour)
> 
> That's it. The responsibility of updating frameworks and migrating data can
> be left up to Koha administrators. It's not ideal, but it would be progress. 
> 
> Perhaps we could update the frameworks for a fresh install to show that's
> how things should go in the future, but I don't see an automatic way of
> fixing this for everyone and I don't think it makes sense to stop working on
> this because it can't be perfect.
> 
> 
> 
> 
> P.S. If I understand koha2marclinks.pl correctly, it is a frightening
> script. On a test instance, it will say that "paidfor" is mapped to 952$x,
> but it's not really...or rather...it's mapped to 952$x for the FA framework
> but none of the others. That's incredibly misleading...
Comment 50 Kyle M Hall 2014-10-02 14:52:52 UTC
Moving and splitting bug into db part and UI part. Koha has moved on quite a but so at least some of the UI code is now outdated.