Cleanup - Notification Endpoints

[jjeroch]

Validation and explanation needed why we have 2 different "Create" notification endpoints:

[Phil91]

@jjeroch there should only be one endpoint to create credentials (for the ssi decline, approve and expiry use cases), the other one is to just update the read status of a notification

[jjeroch]

@Phil91 thanks.
I like to do an adjustment here - the endpoint is super specific for SSI Credentials.
I don't see a reason why we make it so specific.
We should apply an update to change the endpoint name

• Endpoint Path: /api/notification
• Method: POST
• Description: Allows externals to create per POST mechanism a notification creation inside the portal to display the notification to a customer.

Additional needed change: adjust the attribute requester to receiver
Please recheck the logic to set the creator user ID - it must be assured that the creator is always correctly set based on the technical user or company user which runs the endpoint.

#breakingChange #internalBreaking

[Phil91]

@MaximilianHauer @ntruchsess as discussed the create endpoint will stay as it is for the specific useCase of creating a notification for the credentials. We will adjust the role to be more specific from create_notifications to create_ssi_notifications