Bug 9145

Summary: Authorities: standard language for UNIMARC
Product: Koha Reporter: Vitor Fernandes <vfernandes>
Component: MARC Authority data supportAssignee: Vitor Fernandes <vfernandes>
Status: CLOSED FIXED QA Contact: Katrin Fischer <katrin.fischer>
Severity: major    
Priority: P1 - high CC: chris, jcamins, jonathan.druart, katrin.fischer, mathsabypro, paul.poulain
Version: Main   
Hardware: All   
OS: All   
See Also: http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9269
Change sponsored?: Sponsored Patch complexity: Small patch
Documentation contact: Documentation submission:
Text to go in the release notes:
Version(s) released in:
Attachments: BUG 9145: Authorities: standard language for UNIMARC
BUG 9145 - Authorities: standard language for UNIMARC
BUG 9145 - Authorities: standard language for UNIMARC
BUG 9145: Authorities: standard language for UNIMARC
[PASSED QA] BUG 9145: Authorities: standard language for UNIMARC

Description Vitor Fernandes 2012-11-26 11:58:28 UTC
Currently the standard language for UNIMARC in authorities creation is french.
The field 100 is filled by default with this code: "afrey50      ba0"
This should be a system preferences.
Comment 1 Vitor Fernandes 2012-11-26 12:30:54 UTC Comment hidden (obsolete)
Comment 2 Jonathan Druart 2012-12-04 15:50:06 UTC
Hi Vitor,

The authorities.pref becomes bad-formatted after your patch (tabulations characters).

and in C4/AuthoritiesMarc.pm:
- The patch introduces a forbidden pattern: tabulation character (709)
- The patch introduces a forbidden pattern: withespace character  (709)
Comment 3 Vitor Fernandes 2012-12-04 16:03:39 UTC Comment hidden (obsolete)
Comment 4 Vitor Fernandes 2012-12-04 16:06:07 UTC
Hi Jonathan Druart,

The format problem maybe happen from copying from my pref test to the authorities.pref.
Can you test now?

I've modified the authorithies.pref.
Comment 5 Mathieu Saby 2012-12-04 23:02:15 UTC
Hi
In biblio records, field 100 is filled by a "plugin".
Is it possible to make plugins for authorities ? It could be usefull for other coded fields in authorities frameworks (ex : 106, 120, 123...)


Regards,
M. Saby
Rennes 2 University
Comment 6 Vitor Fernandes 2012-12-05 09:59:58 UTC
Hi Mathieu,

This problem is different than the non existence of plugin to UNIMARC authorities.
This problem happens when creating/editing UNIMARC authorities where the cataloguing language is always set to 'fre'.
The submitted patch correct this problem by adding a system preference.

To UNIMARC Authority field 100 plugin there is another bug open (BUG 8334).
Comment 7 Jonathan Druart 2012-12-05 10:09:29 UTC
(In reply to comment #4)
> Hi Jonathan Druart,
>
> The format problem maybe happen from copying from my pref test to the
> authorities.pref.
> Can you test now?
>
> I've modified the authorithies.pref.

Yes, it fixes the previous issue.

However I don't understand how to have a record without 100$a before entering in the AddAuthority routine.
In C4/AuthoritiesMarc ~l.710
We always enter in the following statement:
    if (my $string=$record->subfield('100',"a"))
and never in the elsif ($record->field('100')) or else statement.

Could you provide a test plan to test your patch please ?
Comment 8 Vitor Fernandes 2012-12-05 10:21:47 UTC
Hi Jonathan,

When you put a correct 100$a there isn't any problem with the language, because it will use the language inserted in the subfield.

The problem happens when you insert or import a record without a field 100. The default language will be the 'fre' language.

The patch tries to correct that.
Comment 9 Jonathan Druart 2012-12-05 10:31:58 UTC
Yes, it is what I understood :)
When I add a new authority without 100$a and I edit it, I see the value '20121205     50                    '
and not what I put in the syspref.
Comment 10 Vitor Fernandes 2012-12-05 10:56:53 UTC Comment hidden (obsolete)
Comment 11 Vitor Fernandes 2012-12-05 10:59:00 UTC
Hi Jonathan,

