Report error message if json.error is defined

[rouilj]

When searching the nosy list popup using roles, it will return status 403 and an error json message
if the user is not an admin.

By default roles requires admin rights. In this specific case, the json is:

{
    "error": {
        "status": 403,
        "msg": "User does not have search permission on \"user.roles\""
    }
}

Change classhelper.js to report the error message to the console.

The following diff does the trick:

@@ -1014,6 +1027,10 @@ class ClassHelper extends HTMLElement {
             throw new Error("error parsing json from roundup rest api");
         }
 
+        if (json.error) {
+           throw new Error(`Search error: ${json.error.msg}`)
+        }
+      
         const data = json.data;
         const links = json.data["@links"];

I could report the status as well.

I'm not sure if I can add a message to the user to the error. Maybe something like:

err  = new Error(`Search error: ${json.error.msg}`)
err.userMessage = `The error message said: ${json.error.msg}`
throw err

Then the top level error handler that generates the popup could see if there is a userMessage and add
it to the popup.

Not sure if notifying the user in the popup is worthwhile unless the user can use that info.
In this case, the user would submit a new search without using a Role.

However an error triggers fallback to the classic classhelper.

The same query using the classic classhelper returns a search result after removing properties that the
user doesn't have access to. So searching only with roles=user roles=admin roles=anything show all
users.

[malvpatel]

PR - #62

@rouilj A simple solution to this right now is to show an alert in the popup window itself when the "user" tries to search on roles and is forbidden from doing so.

This can be seen by the user, now its understandable that he cannot perform search on roles.

resetting the select back to default will be a bit complex as it will require me to parse the message and get the "user.roles" and split this again into just roles (identifying the field causing the issue)

[rouilj]

Hi Malav:

TL;DR I think the simple solution is the way to go. Display the REST error to the user, tell
them you will trigger the fallback classhelper. Do not try parsing the message or resetting
anything.

You said:

resetting the select back to default will be a bit complex as it will require me to parse the message and get the "user.roles" and split this again into just roles (identifying the field causing the issue)

What do you mean by: "resetting the select back to default". Do you mean:

1 emptying the roles input
2 preventing roundup-classhelper from invoking the fallback classhelper

I assume you mean option 1. If roundup-classhelper triggers the fallback classhelper on error,
then there is nothing to empty as the popup from roundup-classhelper is closed. Option 2
would be needed for you to do option 1. See below for option 2 issues.

At this point I am not sure we know enough to determine what roundup-classhelper should do
to recover from this. I am ok with displaying the error returned from the REST endpoint to the user.
The user can handle reset option 1 by choosing '--'. As/If we get more feedback
roundup-classhelper can do something different.

What concerns me about reset option 2 is getting the user into a failure loop where
roundup-classhelper never invokes the fallback option. If roundup-classhelper believes:

• the 400 error is due to user failure (as opposed to an admin issue)
• the user has the information to fix the error (assuming REST errors are meaningful to the user)
• the user can fix the error. This assumes the user understands what the REST error means and
  how to apply the info. It also means that they can select a different option, probably true but
  we have not tested every client side browser/environment/browser plugin ....

If any of those is not true, the user is stuck in roundup-classhelper and has no way
to use the fallback classhelper that might not have the same issue.
Again I am not sure we have enough info (at this time) to know the correct response.

require me to parse the message
Parsing the error message that is supposed to be sent to a human is tricky. In theory the error
message can be translated to the user's native language. I do not recommend parsing the message.
It tightly couples roundup-classhelper to a specific string.

In another issue I mention adding a code for the error. For example see https://issues.roundup-tracker.org/issue2551237 and consider the type field. That could be useful as it would not
be translated and could include properties like a pre-parsed field name (roles) for use by the
REST interface consumer. This would be suitable to base reset or recovery code on.

[malvpatel]

Yea, the simple solution is the way to go second was just the after thought and it is not at all feasible

[rouilj]

This is working as shown in screenshot. Closing.