Bug 21705

Created attachment 128186 [details] [review]
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:
1) Apply patch
2) Delete existing frameworks
   -  In the database
      delete from marc_tag_structure;
      delete from marc_subfield_structure;
      delete from biblio_framework;
3) Load default framework
   - In a terminal, run
     ./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4) In the staff interface, go to Administration > MARC bibliographic framework
   - Make sure the default framework is there
5) In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
   - biblioitems.publishercode should be mapped to 260 as well as 264
6) Create a bibliographic record with a value in 264
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate
7) Create a bibliographic record with a value un 260
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate

I hope I didn't forget anything! :)

Caroline

Hi Caroline.

I'm not seeing copyrightdate in steps 6 and 7.

The database query I used was (where XXX = the newly created record number): select * from biblioitems where biblionumber = XXX;

Both mappings for biblio.copyrightdate appear in  Koha to MARC mappings.

Note: For step 5 I'm assuming biblioitems.publishercode should be biblio.copyrightdate.

David

I changed the assignee to Caroline.

Hi David, 

I think you were misled by my test plan. I copy-pasted from another one and forgot to change everything I should have... I'm rewriting the test plan and hopefully I won't make any more mistakes...

Caroline

Created attachment 141394 [details] [review]
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:

1. Apply patch
2. Delete existing frameworks
2.1. In the database, run the following commands
delete from marc_tag_structure;
delete from marc_subfield_structure;
delete from biblio_framework;
3. Load default framework
3.1. In a terminal, run
./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4. In the staff interface, go to Administration > MARC bibliographic framework
--> The default framework should be there
5. Make 264c appear in the editor
5.1. In Administration > MARC bibliographic framework, click on Actions > MARC structure next to the default framework
5.2. Search for 264
5.3. Click on Actions > Edit subfields
5.4. Click on tab c
5.5. Check the 'Editor' box 
5.6. Click 'Save changes'
6. In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
6.1. Go to Administration > Koha to MARC mapping
6.2. Search for copyrightdate
--> biblio.copyrightdate should be mapped to 260c as well as 264c
7. Create a bibliographic record with a value in 264c
7.1. Go to Cataloging
7.2. Click 'New record'
7.3. Fill in mandatory fields (000, 003, 005, 008, 040c, 245a, 942c)
7.4. Enter a date in 264c
7.5. Click 'Save'
7.6. Note the record number (no need to add an item)
8. Create a bibliographic record with a value in 260c
8.1. Go to Cataloging
8.2. Click 'New record'
8.3. Fill in mandatory fields (000, 003, 005, 008, 040c, 245a, 942c)
8.4. Enter a date in 260c
8.5. Click 'Save'
8.6. Note the record number (no need to add an item)
9. Check the database biblio entry for both records, they should both have a value for copyrightdate
9.1. In the database, enter the following query, replacing AA with your biblionumber from step 7.6 and BB with the biblionumber from 8.6
select biblionumber, copyrightdate from biblio where biblionumber in (AA, BB)
--> Both biblios should have a date in copyrightdate

I hope I didn't forget anything! :)

Caroline

Created attachment 141400 [details] [review]
Bug 21705: Map copryrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:
1) Apply patch
2) Delete existing frameworks
   -  In the database
      delete from marc_tag_structure;
      delete from marc_subfield_structure;
      delete from biblio_framework;
3) Load default framework
   - In a terminal, run
     ./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4) In the staff interface, go to Administration > MARC bibliographic framework
   - Make sure the default framework is there
5) In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
   - biblioitems.publishercode should be mapped to 260 as well as 264
6) Create a bibliographic record with a value in 264
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate
7) Create a bibliographic record with a value un 260
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate

I hope I didn't forget anything! :)

Caroline

Signed-off-by: David Nind <david@davidnind.com>

Created attachment 141402 [details]
Screenshots - Display of 260c (has a label) and 264c (has no label)

