Bug 16744 - new records not indexed if using a customize Koha Framework
Summary: new records not indexed if using a customize Koha Framework
Status: RESOLVED DUPLICATE of bug 16431
Alias: None
Product: Koha
Classification: Unclassified
Component: Cataloging (show other bugs)
Version: 3.22
Hardware: All All
: P5 - low critical
Assignee: Galen Charlton
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-06-15 14:03 UTC by Hugo Agud
Modified: 2016-08-31 12:55 UTC (History)
4 users (show)

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

Attachments
Customize Koha Framework (181.20 KB, application/vnd.oasis.opendocument.spreadsheet)
2016-06-15 14:03 UTC, Hugo Agud 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Hugo Agud 2016-06-15 14:03:43 UTC 
Created attachment 52426 [details]
Customize Koha Framework

We have identified a possible bug when adding new records using a customize koha framework.

If we add a new record with the customize framework, it is not indexed in Koha and not published in the OPAC, if we edit the same record and change the framework to default, the record is indexed and published.

From logs we only see this:
tail -f indexer-output.log
error retrieving biblio 22947 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 705.

We have tested in debian 8 with plack for koha 3.22.5 and 3.22.7, not tested in koha 16.05

Reproduce:
1. Add the OPDF framework to koha
2. Restart plack and restart memcached to make sure everything is clear and ready for work.
3. Add a new record (it can duplicate and existing, new record or import via z39.50 it doesn't matter at all)
4. Save it, it has no effect to add or not add items to biblio.
5. Try to search into koha.
6. check logs tail -f indexer-output.log

Regarding the koha framework: there is no tag deleted just tab '-1' for those fields that we do not wish to check.
Comment 1 Katrin Fischer 2016-06-15 22:47:40 UTC 
Hm, could it have to do with 999 in some way (biblionumber and biblioitemnumber)? If you manually export the record as MARCXML - are those fields set correctly?
Comment 2 Hugo Agud 2016-06-17 09:49:03 UTC 
I do not think so, I have exported the blob from biblioitems and 999c and c seems to be ok
Comment 3 Hugo Agud 2016-07-13 06:10:46 UTC 
Good morning

Further investigation shows thats behaivour is produced only when we apply'USE_INDEXER_DAEMON="yes"' 

No problem adding new records using the old rebuild procedure of /etc/cron.d/koha-common
Comment 4 Tomás Cohen Arazi (tcohen) 2016-07-13 19:14:51 UTC 
Adding Jonathan, as this looks like a caching problem with the frameworks, as the indexer daemon is a long-living process.
Comment 5 Tomás Cohen Arazi (tcohen) 2016-07-13 23:03:48 UTC 
(In reply to Hugo Agud from comment #3)
> Good morning
> 
> Further investigation shows thats behaivour is produced only when we
> apply'USE_INDEXER_DAEMON="yes"' 
> 
> No problem adding new records using the old rebuild procedure of
> /etc/cron.d/koha-common

Both use the same script (rebuild_zebra.pl) it is just that INDEXER_DAEMON=yes makes it run in daemonized way. That's hwy I think it might be related to caching.
Comment 6 Jonathan Druart 2016-07-15 13:15:19 UTC 
Could you test on 16.05 and master please?
This may be fixed by bug 16431.
Comment 7 Jonathan Druart 2016-08-19 09:01:32 UTC 
(In reply to Jonathan Druart from comment #6)
> Could you test on 16.05 and master please?
> This may be fixed by bug 16431.

ping?
Comment 8 Hugo Agud 2016-08-31 10:24:14 UTC 
on a koha 16.05.03 fresh install on debian jessy and plack enabled we have applied the test procedure and the bug is fixed with bug  https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16431
Comment 9 Jonathan Druart 2016-08-31 12:55:49 UTC 

*** This bug has been marked as a duplicate of bug 16431 ***