Enhancement of Error Handling during API call

[MaximilianHauer]

Overview

Explain it in 2 sentences

Improve the Error Messages to support multiple languages, standardize the error handling, and standardize the presentation of error messages in the frontend.

What's the benefit ?

Misbehavior is better understood by the user and enables them to more easily solve their problems independently, resulting in a better user experience and reduced load on customer support.

What are the Risks/Dependencies ?

• No dependencies to other systems

Detailed explanation

Current Implementation

The current implementation of Error Handling provides a suboptimal user experience. Different methods are used to display errors, and in most cases, the reason for the error is not provided to the user. This lack of clarity hinders users from understanding the problem and resolving it independently.

This situation could lead to users contacting support more often, which creates unnecessary effort for the operations department.

Proposed Improvements

The user should receive a clear and understandable error message that explains the cause of the problem. This will enable the user to solve the issue themselves or at least provide better information to the support team to act on a solution.

By implementing these improvements, we can enhance the user experience by providing clear and understandable error messages, which will reduce the need for user support and empower users to solve issues independently.

To ensure multi-language support, the error messages should be displayed in the user's selected language.

Feature Team

Contributor

@oyo / @ntruchsess

Committer

@evegufy / @Phil91 / @oyo / @ntruchsess

User Stories

• sig#882 - Implement a Generic Error Handling Method in the Frontend portal-frontend#1166
• sig#882 - Define Languagefile for ErrorMessages portal-backend#1044
• sig#882 - Refine Backend Error Messages portal-backend#1045
• sig#882 - Identify Error Message Locations in the Frontend portal-frontend#1167
• sig#882 - Remove deprecated code portal-backend#1046

Acceptance Criteria

Note: We will provide the Acceptance Criteria on User Story Level

Testcases

Test Case 1: Display of Error Message in User's Selected Language
Description: Verify that the error message is displayed in the user's selected language when an error occurs.
Steps:

1. Log in to the application with valid credentials.
2. Set the preferred language to a non-default language (e.g., Spanish).
3. Perform an action that is known to trigger an error (e.g., input invalid data in a form).
4. Submit the form or complete the action to trigger the error handling mechanism.

Expected Results:
The error message should be displayed in the selected non-default language (Spanish in this case).
The error message should clearly state the reason for the error.
The user should be able to understand the error message without ambiguity.

Test Case 2: Clarity of Error Message for Form Validation
Description: Ensure that the error message for form validation is clear and provides the reason for the error.
Steps:

1. Log in to the application with valid credentials.
2. Navigate to a form within the application.
3. Fill out the form with invalid data (e.g., an incorrect email format).
4. Attempt to submit the form.

Expected Results:
An error message should be displayed near the field with the invalid data.
The error message should specify the exact reason why the data is invalid (e.g., "The email address is not in a valid format").
The user should be able to correct the error based on the information provided in the error message.

Test Case 3: Consistency of Error Display Methods
Description: Check the consistency of error display methods across different parts of the application.

Steps:

1. Log in to the application with valid credentials.
2. Trigger different types of errors by performing various actions (e.g., network error, form validation error, page not found).
3. Note the method of error display for each type of error (e.g., popup, inline message, dedicated error page).

Expected Results:
The method of displaying errors should be consistent across the application.
The user should not experience different methods of error display for similar types of errors.

Test Case 4: Error Message Accessibility
Description: Ensure that error messages are accessible to users with disabilities, such as those using screen readers.
Steps:

1. Log in to the application with valid credentials using a screen reader.
2. Perform actions that trigger errors.
3. Listen to how the screen reader announces the errors.

Expected Results:
The screen reader should clearly announce the error messages.
Users with visual impairments should be able to understand the error and its cause through the screen reader's announcement.

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

• This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
    • CX-0010 Business Partner Number
    • CX-0013 Identity of Member Companies
    • CX-0018 Data Space Connectivity (EDC)
    • CX-0049 DID Document Schema
    • CX-0050 Framework Agreement Credential
    • CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
    • CX-0001 EDC Discovery API
    • CX-0002 Digital Twins in Catena-X
    • CX-0018 Data Space Connectivity (EDC)
  • Data Format:
    • The data model is based on a published Semantic Model
• The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

Additional information

• I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

[MaximilianHauer]

frontend-registration needs to be included too

[Cofinity-UX]

Hi @MaximilianHauer
Prime React V9 provides the most usable component to combine snackbar/toast functionalities:
https://primereact.org/toast/