Bug 4461 - Context-sensitive report a problem screen
Summary: Context-sensitive report a problem screen
Status: Failed QA
Alias: None
Product: Koha
Classification: Unclassified
Component: OPAC (show other bugs)
Version: master
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Aleisha Amohia
QA Contact: Nick Clemens
URL:
Keywords:
: 4881 (view as bug list)
Depends on:
Blocks:
 
Reported: 2010-05-06 02:44 UTC by Jared Camins
Modified: 2017-10-26 11:48 UTC (History)
9 users (show)

See Also:
Change sponsored?: Sponsored
Patch complexity: Medium patch
Who signed the patch off:
Text to go in the release notes:
Version(s) released in:


Attachments
Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC (24.97 KB, patch)
2017-01-12 23:03 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC (26.99 KB, patch)
2017-01-16 21:57 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC (26.37 KB, patch)
2017-03-28 04:00 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 4461: [FOLLOW-UP] Problem Report feature (23.04 KB, patch)
2017-08-11 05:15 UTC, Aleisha Amohia
Details | Diff | Splinter Review
Bug 4461: [FOLLOW-UP] Problem Report feature (23.04 KB, patch)
2017-08-20 22:16 UTC, Aleisha Amohia
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC (26.44 KB, patch)
2017-08-22 11:50 UTC, Josef Moravec
Details | Diff | Splinter Review
[SIGNED-OFF] Bug 4461: [FOLLOW-UP] Problem Report feature (23.10 KB, patch)
2017-08-22 11:50 UTC, Josef Moravec
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Cormack 2010-05-21 01:27:28 UTC


---- Reported by camins@numismatics.org 2010-05-06 14:44:22 ----

It would be very helpful to optionally have a context-sensitive "report a problem" link on every page. The page that opens should have an input box for the user to compose a message to KohaAdminEmailAddress. The resulting e-mail should include not just the user's message but also the exact page s/he is on, and the currently-logged in username.

I have seen features like this in a number of libraries' catalogs, but I can't seem to remember which at the moment.



---- Additional Comments From irma@calyx.net.au 2010-05-06 23:33:32 ----

In fact to have 2 options to "report a problem' would be good.
1) Linking to KohaAdminEmailAddress 
2) Linking to a librarian as some reports might be more re "how to use this page".




--- Bug imported by chris@bigballofwax.co.nz 2010-05-21 01:27 UTC  ---

This bug was previously known as _bug_ 4461 at http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4461

Actual time not defined. Setting to 0.0
Setting qa contact to the default for this product.
   This bug either had no qa contact or an invalid one.
CC member irma@calyx.net.au does not have an account here

Comment 1 Owen Leonard 2010-08-27 19:36:16 UTC
*** Bug 4881 has been marked as a duplicate of this bug. ***
Comment 2 Aleisha Amohia 2017-01-12 23:03:43 UTC Comment hidden (obsolete)
Comment 3 Owen Leonard 2017-01-13 13:18:31 UTC
I think this looks good, but there are some issues that need to be looked at:

I think that if there is no email address for the logged-in user's library the page should not offer to email the librarian. In my test if I submit a report to the librarian and there is no email address for my home library, the entry saved in message_queue has an empty 'to_address' field.

There are HTML validation errors triggered by duplicate id attributes on form fields. The form fields on the two different tabs should not have the same ids (note that input name and id attributes do not have to match);

Also, in the OPAC (and soon to be the case in the staff client), page-specific JavaScript goes into a special BLOCK which is processed in the footer include. So instead of this, at the end of opac-reportaproblem.tt:

[% BLOCK jsinclude %][% END %]

<script type="text/javascript">
    $(document).ready(function(){
        $("#reportproblem").tabs();
    });
</script>

It should be:

[% BLOCK jsinclude %]
    <script type="text/javascript">
        $(document).ready(function(){
            $("#reportproblem").tabs();
        });
    </script>
[% END %]
Comment 4 Aleisha Amohia 2017-01-16 21:57:11 UTC Comment hidden (obsolete)
Comment 5 Eric 2017-03-21 15:31:15 UTC
Patch doesn't apply :

