The categories table contains the following vales of category_type: +---------------+ | category_type | +---------------+ | A | | X | | I | | S | | C | +---------------+ I suggest that the following entries be added under authorized values: +-------------+------------------+-------------+-------------+ | category | authorised_value | lib | lib_opac | +-------------+------------------+-------------+-------------+ | PATRON_TYPE | A | Adult | Adult | | PATRON_TYPE | X | Othter | Othter | | PATRON_TYPE | I | Institution | Institution | | PATRON_TYPE | S | Staff | Staff | | PATRON_TYPE | C | Child | Child | +-------------+------------------+-------------+-------------+ ... It's just a convenience.
Hi Barton, what is the use case? Those are hardcoded values you are not supposed to change, wouldn't it be confusing? It's also a problem as it would 'undo' translations. Right now those values are translatable where used.
(In reply to Katrin Fischer from comment #1) > Hi Barton, > > what is the use case? Those are hardcoded values you are not supposed to > change, wouldn't it be confusing? It's also a problem as it would 'undo' > translations. Right now those values are translatable where used. Katrin, I don't have too much of a use-case for this -- occasionally, I'll write reports that make use of category_type, but even then, I'm probably only using one of them (querying for adult patrons, or staff or children). I guess it would be handy to have them in a drop down, a-la SELECT count(*), s.ccode FROM statistics s INNER JOIN borrowers p using (borrowernumber) INNER JOIN categories c using (categorycode) WHERE s.type in ( 'issue', 'renew' ) AND c.category_type = <<Patron Type|PATRON_TYPE>> GROUP BY ccode More than anything, I find having one-character values scattered throughout the source code to be very confusing. The authorised_values table acts as a controlled vocabulary for Koha... from a support perspective, we get a lot of questions of the form "What does WRDL stand for?", "I see 'F', 'FU' and 'PAY' among my fines, is that defined anywhere?". Those are questions that tend to linger unanswered on mailing lists because the people who know are busy and the people who don't haven't the first clue as to where to look. Having these in the authorised_values gives a good, consistent place for users to look for mysterious codes found in the database. I'm going to go ahead and close this as invalid; I hadn't taken the aspect of translations into account... but maybe we should consider making the codes that we use internally to Koha more human readable?
Maybe we should add more info to the manual about those as a first step? There is some information on the 'new report' help page, but that's hard to find. I added a task on Taiga: https://tree.taiga.io/project/ldjamison-kohadocs-1805/task/559