Created attachment 4999 [details] screenshot To test: - add a new personal name or other authority - search for your authority - Bug: detail page will show it as 'Default' - edit screen shows authority type correctly I suspect a template problem but wasn't able to spot it.
If this is a template error then it's not one I can see either. I'm reclassifying this as an Authorities bug.
Created attachment 10265 [details] [review] Bug 6720: Display the authority type in OPAC Due to a peculiarity in the way SearchAuthorities worked, the authority search results on the OPAC always listed the authority type that the user searched for, rather than the authority type of the results.
Created attachment 10294 [details] [review] [SIGNED-OFF] Bug 6720: Display the authority type in OPAC Due to a peculiarity in the way SearchAuthorities worked, the authority search results on the OPAC always listed the authority type that the user searched for, rather than the authority type of the results. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Works nicely, result list for OPAC search now shows the authority type for each record.
Small note: Bug should remain open after pushing this patch. The problem also still exists on the authority detail page in staff.
Created attachment 10295 [details] [review] Bug 6720: show authority type in auth details
Created attachment 10297 [details] [review] [SIGNED-OFF] Bug 6720: show authority type in auth details Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Authority type on detail page in staff now shows correctly.
Thx Jared for providing an additional patch for the staff side problem!
Patch 1: adds new template param to get the Auth Type properly, then displays it in the template. Passed QA. Patch 2: replaces an empty string with the actual Auth Type. Marking Passed QA.
The 1st patch does not apply anymore, the 2nd one is OK, so will push the 2nd one now, please rebase the 1st one
Comment on attachment 10297 [details] [review] [SIGNED-OFF] Bug 6720: show authority type in auth details This patch has been pushed
Created attachment 10380 [details] [review] Bug 6720: Display the authority type in OPAC Due to a peculiarity in the way SearchAuthorities worked, the authority search results on the OPAC always listed the authority type that the user searched for, rather than the authority type of the results. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Works nicely, result list for OPAC search now shows the authority type for each record. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Rebased 20 June 2012.
Another signoff for the first patch now that it's been rebased would be super keen.
Jared, is http://git.koha-community.org/gitweb/?p=koha.git;a=blobdiff;f=authorities/detail.pl;h=a7d7d8f21882b7bcace75c5eb862eaebad8dfdeb;hp=d4f2c6730c76f19fb0aeefebdfd7fe5558066eff;hb=f809e47fd1644314bbd63542f3021382eece642f;hpb=f2ca89b30e8d48b987782ff3f9f7c8e8240b87a4 Safe to cherry-pick now, or best to wait until the second patch is pushed to master also?
(In reply to comment #13) > Jared, is > http://git.koha-community.org/gitweb/?p=koha.git;a=blobdiff;f=authorities/ > detail.pl;h=a7d7d8f21882b7bcace75c5eb862eaebad8dfdeb; > hp=d4f2c6730c76f19fb0aeefebdfd7fe5558066eff; > hb=f809e47fd1644314bbd63542f3021382eece642f; > hpb=f2ca89b30e8d48b987782ff3f9f7c8e8240b87a4 > > Safe to cherry-pick now, or best to wait until the second patch is pushed to > master also? You can cherry-pick that patch, and cherry-pick the next once it's been pushed to master.
Done, thanks for the quick reply
Created attachment 10444 [details] [review] Bug 6720: Display the authority type in OPAC Due to a peculiarity in the way SearchAuthorities worked, the authority search results on the OPAC always listed the authority type that the user searched for, rather than the authority type of the results. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Works nicely, result list for OPAC search now shows the authority type for each record. Signed-off-by: Jared Camins-Esakov <jcamins@cpbibliography.com> Rebased 20 June 2012. Signed-off-by: Mirko Tietgen <5p4m@gmx.de> Works as expected.
Comment on attachment 10380 [details] [review] Bug 6720: Display the authority type in OPAC This one seems to be obsoleted
QA Comments: my $thisauthtype = GetAuthType(GetAuthTypeCode($authid)); This line is very scabby. It does 2 selects on the auth_header table. But I don't find an other way to do that in our API. Considering the dirty code into the SearchAuthorities routine, I mark as passed QA this patch.
mmm... the code says: + $newline{authtype} = defined ($thisauthtype) ? + $thisauthtype->{'summary'} : + GetAuthType($authtypecode)->{'summary'}; "summary" is not the authtype description, but how the authority display is built. I tried the patch anyway, and got a -suspected- wrong result: The "type of heading" column now show: [200a][, 200b][ 200d][ ; 200c][ (200f)] :\\\
(In reply to comment #19) > mmm... the code says: > + $newline{authtype} = defined ($thisauthtype) ? > + $thisauthtype->{'summary'} : > + > GetAuthType($authtypecode)->{'summary'}; > > "summary" is not the authtype description, but how the authority display is > built. I tried the patch anyway, and got a -suspected- wrong result: > > The "type of heading" column now show: > [200a][, 200b][ 200d][ ; 200c][ (200f)] > > :\\\ This definitely does not sound right. Follow-up coming shortly.
Created attachment 10861 [details] [review] Bug 6720 follow-up: use authtypetext instead of summary Although auth_types.summary contains a string describing the type of authority in MARC21, it does not in UNIMARC. auth_types.authtypetext contains the proper label in both marcflavours.
The 3 patches on branch new/bug_6720 can be cherry picked to 3.8.x.
String changes, held for 3.8.4
Patches do not apply on 3.8.x
I think I've found a big problem with this patch. Under certain circumstances (I think it's because zebra & mysql are unsynched, this can happen when you just deleted an authority, and it hasn't been deleted on zebra) I get: Can't use an undefined value as a HASH reference at /home/paul/koha.dev/koha-community/C4/AuthoritiesMarc.pm line 355. at /home/paul/koha.dev/koha-community/authorities/authorities-home.pl line 203 git blame tells me the culprit is here. Investigating a little bit, I see that: + GetAuthType($authtypecode)->{'summary'}; will fail if GetAuthType() returns nothing Changing this line to ( GetAuthType($authtypecode) ? $_->{'authtypetext'}:''); seems to fix the problem. Jared, could you check, confirm & provide a patch, i'll sign it immediately Another problem, maybe not related = the authorities in the list are now displayed HASH(0xb67ed88)
Created attachment 11296 [details] [review] Bug 6720 follow-up: fix error when auth has been deleted Thanks to Paul Poulain for finding the problem and proposing a solution.
Your suggested fix worked perfectly, as far as I could tell. (In reply to comment #25) > Another problem, maybe not related = the authorities in the list are now > displayed HASH(0xb67ed88) See bug 8520 for a patch.
follow-up signed-off, passed QA & pushed in one go
The three patches here don't apply cleanly to 3.8.x <<<<<<< HEAD ======= my $thisauthtype = GetAuthType(GetAuthTypeCode($authid)); $newline{authtype} = defined ($thisauthtype) ? $thisauthtype->{'authtypetext'} : (GetAuthType($authtypecode) ? $_->{'authtypetext'} : ''); >>>>>>> 983012d... Bug 6720 follow-up: fix error when auth has been deleted
Was released in 3.10.0, patches attached don't apply to 3.8.x, closing