An easy-peasy way to order the display of Koha’s ExtendedPatronAttributes fields.
This is going to be a brief tutorial, ExtendedPatronAttributes provide the capability to add custom fields to Koha’s patron management e.g. if we wish to capture say Program enrolled or Roll No. or other demographic details that we may be required to maintain under (a) law of the land or (b) governing rules of our library, this feature of Koha is friend we need to take help of.
If you have just landed on this blog and have no idea what we are talking about, we suggest that you may like to first read this earlier post – Harnessing Koha’s ExtendedPatronAttributes (aka patron custom fields). And while you are here, you may also like to visit this article.
Ok! Enough backstory, now back on topic! 🙂 When we define new custom fields to Koha using Home › Administration › Patron attribute types, the key thing to remember here is that these are ordered and displayed using alphabetic ascending sorting order of the defined Patron attribute type code.
Which means, when we defined a list of custom fields to capture student registration details e.g. as given in the screenshot below, we want them to be displayed in the order of the codes are numbered in the blue circles i.e. Student code, Registration No. and Roll No. in that order respectively.
Instead what we get is this:
We simply need to number our codes. The way to do this is simply to prefix them with a serial number. Here we chose to use 00_, 01_, 02_”. Of course, this also meant that we had to dump off our old codes and put in these as replacement.
Hint: Do this before you start using the defined fields while entering your patron records. While it can be done later, you need to know what you are doing if you don’t want to mess up your patron data.
You can see what we did below:
And as you can see below, we have the fields displayed exactly in the order we had wanted in the first place.
Presenting an use-case requiring setting the default messaging preference for SMS alerts sent by Koha.
Earlier in the day, my professional colleague and friend Joydeep Chanda asked a question. His Koha v3.22.10 installation (at Gurudas College Library) had turned on SMS alert service for its users. The library being a long time Koha user, presented a challenge. He had ~ 6000+ users, so now he and his staff had the unenviable task of having to update the
smsalertnumber field in the
borrowers table for these 6000+ users. I pointed him to a recent Facebook post by another friend Vimal Kumar Vazaphally. That solved part of his problem, but he still had to choose the default types of SMS messages to be delivered.
So, I pointed him to another post by Vimal – “Use of borrowers-force-messaging-defaults script“. But after a while he complained that while the
borrowers-force-messaging-defaults script did set the SMS options, it also enabled *all* of them, he wanted SMS send option to be set only for
borrowers-force-messaging-defaults as included in its source:
If the EnhancedMessagingPreferences syspref is enabled after borrowers have been created in the DB, those borrowers won’t have messaging transport preferences default values as defined for their borrower category. So you would have to modify each borrower one by one if you would like to send them ‘Hold Filled’ notice for example.
This script create transport preferences for all existing borrowers and set them to default values defined for the category they belong to.
The answer lies in correctly assigning advanced messaging preferences by default to a patron category *and then* running the
borrowers-force-messaging-defaults script. In order for the patron category edit page display the “Default messaging preferences for this patron category” sub-form, the system preference
EnhancedMessagingPreferences needs to be enabled.
- Check if the
EnhancedMessagingPreferences is enabled. If not, then enable it.
- Go to Home -> Administration -> Patron categories and select the category to edit.
- Scroll down the Modify category form to the “Default messaging preferences for this patron category” section.
- Select the checkboxes against the SMSes you want to be sent by default for that category.
- Save the changes
- Go to a command line terminal and run the
borrowers-force-messaging-defaults script. This will ensure that only the defaults are set.
 “Koha and key lessons of using transactional SMS in India” by L2C2 Technologies
 Press release about setting up of SMS alert service at Gurudas College Library.
 SMS-Send-IN-Unicel-0.01 at CPAN
In-line line breaks in a CSV file can really send your Koha patron import script into a tailspin. Here is what you need to watch out for and the couple of other gotchas which will make you upgrade your Koha instance if the version you are using is less than 3.22.7.
Last week a friend working at a local college approached me for a spot of help. He was trying to import his patrons into Koha but was failing miserably. After he nearly got his head snapped off (Me: Do I look like I’m in the fortune telling profession???) he agreed to send over his data – an MS-Excel sheet for me to take a look at.
I pulled up a 3.22.6 instance I had laying around and tried to import his data. Quite expectedly, there were errors galore and the pretty much the same ones he was complaining about.
surname fields were NOT missing in *any* single record. So what was going on here??? The most interesting to note here is that patron importer script said :
272 not imported because they are not in the expected format
272 records parsed
Now this was really something as the total number of student records in that patron uploader CSV file were only 144. So where does the number 272 come from?
The answer to this was easy to find. My friend’s data had several records in a rather bad shape – they had embedded line-breaks within the cell. I’ve highlighted the first few of the badly formatted cells with yellow in the screenshot below.
So, I copied the first 28 records over to a new file, ran a hackish utility script to clean out the line breaks and saved these 28 records as a new file and proceeded to upload it. This time of course “the fat lady sang” i.e. the records got imported nice and we were done!. 😀
NOTE: Of course while doing that we encountered a few Koha bugs as well – Bug id 15840 and Bug id 16426. The work-around mentioned in comment #16 of the latter bug, by Koha QA Manager Katrin Fischer holds good, in case you get stuck here and can’t immediately upgrade. Otherwise to avoid these to bugs, your real option is to upgrade your Koha instance, something that I’m going to recommend to my friend (aside from him fixing his data).
Reference:  Wikipedia “It ain’t over till the fat lady sings”