https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |27945 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27945 [Bug 27945] Limit the number of active article requests per patron category -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Owen Leonard <oleonard@myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |master Assignee|oleonard@myacpl.org |koha-bugs@lists.koha-commun | |ity.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #3 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Not a lot of cost for the detail view (and we try to do it for holds on this view). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC| |tomascohen@gmail.com Assignee|koha-bugs@lists.koha-commun |tomascohen@gmail.com |ity.org | -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Disable "Request article" |Only show "Request article" |links when limit is reached |if allowed on the detail | |view -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Needs Signoff Patch complexity|--- |Trivial patch -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #9 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Created attachment 125921 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=125921&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #11 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Jonathan Druart from comment #10)

Comment on attachment 125921 [details] [review] Bug 29168: (follow-up) Indentation of next code block

Not related changes that can cause unnecessary conflicts.

Beetje flauw. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #13 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I expected a big complicated patch and was pleasantly disappointed. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Passed QA |In Discussion -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #16 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- Shorter and less unnecessary calls in some cases. Yes please resubmit. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|In Discussion |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |david@davidnind.com --- Comment #19 from David Nind <david@davidnind.com> --- Created attachment 128251 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=128251&action=edit 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. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #20 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- (In reply to David Nind from comment #19)

When viewing the detail page for a record in the OPAC when logged in I get

