| Summary: | Interface to define relational rules for MARC fields that use authorised values | ||
|---|---|---|---|
| Product: | Koha | Reporter: | Aleisha Amohia <aleisha> |
| Component: | Cataloging | Assignee: | Julian Maurice <julian.maurice> |
| Status: | ASSIGNED --- | QA Contact: | Testopia <testopia> |
| Severity: | new feature | ||
| Priority: | P5 - low | CC: | angela.berrett, julian.maurice, m.de.rooy, martin.renvoize, pedro.amorim, phil |
| Version: | Main | ||
| Hardware: | All | ||
| OS: | All | ||
| 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
Bug 34198: [DO NOT PUSH] Update DBIC schema Bug 34198: Add parent-child relationship to authorised values Bug 34198: [DO NOT PUSH] Update DBIC schema Bug 34198: Use Koha::I18N as workaround to a bug in template translator |
||
|
Description
Aleisha Amohia
2023-07-04 22:56:54 UTC
Created attachment 189006 [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 Created attachment 189007 [details] [review] Bug 34198: [DO NOT PUSH] Update DBIC schema Patch from commit 09874bd 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 Created attachment 189069 [details] [review] Bug 34198: [DO NOT PUSH] Update DBIC schema Patch from commit 0d0e207 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. 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. |