Some problems occurred applying patches from bug 4461:
<h1>Something went wrong !</h1>Applying: Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC
Using index info to reconstruct a base tree...
M       Koha/Schema/Result/Borrower.pm
M       installer/data/mysql/kohastructure.sql
M       koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc
Falling back to patching base and 3-way merge...
Auto-merging koha-tmpl/opac-tmpl/bootstrap/en/includes/opac-bottom.inc
Auto-merging installer/data/mysql/kohastructure.sql
Auto-merging Koha/Schema/Result/Borrower.pm
CONFLICT (content): Merge conflict in Koha/Schema/Result/Borrower.pm
Patch failed at 0001 Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC
The copy of the patch that failed is found in: .git/rebase-apply/patch
When you have resolved this problem run git bz apply --continue.
If you would prefer to skip this patch, instead run git bz apply --skip.
To restore the original branch and stop patching run git bz apply --abort.
error: Failed to merge in the changes.
Bug 4461 - Context-sensitive report a problem screen

59032 - Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC
Comment 6 Aleisha Amohia 2017-03-28 04:00:03 UTC Comment hidden (obsolete)
Comment 7 Katrin Fischer 2017-05-01 15:34:04 UTC
Hi Aleisha,

this doesn't apply. It is recommended to have the changes to the Schema in a separate patch, because it's likely to conflict a lot. This way one can opt to not apply the patch and run the schema update locally when testing or pushing and you don't have to rebase as often.
https://wiki.koha-community.org/wiki/Database_updates#Changes_with_DBIx::Class
Comment 8 Katrin Fischer 2017-05-01 15:34:59 UTC
Ok... partially talking nonsense. It DOES currently apply!
Comment 9 Katrin Fischer 2017-05-01 15:54:55 UTC
Really like the feature! Maybe we should add something like this to staff too?

Possible problems:
- Instead of tabs have a simple pull down to switch the recipient. At the moment, if you have typed up your message and then change your mind about whom to send it to, you have to start over as the text won't carry over from one tab to the other.
- When submitting a problem report to the aministrator and there is no branch email supplied, the 'success' message and the 'error' message will both show at the same time after submitting. This might be confusing to the patron. Maybe we could avoid that by showing the 'error' next to the submit button or if we didn't have the tabs, not show the option to email the library at all, when there is no email address set for the branch?
- There are some constraints with email sending if you are hosted and using the provider's mail server. So a while ago we have added branchreplyto (branches) and ReplyToDefault (system preference). It would be cool if you could check those first and email there if they are set and then fall back to branchemal and KohaAdminEmailAddress (like it's done for overdues etc.)
- If you are not logged in when clicking on 'report a bug' the problem will be reported against the opac-reportproblem page.

Questions:
- I know that the feature can be hidden using the id (thx!), but maybe this should also be a preference? 
- How will the table in the database be maintained? Is there a way to empty it or plans to make it accessible from the GUI?
Comment 10 Aleisha Amohia 2017-08-11 05:15:32 UTC Comment hidden (obsolete)
Comment 11 Aleisha Amohia 2017-08-20 22:16:47 UTC Comment hidden (obsolete)
Comment 12 Aleisha Amohia 2017-08-20 22:17:07 UTC
Forgot to change status - this is ready to test
Comment 13 Josef Moravec 2017-08-22 11:50:38 UTC
Created attachment 66323 [details] [review]
[SIGNED-OFF] Bug 4461: Add a context-sensitive 'Report a Problem' feature to OPAC

This patch adds a 'Report a problem' link to the bottom of every page in
the OPAC. The user can choose to submit their report to the library or
Koha administrator. The report will store the user's problem message,
but also their username and the page they were on when they clicked the
'report a problem' link. The patch adds a table 'problem_reports' to the
db.

Update: This patch adds a check for the KohaAdminEmailAddress and
library branch email before sending the report.
Update: Fix merge conflicts

