Improve UX of crashed Notifications

[ds-jleyh]

As ...
I want ...
so that ...

Hints / Details

The problem:
A notification was previously created and is now "approved" by a supervisor.
Now this notification should be sent to the EDC.
The backend does not represent that status if EDC is down or responds with an error.
The notification displays the success but the status will stay as it is -> From queued to queued.
From technical perspective this is correct, but the user needs a clear notification what happened.

Possible improvements:

1. Display appropriate error handling.
2. If EDC is down update the status to "sending..."
3. Retry a couple of times automatically
   a. Update status to "failed to send" if notification is not sent
4. Provide "Retry" or standard "approve" and "cancel" options for "failed to send" notification
5. Provide detailed information on detail paged why the notification was not sent
6. If a webhook is already in place, inform the user that the notification was not sent

Acceptance Criteria

[x] Backend has been adapted to reflect if the notification status could be transfered to the next status.
[x] Frontend displays a success if the notification could be transfered
[x] Frontend displays a error and asks for retry of the user.

Out of Scope

• ...

[jzbmw]

https://jira.catena-x.net/browse/TRACEFOSS-924

[mkanal]

Hey @ds-crehm this might be a topic for you?

[ds-mmaul]

Implemented change that when there is an error in the creation of a notification, the error message from BE and a try again button is displayed:

By clicking on the try again button, the creation of the notification gets executed again.

This means, the FE is expecting an error with an appropiate message from the Backend. Currently the message is pulled from the Http response field 'error' which contains the string error message. BE needs to implement the error message in the response and with that the issue is done

[ds-mwesener]

Hi @ds-crehm feature has been installed on e2e environments. Testing can be done by sending an alert with an part which owns the company and using the bpn of the other company.
Example:

1. Opening e2e-a
2. Open parts
3. Select part
4. Start alert
5. Use bpn: BPNL00000003CNKC which is e2e-b
6. Create alert
7. Go to created alerts
8. Approve alert
   Expected behaviour: Error message comes up with a retry button.

Repeat the steps in a successful scneario and you will see a success info.

[ds-crehm]

Test successful (tested on E2E-A):

• Alert stays in status "QUEUED"
• Clicking on "Try again" brings back the approval window.
• Clicking on "X" closes the popup
• Popup disappears after a couple of seconds
• (Successful scenario still working)

Notes:

• Error message was not very detailed in my test case.
• The parts where I can hover/click are not accurate:
  
  I can hover and click in the entire left area to highlight and activate the "Try again"-button. But the cursor only changes within the actual "Try again"-button.
  For the "X" anywhere on the right area can be clicked to close the notification.

[ds-mmaul]

Hi @ds-crehm ,

issue is fixed and merged with catenax-ng#1041. Ready to recheck, thanks!

[ds-crehm]

Tested again. Now the hoverable/clickable areas are accurate.