Bug 10892 - Make facets customisable - step 1 : store facet config in YAML block
Summary: Make facets customisable - step 1 : store facet config in YAML block
Status: CLOSED INVALID
Alias: None
Product: Koha
Classification: Unclassified
Component: Searching (show other bugs)
Version: master
Hardware: All All
: P3 enhancement (vote)
Assignee: Mathieu Saby
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-09-16 09:35 UTC by Mathieu Saby
Modified: 2014-12-07 20:02 UTC (History)
2 users (show)

See Also:
Change sponsored?: ---
Patch complexity: Trivial patch
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
[PATCH] Bug 10892 : Make facets customizable - step 1 store configuration in YAML block (12.24 KB, patch)
2013-09-17 16:05 UTC, Mathieu Saby
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Mathieu Saby 2013-09-16 09:35:08 UTC
This is the first step of the plan defined in Bug 10891 : storing facets configuration in YAML block.
Next step : allowing librarians to edit this YAML bloc, either directly in a syspref, or in a specific page (still to be discussed).
Comment 1 Mathieu Saby 2013-09-17 16:05:03 UTC
Created attachment 21141 [details] [review]
[PATCH] Bug 10892 : Make facets customizable - step 1 store configuration in YAML block


This is the first of a group of patches whose goal is to make facets configurable.
This patch stores facet configuration in a YAML block, within Koha.pm file.
Next steps will be to use an external YAML file.

No functional changes are expected, except for UNIMARC :
I took the occasion for fixing location facets, which were broken (wrongly build on 995$c instead of 995$e).

To test :
1. make some searches, use facets
2. apply
3. make the same searches, use facets the same way. No differences should be visible
4. in a UNIMARC Koha, check location facets are visible after applying the patch
Comment 2 Mathieu Saby 2013-09-17 16:07:41 UTC
Note : I have also made a separated bug for fixing UNIMARC location facets (http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10893)
This is because I am not sure my way for storing facets in YAML will be accepted, and maybe it will be only applied to  version 3.14 of Koha and not to previous ones.

So, the bug 10893 need to be signed off to.

M. Saby
Comment 3 Mathieu Saby 2013-09-21 08:18:12 UTC
In fact, creating a new sql table for facets is maybe a more logical solution than using YAML.

M. Saby
Comment 4 Frédéric Demians 2013-09-21 09:44:04 UTC
Translation alert:

Facet labels are found in three locations:

  1. facet definition
  2. OPAC template opac-tmpl/prog/en/includes/opac-facets.inc
  3. Intra template intranet-tmpl/prog/en/includes/facets.inc

2&3 are here to make facet labels translatable.

In brief, adding a new facet implies now the following steps:

  - Edit facet data structure in Koha.pm
  - Add a new Zebra index if it not already exists
  - Edit both facet label definition templates
Comment 5 Mathieu Saby 2013-09-21 10:52:51 UTC
Yes, I know that. That's why I want to add some "standard" facet, based on existing zebra conf, which could be activated or not. It implies changing the 2 templates and the definition currently stored in Koha.pm.

Once the configuration will be in YAML separate file, as libraries would be able to edit the YAML file (to change facet orders or fields used to build them), I suppose writing a patch for adding new facets could not be done cleanly just by git.
I think we will need to run a little script that will read the existing YAML into perl data structure (array of hashes or hash of hashes), add new facet in this structure, and dump it into YAML file again.
(The equivalent of operations made by updatedatabase for sql database)

For "local use" facets defined by the library itself :
- templates files won't know the name of these new facets
- it won't work if it does not match zebra record.abs (we will need a warning for avoiding librarians to do mistakes)

But this can be circumvented if YAML data for local use facets are not structured like the standard ones.
For ex, something like : 

customfacet1:
   type: 'customfacet'
   idx: 'customindex'
   labels:
      en: 'Custom facet 1'
      fr-FR: 'Facette spéciale 1'
   tags:
      -210$b
   sep: ' - '
   order:5

and code like that:
- in facet configuration page :
if (type = customfacet) {
   get all the list of the languages available in OPAC and Staff interface
   ask the librarian to define a label for each of these languages (for ex, "en" and "fr-FR")
   store it in labels->{en} and labels->{fr-FR}
}

- in template displaying facets in OPAC and Staff interface
if (type = customfacet) {
  display labels->{current_language} 
}

Do you think it will work?

Mathieu
Comment 6 I'm just a bot 2013-09-24 05:39:45 UTC
Patch applied cleanly, go forth and signoff
Comment 7 Mathieu Saby 2013-09-29 21:10:31 UTC
No need to consider this bug. I will use JSON for storing configuration of facets.

M. Saby