Time  Nick            Message
22:17 tuxayo          Good, things happened ^^
22:17 caroline        (informal)
22:17 caroline        just a lot of dicussion about the wiki
22:17 caroline        tuxayo: don't worry, it didn't really happen
22:13 tuxayo          Shoots, I missed the meeting although I was free
21:19 mkuhn           I'm now soon going to bed (it's 10 PM over here), so have a nice evening!
21:18 * thd           goes to the post office
21:18 thd             mkuhn: The database thing is a solved problem for over a year but I need to check my work and write some automated tests for verification.
21:17 thd             mkuhn: MediaWiki 1.16 should have no problems.  Semantic MediaWiki which never worked may have to be dropped and re-added.
21:16 mkuhn           "you can upgrade in one step, from your old version to the latest stable version" sounds good - then get rid of old extensions... and of course the database thing
21:15 mkuhn           Mediawiki 1.5 ?? Brrrr
21:14 thd             mkuhn: https://www.mediawiki.org/wiki/Manual:Upgrading#How_do_I_upgrade_from_a_really_old_version?_In_one_step,_or_in_several_steps?
21:13 thd             mkuhn: The core software should work find for upgrading in one jump.  One merely sees each of the incremental and unavoidable error messages at once.
21:13 mkuhn           Btw some extensions are completely out of date, unmaintained, even archived
21:12 mkuhn           But I never updated 1.16 to 1.35 - what a jump
21:11 mkuhn           As I see in https://wiki.koha-community.org/wiki/Special:Version there are not so many extensions
21:11 thd             mkuhn: I am going to go back to proving that the migration works without the data loss shortcut which Joubu took after going to the post office now.
21:09 thd             mkuhn: Yes, but the best tools for moving forward with MediaWiki or even maintaining an archive of old stuff will not be available if it cannot be demonstrated upgraded to the current version with no data loss and migrated to MySQL.
21:09 mkuhn           Also some people have very weird ideas how to "create content" (copy&paste for example)
21:08 mkuhn           who does that? People don't like to do it
21:07 mkuhn           But how does that? People don't like to do it
21:07 mkuhn           However, if the regime stands not before creating content, then at least the content should be maintained AFTER it has been created
21:07 thd             mkuhn: It is fine to let people create stuff and clean it later.
21:06 mkuhn           As far as I'm concerned, Dokuwiki is not the way to go
21:06 thd             mkuhn: The regime should never stand in people's way when they just want to create some content.
21:05 thd             In Dokuwiki most of the pages people had ever created had been lost.
21:05 mkuhn           Yes I understand - people don't like regimes, they like to do what they want...
21:05 thd             mkuhn: Exactly, finding "orphans" is a core feature of MediaWiki but not Dokuwiki.
21:04 mkuhn           also orphaned files, orphaned categories, pages, templates etc
21:04 thd             mkuhn: I had maintained an extension which forced people to choose a category for new pages but that was unpopular because the procedure needed for adding a new category slowed people down.
21:04 mkuhn           You can list all uncategorised categories, uncategorised pages, uncategorised templates etc etc
21:03 mkuhn           In mediawiki you can find untagged pages in various ways, through the spcial page - no extensions needed
21:02 thd             mkuhn: Dokuwiki has a tag extension which for some period allowed finding "orphan" untagged pages.  However, that feature is reported to have been broken for a long period now.
21:02 mkuhn           For my part I wouldn't even be unhappy if nothing changes with the current wiki (but I see the technical problem of using software from 2010, old as the hills).
21:01 mkuhn           That's human, it seems. That won't change in Dokuwiki, mediawiki, wahteverwiki. This can only be solved through regime - and people don't like that either...
21:00 thd             mkuhn: Dokuwiki like any software has some serious flaws which had frustrated me greatly.  The biggest problem was really people were very poor at remembering to put a tag or a category on a newly created page.
20:59 mkuhn           The crucial thing here is the should, I guess. I heard that so many times but it never really happened. In the end one of the software pieces is king and the rest is released - untested...
20:58 thd             mkuhn: Supporting multiple databases should be easy if everything is abstracted to be written in a database agnostic manner and not specially written for each database.
20:57 mkuhn           About Dokuwiki I would use it, but I sure wouldn't start installing, configuring, LEARNING it...
20:56 mkuhn           However, I'm not exactly sure If I could help in some way, except in sharing opinions...
20:56 thd             mkuhn: One advantage in favour of possibly using Dokuwiki is that the software is much less complicated.  However, there is also less help to be had from the much smaller Dokuwiki community fixing broken extensions for which the functionality is a core feature of MediaWiki.
20:55 mkuhn           I remember someone wanted to write support for Postgres when using Koha - it never got anywhere. In my experience it was never a good idea to support everything. Because that always means someone has to maintain it and that's why it always ends the same way...
20:53 thd             mkuhn: I have had success modifying extensions to work in more recent versions.
20:53 mkuhn           Extensions generally do work if apllied to the correct version - the problem with some extensions is they are sometimes abandoned
20:53 thd             mkuhn: MediaWiki documentation circa 2008 2009 showed some commitment to database agnosticism but it was unsustainable for the MediaWiki community as a whole and never became anything other than an experiment.
20:52 mkuhn           I'm fine with going away from Postgres
20:51 thd             mkuhn: We do not necessarily need Semantic MediaWiki even if it would be nice but we need extensions to generally work and not merely the subset which happens to work fine under Postgres.
20:50 thd             mkuhn: Such checks are not universal but depend upon the extension manager to write them.
20:49 thd             mkuhn: When installing extensions there can be various command line procedures to ensure that everything is running correctly for some extensions to validate the installation.
20:47 mkuhn           What do you mean with "command line checks"?
20:46 thd             mkuhn: In circa 2009, when the old Dokuwiki went down with LibLime non-cooperation with the community we had not tested enough to discover that command line checks for some things would fail with MediaWiki under Postgres.
20:46 mkuhn           There are sooo many extensions for Mediawiki - and I have tested and used a lot...
20:45 mkuhn           OK, I have never implemented Semantic MediaWiki - sounds great (if there is someone who understands how to do it :)
20:44 thd             mkuhn: No MySQL based MediaWiki allows Semantic MediaWiki and many other extensions to run which fail command line tests under Postgres.
20:43 mkuhn           So this means newer mediawiki software supports a better way of tagging? I don't know about that... I still use categories and links in my own installations, ols skool
20:41 thd             The bigger problem as ashima stressed to me a few years ago is migrating the database so that extensions which support faceted tags/categories will even work.
20:40 mkuhn           Yes, different names for different functions... I struggle with that problem even in the Koha software itself - where it is even worsened by inconsistent translations
20:39 caroline        it's the same for everyone... no one has time to work on this, hence the current state
20:39 thd             The number of pages is relatively small.
20:39 mkuhn           Only if I had the time... or only for a defined set of pages...
20:38 thd             mkuhn: It can all be done with tagging pages.
20:38 caroline        mkuhn: are you volunteering :D
20:38 thd             mkuhn: People use different names for the same function and one does not see what the other has done.
20:38 mkuhn           Who will do that? Who will want to do that?
20:38 mkuhn           I know that problem, but I can only see a solution with that by a stricter regime... more maintenance...
20:37 thd             mkuhn: The problem is that we have issues such as multiple pages with installation instructions which are not distinguished as to which applies to the current version and uninformed users can become confused.
20:36 mkuhn           OK, and I admit - I almost never go into the history of wiki pages, so that content could be deleted (as far as i am concerned)
20:35 mkuhn           Yes, as I said - if everything is preserved with the current/unchanged URL I am happy with everything else
20:35 mkuhn           Sometimes I am very happy to find old information about not so current versions that people ask me about
20:35 thd             mkuhn: You correctly identify but one of many reasons that old content should be well preserved.
20:34 mkuhn           What exactly is out of date? Some people are still using Koha 3.22 or older, as I see in the mailing list
20:33 thd             With appropriate tagging even minimally for current searches could automatically avoid out of date content.
20:32 mkuhn           Maintanining is more regime than now
20:32 mkuhn           Yes, but still it is good software - of course I prefer MariaDB
20:32 thd             mkuhn: Yes maintaining the tags is important.
20:31 thd             mkuhn: A header would be created magically by an extension.
20:31 thd             MySQL AB took the deliberate choice of not following some standards to pressure companies into buying proprietary licenses.
20:31 mkuhn           This could be done with a header in each article - but someone would have to maintain these tags
20:29 mkuhn           I understand, Postgres was hyped by some, but it never ever got where Mysql/MariaDB is now
20:29 thd             In any wiki we may need to add some tag to pages marking those as current and a different tag to other pages marking those as outdated.
20:28 thd             mkuhn: Postgres seemed a more standards compliant choice and we had not found the documents stating that Postgres was not well supported.
20:27 mkuhn           1.16 was released in 2010
20:27 caroline        Along with the software upgrade, I think the couple of us who had volunteered to clean up the wiki were a bit too daunted to clea it up, hence the suggestion to open a new one and just transfer what we know is correct and go from there
20:26 mkuhn           OK, I don't see that from the outside, as I said I always used MariaDB (Mysql before)
20:25 thd             The problem was choosing the wrong database, Postgres, to test.
20:25 mkuhn           I see it is Mediawiki 1.16, uhuuh
20:25 thd             The problem was never waiting too long.
20:25 mkuhn           This would be great, in my case I was always able to upgrade my mediawiki versions (though I didn't ever wait so long)
20:25 thd             It was complicated because it definitely required a lot of work.
20:24 thd             I may have an upgraded copy at this time next week.
20:23 thd             It is not too complicated to upgrade.
20:23 thd             mkuhn: The problem we arrived at by accident was in 2009 in the wake of lack community cooperation the old wiki went down and the untested test implementation of MediaWiki became the only thing.\.
20:23 caroline        I'm talking about the software itself, not the information
20:23 mkuhn           Hm, okay... it is really a very old version
20:22 mkuhn           Even with outdated and old stuff in it, the current wiki is THE Koha source, for me... and sometimes even old/outdated stuff is useful
20:22 caroline        (from what I understand)
20:22 caroline        mkuhn: the need to change is that the mediawiki version we run is out of date and it's too complicated to upgrade it
20:21 mkuhn           Yes, agree... but this usually needs a stricter regime...
20:21 thd             We need to test various options.
20:21 thd             mkuhn: What is import is to be able to find what is current.
20:21 mkuhn           Sure, but then I don't see no need for a change? If nothing will change?
20:20 thd             mkuhn: Any wiki will have outdated content over time.
20:20 thd             mkuhn: We ended up with what we had not appreciated was only experimental support for Postgres when choosing that database for MediaWiki.
20:19 mkuhn           But this would mean there must be a stricter regime... otherwise the new wiki will end up liek the current one
20:19 cait            i actually wanted to get some reading in :) so leaving now for real
20:19 cait            but we will figure it out
20:19 cait            I think if we make sure we have the better and easier to find information in a new wiki, i think that would be better
20:18 mkuhn           Maybe the new wiki could just be called else, so the old URLs could stay. I find it VERY annoying when large site change their URLs and you can't find anything anymore (like the Geman National Library did, for example, and many others, that should know better)
20:18 thd             At the least I intend to fix the archive so that the archive will not be running out of date software and can move forward over time.
20:17 cait            Joubu suggested redirecting/forwarding for th emost prominent pages - sql reports etc.
20:17 mkuhn           If the data and the URL of the current data will be kept, I will be happy
20:17 cait            i really think w eneed to loose some stuff :)
20:16 cait            it will just change to ol-dwiki or something
20:16 caroline        the info that is still relevant would be transferred to the new wiki
20:16 cait            yes
20:16 caroline        mkuhn: I think the plan is to still have the current wiki available, but archived
20:16 thd             mkuhn: I put enormous effort into ensuring that nothing will be lost.
20:15 mkuhn           My main concern would be that some data will be lost, all the URL will change etc. so people (like me) won't find things anymore
20:15 thd             mkuhn: When the ecomony went bad last time circa 2009 there was a community problem with LibLime where people in charge were especially worried about sharing with the community.
20:14 thd             mkuhn: Let me explain the history.
20:14 thd             mkuhn: No less strict.
20:14 mkuhn           Will some or all data be transferred to the new wiki? Will all the URL change so nothing is findable anymore und their known URL? (except thru the Wayback machine)
20:14 mkuhn           Will, for example, a stricter regime be implemented with the new wiki regarding the addition of new articles, their quality, their currentness and their linking to other articles?
20:14 thd             mkuhn: So you have not tried multiple versions of PHP on the save server in different virtual hosts.
20:13 mkuhn           I just saw someone would like to chnage the software so I was asking myself what is exactly the goal of it?
20:12 thd             Yesterday, I had my first COVID-19 vaccine so I am becoming safer and just dropping everything to support whatever peple want to do with the wiki.
20:12 cait            i'll be off for a while - been a long day (training again) cya later all
20:11 thd             I had basically solved the wiki issue at the end of 2019 but 2020 killed my time.
20:11 mkuhn           I'm running Mediawiki with MariaDB (Mysql), never tried Postgresql
20:10 caroline        glad to know my email got some attention :D
20:10 thd             After the last meeting I discussed with Joubu how he had missed character encoding and MediaWiki support issues in transfering data between Postgres and MySQL.
20:09 mkuhn           Caroline Cyr-La-Rose wrote the wiki question is often on the Development IRC meetings agenda, she mentioned this date today
20:08 cait            but maybe you 2 could talk off-meeting and share on the mailing list?
20:08 cait            we don't have new thing slisted
20:08 cait            https://wiki.koha-community.org/wiki/General_IRC_meeting_14_April_2021
20:08 mkuhn           I'm here because of the wiki thing
20:08 huginn          mkuhn: downloading the Perl source
20:08 cait            do we have a lot of new stuf fon the agenda? i am going ot check
20:08 mkuhn           @thd: was ist successful? I run my own Mediawiki software, but only one version at once (because of dependencies etc)
20:07 cait            it might ont be working
20:06 mkuhn           If he was called Louis you could call for Louisssssssss (as in Jackie Brown)
20:04 thd             I was trying to enable current old version and fully updated versions of the wiki to run on the same server.
20:04 cait            Joubu Joubu ... Joubu
20:04 * cait          tries the bettlejuice trick
20:04 cait            not sure if that is now already
20:04 cait            I think Joubu mentioned he would be away for some time end of month
20:03 mkuhn           well, old nick
20:03 cait            new nick? ;)
20:03 oleonard        thd: No I don't
20:03 mkuhn           Hello cait, long time I didn't see you here :)
20:02 cait            i tihnk it hasn't been started yet?
20:02 mkuhn           #info Michael Kuhn, Switzerland
20:02 cait            e
20:02 cait            i'd be her
20:02 thd             oleanard: Do you have any experience running multiple versions of PHP on the same webserver in different virtual hosts?
20:02 caroline        I'm vaguely around... I had an action from last meeting (because I wasn't there lol!)
20:01 oleonard        Not sure who all is here for a meeting
20:01 oleonard        Hi cait
20:00 oleonard        Oh I missed him on my list
20:00 thd             Only monitor of Joubu
19:59 oleonard        No Joubu eh
17:18 reiveune        bye
17:13 cait2           ok, i gotta go outside for a little bit, bye all
17:12 cait2           or otherwise highlight it visually
17:12 cait2           and then also moveit to holdings with jquery if people want to
17:12 cait2           putting the link in the record with a link text
17:12 cait2           we usually try to avoid items...
17:11 oleonard        Thanks!
17:11 cait2           oleonard: haen't been on your catalog in a while - looks really pretty
16:35 oleonard        https://search.myacpl.org/cgi-bin/koha/opac-search.pl?idx=kw&q=neal%20stephenson&count=20&limit=ccode:DNLD
16:34 oleonard        caroline we do that but then we alter the display so that it doesn't look like an item
16:01 caroline        she says right now they create one "item" per branch but she says it doesn't reflect the actual number of items
16:00 caroline        One of my clients is looking at how to indicate that an ebook "item" is the property of multiple branches
15:59 caroline        Do any of your clients share one copy of an ebook for many sites?
15:24 teertha         caroline: thanks :)
15:19 caroline        it's just for sorting
15:19 huginn          teertha: downloading the Perl source
15:19 teertha         @huginn forget perl source
15:18 huginn          teertha: downloading the Perl source
15:18 teertha         @caroline: so basically jusr sorting and kind of bookmarking for quick access?
15:16 caroline        so If there is a frequency that you use a lot, you can put 0 as display order and it will appear at the top so you don't have to look for it
15:16 caroline        0 is the top position
15:16 caroline        teertha: it's to control the order in which the frequencies appear in the drop-down menu
15:13 huginn          teertha: cait2 was last seen in #koha 13 minutes and 56 seconds ago: <cait2> i don't think we are leaving files out, do we?
15:13 teertha         @seen cait2
15:12 teertha         can anyone please help me understand the purpose and functionality of Display Order in managing frequencies of issue?
15:11 teertha         working as a junior librarian i am facing some problem in serial module.
15:10 teertha         My name is Teertha this the first time i am getting into koha.
15:08 teertha         kia ora #koha
14:59 cait2           i don't think we are leaving files out, do we?
14:59 cait2           ashimema: discussing if the Email.t is in packages or not
14:46 * ashimema      schoolboy german isn't up to following that.
14:40 MichaelKuhn     Ich habe eben nochmal mit "find / -name Email.t -print" gesucht - keine Datei "Email.t". Aber wenn sie natürlich einen anderen namen hätte kann ich sie nicht finden...
14:39 cait2           evtl, anderer Pfad
14:39 cait2           vielleicht wurde sie mal umbenannt oder verschoben, generell müssten die .t Dateien mit den Unit tests aber auch volsltändig in den Tarballs bzw. Packages sein
14:38 cait2           disconnect, vpn, sorry
14:37 MichaelKuhn     Gut... ich brauche sie ja auch nicht
14:37 MichaelKuhn     Email.t habe ich aber auf dem Koha-System nicht gefunden?
14:37 cait            ja, da war mein Denkfehler - hatte es nicht gleich gesehen
14:37 MichaelKuhn     But that's why I asked :)
14:37 cait            aber sie wird im laufende Betrieb nicht ausgeführt
14:37 MichaelKuhn     Yes, I thought so - not pushed
14:37 cait            vorhanden ist sie
14:36 MichaelKuhn     Weitere Änderungen gab es nur in der Datei "Email.t", welche aber offenbar nur für interne Test benötigt wird und auf dem Koha-System selber nicht vorhanden ist.
14:36 cait            it hasn't been pushed yet
14:36 cait            MichaelKuhn: ah i see why
14:36 MichaelKuhn     Hallo Katrin - da war ich schon, aber da befindet sich offenbar nur die bereits veröffentlichte Version... ich habe nun die Änderungen händisch eingepflegt (seit gestern einige Male hin und her...). Trotzdem danke!
14:32 cait1           https://git.koha-community.org/Koha-community/Koha/src/branch/master/Koha/Email.pm
14:31 cait1           but i'd double check the patch for changes made to other files
14:31 cait1           i am sure you can download it from there
14:31 cait1           https://git.koha-community.org
14:31 cait1           MichaelKuhn: yu can browse the repository via git
14:25 huginn          Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26705 major, P5 - low, ---, tomascohen, Passed QA , System preference NoticeBcc not working
14:25 MichaelKuhn     Hi - I'm looking for a way to download the most current (but unreleased) version of "Email.pm" with alle the changes made via bug 26705. Is it possible?
13:45 oleonard        I will do some tests later today. Gotta disappear for a while.
13:45 ashimema        were you going to have a go at that oleonard..?
13:40 ashimema        good call
13:38 oleonard        (that example uses markup, but I'm sure we can find something right)
13:37 oleonard        There are CSS alternatives, though, so we just need to find the right thing http://jsfiddle.net/kevinkirchner/DQruj/
13:37 ashimema        ack..
13:36 ashimema        just to make doubly sure
13:36 ashimema        but I'm going to ask for a second check with the screen reader they're using at catalyst
13:36 oleonard        So it's not really an option
13:36 oleonard        What I found in my google searches was that screen readers sometimes do read them
13:36 ashimema        I'm just adding my SO line now and adding the followup
13:36 ashimema        yup
13:36 oleonard        ashimema: using css content?
13:36 ashimema        the screen reader didn't pick them up
13:35 oleonard        The advantage of the CSS solution is that it works just by adding the <li> for the breadcrumb
13:35 ashimema        in a quick test here.. simply adding them via css did the trick
13:35 oleonard        In order to use "area-hidden" we'd have to add the separators as an html element
13:33 ashimema        indeed
13:33 caroline        is it henry?
13:33 caroline        maybe we can ask our accessibility advocate?
13:32 caroline        no :(
13:32 ashimema        got anyone that uses a screenreader caroline?
13:31 ashimema        the current page is now an anchor
13:31 caroline        so what is the final decision on the breadcrumbs?
13:31 ashimema        oh I see..
13:29 dersmon         hi!
13:23 ashimema        so it was
13:23 * ashimema      checks out master and check
13:21 cait1           yes?
13:21 ashimema        so, black but not bold
13:20 cait1           they were black i think
13:11 koha-jenkins    Project Koha_20.11_D11 build #91: SUCCESS in 39 min: https://jenkins.koha-community.org/job/Koha_20.11_D11/91/
13:06 ashimema        I think I expected bold but still blue
13:06 ashimema        bold and black
13:06 ashimema        oleonard.. was that the case before your patches too?
13:06 ashimema        it turns the text black too at the moment
13:06 ashimema        ooh..
13:04 ashimema        unless we mark it somehow not to be
13:04 ashimema        but I think if it's added as a character it still gets read out
13:04 ashimema        you can indeed add > with css
13:04 cait1           or that
13:03 ashimema        I think we can achieve the same with our > char, but adding in an 'aria-hidden' attribute on it.
13:03 cait1           if it's just amatter of it not being read out lout
13:03 cait1           couldn't you?
13:03 cait1           but you could use css to add a > too
13:03 ashimema        the idea being.. as it's a graphical element rather than a character it won't get anounced by a screen reader
13:03 cait1           hm
13:03 ashimema        it's a css border that's been tilted forward
13:02 ashimema        it's not an actual '/'
13:02 ashimema        but
13:02 ashimema        they changed it to '/' for accessability..
13:02 cait1           not sure if there are any general recommendations we shoudl follow, but that would be my opinion right now :)
13:01 cait1           i feel it's easier to read
13:01 ashimema        me too
13:01 cait1           we have also used that in documentation and i think in the manual.... and i like the visual
13:01 cait1           hm >
13:00 ashimema        thoughts on '/' vs '>' cait1 ?
13:00 cait1           it seems a double up
13:00 cait1           i would not bold it
13:00 oleonard        I didn't want to reverse the intention of the original patchset without talking about it first
13:00 cait1           i think as we have the heading on the page that is prominent
13:00 ashimema        but the question still stands.. should it be bold or not
13:00 ashimema        It was made bold by the patchset.. oleonard then broke that so he fixed it back
12:58 koha-jenkins    Project Koha_20.11_U18 build #56: SUCCESS in 1 hr 25 min: https://jenkins.koha-community.org/job/Koha_20.11_U18/56/
12:57 cait1           scroll first!
12:56 cait1           oh
12:56 cait1           i think i would like it non-bold :)
12:40 koha-jenkins    Project Koha_20.11_D9 build #78: SUCCESS in 1 hr 6 min: https://jenkins.koha-community.org/job/Koha_20.11_D9/78/
12:31 koha-jenkins    Project Koha_20.11_D11 build #90: SUCCESS in 27 min: https://jenkins.koha-community.org/job/Koha_20.11_D11/90/
12:27 koha-jenkins    Project Koha_20.11_D10 build #76: UNSTABLE in 54 min: https://jenkins.koha-community.org/job/Koha_20.11_D10/76/
12:24 koha-jenkins    Project Koha_20.11_U2010 build #55: SUCCESS in 51 min: https://jenkins.koha-community.org/job/Koha_20.11_U2010/55/
12:14 ashimema        back shortly.. then I will continue here
12:14 ashimema        right.. I'm going for a quick walk
12:14 ashimema        okies
12:14 koha-jenkins    Project Koha_20.11_U16 build #61: SUCCESS in 38 min: https://jenkins.koha-community.org/job/Koha_20.11_U16/61/
12:13 oleonard        I have corrected my CSS patch so that it doesn't undo the bold breadcrumb
12:09 ashimema        but yeah.. I reckon we can achieve the same by adding aria-hidden to them
12:09 oleonard        Is CSS content announced?
12:08 ashimema        idea being a border isn't anounced by a screen reader
12:08 ashimema        they're borders instead of characters
12:08 ashimema        it's part of the guideline that's linked
12:07 oleonard        The dividers
12:07 ashimema        the bold or the right pointing quote
12:07 * ashimema      wonders if we could add that back but use aria-hidden on it.
12:07 oleonard        I'm not sure if that change was accessibility-related or not
12:04 ashimema        I liked that display queue
12:04 ashimema        must admit.. I think it's a shame we loose the chevron
12:04 koha-jenkins    Project Koha_20.11_U20 build #60: SUCCESS in 31 min: https://jenkins.koha-community.org/job/Koha_20.11_U20/60/
12:04 ashimema        and I don't see the accessibility guideline saying it should be either
12:03 oleonard        It wasn't
12:03 ashimema        I don't think it was prior to this was it?
12:03 ashimema        but.. you're saying you don't think it should be boldended?
12:03 oleonard        Give me a moment to look into it
12:03 ashimema        lol
12:03 oleonard        Haha then I broke something
12:02 wahanui         rumour has it chrome is fine fox123
12:02 ashimema        chrome?
12:02 ashimema        it doesn't go bold for me
12:02 ashimema        oh really
12:02 oleonard        I don't like the bold (which I do see)
12:01 oleonard        Oh actually I was going to comment on that... That's the one thing I would change
12:01 ashimema        I don't see that.. did you?
12:01 ashimema        `and the last breadcrumb has bold text` in the test plan
12:01 wahanui         oleonard is probably happy for ashimema to write the release script
12:01 ashimema        oleonard
11:56 kidclamp        making me take responsibility for my code
11:56 kidclamp        oleonard++
11:54 ashimema        pleasure kidclamp :)
11:54 kidclamp        ashimema++
11:52 ashimema        that bug was already on my list
11:52 ashimema        nice one oleonard
11:37 oleonard        4 follow-ups still waiting for signoff.
11:36 huginn          Bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27846 enhancement, P5 - low, ---, wainuiwitikapark, Needs Signoff , Accessibility: Staff Client - Breadcrumbs should be more accessible
11:36 * oleonard      finished testing, signing off, and following-up Bug 27846 and boy are my arms tired
11:36 oleonard        Hi #koha
10:49 shaffendi       anyone here
10:49 shaffendi       hi hello
10:41 eythian         ashimema: not too bad, just generally bored :)
10:41 eythian         ashimema: I know the occasional thing about it :) and yeah, I see you added me to a bug about it, but it looks like it was resolved anyway.
10:40 ashimema        how are you anyways eythian
10:40 ashimema        lol.. I've totally forgotten what it was
10:40 ashimema        or maybe it was something else
10:40 ashimema        I think..
10:39 ashimema        I was going to ask if I was remembering rightly that your a bit of an email guru..
10:39 ashimema        no worries eythian
10:33 cm              hi
10:33 eythian         ashimema: sorry, wasn't around yesterday
10:04 MarkHofstetter1 yes
09:57 cait1           have you opened the record for editing?
09:57 cait1           it's probably another reason you don't see it
09:57 cait1           but you can change the guarantor :)
09:28 MarkHofstetter1 I mean there may be very good reasons not to be able to change that, but it may be not userfriendly
09:24 cait1           if you are offered the guarantor fields or not
09:23 cait1           but it depends on the categories and such
09:23 cait1           no it's possible
09:21 MarkHofstetter1 Good morning, is it/should it be possible to add a guarantor to an existing patron, or is this forbidden by design? thx
07:30 alex_a          Bonjour
07:27 wahanui         privet, reiveune
07:27 reiveune        hello
07:18 severine_q      good morning #koha :)
01:35 koha-jenkins    Project Koha_19.11_U18 build #306: FIXED in 40 min: https://jenkins.koha-community.org/job/Koha_19.11_U18/306/
01:35 wahanui         Congratulations!
01:35 koha-jenkins    Yippee, build fixed!
01:00 koha-jenkins    Project Koha_19.11_U16 build #61: SUCCESS in 55 min: https://jenkins.koha-community.org/job/Koha_19.11_U16/61/
00:51 koha-jenkins    Project Koha_19.11_D10 build #146: SUCCESS in 43 min: https://jenkins.koha-community.org/job/Koha_19.11_D10/146/
00:43 koha-jenkins    Project Koha_19.11_U18 build #305: ABORTED in 10 min: https://jenkins.koha-community.org/job/Koha_19.11_U18/305/
00:37 koha-jenkins    Project Koha_19.11_D8 build #377: SUCCESS in 32 min: https://jenkins.koha-community.org/job/Koha_19.11_D8/377/
00:35 koha-jenkins    Project Koha_19.11_D9 build #308: UNSTABLE in 29 min: https://jenkins.koha-community.org/job/Koha_19.11_D9/308/
00:29 koha-jenkins    Project Koha_19.11_U20 build #202: SUCCESS in 23 min: https://jenkins.koha-community.org/job/Koha_19.11_U20/202/
00:17 koha-jenkins    Project Koha_19.11_U18 build #304: ABORTED in 12 min: https://jenkins.koha-community.org/job/Koha_19.11_U18/304/
00:15 aleisha         okay thank you i'll use that
00:15 dcook           Whether it's before or after you alter it
00:14 dcook           I wish you luck. You can always use new ZOOM::Query::PQF->new() in an eval{} to see at what point the query is causing problems
00:13 dcook           Yeah, that'll take some digging
00:13 aleisha         haha also the search stuff is different between biblio and authorities! very hard to troubleshoot
00:12 dcook           Ah, good ol' mangling hehe
00:12 aleisha         the query comes through as normal, im just amending it once it gets in
00:12 dcook           Koha's code is terrible when it comes to working with the ZOOM libraries too btw
00:12 aleisha         not creating my own!
00:11 dcook           Are you getting your Zconn from C4::Context or creating your own?
00:11 aleisha         yes it is
00:10 dcook           This is custom code now, right?
00:10 dcook           You're very welcome. Always good to review Zebra queries.
00:10 aleisha         thank you for your help!!
00:10 dcook           Alas, I should switch to other things, but I'd say your query is OK. It'll be the Perl coding that you need to perfect.
00:09 dcook           Looks like a fairly generic error
00:09 dcook           https://metacpan.org/release/Net-Z3950-ZOOM/source/lib/ZOOM.pm heh
00:08 aleisha         wish there was more documentation on the errors!
00:07 dcook           I had a feeling you were going to say that heh
00:06 aleisha         hmm that gets the same error
00:05 dcook           yep
00:04 wahanui         i already had it that way, huginn.
00:04 huginn          aleisha: I'll give you the answer as soon as RDA is ready
00:04 aleisha         @attr 14=1 @and  @attr 1=Heading-Main  @attr 5=1 @attr 4=6 "fish" @or @attr 1=Subject-heading-thesaurus @attr 3=2 @attr 4=1 @attr 5=1 @attr 6=3 "scisshl" @attr 1=Subject-heading-thesaurus @attr 3=2 @attr 4=1 @attr 5=1 @attr 6=3  "scot" like this?
00:04 dcook           That will ignore uninitialized indexes
00:04 aleisha         heh
00:04 dcook           Oh I said that.
00:04 dcook           Or rather... @attr 14=1 I guess
00:03 dcook           Add @attr 14=1 to the very start
00:03 dcook           Let's see..
00:02 aleisha         hmm interesting
00:02 dcook           Let me see if there's a little workaround..
00:02 dcook           I think that usually happens when there's nothing in an index? Admittedly I haven't seen that one myself. Just Googling..
00:00 aleisha         the error is ZOOM error 20003 "can't set prefix query"
00:00 aleisha         oh okay !