Since bug 27945 we can limit article request per patron's category. However the "request article" links (detail and search views) are still active. We could disable them and add a tooltip.
Are we doing the same for holds now? I think we didnt, we only calculated if we allow when the user clicked further?
Note that we may not even be able to say if a request is possible. We are doing sort of intelligent guess now. You have biblio and item level requests. You depend on multiple circ rules. Etc. It will be too costly to calculate beforehand?
Not a lot of cost for the detail view (and we try to do it for holds on this view).
(In reply to Jonathan Druart from comment #3) > Not a lot of cost for the detail view (and we try to do it for holds on this > view). True. I had the results view in mind.
I would suggest to change the title if this is about detail view btw.
We can easily hide the link on the search result view in some case (like the limit per category)
Created attachment 125890 [details] [review] Bug 29168: Only show 'Request article' if allowed on the detail view This patch adds a check for the patron being able to place the request, in the case of logged in patron. The anonymous patron will still be displayed the link, and redirected to the login page as required. To test: 1. Set the article request limit to 1 2. Place a request on behalf of a known patron 3. With the patron session, in the OPAC, try to place a new article request from the detail page => SUCCESS: There's no link 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
Created attachment 125920 [details] [review] Bug 29168: Only show 'Request article' if allowed on the detail view This patch adds a check for the patron being able to place the request, in the case of logged in patron. The anonymous patron will still be displayed the link, and redirected to the login page as required. To test: 1. Set the article request limit to 1 2. Place a request on behalf of a known patron 3. With the patron session, in the OPAC, try to place a new article request from the detail page => SUCCESS: There's no link 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Created attachment 125921 [details] [review] Bug 29168: (follow-up) Indentation of next code block Indentationt of lines 811-823 directly after changed code corrected. Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl>
Comment on attachment 125921 [details] [review] Bug 29168: (follow-up) Indentation of next code block Not related changes that can cause unnecessary conflicts.
(In reply to Jonathan Druart from comment #10) > Comment on attachment 125921 [details] [review] [review] > Bug 29168: (follow-up) Indentation of next code block > > Not related changes that can cause unnecessary conflicts. Beetje flauw.
Created attachment 127175 [details] [review] Bug 29168: Only show 'Request article' if allowed on the detail view This patch adds a check for the patron being able to place the request, in the case of logged in patron. The anonymous patron will still be displayed the link, and redirected to the login page as required. To test: 1. Set the article request limit to 1 2. Place a request on behalf of a known patron 3. With the patron session, in the OPAC, try to place a new article request from the detail page => SUCCESS: There's no link 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io> Signed-off-by: Marcel de Rooy <m.de.rooy@rijksmuseum.nl> Signed-off-by: Katrin Fischer <katrin.fischer.83@web.de>
I expected a big complicated patch and was pleasantly disappointed.
This is getting complicated. I think it should be simplified. Isn't the following correct/enough? if ( $patron && $patron->can_request_article ) { $artreqpossible = $biblio->can_article_request( $patron ); } elsif ( $itemtype ) { $artreqpossible = $itemtype->may_article_request }
(In reply to Jonathan Druart from comment #14) > This is getting complicated. I think it should be simplified. > > Isn't the following correct/enough? > > if ( $patron && $patron->can_request_article ) { > $artreqpossible = $biblio->can_article_request( $patron ); > } elsif ( $itemtype ) { > $artreqpossible = $itemtype->may_article_request > } It looks similar to me, a bit shorter. Do you want me to resubmit the patch in this form?
Shorter and less unnecessary calls in some cases. Yes please resubmit.
Created attachment 127441 [details] [review] Bug 29168: Only show 'Request article' if allowed on the detail view This patch adds a check for the patron being able to place the request, in the case of logged in patron. The anonymous patron will still be displayed the link, and redirected to the login page as required. To test: 1. Set the article request limit to 1 2. Place a request on behalf of a known patron 3. With the patron session, in the OPAC, try to place a new article request from the detail page => SUCCESS: There's no link 4. Sign off :-D Signed-off-by: Tomas Cohen Arazi <tomascohen@theke.io>
*** Bug 28360 has been marked as a duplicate of this bug. ***
Created attachment 128251 [details] Bug 29168 - Error trace when viewing detail in OPAC when logged in When viewing the detail page for a record in the OPAC when logged in I get the error as attached. This is after applying the patch, enabling article requests, but before setting any article request limits. If you are not logged in, the detail page is displayed as expected.