Missing information while editing beacons causes cryptic error message

[Piiit]

We should avoid "alert(...)" here. This is not about hiding errors, which are important to show, but the workflow of an webapp user should not be interrupted with modal dialogs, nor have such cryptic information. Maybe we should give an error as HTML element, and provide these information just in our logs.

See screenshot:

It happens when an incomplete beacon detail gets saved.

[noctho]

Sure. I'll try to find another way to show that an error has occurred.

The problem with this particular form is that there is no client side input validation implemented. The only way to give the user an information which inpult fields are invalid is to show the server's error message. Otherwise i can only display a general error message. To give a optionally detailed information, I could hide this information by default and make it collapsible.

I can only display a personalized message for the two cases where I have defined custom error message.

[noctho]

I replaced all "alert()" with HTML elements to give an error message. See #68

[Piiit]

Tested, and it works, but the feedback of missing values is limited to jsut saying that it did not work, not what is exactly missing. We should give visual feedback or at least write what is missing. In our test it was the UUID that was missing

[davidebz]

Hello Peter,

unfortunately the original version of the application looked like this: in case of an error, it displayed a generic error message. All the new functions we have added contain more specific error messages. For the pre-existing ones, however, there is no switch to activate them in block, we have to fix the code field by field.

This is because if I remember often the error messages are generated automatically by java annotations in the API which however do not contain descriptive text for the user or the resulting text is not suitable for human.

Moreover we would have to decide whether the validation and the related user frendly messages will we put on the API side (so only after sending the form) and / or use a client side validation (so after the modification of each field).

Fixing all missing pre-existing error messages I see a very large unexpected job.

What we can make ourselves available in is still discussing a possible architecture to add error messages for example by implementing it for a couple of fields (perhaps the most critical like uuid).

[noctho]

As a quick solution, I could extract the involved input fields from the error message and list them. A full client-side validation is not possible in the short time remaining.

[Piiit]

That would already be something useful, thanks. I understand that we are too close to put in many new features... Just write something that states:

• It was an error on API side / server response
• The input sent to the server was wrong or had missing information
• These are the fields involved (<-- nice to have part)

Thanks

[noctho]

Ok I implemented it but there are some limitations. If the request body cannot be parsed (an HttpMessageNotReadableException occurs), only one of the involved fields is displayed. For instance, if an integer value was expected and the passed value contains some non-numeric characters. The complete list is only displayed if some fields are empty or if some values are not in the correct range and no .

[Piiit]

We decided that the regular users see only one Jitsi Server... so we show only a single entry with a name, and if we are logged in with rights to access the internal Jitsi server, we show both servers, the first as is with two different names. We still need to ask Elisa which names to use. In the meantime we should just implement the rights and different choices.... I will add an attribute to keycloak for that, called "VirtualVillageManagerNOI".

[Piiit]

Last comment should have been inside issue #42