Display general backend problems

[bernhardreiter]

There are several different kind of problems with calling the fody-backend:

1. network problems
2. backend trouble (aka 500)
3. problems with a user request (often 400 or unauth)

While #29 is more specific to commit problems (with is the third class of issues), there also should be a method to display general problems in all section of the backend to the user.

technical ideas:

Use the notification style in the navigation bar of the copilot template?

Or display it closer to the the place where the user is looking (in case of contacts this would be either the search field like the results limitation or close to the commit button).

[bernhardreiter]

Technical considerations

If there is a backend problem it should be visible without scrolling. Right now there is no area that is visible all times. So we have two possible solutions:

1. create a general area that is visible in the general case (e.g. by an upcoming toaster ui element)
2. or do it individually depending for which element the request is

1. general place

Right now there already is a general place which is a working animation if an API call takes too long. This is done in the upper menu bar. This could be a good default place.

2. close to individual elements

A grep '$http' -r shows all places where the vue-resource function is called. We have 15 places. Some of them are close enough together be use one display element for their joined status messages.

[bernhardreiter]

9f23e5678ba42fd2b99ad4541e847d4b372f33e9 adds a general backendProblem display area in the navigation bar as proof of concept. The problem with this is, when it should be cleared, if we have several request on a subpage.

[bernhardreiter]

If we have several requests possibilities per page, the general place solution would only work, if we'd track the status for each possible connection for the display. This can have advantages if it is three times the same problem, but it is close to introducing a global state of the backend, which is even more work.

So I'll try the "2. close to individual elements" solution next.

[bernhardreiter]

technical notes

To create some error messages from the backend for testing:

• stop the 'yarn serv' -> status code 0
• stop the fody-backend -> 502 gateway error
• add a syntax error in the fody-backend endpoint function -> 500
• too see the loading, add an import time, time.sleep(10) or so to the endpoint
• add an additional parameter to the function endpoint which is not supplied e.g. no: int -> 400 from hug
• other client error needs setting of the status code, e.g. from falcon import HTTP_BAD_REQUEST, HTTP_NOT_FOUND, getting the response from the endpoint function definition and then response.status = HTTP_BAD_REQUEST; return {"reason": "DataError, probably not in cidr style."}, see https://falcon.readthedocs.io/en/stable/api/status.html
• for an invalid json from the client, get the response object from the endpoint function and then response.body = '{abc' ; return

[bernhardreiter]

Here is can be seen that the reason for a backend call failure is shown for tickets.

And if no events for a ticket are found, this is different now:

[bernhardreiter]

Status with work from last week committed now.

• [x] Dashboard (3 info boxes)
• [x] Tickets (3 places)
• [ ] Statistics (3 places)
• [ ] Contacts (4 places)

[bernhardreiter]

• [x] Statistics (3 places)

[bernhardreiter]

• [x] Statistics (3 places)
• [x] Contacts (4 places)

Some illustrating screenshots

(Note the backend does not (yet) give more information in this commit case.)