This patch creates a simple item landing page in OPAC by tweaking opac-detail.pl to only show a specific item. It could serve to resolve an item persistent identifier until we perhaps have a better alternative in OPAC.
Created attachment 106003 [details] [review] Bug 25801: Add itemnumber parameter to opac-detail Note: The GetItemsInfo call is now suboptimal. Leaving it as-is for now in the hope that item refactoring picks it up ;) Test plan: Test opac-detail via biblionumber (regular use). Test opac-detail by passing an itemnumber in the URL. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 106004 [details] [review] Bug 25801: Add itemnumber parameter to opac-detail Note: The GetItemsInfo call is now suboptimal. Leaving it as-is for now in the hope that item refactoring picks it up ;) Test plan: Test opac-detail via biblionumber (regular use). Test opac-detail by passing an itemnumber in the URL. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Owen Leonard <oleonard@myacpl.org>
(In reply to Owen Leonard from comment #2) > Created attachment 106004 [details] [review] [review] > Bug 25801: Add itemnumber parameter to opac-detail > > Note: The GetItemsInfo call is now suboptimal. Leaving it as-is > for now in the hope that item refactoring picks it up ;) > > Test plan: > Test opac-detail via biblionumber (regular use). > Test opac-detail by passing an itemnumber in the URL. > > Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> > > Signed-off-by: Owen Leonard <oleonard@myacpl.org> Thx Owen. So fast ;)
This works well, but I am wondering about the use case - can you share your idea behind this? The thing that is irritating for me is the hiding of the other items with no way to make them visible (like a link to switch to the 'full holdings' or something like that?) Another option could be highlighting the item in the URL param visually in the table instead of hiding all others. Also the test plan was lacking a bit, I guessed: /cgi-bin/koha/opac-detail.pl?itemnumber=605 That works and it will ignore the biblionumber, if also supplied?
Failing QA as a way to alert Marcel of the questions.
(In reply to Katrin Fischer from comment #4) > This works well, but I am wondering about the use case - can you share your > idea behind this? The idea is that if I would have an item persistent identifier for say item 345 (belonging to biblio 234) like e.g. mylibrary.com/item/345, how will this be resolved in OPAC? We have no landing page for items. If I resolve to biblio 234, I see all items. This is not meant to be the perfect solution but a first attempt to have a landing page for items. See also bug 24544 (still in progress).
(In reply to Katrin Fischer from comment #4) > The thing that is irritating for me is the hiding of the other items with no > way to make them visible (like a link to switch to the 'full holdings' or > something like that?) Another option could be highlighting the item in the > URL param visually in the table instead of hiding all others. I would prefer to list the item only. But we could add a link to go back to the normal view? Show all items? > Also the test plan was lacking a bit, I guessed: > /cgi-bin/koha/opac-detail.pl?itemnumber=605 > > That works and it will ignore the biblionumber, if also supplied? OK I will adjust the test plan. Thanks for your feedback.
Hi Marcel, I think a link to he 'full' display would really make me feel more confident about this. And we could make to so it can be easily hidden if needed. Thx for taking my comments into consideration.
Created attachment 106321 [details] [review] Bug 25801: Add itemnumber parameter to opac-detail Note: The GetItemsInfo call is now suboptimal. Leaving it as-is for now in the hope that item refactoring picks it up ;) Test plan: Test opac-detail via biblionumber (regular use). Test opac-detail by passing an itemnumber in the URL: /cgi-bin/koha/opac-detail?itemnumber=999 Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Owen Leonard <oleonard@myacpl.org>
Created attachment 106322 [details] [review] Bug 25801: (follow-up) Add Show all items-link on opac-detail As requested by Katrin in QA, it might be helpful to provide a link to return to the regular view with all items. The information about acquisition and holds refers to all items, so I moved it inside the else branch of this block. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 106323 [details] [review] Bug 25801: (follow-up) Fix indentation level of else block Just fixing the indentation here with a substitution cmd. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 106366 [details] [review] Bug 25801: Add itemnumber parameter to opac-detail Note: The GetItemsInfo call is now suboptimal. Leaving it as-is for now in the hope that item refactoring picks it up ;) Test plan: Test opac-detail via biblionumber (regular use). Test opac-detail by passing an itemnumber in the URL: /cgi-bin/koha/opac-detail?itemnumber=999 Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Owen Leonard <oleonard@myacpl.org> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 106367 [details] [review] Bug 25801: (follow-up) Add Show all items-link on opac-detail As requested by Katrin in QA, it might be helpful to provide a link to return to the regular view with all items. The information about acquisition and holds refers to all items, so I moved it inside the else branch of this block. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
Created attachment 106368 [details] [review] Bug 25801: (follow-up) Fix indentation level of else block Just fixing the indentation here with a substitution cmd. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
(In reply to Katrin Fischer from comment #14) Thx
I like the idea of having a web page to show for an item (whether it's for a persistent identifier or just for doing manual updates to an item without needing a bib number). However, I can understand Katrin's concerns. It seems like we're hacking/shoehorning the opac-detail.pl page to serve a purpose it's not meant to serve. What's the practical use case for this? Is this to be used for a RDF subject? Or some other purpose?
(In reply to David Cook from comment #16) > I like the idea of having a web page to show for an item (whether it's for a > persistent identifier or just for doing manual updates to an item without > needing a bib number). > > However, I can understand Katrin's concerns. It seems like we're > hacking/shoehorning the opac-detail.pl page to serve a purpose it's not > meant to serve. > > What's the practical use case for this? Is this to be used for a RDF > subject? Or some other purpose? Hi David, See also comment1. This is a first attempt to quickly have an item landing page (hacking just a few lines). And yes, the item persistent identifier to be used in RDF subjects should be resolved by the opac-detail item page when content negotiation comes down to HTML.
(In reply to Marcel de Rooy from comment #17) > See also comment1. This is a first attempt to quickly have an item landing > page (hacking just a few lines). And yes, the item persistent identifier to > be used in RDF subjects should be resolved by the opac-detail item page when > content negotiation comes down to HTML. I don't see a use case in Comment 1. RDF subjects was my first thought, although reading more about RPC and REST APIs and thinking that having a canonical item URL (or PID) could be useful for a REST API (better to return a URL rather than an itemnumber for instance). I was wondering if you had a particular use case that you plan to use this for in the short term is all. Like is the HTML representation important in your use case? Or is it just to uniquely identify the resource (say for a RDF subject or REST API)? I think it's a great idea, but I'm just curious about the implementation.
(In reply to David Cook from comment #18) > RDF subjects was my first thought, although reading more about RPC and REST > APIs and thinking that having a canonical item URL (or PID) could be useful > for a REST API (better to return a URL rather than an itemnumber for > instance). > I was wondering if you had a particular use case that you plan to use this > for in the short term is all. Like is the HTML representation important in > your use case? Or is it just to uniquely identify the resource (say for a > RDF subject or REST API)? Yes, the landing page of the item persistent identifier (URL) is not that important, but I do want to be able to dereference it. Including an HTML representation when that would be the result of content negotiation. But surely the main thing is a unique resource identifier in the form of a URL. We will be using something like https://id.rijksmuseum.nl/3012345 Our institutional PID resolver knows (as a partial or meta resolver) how to pass library PIDs to the library PID resolver. Which would use opac-detail for HTML in case of a biblio or item.
(In reply to Marcel de Rooy from comment #19) > Yes, the landing page of the item persistent identifier (URL) is not that > important, but I do want to be able to dereference it. Including an HTML > representation when that would be the result of content negotiation. But > surely the main thing is a unique resource identifier in the form of a URL. > Cool. That sounds good to me. > We will be using something like https://id.rijksmuseum.nl/3012345 > Our institutional PID resolver knows (as a partial or meta resolver) how to > pass library PIDs to the library PID resolver. Which would use opac-detail > for HTML in case of a biblio or item. Could you explain this part a bit more? Is the idea that you'll mint institution level PIDs (like https://id.rijksmuseum.nl/3012345) and those will resolve to Koha PIDs/URLs? That would be cool.
> > We will be using something like https://id.rijksmuseum.nl/3012345 > > Our institutional PID resolver knows (as a partial or meta resolver) how to > > pass library PIDs to the library PID resolver. Which would use opac-detail > > for HTML in case of a biblio or item. > > Could you explain this part a bit more? Is the idea that you'll mint > institution level PIDs (like https://id.rijksmuseum.nl/3012345) and those > will resolve to Koha PIDs/URLs? Our discussion goes out of scope here? :) What we currently do: The main resolver (WIP) passes all 3xxx to the library resolver. That one knows how to resolve them depending on accept header. Similarly, we do not have one minter. The library pid generator mints PIDs in the id.rijksmuseum.nl domain but only starting with a 3 as a hidden designator for library domain.
Pushed to master for 20.11, thanks to everybody involved!
enhancement will not be backported to 20.05.x