Possible issues with 942$0 (totalissues) values?

classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

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

_______________________________________________
Koha-devel mailing list
[hidden email]
http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : http://www.koha-community.org/
git : http://git.koha-community.org/
bugs : http://bugs.koha-community.org/