[Koha-devel] Possible issues with 942$0 (totalissues) values?

[Theodoros Theodoropoulos]

Hello everyone,

There might be some issues in Koha involving 942$0, update_totalissues 
script and sorting by popularity.

If I understand correctly, the update_totalissues script updates 
biblioitems.totalissues and updates the 942$0 too (see 
C4::UpdateTotalIssues). Also I believe that sorting by popularity is 
based on the indexed 942$0 values and not on the values in 
biblioitems.totalissues

So, I think there are a couple of cases where this number can be 
inaccurate leading to a false sorting-by-polularity.

1. If the value is prefilled by the script, regardless of the 942$0 
subfield being hidden in the Marc framework, a librarian with 
cataloguing permissions may go into the marc editor and change it directly.
That number will be indexed by zebra and used in sorting by popularity.
The only way of 942$0 being 'fixed' by the system is after a checkout of 
an item of this biblio is made. Then, the update_totalissues script will 
requery the DB tables to count the total number of checkouts and update 
942$0

2. Likewise, when a librarian with cataloguing permissions duplicates a 
biblio record with a value in 942$0, this value will be copied to the 
cloned record as well. As you imagine, this is wrong because it's a NEW 
biblio record (and probably has no items yet, so no checkouts), so 942$0 
should be initially 0. Again this 'cloned' value will be taken by the 
system as the 'official' number of total checkouts for this biblio (at 
least for sorting purposes) and will remain there until a checkout of an 
item of this biblio is made (so the script will recalculate the proper 
number and hopefully update it)

The 1st cannot be solved by simply 'hiding' 942$0 in the Default 
framework. The script will have the value filled, so the subfield will 
be visible and editable.
Is there a way to hide (or make readonly) certain fields from the 
cataloguer (even in the advanced editor?). Maybe a new syspref could be 
incorporated to restrict viewing/editing of certain MARC field/subfields?

The 2nd issue seems equally (if not more) important because it's more 
likely to happen.
I vaguely remember a discussion from the past where it was mentioned 
that by selecting 'flagged' in "Edit Framework Subfields > Advanced 
constraint values > Visibility", the value of that subfield would not be 
cloned in a new biblio, but I couldn't reproduce it in my tests.
Maybe we could use this for differentiating the case when all checkboxes 
are unchecked and where flagged is selected? (I believe that right now 
the behavior of these two is identical).

I'm only thinking aloud, so any ideas/comments would be more than welcome!

Kind regards,
Theodoros Theodoropoulos