Graceful handling of dataTable errors

[jorge-leon]

Is your feature request related to a problem? Please describe.

Ticket lists are generated with dataTables via Ajax requests. When these fail a JavaScript alert pop up with a message like

DataTables warning: table id=ticketTable - Ajax error. For more information about this error, please see http://datatables.net/tn/7

is shown. For the end user, this is confusing.

Describe the solution you'd like

An error message should be shown to the end user, which indicates that the ticket data could not be loaded, and that it is
a system error, so that she knows whom to address for a solution.

Additionally the error condition should be logged.

Describe alternatives you've considered

Additional context

I stumbled over this in a test set up with uWSGI where the request size is by default limited to 4096 bytes. The datatables_ticket_list endpoint is called with a somewhat longer GET request. While this can be fixed and documented in the setup notes, there might be other issues preventing the Ajax call to succeed.

A quick and simple way to resolve this is by setting the dataTable errMode to a respective JavaScript function, like shown in the diff below.

--- a/helpdesk/templates/helpdesk/ticket_list.html
+++ b/helpdesk/templates/helpdesk/ticket_list.html
@@ -341,6 +341,9 @@
         
         $(document).ready(function () {
             // Ticket DataTable Initialization
+	    $.fn.dataTable.ext.errMode = function(settings, helpPage, message) {
+		alert("{% trans 'Error fetching tickets occured, the system administrators of this serv
er has been informed' %}")
+	    };
             $('#ticketTable').DataTable({
                 language: {
                     "emptyTable": "{% trans 'No Tickets Match Your Selection' %}"

With regard to logging: a lot of views in staff.py are prone to just "throw" their Exceptions into the server log. I suggest to cautiously wrap them into try - except blocks, log the exception, or whatever seems fit and return a HttpResponseServerError - or whatever seems fit.

Before working on a PR I'd like to get feedback.

[uhurusurfa]

This is a reasonable approach.
Note that you will also have to add an API route and handler on the server side to handle the post of the error messages generated by Javascript back to the server and persist them if you want a server log of these errors.

[jorge-leon]

This is a reasonable approach. Note that you will also have to add an API route and handler on the server side to handle the post of the error messages generated by Javascript back to the server and persist them if you want a server log of these errors.

I haven't considered this. Anyway, if the client side fails to complete a HTTP request in the first place it might not be able to succeed with a second one.

With regard to error logging I misled myself: Failed Ajax requests won't reach the server. Exeptions while returning a response from Django will surface during testing.