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