Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Common Error and Warning Interface #250

Open
rekt-hard opened this issue Aug 29, 2024 · 0 comments
Open

Common Error and Warning Interface #250

rekt-hard opened this issue Aug 29, 2024 · 0 comments
Assignees
Labels
Maintenance Master/Epic Container for multiple sub issues

Comments

@rekt-hard
Copy link
Collaborator

Description
A common error interface to be used for responses from the back end. This will allow to gather errors during a request and provide them in a common response format.

Proposed solution
During a request, there might be several error possibilities due to business logic.

As an example, validating request data may raise several errors. Each provided field may have certain validation rules. All of them can be reported in a single response. Other examples are trying to retrieve an entity which does not exist, or not having the appropriate permissions.

Streamlining how errors are reported also provides benefits for the front end. When a request fails, it is easy to parse the response and show a common error element with the provided message. Right now, the messages are defined in the front end, which might not know what exactly went wrong. This can be frustrating for users as there is no explanation or which actions to take in order to fix an issue.

E.g.: When updating a DMP, there can be several validation issues. Simply showing The DMP could not be updated is not very helpful. Showing an explicit message like The project title can not be empty provides a clear description.

Additionally, there might not be any validation errors but simply warnings about certain issues. It could make sense to provide a message like No contact person has been specified. While it is not necessary to set a contact person, it is a good idea to specify it due to the impact it has on the export.

Alternative solution

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Maintenance Master/Epic Container for multiple sub issues
Projects
None yet
Development

When branches are created from issues, their pull requests are automatically linked.

3 participants