http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11232
wajasu <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #31 from wajasu <[email protected]> --- Idea: To determine which indexes get the additional index:0, we could: provide a UI(similiar to msaby's suggestion that allows us to select an index by grabbing the <target_index> nodes from biblios-koha-indexdefs.xml, and search replacing <target_index>index:p</target_index> with <target_index>index:p</target_index><target_index>index:0</target_index> (control_field, data_field, sub_field savy UI is possible) That would at least let the selection be flexible according to the current configuration, though that file must be located for "koha packages"(TBD). We could roll out with things initially matching today's facets, and let them select predefined profiles at some point(future feature). The facet selection UI should highlight configured(non-disabled) facets that are may not exist anymore in the biblios-koha-indexdefs.xml, to aid debugging when that file is subsequently modified (admin or future koha update). When querying the chosen facets, it might be worth querying the whole list at once and if it fails, querying each sequentially such that if one fails, we just don't supply that label to the UI and log the failing facet, refering them to the facet config UI to reconcile. But things continue to run. It might be worth looking into generating retreival-info-bib-grs1-faceted.xml and biblios-koha-indexdefs-faceted.xml and launching xsltproc to generate biblio-zebra-indexdefs-faceted.xsl, without touching the original configs. Facets could be disabled to enable non-faceted searching until the issue is resolved. We might also employ xi:include and fallback in koha-conf.xml to use the faceted file(s) which could be generated/removed by the facet config UI. <xi:include href="/home/koha/koha-dev/etc/zebradb/retrieval-info-bib-dom.xml" xmlns:xi="http://www.w3.org/2001/XInclude";> <xi:fallback> Thus leaving koha-conf.xml flexible. Mapping tags to new indexes that go in biblios-koha-indexdefs.xml can possibly be a separate effort. Of course this is all very zebra focused. But the idea is to restrict free form editing (for security) and allow newly introduced indexes to roll out without concern of breaking updates. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list [email protected] http://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/
