Merge branch 'develop' into 11959-automate-solr-schema-updates

Author: poikilotherm

doc/release-notes/10490-COAR-Notify.md

@@ -0,0 +1,23 @@
+### Support for COAR Notify Relationship Announcement
+
+Dataverse now supports sending and receiving [Linked Data Notification ](https://www.w3.org/TR/ldn/) messages involved in the 
+[COAR Notify Relationship Announcement Workflow](https://coar-notify.net/catalogue/workflows/repository-relationship-repository/).
+
+Dataverse can send messages to configured repositories announcing that a dataset has a related publication (as defined in the dataset metadata). This may be done automatically upon publication or triggered manually by a superuser. The receiving repository may do anything with the message, with the default expectation being that the repository will create a backlink from the publication to the dataset (assuming the publication exists in the repository, admins agree the link makes sense, etc.)
+
+Conversely, Dataverse can receive notices from other configured repositories announcing relationships between their publications and datasets. If the referenced dataset exists in the Dataverse instance, a notification will be sent to users who can publish the dataset, or, optionally, only superusers who can publish the dataset. They can then decide whether to create a backlink to the publication in the dataset metadata.
+
+(Earlier releases of Dataverse had experimental support in this area that was based on message formats defined prior to finalization of the COAR Notify specification for relationship announcements.)
+
+#### New Settings/JVM Options
+
+Configuration for sending messages involves specifying the
+:COARNotifyRelationshipAnnouncementTargets and :COARNotifyRelationshipAnnouncementTriggerFields
+
+Configuration to receive messages involves specifying
+DATAVERSE_LDN_ALLOWED_HOSTS (dataverse.ldn.allowed-hosts)
+
+Notifications are sent by default to users who can publish a dataset. The option below can be used to restrict notifications to superusers who can publish the dataset.
+ 
+DATAVERSE_COAR_NOTIFY_RELATIONSHIP_ANNOUNCEMENT_NOTIFY_SUPERSUSERS_ONLY
+

doc/release-notes/11522-licenses-added.md

@@ -0,0 +1,17 @@
+### Additional licenses
+
+The following Open Data Commons licenses have been added:
+
+- Open Database License (ODbL)
+- Open Data Commons Attribution License (ODC-By)
+- Open Data Commons Public Domain Dedication and License (PDDL))
+
+The following software license has been added:
+
+- European Union Public License (EUPL)
+
+The following country-specific license has been added:
+
+- Open Government Licence (OGL UK)
+
+The licenses above are widely recognized and used in Europe and beyond to promote data and software sharing. See [the guides](https://dataverse-guide--11522.org.readthedocs.build/en/11522/installation/config.html#configuring-licenses) and #11522.

doc/release-notes/11639-db-opts-idempotency.md

@@ -43,3 +43,13 @@ The following database settings are were added to the official list within the c
 - `:LDNAnnounceRequiredFields`
 - `:LDNTarget`
 - `:WorkflowsAdminIpWhitelist` - formerly `WorkflowsAdmin#IP_WHITELIST_KEY`
+- `:PrePublishDatasetWorkflowId` - formerly `WorkflowServiceBean.WorkflowId:PrePublishDataset`
+- `:PostPublishDatasetWorkflowId` - formerly `WorkflowServiceBean.WorkflowId:PostPublishDataset`
+
+### Important Considerations During Upgrade Of Your Installation
+
+1. Running a customized fork? Make sure to add any custom settings to the SettingsServiceBean.Key enum before deploying!
+2. Any database settings not contained in the `SettingServiceBean.Key` will be removed from your database during each deployment cycle.
+3. As always when upgrading, make sure to backup your database beforehand!
+   You can also use the existing API endpoint `/api/admin/settings` to retrieve all settings as JSONish data for a quick backup before upgrading.
+

doc/release-notes/11695-11940-change-api-get-storage-driver.md

@@ -0,0 +1,12 @@
+## Get Dataset/Dataverse Storage Driver API
+
+### Changed Json response - breaking change!
+
+The API for getting the Storage Driver info has been changed/extended.
+/api/datasets/{identifier}/storageDriver
+/api/admin/dataverse/{dataverse-alias}/storageDriver
+Rather than returning just the name/id of the driver (with the key "message"), the api call now returns a JSONObject with the driver's "name", "type" and "label", and booleans indicating whether the driver has "directUpload", "directDownload", and/or "uploadOutOfBand" enabled.
+
+This change also affects the /api/admin/dataverse/{dataverse-alias}/storageDriver api call. In addition, this call now supports an optional ?getEffective=true to find the effective storageDriver (the driver that will be used for new datasets in the collection)
+
+See also [the guides](https://dataverse-guide--11664.org.readthedocs.build/en/11664/api/native-api.html#configure-a-dataset-to-store-all-new-files-in-a-specific-file-store), #11695, and #11664.

doc/release-notes/11695-change-api-get-storage-driver.md

@@ -0,0 +1,21 @@
+## Notifications API Update
+
+**Endpoint:** `notifications/all`
+
+**Enhancements:**
+
+* When the query parameter `inAppNotificationFormat=true` is set:
+
+    * Notifications of types:
+
+        * `REQUESTFILEACCESS`
+        * `REQUESTEDFILEACCESS`
+        * `GRANTFILEACCESS`
+        * `REJECTFILEACCESS`
+
+  now return both the **dataset display name** and **dataset persistent identifier**.
+
+    * Notifications of type `DATASETMENTIONED` now return a **formatted JSON** in the `additionalInfo` field when this field contains a valid persisted JSON string, instead of a raw JSON string.
+
+Related issue: #11804
+Related PR: #11851

doc/release-notes/11804-notifications-api-updates.md

@@ -0,0 +1,16 @@
+The recommended Payara version has been updated to Payara-6.2025.10
+
+Payara 6.2025.10 cannot be used with earlier versions of Dataverse, e.g. v6.8.
+
+Standard Payara upgrade instructions - as in the 6.7 release notes should be added, 
+but we should assure the instructions don't have you trying to run 6.8 with the latest Payara 
+and perhaps should explicitly note that you can't. 
+
+We should also change the 'standard' language related to Payara updates to include copying the
+*.p12 files from the distributed domain1/config directory into the Dataverse domain1/config directory,
+at least if/when they are different. Those files include base certs and over time using the old files
+can cause SSL errors. If the domain.xml file is old enough, it may also reference *.jks files instead
+of the *.p12 ones. That should also be fixed (domain.xml having those lines updated to reference *.p12 files).
+FWIW: I ran across this at TDL where a dev machine stopped being able to contact DataCite because the root
+cert used by DataCite today is not in the *.jks files that had been copied forward during Payara updates.)
+

doc/release-notes/11827-Payara-6.2025.10.md

@@ -0,0 +1 @@
+This release adds database indexes on GuestbookResponse and DatasetMetrtics, speeding up Dataset deletes. It also adds a constraint preventing null VersionState, as a matter of good housekeeping practice. 

doc/release-notes/11828-unacceptable-performance-deleting-datasets.md

@@ -0,0 +1,3 @@
+### Big Data Admin Section
+
+- A new section - Scaling Dataverse with Data Size - has been added to the Admin Guide. It is intended to help administrators configure Dataverse appropriately to handle larger amounts of data.

doc/release-notes/11850-big-data-admin-guide.md

@@ -0,0 +1,72 @@
+## Notifications API Update
+
+**Endpoint:** `notifications/all`
+
+The user notifications endpoint has been enhanced with new optional query parameters to allow for more specific and
+efficient data retrieval.
+
+**1. Filter by Unread Status**
+
+You can now fetch only unread notifications by using the `onlyUnread` boolean parameter.
+
+* **`onlyUnread`**: (Optional, boolean) When set to `true`, the API will only return notifications that the user has not
+  yet marked as read.
+
+**Example:**
+
+```bash
+curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all?onlyUnread=true"
+```
+
+**2. Pagination Support**
+
+Pagination is now supported through the limit and offset parameters, allowing you to retrieve notifications in smaller,
+manageable chunks.
+
+- **`limit`**: (Optional, integer) Specifies the maximum number of notifications to return.
+
+- **`offset`**: (Optional, integer) Specifies the number of notifications to skip before starting to return results.
+
+Example (Retrieve notifications 11 through 20):
+
+```bash
+curl -H "X-Dataverse-key:$API_TOKEN" "$SERVER_URL/api/notifications/all?limit=10&offset=10"
+```
+
+**3 Breaking Change: API Response Format Updated**
+
+To support pagination and improve consistency across the API, the JSON response format for this endpoint has been
+changed. This is a breaking change and will require updates to any client code currently using this endpoint.
+
+**Old Format:**
+
+Previously, the response nested the notification list inside a notifications object within the data field.
+
+```
+{
+  "status": "OK",
+  "data": {
+    "notifications": [
+      / ... /
+    ]
+  }
+}
+```
+
+**New Format:**
+
+The response now includes a top-level totalCount field (required for pagination) and places the notification list
+directly in the data field. This flattens the structure and makes it consistent with other paginated endpoints.
+
+```
+{
+  "status": "OK",
+  "totalCount": 2,
+  "data": [
+    / ... /  
+  ]
+}
+```
+
+Related issue: #11852
+Related PR: #11854