On master you can add a reason for suggestion in OPAC and in acquisitions when creating a suggestion. This value is not saved into the database.
mmm... just checked on 3.6.0 and it works fine for me. Anything in the logs ?
Retesting now...
I can still reproduce this. 1) Create suggestion in OPAC 2) Fill out title and select a reason from the pull down field 3) Check suggestion in database and in acq - reason is not saved or shown Error logs show no errors.
well, I just tried by selecting a suggestion or entering one manually, and it worked fine. I also tried by creating a suggestion from both OPAC and staff. Do you have an error in your logs ?
Feature was implemented as Bug 1883. I am not sure where the patron reason should save to - there is suggestions.reason - but perhaps this should only be used for accept/reject reaosns from staff? That way the patron reason would not be overwritten.
My guess is that when working on Bug 1883 I modified my database to add a "patronreason" column to the suggestions table. With that in place the feature works. I'll submit a follow-up which makes the table modification.
Created attachment 6066 [details] [review] Proposed fix The fix for Bug 1883 seems to have lacked the necessary update to the database to add the "patronreason" column to the suggestions table. This patch does so.
Created attachment 6068 [details] [review] [SIGNED-OFF] Bug 6880- Reason for suggestions do not save The fix for Bug 1883 seems to have lacked the necessary update to the database to add the "patronreason" column to the suggestions table. This patch does so. Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de> Patch adds database update and change to kohastructure. After this patch is applied, the patron's reason for making a suggestion (form in opac) is saved to the database correctly. The reason is also shown in the detail view of the suggestion. This needs to be backported to 3.6
*** Bug 6856 has been marked as a duplicate of this bug. ***
QA Comment: Code looks good. Patch passed QA. Some developers may have the column already somehow, but will not be troubled by the SQL error if an update tries to add it again. (This could have been checked [very] theoretically.) In the print statement in updatedatabase the bug report number could be mentioned for more information. The whole update procedure is under change now and I suspect that this patch therefore will be on hold until the new system is in place. (Effectively creating the need for a rebase..)
Or will be applied to 3.6 and require a new patch for master... thx for QA Marcel, we will wait and find out.
patch pushed, please test (DB rev 3.6.3.001)
There have been no further reports of problems so I am marking this bug resolved.