To test:
1) Apply patch, update database, rebuild schema
2) Restart koha-common and memcached
3) Confirm that your user has an email address.
4) Confirm that your library does NOT have an email address.
5) Confirm that your syspref KohaAdminEmailAddress is NOT filled.
6) Log into OPAC
7) Click the 'Report a problem' link at the bottom of whatever page
you're on
8) Notice that there are error messages alerting that library does not
have an email address and that the Koha Administrator does not have
email address. Both submit buttons will be disabled.
9) Add an email address for your library. You may have to restart
memcached again. The error message for the library email address will
have disappeared and the Submit button for 'Report to library' will now
work.
10) Add an email address for the syspref KohaAdminEmailAddress. You may
have to restart memcached again. The error message for the administrator
email address will have disappeared and the Submit button for 'Report to
Koha Administrator' will not work.
11) First try submitting a problem to the library. Confirm that the
fields for 'Problem found on page' and 'Username' are correct, then fill
out the 'Subject' and 'Message' and click Submit.
12) Confirm a message shows at the top of the page to show success.
13) Go into mysql and display records from the message_queue table.
Confirm that the borrowernumber and subject are correct. Confirm that
content shows the message from the problem report, but also the user's
username and the problem page. Confirm that the to_address shows the
library's email address and the from_address shows the user's email
address.
14) Now try submitting a problem to the Koha Admin. Fill fields and
click Submit. Confirm message shows at top to show success again.
15) Check message_queue for new problem report. Confirm that the
to_address shows the email address from the syspref
KohaAdminEmailAddress.

Sponsored-by: Catalyst IT

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Comment 14 Josef Moravec 2017-08-22 11:50:41 UTC
Created attachment 66324 [details] [review]
[SIGNED-OFF] Bug 4461: [FOLLOW-UP] Problem Report feature

This patch:
 - uses a pull down menu to switch the recipient instead of tabs
 - if the library has no email or the administrator has no email, this
 error message has been moved to be down by the Submit button
 - includes use of branchreplyto and ReplytoDefault for branch email
 - disables use of the feature if the user is not logged in
 - adds a syspref to hide or show the feature
 - provides support for if JS is disabled

Additional testing:
 - using the message_queue table, check that the correct recipient
 receives a problem report when switching in the drop down menu
 - check appropriate error message shows next to the submit button if an
 email is not provided. this should dynamically change as you select a
 different recipient from the drop down menu
 - check that when the library is the recipient, the feature sends the
 report to the branchreplyto, then the ReplytoDefault, then the branch
 email in that priority order
 - log out of the OPAC and confirm that you can't submit a report
 without logging in. the submit button should be disabled
 - disable the OPACReportProblem syspref. the Report a Problem link in
 the footer should be gone. if you force the URL
 (/cgi-bin/koha/opac-reportproblem.pl) the form should be hidden and
 replaced with an error message.
 - disable JS in your browser. confirm that you are still able to send
 problem reports to library and administrator. remove the administrator
 email address. confirm the error message shows next to the submit
 button and that clicking the submit button returns an error. check in
 the message_queue that the email was never sent.

After this feature is passed:
 - i would like to add a staff-side feature where staff can see the
 problem reports and mark them as 'read'. i'll work on that once this
 gets through :)

Signed-off-by: Josef Moravec <josef.moravec@gmail.com>
Comment 15 Josef Moravec 2017-08-22 11:52:13 UTC
(In reply to Aleisha Amohia from comment #11)

> After this feature is passed:
>  - i would like to add a staff-side feature where staff can see the
>  problem reports and mark them as 'read'. i'll work on that once this
>  gets through :)

Great idea, I am really looking forward to ;)
Comment 16 Barton Chittenden 2017-09-01 15:54:59 UTC
This is a *bit* off topic, but I've been working on a plugin that fills a similar niche on the staff side: https://github.com/bywatersolutions/koha-plugin-support
Comment 17 Nick Clemens 2017-10-26 11:48:08 UTC
Hi Aleisha,

1 - Need tests for new Objects

2 - With 'DefaultReplyTo' unset it is still 'defined' so I get the library email option even when none are set.

3 - If not logged in I still see the report form, I think I should just get the warning to log in.

3 - Similarly, if both emails are undefined maybe I shouldn't get the form at all since I can't submit?

4 - Rather than a JS function to disable the submit button can we just disable the input on the dropdown and add a tooltip? Or only provide a dropdown if there is a choice possible? The warning about missing emails seems more appropriate for the about page than the users.

5 - The new preference is defaulting to 'Allow' it should default to 'Don't Allow'