https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29539
--- Comment #41 from Tiago Simões <[email protected]> --- (In reply to Wainui Witika-Park from comment #40) > (In reply to Tiago Simões from comment #39) > > Not sure if the comments above were for me since I expressed interest in > > backporting it to previous versions than 23.11, but I can try and test in > > KTD. The problem is that I don't have any experience with docker so it might > > take a while for me to come up with a test plan as I need to familiarize > > myself with it. > > > > Any kind of help in doing so is welcome, if only to speed things up. If not, > > as far as I'm concerned, I can wait for an upgrade to a supported version. > > > > If the comments weren't directed at me, then please ignore. > > Hi Tiago, Thanks for your response! > > My comments were just directed at anyone really :) > > I am having trouble setting up the following: You will need to have a > bibliographic record with at least one subject autority connected in unimarc > framework. > > I'm not very familiar with unimarc and unsure how to change the marcflavour > on my ktd and having it persist through a reset_all. > > Any help from anyone would be greatly appreciated :) Hi Wainui, I've finally set up ktd with the 23.05 version and with the UNIMARC flavour. I've initially started it with marc21 and then switched to unimarc by accessing the .env file in the koha-testing-docker directory and changing the KOHA_MARC_FLAVOUR parameter from marc21 to unimarc. Everything seemed to work fine. I noticed the sample bibliographic records were different (all in french as far as I could tell) and the records' information was filled in the right unimarc fields (again, as far as I could tell). I even tried reset_all and reset_all_unimarc and, again, no issues. But I did notice that there were so little MARC bibliographic frameworks created (Default, Acquisitions and Fast Cataloguing), so the fields were kind of all over the place. Lots of mandatory unimarc fields that should not be mandatory, which makes the process of reproducing the bug difficult, since you first need to edit a record and switch the order in which the 606$9 and 606$a appear. If you still want to go through with backporting to older versions, I can create a bibliographic framework on my ktd environment, at least for books, just to make the process less of a hassle. If not, I completely understand. Either way, would it be worth it to ask for these frameworks to be added to ktd? I'd also add another step between 2) and 3), which is: Edit one or more records and switch the order of $9 and $a so the latter comes before the former. This can be tested with just the 606 field, as it is the most commonly used one in the 6 class. I hope my reply was helpful and not too confusing :). -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
