Merge remote-tracking branch 'IQSS/develop' into develop

Author: qqmyers

.github/workflows/deploy_beta_testing.yml

@@ -70,7 +70,7 @@ jobs:
           overwrite: true
 
       - name: Execute payara war deployment remotely
-        uses: appleboy/ssh-action@v1.2.2
+        uses: appleboy/ssh-action@v1.2.3
         env:
           INPUT_WAR_FILE: ${{ env.war_file }}
         with:

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

@@ -0,0 +1,55 @@
+## Database Settings Cleanup
+
+With this release, we remove some legacy specialties around Database Settings and provide better Admin API endpoints for them.
+
+Most important changes:
+
+1. Setting `BuiltinUsers.KEY` was renamed to `:BuiltinUsersKey`, aligned with our general naming pattern for options.
+2. Setting `WorkflowsAdmin#IP_WHITELIST_KEY` was renamed to `:WorkflowsAdminIpWhitelist`, aligned with our general naming pattern for options.
+3. Setting `:TabularIngestSizeLimit` no longer uses suffixes for formats and becomes a JSON-based setting instead.
+4. If set, all three settings will be migrated to their new form automatically for you (Flyway migration).
+5. You can no longer (accidentally) create or use arbitrary setting names or languages.
+   All Admin API endpoints for settings now validate setting names and languages for existence and compliance.
+
+As an administrator of a Dataverse instance, you can now make use of enhanced Bulk Operations on the Settings Admin API:
+
+1. Retrieving all settings as JSON via `GET /api/admin/settings` supports localized options now, too.
+2. You can replace all existing settings in an idempotent way sending JSON to `PUT /api/admin/settings`.
+   This will create, update and remove settings as necessary in one atomic operation.  
+   The new endpoint is especially useful to admins using GitOps or other automations.
+   It allows control over all Database Settings from a single source without risking an undefined state.
+
+Note: Despite the validation of setting names and languages, the content of any database setting is still not being validated when using the Settings Admin API!
+
+### Updated Database Settings
+
+The following database settings are were added to the official list within the code (to remain valid with the settings cleanup mentioned above):
+
+- `:BagGeneratorThreads`
+- `:BagItHandlerEnabled`
+- `:BagItLocalPath`
+- `:BagValidatorJobPoolSize`
+- `:BagValidatorJobWaitInterval`
+- `:BagValidatorMaxErrors`
+- `:BuiltinUsersKey` - formerly `BuiltinUsers.KEY`
+- `:CreateDataFilesMaxErrorsToDisplay`
+- `:DRSArchiverConfig` - a Harvard-specific setting
+- `:DuraCloudContext`
+- `:DuraCloudHost`
+- `:DuraCloudPort`
+- `:FileCategories`
+- `:GoogleCloudBucket`
+- `:GoogleCloudProject`
+- `: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,41 @@
+# 11744: CORS handling improvements
+
+Modernizes CORS so browser integrations (previewers, external tools, JS clients) work correctly with multiple origins and proper caching.
+
+## Highlights
+
+- Echoes the request origin (`Access-Control-Allow-Origin`) when it matches `dataverse.cors.origin`.
+- Adds `Vary: Origin` for per-origin responses (not for wildcard).
+- Supports comma‑separated origin list; any `*` in the list = wildcard mode.
+- CORS now only enabled when `dataverse.cors.origin` is set (removed `:AllowCors` no longer enables it).
+- All comma-separated configuration settings (database properties and MicroProfile config) now ignore spaces around commas; tokens remain unchanged (no quote parsing). Examples: `dataverse.cors.methods`, `dataverse.cors.headers.allow`, `dataverse.cors.headers.expose`. See "Comma-separated configuration values" in the Installation Guide.
+- Docs updated (Installation, Big Data Support, External Tools, File Previews); new tests cover edge cases.
+
+## Admin Action
+
+Set `dataverse.cors.origin` explicitly (required). Use explicit origins (not `*`) for credentialed requests. Ensure proxies keep `Vary: Origin`.
+
+Examples:
+
+```
+dataverse.cors.origin=https://example.org
+dataverse.cors.origin=https://libis.github.io,https://gdcc.github.io
+dataverse.cors.origin=*
+```
+
+Optional (unquoted):
+
+```
+dataverse.cors.methods=GET, POST, OPTIONS, PUT, DELETE
+```
+
+## Compatibility
+
+- Must configure `dataverse.cors.origin`; `:AllowCors` was deprecated and has now been removed.
+- Any `*` triggers wildcard (no per-origin echo / no Vary header).
+
+## Docs
+
+See updated `dataverse.cors.origin` section and related notes in Big Data Support (S3), External Tools, and File Previews.
+
+<!-- Maintainer note: The generic behavior for comma-separated settings has been documented centrally under Installation Guide > Configuration > "Comma-separated configuration values". Keep this item here as a cross-reference. -->

doc/release-notes/11744-cors-echo-origin-vary.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.