Bug 34198 - Interface to define relational rules for MARC fields that use authorised values
Summary: Interface to define relational rules for MARC fields that use authorised values
Status: ASSIGNED
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: Main
Hardware: All All
: P5 - low new feature
Assignee: Julian Maurice
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-07-04 22:56 UTC by Aleisha Amohia
Modified: 2025-11-07 18:45 UTC (History)
6 users (show)

See Also:
GIT URL:
Initiative type: ---
Sponsorship status: ---
Comma delimited list of Sponsors:
Crowdfunding goal: 0
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:
Circulation function:


Attachments
Bug 34198: Add parent-child relationship to authorised values (48.97 KB, patch)
2025-11-04 09:24 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 34198: [DO NOT PUSH] Update DBIC schema (4.90 KB, patch)
2025-11-04 09:24 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 34198: Add parent-child relationship to authorised values (48.96 KB, patch)
2025-11-05 08:20 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 34198: [DO NOT PUSH] Update DBIC schema (4.90 KB, patch)
2025-11-05 08:20 UTC, Julian Maurice
Details | Diff | Splinter Review
Bug 34198: Use Koha::I18N as workaround to a bug in template translator (3.01 KB, patch)
2025-11-06 15:25 UTC, Julian Maurice
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Aleisha Amohia 2023-07-04 22:56:54 UTC
We have a case where a set of MARC tags use authorised values i.e. 902$a, 902$b, 902$c, 902$d. Each of these subfields will use different authorised values.

We'd like the authorised values displayed for 902$b to change depending on how 902$a is set. For example, if 902$a is set to a specific value, then the irrelevant options for 902$b should be hidden so they can't be selected. This might go on i.e. the values for 902$c are then dependent on the setting of 902$b.

These rules would need to be editable by the library.
Comment 1 Julian Maurice 2025-11-04 09:24:30 UTC Comment hidden (obsolete)
Comment 2 Julian Maurice 2025-11-04 09:24:31 UTC Comment hidden (obsolete)
Comment 3 Julian Maurice 2025-11-05 08:20:32 UTC
Created attachment 189068 [details] [review]
Bug 34198: Add parent-child relationship to authorised values

The goal is to have some kind of hierarchy between different authorised
value categories so that, when cataloging, selecting an authorised value
in a parent authorised value category allow only a subset of values for
child authorised value categories.

This patch allows authorised value categories to have a parent category.
When an authorised value category have a parent, its authorised values
can have a parent authorised value in the parent category.

An authorised value that have a parent can only be selected if:
- its parent authorised value have been selected, or
- no authorised value have been selected in the parent category

An authorised value that have no parent can always be selected.

This only works within the context of a MARC field. Selecting a value
for a subfield will only alter subfields of the same field.

A child category can also be a parent category. There is no limit to the
depth of this hierarchy.

Test plan:
1. Create an authorised value category TYPE with the following values:
   - Type 1
   - Type 2
   - Type 3
2. Create an authorised value category SUBTYPE (parent: TYPE) with the
   following values:
   - Subtype 1.1 (parent: Type 1)
   - Subtype 1.2 (parent: Type 1)
   - Subtype 2.1 (parent: Type 2)
   - Subtype 2.2 (parent: Type 2)
   - Subtype X.1 (no parent)
   - Subtype X.2 (no parent)
3. Create an authorised value category SUBSUBTYPE (parent: SUBTYPE) with
   the following values:
   - Subsubtype 1.1.1 (parent Subtype 1.1)
   - Subsubtype 2.2.1 (parent Subtype 2.2)
   - Subsubtype Y (no parent)
4. In the default MARC framework, create a 900 field. Within this field,
   - create a subfield 'a' linked to AV category TYPE,
   - create a subfield 'b' linked to AV category SUBTYPE,
   - create a subfield 'c' linked to AV category SUBSUBTYPE.
5. In the default MARC framework, in the item MARC field (952 or 995),
   edit or create 3 subfields to link them to these AV categories.
   Do the same for ACQ framework.
6. Do the same thing again for an authority type
7. Edit or create a bibliographic record. Go to field 900 and select a
   value for $a then open $b dropdown list to verify that values are
   disabled correctly. For instance, if $a = 'Type 1', 'Subtype 2.1' and
   'Subtype 2.2' should be disabled.
   Select a value for $b and open $c dropdown list to verify that values
   are disabled correctly.
   Clone a field and verify that this works in the cloned field too.
8. Repeat step 7 for the item editor
9. Repeat step 7 for the item editor in acquisitions
10. Repeat step 7 for the authority editor
Comment 4 Julian Maurice 2025-11-05 08:20:33 UTC
Created attachment 189069 [details] [review]
Bug 34198: [DO NOT PUSH] Update DBIC schema

Patch from commit 0d0e207
Comment 5 Martin Renvoize (ashimema) 2025-11-05 08:43:32 UTC
This looks interesting, noting for later. We should add support for this in the Vue framework components so it can be easily applied there generically too.
Comment 6 Julian Maurice 2025-11-06 15:25:10 UTC
Created attachment 189182 [details] [review]
Bug 34198: Use Koha::I18N as workaround to a bug in template translator

When the template translator find a string to replace in an attribute
(in this case, title) it rewrites the whole tag. And when the tag
contain TT syntax, the result is really bad, for instance:

    <option $raw="$raw" %]="%]" [%="[%" attributes="attributes"
    disabled="disabled" title="Les pertes [...]"
    value="[%- aval | html -%]" |="|"
    >[%- mv.labels.$aval | html -%]</option>

By having the attribute value translated by Koha::I18N we avoid that
problem.