The problem is that in authorities.pl the field 100 was filled with '20121205     50 ' if there wasn't a field 100.
That code should be removed because the field 100 verification should be in the AuthoritiesMarc.pm.
Comment 12 Jonathan Druart 2012-12-05 11:27:15 UTC Comment hidden (obsolete)
Comment 13 Jonathan Druart 2012-12-05 11:34:58 UTC
Squashed and signed-off patch.

Another SO would be great.
Comment 14 Paul Poulain 2012-12-12 08:03:13 UTC
QA comment: in bibliographic frameworks, each subfield can have a default value (and date is automatically replaced if you usea YYYYMMDD pattern)
I had preferred that you introduced this feature for authorities instead of doing this patch only for the 100$a field. The improvement would have been much larger.

Would you be willing to rewrite your patch ?

(not changing the status, adding RM to this bug, so he can confirm he agrees with me or no)
Comment 15 Vitor Fernandes 2012-12-12 10:03:13 UTC
Hi Paul,

I understand what you are saying.
Default values for authorities frameworks will be a nice improvement.
Besides that even with default values this patch is needed.
The field 100 in UNIMARC authorities always needed to be filled (using or not the interface). If the field isn't filled in the interface it will be automatically filled with the 'afrey50      ba0', which is a problem. This patch avoid that. With the patch 3 things happens:

- If the 100$a is filled nothing is done, so using default values or filling with plugins or by hand is not a problem
- If there is a 100 field but not a $a subfield, a 100$a is created with the date and the system preference created
- If there isn't a 100 field, a 100 field and a 100$a subfield are created with the date and the system preference created.

Even with default values the patch is needed, because 100$a needs to exist in UNIMARC even when is not filled in the interface.
There is another system preference that does something like this: MARCAuthorityControlField008
Comment 16 Jared Camins-Esakov 2012-12-12 12:15:09 UTC
Paul,

(In reply to comment #14)
> QA comment: in bibliographic frameworks, each subfield can have a default
> value (and date is automatically replaced if you usea YYYYMMDD pattern)
> I had preferred that you introduced this feature for authorities instead of
> doing this patch only for the 100$a field. The improvement would have been
> much larger.
> 
> Would you be willing to rewrite your patch ?
> 
> (not changing the status, adding RM to this bug, so he can confirm he agrees
> with me or no)

This patch would be required anyway, I think, because right now the UNIMARC 100 field is forcefully populated to the hard-coded frey50:
jcamins@kohadev:~/kohaclone$ grep frey C4/*
C4/AuthoritiesMarc.pm:          $string=~s/fre50/frey50/;
C4/AuthoritiesMarc.pm:          $record->field('100')->update('a'=>$date."afrey50      ba0");
C4/AuthoritiesMarc.pm:            ,'a'=>$date."afrey50      ba0")
C4/Biblio.pm:        substr( $string, 22, 6, "frey50" );
C4/Charset.pm:        substr( $string, $encodingposition, 8, "frey50  " );
Comment 17 Vitor Fernandes 2012-12-12 12:24:30 UTC
Hi Jared,

This patch is only for AuthoritiesMarc.pm.
There is another patch for BUG 8347, that changes Charset.pm and Biblio.pm.
Comment 18 Paul Poulain 2012-12-17 16:48:38 UTC
OK, I agree with you arguments and change my mind. Will QA this patch later. If someone else want to QA, feel free.
Comment 19 Katrin Fischer 2013-02-17 21:36:12 UTC
Created attachment 15482 [details] [review]
[PASSED QA] BUG 9145: Authorities: standard language for UNIMARC

New Authority system preference created UNIMARCAuthorityField100 with default value "afrey50      ba0".
AuthoritiesMarc.pm uses the system preference instead of label "afrey50      ba0".

Signed-off-by: Jonathan Druart <jonathan.druart@biblibre.com>
Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Works as described, all tests and QA script pass.

1) Check system preference is created correctly.
2) Change pref.
3) Catalog a new authority.
4) Change framework to make 100 show in frameworks or check in the
   the database, that now 100 has the new defined value.
Comment 20 Jared Camins-Esakov 2013-02-20 13:42:42 UTC
This patch has been pushed to master.
Comment 21 Chris Cormack 2013-02-21 05:46:05 UTC
Pushed to 3.10.x will be in 3.10.3