(In reply to Caroline Cyr La Rose from comment #4)
> Hi David, 
> 
> I think you were misled by my test plan. I copy-pasted from another one and
> forgot to change everything I should have... I'm rewriting the test plan and
> hopefully I won't make any more mistakes...
> 
> Caroline

Thanks Caroline for the comprehensive updated test plan! It made it very easy to test.

I've signed off, but did note that:

1. For step 7 with the 264c, the date I entered shows in the normal display (and the OPAC) as a date on its own line - without any label.

2. For step 8 with the 260c, the date I entered shows in the normal display after the label "Publication details".

See the attached screenshots. 

Also, I'm not sure why, but the commit message changed back to the original one when I signed it off (comment #6).

David

(In reply to David Nind from comment #7)
> 
> Thanks Caroline for the comprehensive updated test plan! It made it very
> easy to test.
> 
> I've signed off, but did note that:
> 
> 1. For step 7 with the 264c, the date I entered shows in the normal display
> (and the OPAC) as a date on its own line - without any label.
> 
> 2. For step 8 with the 260c, the date I entered shows in the normal display
> after the label "Publication details".
> 
> See the attached screenshots. 
> 

Yes, that is normal, it has to do with indicators. Since 264 can be used for more than publication (it can be used for production information, manufacture information, etc.) it needs to know what you are cataloguing in there exactly. If you want 'Publication', you need to write 1 in the second indicator https://www.loc.gov/marc/bibliographic/bd264.html


> Also, I'm not sure why, but the commit message changed back to the original
> one when I signed it off (comment #6).

Not sure either... I was sure I'd obsoleted the older patch... Maybe someone more used to bugzilla will be able to enlighten us

(In reply to Caroline Cyr La Rose from comment #8)

> Yes, that is normal, it has to do with indicators. Since 264 can be used for
> more than publication (it can be used for production information,
> manufacture information, etc.) it needs to know what you are cataloguing in
> there exactly. If you want 'Publication', you need to write 1 in the second
> indicator https://www.loc.gov/marc/bibliographic/bd264.html

Thanks Caroline! There is always something to learn with MARC21 and cataloguing...

Created attachment 141475 [details] [review]
Bug 21705: Map copyrightdate to both 260/264c by default for new MARC21 installations

This patch adds a mapping from 264 to biblio.copyrightdate.

To test:
1) Apply patch
2) Delete existing frameworks
   -  In the database
      delete from marc_tag_structure;
      delete from marc_subfield_structure;
      delete from biblio_framework;
3) Load default framework
   - In a terminal, run
     ./misc/load_yaml.pl -f installer/data/mysql/en/marcflavour/marc21/mandatory/marc21_framework_DEFAULT.yml --load
4) In the staff interface, go to Administration > MARC bibliographic framework
   - Make sure the default framework is there
5) In Administration > Koha to MARC mapping, check the mappings for biblio.copyrightdate
   - biblioitems.publishercode should be mapped to 260 as well as 264
6) Create a bibliographic record with a value in 264
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate
7) Create a bibliographic record with a value un 260
   - In the database, check the biblio entry for this record, the value from 264 should be in copyrightdate

I hope I didn't forget anything! :)

Caroline

Signed-off-by: David Nind <david@davidnind.com>

Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>

Please inform users of existing installations more explicitly via release notes about adding 264 too.

Hi Marcel,
I added release notes specifying it is only for new installations and where to add it for current installations.
Do you want me to also add a dbrev like in bug 30850?
Thanks!
Caroline

(In reply to Caroline Cyr La Rose from comment #12)
> Hi Marcel,
> I added release notes specifying it is only for new installations and where
> to add it for current installations.
> Do you want me to also add a dbrev like in bug 30850?
> Thanks!
> Caroline

Let's see if our RM should insist..

Historically we haven't changed mappings on update and it's not enough anyway, as you would create an inconsistent state of the data: the mappings only work for the new records. So this could lead more to confusion than being actually helpful. If people want this, they also need to run the script to update existing data or be aware of the change. (

(In reply to Katrin Fischer from comment #14)
> Historically we haven't changed mappings on update and it's not enough
> anyway, as you would create an inconsistent state of the data: the mappings
> only work for the new records. So this could lead more to confusion than
> being actually helpful. If people want this, they also need to run the
> script to update existing data or be aware of the change. (

True, but please read the context.

(In reply to Marcel de Rooy from comment #15)
> (In reply to Katrin Fischer from comment #14)
> > Historically we haven't changed mappings on update and it's not enough
> > anyway, as you would create an inconsistent state of the data: the mappings
> > only work for the new records. So this could lead more to confusion than
> > being actually helpful. If people want this, they also need to run the
> > script to update existing data or be aware of the change. (
> 
> True, but please read the context.

Ah, sorry... can we blame Monday morning?

Pushed to master for 22.11.

Nice work everyone, thanks!