Notifications API extension and new notifications generated by API operations

[GPortas]

What this PR does / why we need it:

Includes the following changes:

getAllNotificationsForUser API extension

• Extended endpoint getAllNotificationsForUser(/notifications/all), which now supports an optional query parameter inAppNotificationFormat which, if sent as true, retrieves the fields needed to build the in-app notifications for the Notifications section of the Dataverse UI, omitting fields related to email notifications.

Notifications triggered by API endpoints

The addDataset and addDataverse API endpoints now trigger user notifications upon successful execution.

Related issue: #1342

Which issue(s) this PR closes:

• Closes Notifications API: remove hard-coded dataset urls from message text #11648

Special notes for your reviewer:

The new fields returned by the new inAppNotificationFormat flag are based on the fields required by JSF to compose the notifications on the user page.

Suggestions on how to test this:

1. Creating an account, dataverses, and datasets—these operations should generate notifications that you can then query using the API endpoint.

2. Test calling the endpoint with the new query parameter and without it, to see the differencies.

Retrieving notifications for In-App:

curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all?inAppNotificationFormat=true"

Retrieving notifications as before:

curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all"

❗❗

For dataset creation to trigger a notification, the SendNotificationOnDatasetCreation setting must first be enabled (set to true). This behavior already existed in Dataverse, but previously only curators would receive a notification when the setting was true. Now, the author also receives a notification if the setting is true and the dataset is created through the API.

I am open to removing the setting to avoid requiring an additional step of enabling it in installations that use the SPA. However, I have decided to keep it for backward compatibility.

❗❗

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

No

Is there a release notes update needed for this change?:

Yes, find attached

Additional documentation:

Preview at https://dataverse-guide--11696.org.readthedocs.build/en/11696/api/native-api.html#get-all-notifications-by-user

[coveralls]

coverage: 23.312% (+0.1%) from 23.199%
when pulling 877e428 on 11648-notifications-api-extension
into 8592e63 on develop.

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:11648-notifications-api-extension

ghcr.io/gdcc/configbaker:11648-notifications-api-extension

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.

[pdurbin]

Thanks for addresses all my comments! Also, tests are passing: https://jenkins.dataverse.org/job/IQSS-Dataverse-Develop-PR/job/PR-11696/45/testReport/

Approved!

[ofahimIQSS]

Looks good to me, merging.