To direct patrons to 360Link page, You either need to make a different URL for all their holdings pages, something like: http://zz8kv2kj8h.search.serialssolutions.com/?sid=&ISSN=<insert journal ISSN here>" We will detect serialssolutions url, and if ISSN url arg is missing, we will add it.
Created attachment 3819 [details] [review] patch
Created attachment 5245 [details] [review] Bug 6129 - [master] this adds an ISSN to serialssolutions URLs If a URL is a serialssolutions URLs that doesn't already have an ISSN parameter, this adds one on the OPAC. Author: Srdjan Jankovic <srdjan@catalyst.net.nz> Author: Robin Sheat <robin@catalyst.net.nz>
Created attachment 5246 [details] [review] Bug 6129 - [3.4.x] this adds an ISSN to serialssolutions URLs If a URL is a serialssolutions URLs that doesn't already have an ISSN parameter, this adds one on the OPAC. Author: Srdjan Jankovic <srdjan@catalyst.net.nz> Author: Robin Sheat <robin@catalyst.net.nz>
Comment on attachment 5246 [details] [review] Bug 6129 - [3.4.x] this adds an ISSN to serialssolutions URLs This patch does not apply cleanly to 3.4.x. Please rebase and resubmit.
Created attachment 5304 [details] [review] Bug 6129 - [3.4.x] this adds an ISSN to serialssolutions URLs If a URL is a serialssolutions URLs that doesn't already have an ISSN parameter, this adds one on the OPAC. Author: Srdjan Jankovic <srdjan@catalyst.net.nz> Author: Robin Sheat <robin@catalyst.net.nz>
This patch fixes the 3.4.x conflict. Thought I'd fixed that the first time, apparently not.
Updating Version : This ENH will be for Koha 3.8
Bug versionned for master. entries will be made against rel_3_8 once the patch has been applied (see thread about that on koha-devel yesterday)
The fix for this bug was published in the 3.4.5 release. If you were the reporter of this bug, please take time to verify the fix and update the status of this bug report accordingly. If the bug is fixed to your satisfaction, please close this report.
Chris N, Paul: this has been put into 3.4.5 and is lined up for 3.8 ... this means that it'll skip 3.6, is that a good thing to do?
Patch for master does not apply: Apply? [y]es/[n]o/[e]dit/[v]iew patch/[a]ccept all y Applying: Bug 6129 - [master] this adds an ISSN to serialssolutions URLs Using index info to reconstruct a base tree... Falling back to patching base and 3-way merge... Auto-merging C4/Biblio.pm Auto-merging catalogue/detail.pl CONFLICT (content): Merge conflict in catalogue/detail.pl Auto-merging koha-tmpl/opac-tmpl/prog/en/xslt/MARC21slim2OPACDetail.xsl Auto-merging opac/opac-detail.pl CONFLICT (content): Merge conflict in opac/opac-detail.pl Failed to merge in the changes. Patch failed at 0001 Bug 6129 - [master] this adds an ISSN to serialssolutions URLs When you have resolved this problem run "git am --resolved". If you would prefer to skip this patch, instead run "git am --skip". To restore the original branch and stop patching run "git am --abort". I am not sure if we should build in solutions for single vendors like this. Could there be a way to make this more flexible?
(In reply to comment #11) > Patch for master does not apply: > > > I am not sure if we should build in solutions for single vendors like this. > Could there be a way to make this more flexible? There could be, but that should definitely not stop this going in, this only adds the issn parameter to a serialsolutions url if one exists in the data already (and doesn't have the issn parameter set). Also it is in 3.4.x ... so not putting it in 3.6.x and master means we are conciously causing a regression.
That makes sense to me. I was wondering about it because I was trying to use a web service for serials last week that requires to have an url with the issn. We don't have the issn available in the SearchForTitleIn system preference and it's a bit hard to get it with jQuery. But this can all go on a separate enhancement request :)
Created attachment 6916 [details] [review] patch
Hardcoding for one specific service (Serials Solutions) strikes me as a very hacky and unsustainable way of fixing this problem. This kind of processing should be put into a plugin file or some other kind of external means, rather than into C4/Biblio.pm directly.
Wouldn't it be better to add ISSN for SearchForTitleIn?
Actually, never mind. This is because serialssolutions apparently provides records with URLs that are missing the ISSN, not for adding serialssolutions URLs to records that don't have that 856 yet.
(In reply to Jared Camins-Esakov from comment #17) > Actually, never mind. This is because serialssolutions apparently provides > records with URLs that are missing the ISSN, not for adding serialssolutions > URLs to records that don't have that 856 yet. Question for the audience ... is Serials Solutions still distributing records with (apparently) incomplete URLs? If so, I think a better implementation of the fixup nowadays would be as a TT plugin.
Still valid?
(In reply to Galen Charlton from comment #18) > (In reply to Jared Camins-Esakov from comment #17) > > Actually, never mind. This is because serialssolutions apparently provides > > records with URLs that are missing the ISSN, not for adding serialssolutions > > URLs to records that don't have that 856 yet. > > Question for the audience ... is Serials Solutions still distributing > records with (apparently) incomplete URLs? > > If so, I think a better implementation of the fixup nowadays would be as a > TT plugin. Closing this now more than 7 years after last comment. Please reopen if you disagree and can confirm that this is still an issue for libraries.