:-( This was because the `can_article_request` method was renamed on bug 27945. I've fixed that now. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #21 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 201762 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=201762&action=edit 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> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #22 from David Nind <david@davidnind.com> --- I've tested, but the behavour is different from what is described. Instead of removing the "Request article" link, the link remains. When you click on the "Request article" link, and you have reached the limit set, you get an information message in a light blue box with: "You reached your open article requests limit." Testing notes (using KTD): 0. Apply the patch and restart everything (restart_all). 1. Enable the ArticleRequests system preference. 2. Set the article request limit to 1: 2.1 Go to Administration > Patrons and circulation > Circulation and fine rules 2.2 Find the "Default open article requests limit" section on the page 2.3 For "All", set "Total article requests" to 1 2.4 Click "Add" 3. In the staff interface place an article request on Programming Perl (262) for Mary Burton. 4. Set a user name and password for Mary Burton, so you can log in as her in the OPAC. 5. Open the OPAC in an incognito/private window. 6. Look at any record details page, and note that there is a "Request article" link. 7. Log in as Mary 8. Look at any details page for a record - note that is a "Request article" link. 9. Click the "Request article" link. 10. You get an information message "You reached your open article requests limit.". 11. Delete the article request already made using the staff interface. 12. Refresh a details page in the OPAC with Mary logged in. 13. Click the "Request article" link. 14. Can now place an article request. -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #23 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 202849 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202849&action=edit Bug 29168: Disable 'Request article' link when patron has reached the limit Stash patron_can_request_article in get_template_and_user so all OPAC pages get it for free. The two template includes that render the 'Request article' link (opac-detail-sidebar.inc and title-actions-menu.inc) now check this variable. When the patron has reached their limit, the link is shown disabled with a tooltip ('You have reached your open article requests limit.') rather than hidden entirely. The disabled state only shows when circ rules would otherwise allow the request (artreqpossible is truthy) — if circ rules say 'no' for this patron category/itemtype, no link is shown at all. Template logic (both includes): artreqpossible (circ rules allow) AND patron_can_request_article → active link artreqpossible (circ rules allow) AND NOT patron_can_request_article → disabled link with tooltip NOT artreqpossible (circ rules deny) → no link Note: artreqpossible is computed per-biblio by each script. On search results it uses guess_article_requestable_itemtypes (itemtype-only, category-agnostic), while detail pages use can_article_request($patron) which is patron-category-aware. This means a record might show a disabled link in search results but no link at all on the detail page if the patron's category doesn't match the circ rules. This is a pre-existing inconsistency unrelated to this patch. The server-side check in opac-request-article.pl remains as a fallback for bookmarked/direct URLs. Community poll result: 5 votes for disabled+tooltip, 2 for hiding. The check runs once per request in C4::Auth, gated on the ArticleRequests syspref being enabled and a patron being logged in. Defaults to 1 for anonymous sessions so the link remains active and redirects to login on click. Test plan: 1. Apply patch 2. ktd --name bug29168 --shell k$ restart_all 3. Enable ArticleRequests syspref 4. Set article request limit to 1: Administration > Circulation and fine rules > Default open article requests limit > All > Total: 1 > Add 5. Ensure the 'All' circ rule has article_requests set to 'yes' (Default checkout, hold and return policy > Article requests > Yes) 6. Place an article request for a patron via the staff interface 7. Log in as that patron in the OPAC 8. Look at a record detail page => SUCCESS: 'Request article' link is disabled with tooltip 9. Search for records => SUCCESS: 'Request article' link is disabled in search results 10. Hover over the disabled link => SUCCESS: Tooltip says 'You have reached your open article requests limit.' 11. Log out of the OPAC 12. Look at same detail page and search results => SUCCESS: 'Request article' link is active (anonymous user) 13. Delete the article request via staff interface 14. Log back in as the patron, refresh the OPAC detail page => SUCCESS: 'Request article' link is active again 15. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #25 from Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> --- Created attachment 202851 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202851&action=edit Bug 29168: (follow-up) respect explicit article request denial in search results guess_article_requestable_itemtypes now fetches all article_requests rules (not just non-'no' ones) and records explicit denials as 0 in the returned hash. This ensures that a specific itemtype set to 'no' is not overridden by a wildcard 'yes' rule. The lookup in opac-search.pl, opac-shelves.pl, and opac-tags.pl is changed from || (or) to // (defined-or) so that an explicit 0 in the hash is respected rather than falling through to the wildcard. Test plan: 1. Apply patch 2. ktd --shell k$ prove t/db_dependent/Koha/CirculationRules/guess_article_requestable_itemtypes.t => SUCCESS: All tests pass 3. Set a default article request rule to 'yes' (all itemtypes) 4. Add a specific rule for one itemtype set to 'no' 5. Search for a record with that itemtype in the OPAC => SUCCESS: No 'Request article' link in search results 6. Sign off :-D -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 Tomás Cohen Arazi (tcohen) <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com, | |katrin.fischer@bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #202849|0 |1 is obsolete| | Attachment #202850|0 |1 is obsolete| | Attachment #202851|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 --- Comment #28 from David Nind <david@davidnind.com> --- Created attachment 202854 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=202854&action=edit Bug 29168: (regression test) explicit article request denial overridden by wildcard guess_article_requestable_itemtypes does not track explicit 'no' rules for specific itemtypes. When a wildcard rule (NULL itemtype) allows article requests and a specific itemtype rule denies them, the denied itemtype does not appear in the returned hash. The search results page then falls through to the wildcard and incorrectly shows the 'Request article' link. Additionally, opac-search.pl uses || (or) for the lookup, which treats an explicit 0 as falsy and falls through to the wildcard. It should use // (defined-or) to respect explicit denials. Test plan: 1. Apply patch 2. ktd --shell k$ prove t/db_dependent/Koha/CirculationRules/guess_article_requestable_itemtypes.t => FAIL: Tests 3 and 4 in the new subtest fail 3. Sign off :-D Signed-off-by: David Nind <david@davidnind.com> -- You are receiving this mail because: You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29168 David Nind <david@davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Text to go in the| |This improves^ how the release notes| |"Request article" link is | |shown in the OPAC (when | |ArticleRequests is | |enabled): | | | |- No "Request article" link | |is shown on search result | |and detail pages if | |requesting an article is | |not allowed for a patron | |category or item type. | | | |- A "Request article" link | |is shown but is not | |clickable (greyed out) and | |has a tooltip with "You | |have reached your open | |article requests limit.", | |if a patron has reached the | |daily limit for placing | |article requests. | |(Previously, the link was | |clickable, but then there | |was a message saying you | |couldn't place a request - | |which could be confusing.) | | | |^ This change helps avoid | |confusion for patrons: | |rather than show request | |article links, then say | |they can't place an article | |request when they try and | |place a request, the link | |is not clickable and has a | |tooltip with the reason | |why. If they can't place an | |article request at all | |(because of patron or item | |type rules), the request | |article link is not shown. -- You are receiving this mail because: You are watching all bug changes.