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

Author: qqmyers

.github/workflows/deploy_beta_testing.yml

@@ -36,7 +36,7 @@ jobs:
         run: echo "war_file=$(ls *.war | head -1)">> $GITHUB_ENV
 
       - name: Upload war artifact
-        uses: actions/upload-artifact@v4
+        uses: actions/upload-artifact@v5
         with:
           name: built-app
           path: ./target/${{ env.war_file }}
@@ -50,7 +50,7 @@ jobs:
       - uses: actions/checkout@v5
 
       - name: Download war artifact
-        uses: actions/download-artifact@v5
+        uses: actions/download-artifact@v6
         with:
           name: built-app
           path: ./
@@ -69,7 +69,7 @@ jobs:
           overwrite: true
 
       - name: Execute payara war deployment remotely
-        uses: appleboy/[email protected].2
+        uses: appleboy/[email protected].3
         env:
           INPUT_WAR_FILE: ${{ env.war_file }}
         with:

.github/workflows/maven_unit_test.yml

@@ -62,7 +62,7 @@ jobs:
 
           # Upload the built war file. For download, it will be wrapped in a ZIP by GitHub.
           # See also https://github.com/actions/upload-artifact#zipped-artifact-downloads
-          - uses: actions/upload-artifact@v4
+          - uses: actions/upload-artifact@v5
             with:
                 name: dataverse-java${{ matrix.jdk }}.war
                 path: target/dataverse*.war
@@ -72,7 +72,7 @@ jobs:
           - run: |
                 tar -cvf java-builddir.tar target
                 tar -cvf java-m2-selection.tar ~/.m2/repository/io/gdcc/dataverse-*
-          - uses: actions/upload-artifact@v4
+          - uses: actions/upload-artifact@v5
             with:
                 name: java-artifacts
                 path: |
@@ -112,7 +112,7 @@ jobs:
                   cache: maven
 
             # Get the build output from the unit test job
-            - uses: actions/download-artifact@v5
+            - uses: actions/download-artifact@v6
               with:
                   name: java-artifacts
             - run: |
@@ -124,7 +124,7 @@ jobs:
 
             # Wrap up and send to coverage job
             - run: tar -cvf java-reportdir.tar target/site
-            - uses: actions/upload-artifact@v4
+            - uses: actions/upload-artifact@v5
               with:
                   name: java-reportdir
                   path: java-reportdir.tar
@@ -145,7 +145,7 @@ jobs:
                 cache: maven
 
           # Get the build output from the integration test job
-          - uses: actions/download-artifact@v5
+          - uses: actions/download-artifact@v6
             with:
                 name: java-reportdir
           - run: tar -xvf java-reportdir.tar

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/11639-db-opts-idempotency.md

@@ -0,0 +1,45 @@
+## 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`

doc/release-notes/11744-cors-echo-origin-vary.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/11771-update-dataset-license-api.md

@@ -0,0 +1,13 @@
+## New Endpoint: `/datasets/{id}/license`
+
+A new endpoint has been implemented to manage dataset licenses.
+
+### Functionality
+- Updates the license of a dataset by applying it to the draft version.
+- If no draft exists, a new one is automatically created.
+
+### Usage
+This endpoint supports two ways of defining a license:
+1. **Predefined License** – Provide the license name (e.g., `CC BY 4.0`).
+2. **Custom Terms of Use and Access** – Provide a JSON body with the `customTerms` object.
+    - All fields are optional **except** `termsOfUse`, which is required.

doc/release-notes/11804-notifications-api-updates.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/11828-unacceptable-performance-deleting-datasets.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/11832-DataCite-scaling.md

@@ -0,0 +1,14 @@
+This release adds functionality to retry calls to DataCite when their server is overloaded or Dataverse has hit their rate limit.
+
+It also introduces an option to only update DataCite metadata after checking to see if the current DataCite information is out of date.
+(This adds a request to get information from DataCite before any potential write of new information which will be more efficient when 
+most DOIs have not changed but will result in an extra call to get info when a DOI has changed.)
+  
+Both of these can help when DataCite is being used heavily, e.g. creating and publishing datasets with many datafiles and using file DOIs,
+or doing bulk operations that involve DataCite with many datasets.
+
+### New Settings
+
+- dataverse.feature.only-update-datacite-when-needed 
+
+The default is false - Dataverse will not check to see if DataCite's information is out of date before sending an update.

doc/release-notes/11850-big-data-admin-guide.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.