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

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/ssh-action@v1.2.2
+        uses: appleboy/ssh-action@v1.2.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/11612-RAHistory.md

@@ -0,0 +1,17 @@
+# Role Assignment History Tracking
+
+Dataverse can now track the history of role assignments, allowing administrators to see who assigned or revoked roles, when these actions occurred, and which roles were involved. This feature helps with auditing and understanding permission changes over time.
+
+## Key components of this feature:
+
+- **Feature Flag**: The functionality can be enabled/disabled via the `ROLE_ASSIGNMENT_HISTORY` feature flag (default is `off`)
+- **UI Integration**: New history panels on permission management pages showing the complete history of role assignments/revocations
+- **CSV Export**: Administrators can download the role assignment history for a given collection or dataset (or files in a dataset) as a CSV file directly from the new panels
+- **API Access**: New API endpoints provide access to role assignment history in both JSON and CSV formats:
+  - `/api/dataverses/{identifier}/assignments/history`
+  - `/api/datasets/{identifier}/assignments/history`
+  - `/api/datasets/{identifier}/files/assignments/history`
+  
+All return JSON by default but will return an internationalized CSV if an `Accept: text/csv` header is adde
+
+For more information, see #11612

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/11772-update-dataset-terms-of-access-api.md

@@ -0,0 +1,12 @@
+## New Endpoint: `/datasets/{id}/access`
+
+A new endpoint has been implemented to manage dataset terms of access for restricted files.
+
+### Functionality
+- Updates the terms of access for a dataset by applying it to the draft version.
+- If no draft exists, a new one is automatically created.
+
+### Usage
+
+**Custom Terms of Access** – Provide a JSON body with the `customTermsOfAccess` object.
+    - All fields are optional **except** if there are restricted files in which case `fileAccessRequest` must be set to true or  `termsOfAccess` must be provided.

doc/release-notes/11793 - ext. vocab. improvements.md

@@ -0,0 +1 @@
+This version of Dataverse includes extensions of the Dataverse External Vocabulary mechanism (https://guides.dataverse.org/en/latest/admin/metadatacustomization.html#using-external-vocabulary-services) that improve Dataverse's ability to include metadata about vocabulary terms and external identifiers such as ORCID and ROR in it's metadata exports. More information on how to configure external vocabulary scripts to use this functionality can be found at https://github.com/gdcc/dataverse-external-vocab-support/blob/main/docs/readme.md and in the examples in the https://github.com/gdcc/dataverse-external-vocab-support repository.

doc/release-notes/11796-fix-list-dataverse-templates-api-permissions.md

@@ -0,0 +1,10 @@
+### Fixed: Permissions for `/{identifier}/templates` endpoint
+
+The `/{identifier}/templates` endpoint previously required **`editDataverse`** permissions to retrieve the list of dataverse templates.
+
+This has been corrected: the endpoint now requires **`addDataset`** permissions instead.
+
+**Impact:**
+- The endpoint now works in scenarios such as the **Create Dataset form** in the SPA UI, without needing unnecessary elevated permissions.  
+
+Related issues: #11796

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.