Summary: | Suggestion confirmation letter sent when it should not | ||
---|---|---|---|
Product: | Koha | Reporter: | Janusz Kaczmarek <januszop> |
Component: | Acquisitions | Assignee: | Janusz Kaczmarek <januszop> |
Status: | RESOLVED FIXED | QA Contact: | Aleisha Amohia <aleisha> |
Severity: | minor | ||
Priority: | P5 - low | CC: | aleisha, lucas |
Version: | unspecified | ||
Hardware: | All | ||
OS: | All | ||
Change sponsored?: | Sponsored | Patch complexity: | Trivial patch |
Documentation contact: | Documentation submission: | ||
Text to go in the release notes: |
This enhancement prevents a patron who made a suggestion from being notified again if their suggested record is reordered.
|
Version(s) released in: |
24.11.00
|
Circulation function: | |||
Attachments: |
Bug 38235: Suggestion confirmation letter sent when it should not
Bug 38235: Unit tests Bug 38235: Suggestion confirmation letter sent when it should not Bug 38235: Unit tests Bug 38235: Suggestion confirmation letter sent when it should not Bug 38235: Unit tests |
Description
Janusz Kaczmarek
2024-10-23 09:32:04 UTC
Created attachment 173199 [details] [review] Bug 38235: Suggestion confirmation letter sent when it should not When processing a new order (creating basket, receiving order, etc.) using a bibliographic record once already linked to an old suggestion (already completed in the past), Koha generates and sends a confirmation letter that should not be sent at all. This is because suggestions in Koha are linked to a biblionumber (and not the order), and so the old suggestion is identified - erroneously - as relevant. Then C4::Suggestions::ModSuggestion sends a letter whenever it receives STATUS as a parameter, paying no attention to whether the status is changed. So, in this case, a suggestion already in the status AVAILABLE is "updated" to the status AVAILABLE and the letter is generated. To solve this problem, it should be enough to check whether STATUS is actually changed. Test plan: ========== 1. As a patron, make a purchase suggestion. As a librarian, accept it and process it, as usual, through the acquisition process. 2. At the patron account, as librarian, check the generated notices (the most recent should be "Suggested purchase available"). 3. Make a new aquisition order for the same bibliographic record ("From an existing record:") and receive it as usual. 4. Go to the account of the patron that made the original suggestion and check the notices. Note the second, irrelevant letter "Suggested purchase available". 5. Apply the patch; restart_all. 6. Repeat p. 3 and 4. Note that no new notice has been generated. Sponsored-by: Ignatianum University in Cracow Created attachment 173200 [details] [review] Bug 38235: Unit tests BTW, tiny adjustments to existing tests to work with modified C4::Suggestions::ModSuggestion. Created attachment 173227 [details] [review] Bug 38235: Suggestion confirmation letter sent when it should not When processing a new order (creating basket, receiving order, etc.) using a bibliographic record once already linked to an old suggestion (already completed in the past), Koha generates and sends a confirmation letter that should not be sent at all. This is because suggestions in Koha are linked to a biblionumber (and not the order), and so the old suggestion is identified - erroneously - as relevant. Then C4::Suggestions::ModSuggestion sends a letter whenever it receives STATUS as a parameter, paying no attention to whether the status is changed. So, in this case, a suggestion already in the status AVAILABLE is "updated" to the status AVAILABLE and the letter is generated. To solve this problem, it should be enough to check whether STATUS is actually changed. Test plan: ========== 1. As a patron, make a purchase suggestion. As a librarian, accept it and process it, as usual, through the acquisition process. 2. At the patron account, as librarian, check the generated notices (the most recent should be "Suggested purchase available"). 3. Make a new aquisition order for the same bibliographic record ("From an existing record:") and receive it as usual. 4. Go to the account of the patron that made the original suggestion and check the notices. Note the second, irrelevant letter "Suggested purchase available". 5. Apply the patch; restart_all. 6. Repeat p. 3 and 4. Note that no new notice has been generated. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Created attachment 173228 [details] [review] Bug 38235: Unit tests BTW, tiny adjustments to existing tests to work with modified C4::Suggestions::ModSuggestion. Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Hello, I was QAing this but I can't seem to reproduce the original problem and generate a second notice. Can you please provide a clearer test plan? Maybe too much ambiguity. (In reply to Aleisha Amohia from comment #5) > Hello, I was QAing this but I can't seem to reproduce the original problem > and generate a second notice. > > Can you please provide a clearer test plan? Maybe too much ambiguity. Hello Aleisha, Thank you for your interest. Please, confirm that you are using the default KTD settings and that in p. 2 you can see the notice "Suggested purchase available". If yes, in p. 3.: a) Create a new basket (select a vendor and then: New -> Basket). b) Add to basket --> From an existing record: [make a search for the record created from the suggestion from p. 1). c) From the record view: Add order (grayish action menu at the top). d) Pick Koha item type ; Add item ; select Fund ; Save. e) Close basket. f) Receive shipments. g) Enter Vendor invoice # ; proceed with next. h) Click Receive. i) Click Edit. j) Mark checkbox "Receive?" and Confirm. k) Finish receiving. Proceed to p. 4: Go to the account of the patron that made the original suggestion and check the notices. Note the second, irrelevant letter "Suggested purchase available". I hope you will be able to reproduce the issue now. Could you confirm please? (In reply to Janusz Kaczmarek from comment #6) > I hope you will be able to reproduce the issue now. Could you confirm > please? Yes thank you! I don't know what I did differently this time but I can confirm I saw the second irrelevant notice this time. Created attachment 174391 [details] [review] Bug 38235: Suggestion confirmation letter sent when it should not When processing a new order (creating basket, receiving order, etc.) using a bibliographic record once already linked to an old suggestion (already completed in the past), Koha generates and sends a confirmation letter that should not be sent at all. This is because suggestions in Koha are linked to a biblionumber (and not the order), and so the old suggestion is identified - erroneously - as relevant. Then C4::Suggestions::ModSuggestion sends a letter whenever it receives STATUS as a parameter, paying no attention to whether the status is changed. So, in this case, a suggestion already in the status AVAILABLE is "updated" to the status AVAILABLE and the letter is generated. To solve this problem, it should be enough to check whether STATUS is actually changed. Test plan: ========== 1. As a patron, make a purchase suggestion. As a librarian, accept it and process it, as usual, through the acquisition process. 2. At the patron account, as librarian, check the generated notices (the most recent should be "Suggested purchase available"). 3. Make a new aquisition order for the same bibliographic record ("From an existing record:") and receive it as usual. 4. Go to the account of the patron that made the original suggestion and check the notices. Note the second, irrelevant letter "Suggested purchase available". 5. Apply the patch; restart_all. 6. Repeat p. 3 and 4. Note that no new notice has been generated. Sponsored-by: Ignatianum University in Cracow Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com> Created attachment 174392 [details] [review] Bug 38235: Unit tests BTW, tiny adjustments to existing tests to work with modified C4::Suggestions::ModSuggestion. Signed-off-by: Roman Dolny <roman.dolny@jezuici.pl> Signed-off-by: Aleisha Amohia <aleishaamohia@hotmail.com> Pushed for 24.11! Well done everyone, thank you! Merge conflicst with 24.05.x, no backport. |