8573 garbled

.github/PULL_REQUEST_TEMPLATE.md

@@ -2,7 +2,7 @@
 
 **Which issue(s) this PR closes**:
 
-Closes #
+- Closes #
 
 **Special notes for your reviewer**:
 

.github/workflows/guides_build_sphinx.yml

@@ -11,6 +11,6 @@ jobs:
     runs-on: ubuntu-latest
     steps:
     - uses: actions/checkout@v2
-    - uses: OdumInstitute/sphinx-action@master
+    - uses: uncch-rdmc/sphinx-action@master
       with:
         docs-folder: "doc/sphinx-guides/"

doc/release-notes/10379-MetricsBugsFixes.md

@@ -0,0 +1,10 @@
+
+### Metrics API Bug fixes
+
+Two bugs in the Metrics API have been fixed:
+
+- The /datasets and /datasets/byMonth endpoints could report incorrect values if/when they have been called using the dataLocation parameter (which allows getting metrics for local, remote (harvested), or all datasets) as the metrics cache was not storing different values for these cases. 
+
+- Metrics endpoints who's calculation relied on finding the latest published datasetversion were incorrect if/when the minor version number was > 9. 
+
+When deploying the new release, the [/api/admin/clearMetricsCache](https://guides.dataverse.org/en/latest/api/native-api.html#metrics) API should be called to remove old cached values that may be incorrect.

doc/release-notes/10697-improve-permission-indexing.md

@@ -0,0 +1,7 @@
+### Reindexing after a role assignment is less memory intensive
+
+Adding/removing a user from a role on a collection, particularly the root collection, could lead to a significant increase in memory use resulting in Dataverse itself failing with an out-of-memory condition. Such changes now consume much less memory.
+
+If you have experienced out-of-memory failures in Dataverse in the past that could have been caused by this problem, you may wish to run a [reindex in place](https://guides.dataverse.org/en/latest/admin/solr-search-index.html#reindex-in-place) to update any out-of-date information.
+
+For more information, see #10697 and #10698.

doc/release-notes/10708 - MDC Citation and DOI parsing improvements.md

@@ -0,0 +1,3 @@
+MDC Citation retrieval with the PID settings has been fixed.
+DOI parsing in Dataverse is case insensitive, improving interaction with services that may change the case.
+Warnings related to managed/excluded PID lists for PID providers have been reduced

doc/release-notes/10772-fix-importDDI-otherId.md

@@ -0,0 +1,2 @@
+Bug Fix :
+This PR fixes the `edu.harvard.iq.dataverse.util.json.JsonParseException: incorrect multiple   for field otherId` error when DDI harvested data contains multiple ortherId.

doc/release-notes/10857-add-expiration-date-to-recreate-token-api.md

@@ -0,0 +1 @@
+An optional query parameter called 'returnExpiration' has been added to the 'users/token/recreate' endpoint, which, if set to true, returns the expiration time in the response message.

doc/release-notes/10886-update-to-conditions-to-display-image_url.md

@@ -0,0 +1,8 @@
+Search API (/api/search) responses for Datafiles include image_url for the thumbnail if each of the following are true:
+1. The DataFile is not Harvested
+2. A Thumbnail is available for the Datafile
+3. If the Datafile is Restricted then the caller must have Download File Permission for the Datafile
+4. The Datafile is NOT actively embargoed
+5. The Datafile's retention period has NOT expired
+
+See also #10875 and #10886.

doc/release-notes/10901deaccessioned file edit fix.md

@@ -0,0 +1 @@
+When a dataset was deaccessioned and was the only previous version it will cause an error when trying to update the files. 

doc/release-notes/10904-edit-dataverse-collection-endpoint.md

@@ -0,0 +1 @@
+Adds a new endpoint (`PUT /api/dataverses/<identifier>`) for updating an existing Dataverse collection using a JSON file following the same structure as the one used in the API for the creation.

doc/release-notes/10914-users-token-api-credentials.md

@@ -0,0 +1,3 @@
+Extended the users/token GET endpoint to support any auth mechanism for retrieving the token information.
+
+Previously, this endpoint only accepted an API token to retrieve its information. Now, it accepts any authentication mechanism and returns the associated API token information.

doc/release-notes/10919-minor-DataCiteXML-bugfix.md

@@ -0,0 +1 @@
+A minor bug fix was made to avoid sending a useless ", null" in the DataCiteXML sent to DataCite and in the DataCite export when a dataset has a metadata entry for "Software Name" and no entry for "Software Version". The bug fix will update datasets upon publication. Anyone with existing published datasets with this problem can be fixed by [pushing updated metadata to DataCite for affected datasets](https://guides.dataverse.org/en/6.4/admin/dataverses-datasets.html#update-metadata-for-a-published-dataset-at-the-pid-provider) and [re-exporting the dataset metadata](https://guides.dataverse.org/en/6.4/admin/metadataexport.html#batch-exports-through-the-api) or by following steps 9 and 10 in the v6.4 release notes to update and re-export all datasets.

doc/release-notes/10939-i18n-docker.md

@@ -0,0 +1,5 @@
+## Multiple Language in Docker
+
+Configuration and documentation has been added to explain how to set up multiple languages (e.g. English and French) in the tutorial for setting up Dataverse in Docker.
+
+See also #10939

doc/release-notes/10947-unpublished-files-appearing-in-search-results-for-anon-user.md

@@ -0,0 +1,11 @@
+## Unpublished file bug fix
+
+A bug fix was made that gets the major version of a Dataset when all major versions were deaccessioned. This fixes the incorrect showing of the files as "Unpublished" in the search list even when they are published.
+This fix affects the indexing, meaning these datasets must be re-indexed once Dataverse is updated. This can be manually done by calling the index API for each affected Dataset.
+
+Example:
+```shell
+curl http://localhost:8080/api/admin/index/dataset?persistentId=doi:10.7910/DVN/6X4ZZL
+```
+
+See also #10947 and #10974.

doc/release-notes/10969-order-subfields-version-difference.md

@@ -0,0 +1,2 @@
+Bug Fix:
+In order to facilitate the comparison between the draft version and the published version of a dataset, a sort on subfields has been added (#10969)

doc/release-notes/9408-fix-facets-labels-not-translated-in-result-block.md

@@ -0,0 +1,7 @@
+## Fix facets filter labels not translated in result block
+
+On the main page, it's possible to filter results using search facets. If internationalization (i18n) has been activated in the Dataverse installation, allowing pages to be displayed in several languages, the facets are translated in the filter column. However, they aren't translated in the search results and remain in the default language, English.
+
+This version of Dataverse fix this, and includes internationalization in the facets visible in the search results section.
+
+For more information, see issue [#9408](https://github.com/IQSS/dataverse/issues/9408) and pull request [#10158](https://github.com/IQSS/dataverse/pull/10158)

doc/release-notes/9650-5-improve-list-linked-dataverses-API.md

@@ -0,0 +1,5 @@
+The following API have been added:
+
+/api/datasets/{datasetId}/links
+
+It lists the linked dataverses to a dataset. It can be executed only by administrators.

doc/sphinx-guides/source/admin/dataverses-datasets.rst

@@ -129,15 +129,21 @@ Lists the link(s) created between a dataset and a Dataverse collection (see the
 
     curl -H "X-Dataverse-key: $API_TOKEN" http://$SERVER/api/datasets/$linked-dataset-id/links
 
-It returns a list in the following format:
+It returns a list in the following format (new format as of v6.4):
 
 .. code-block:: json
 
   {
     "status": "OK",
     "data": {
-      "dataverses that link to dataset id 56782": [
-        "crc990 (id 18802)"
+      "id": 5,
+      "identifier": "FK2/OTCWMM",
+      "linked-dataverses": [
+        {
+          "id": 2,
+          "alias": "dataverse1",
+          "displayName": "Lab experiments 2023 June"
+        }
       ]
     }
   }

doc/sphinx-guides/source/admin/metadatacustomization.rst

@@ -579,7 +579,7 @@ In general, the external vocabulary support mechanism may be a better choice for
 The specifics of the user interface for entering/selecting a vocabulary term and how that term is then displayed are managed by third-party Javascripts. The initial Javascripts that have been created provide auto-completion, displaying a list of choices that match what the user has typed so far, but other interfaces, such as displaying a tree of options for a hierarchical vocabulary, are possible. 
 Similarly, existing scripts do relatively simple things for displaying a term - showing the term's name in the appropriate language and providing a link to an external URL with more information, but more sophisticated displays are possible.
 
-Scripts supporting use of vocabularies from services supporting the SKOMOS protocol (see https://skosmos.org), retrieving ORCIDs (from https://orcid.org), services based on Ontoportal product (see https://ontoportal.org/), and using ROR (https://ror.org/) are available https://github.com/gdcc/dataverse-external-vocab-support. (Custom scripts can also be used and community members are encouraged to share new scripts through the dataverse-external-vocab-support repository.)
+Scripts supporting use of vocabularies from services supporting the SKOSMOS protocol (see https://skosmos.org), retrieving ORCIDs (from https://orcid.org), services based on Ontoportal product (see https://ontoportal.org/), and using ROR (https://ror.org/) are available https://github.com/gdcc/dataverse-external-vocab-support. (Custom scripts can also be used and community members are encouraged to share new scripts through the dataverse-external-vocab-support repository.)
 
 Configuration involves specifying which fields are to be mapped, to which Solr field they should be indexed, whether free-text entries are allowed, which vocabulary(ies) should be used, what languages those vocabulary(ies) are available in, and several service protocol and service instance specific parameters, including the ability to send HTTP headers on calls to the service.
 These are all defined in the :ref:`:CVocConf <:CVocConf>` setting as a JSON array. Details about the required elements as well as example JSON arrays are available at https://github.com/gdcc/dataverse-external-vocab-support, along with an example metadata block that can be used for testing.

doc/sphinx-guides/source/api/changelog.rst

@@ -12,7 +12,7 @@ v6.4
 
 - **/api/datasets/$dataset-id/modifyRegistration**: Changed from GET to POST
 - **/api/datasets/modifyRegistrationPIDMetadataAll**: Changed from GET to POST
-
+- **/api/datasets/{identifier}/links**: The GET endpoint returns a list of Dataverses linked to the given Dataset. The format of the response has changes for v6.4 making it backward incompatible.
 
 v6.3
 ----

doc/sphinx-guides/source/api/native-api.rst

@@ -74,6 +74,58 @@ The request JSON supports an optional ``metadataBlocks`` object, with the follow
 
 To obtain an example of how these objects are included in the JSON file, download :download:`dataverse-complete-optional-params.json <../_static/api/dataverse-complete-optional-params.json>` file and modify it to suit your needs.
 
+.. _update-dataverse-api:
+
+Update a Dataverse Collection
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Updates an existing Dataverse collection using a JSON file following the same structure as the one used in the API for the creation. (see :ref:`create-dataverse-api`).
+
+The steps for updating a Dataverse collection are:
+
+- Prepare a JSON file containing the fields for the properties you want to update. You do not need to include all the properties, only the ones you want to update.
+- Execute a curl command or equivalent.
+
+As an example, you can download :download:`dataverse-complete.json <../_static/api/dataverse-complete.json>` file and modify it to suit your needs. The controlled vocabulary for ``dataverseType`` is the following:
+
+- ``DEPARTMENT``
+- ``JOURNALS``
+- ``LABORATORY``
+- ``ORGANIZATIONS_INSTITUTIONS``
+- ``RESEARCHERS``
+- ``RESEARCH_GROUP``
+- ``RESEARCH_PROJECTS``
+- ``TEACHING_COURSES``
+- ``UNCATEGORIZED``
+
+The curl command below assumes you are using the name "dataverse-complete.json" and that this file is in your current working directory.
+
+Next you need to figure out the alias or database id of the Dataverse collection you want to update.
+
+.. code-block:: bash
+
+  export API_TOKEN=xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
+  export SERVER_URL=https://demo.dataverse.org
+  export DV_ALIAS=dvAlias
+
+  curl -H "X-Dataverse-key:$API_TOKEN" -X PUT "$SERVER_URL/api/dataverses/$DV_ALIAS" --upload-file dataverse-complete.json
+
+The fully expanded example above (without environment variables) looks like this:
+
+.. code-block:: bash
+
+  curl -H "X-Dataverse-key:xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx" -X PUT "https://demo.dataverse.org/api/dataverses/dvAlias" --upload-file dataverse-complete.json
+
+You should expect an HTTP 200 response and JSON beginning with "status":"OK" followed by a representation of the updated Dataverse collection.
+
+Same as in :ref:`create-dataverse-api`, the request JSON supports an optional ``metadataBlocks`` object, with the following supported sub-objects:
+
+- ``metadataBlockNames``: The names of the metadata blocks you want to add to the Dataverse collection.
+- ``inputLevels``: The names of the fields in each metadata block for which you want to add a custom configuration regarding their inclusion or requirement when creating and editing datasets in the new Dataverse collection. Note that if the corresponding metadata blocks names are not specified in the ``metadataBlockNames``` field, they will be added automatically to the Dataverse collection.
+- ``facetIds``: The names of the fields to use as facets for browsing datasets and collections in the new Dataverse collection. Note that the order of the facets is defined by their order in the provided JSON array.
+
+To obtain an example of how these objects are included in the JSON file, download :download:`dataverse-complete-optional-params.json <../_static/api/dataverse-complete-optional-params.json>` file and modify it to suit your needs.
+
 .. _view-dataverse:
 
 View a Dataverse Collection
@@ -4412,6 +4464,12 @@ In order to obtain a new token use::
 
 	curl -H "X-Dataverse-key:$API_TOKEN" -X POST "$SERVER_URL/api/users/token/recreate"
 
+This endpoint by default will return a response message indicating the user identifier and the new token.
+
+To also include the expiration time in the response message, the query parameter ``returnExpiration`` must be set to true::
+
+	curl -H "X-Dataverse-key:$API_TOKEN" -X POST "$SERVER_URL/api/users/token/recreate?returnExpiration=true"
+
 Delete a Token
 ~~~~~~~~~~~~~~
 

doc/sphinx-guides/source/container/dev-usage.rst

@@ -140,6 +140,56 @@ Alternatives:
 - If you used Docker Compose for running, you may use ``docker compose -f docker-compose-dev.yml logs <service name>``.
   Options are the same.
 
+Accessing Harvesting Log Files
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+\1. Open a terminal and access the Dataverse container.
+
+Run the following command to access the Dataverse container (assuming your container is named dataverse-1):
+
+.. code-block::
+
+  docker exec -it dataverse-1 bash
+
+This command opens an interactive shell within the dataverse-1 container.
+
+\2. Navigate to the log files directory.
+
+Once inside the container, navigate to the directory where Dataverse logs are stored:
+
+.. code-block::
+
+  cd /opt/payara/appserver/glassfish/domains/domain1/logs
+
+This directory contains various log files, including those relevant to harvesting.
+
+\3. Create a directory for copying files.
+
+Create a directory where you'll copy the files you want to access on your local machine:
+
+.. code-block::
+
+  mkdir /dv/filesToCopy
+
+This will create a new folder named filesToCopy inside /dv.
+
+\4. Copy the files to the new directory.
+
+Copy all files from the current directory to the newly created filesToCopy directory:
+
+.. code-block::
+
+  cp * /dv/filesToCopy
+
+This command copies all files in the logs directory to /dv/filesToCopy.
+
+\5. Access the files on your local machine.
+
+On your local machine, the copied files should appear in the following directory:
+
+.. code-block::
+
+  docker-dev-volumes/app/data/filesToCopy
 
 Redeploying
 -----------

doc/sphinx-guides/source/container/running/demo.rst

@@ -137,6 +137,23 @@ In the example below of configuring :ref:`:FooterCopyright` we use the default u
 
 One you make this change it should be visible in the copyright in the bottom left of every page.
 
+Multiple Languages
+++++++++++++++++++
+
+Generally speaking, you'll want to follow :ref:`i18n` in the Installation Guide to set up multiple languages such as English and French.
+
+To set up the toggle between English and French, we'll use a slight variation on the command in the instructions above, adding the unblock key we created above:
+
+``curl "http://localhost:8080/api/admin/settings/:Languages?unblock-key=unblockme" -X PUT -d '[{"locale":"en","title":"English"},{"locale":"fr","title":"Français"}]'``
+
+Similarly, when loading the "languages.zip" file, we'll add the unblock key:
+
+``curl "http://localhost:8080/api/admin/datasetfield/loadpropertyfiles?unblock-key=unblockme" -X POST --upload-file /tmp/languages/languages.zip -H "Content-Type: application/zip"``
+
+Stop and start the Dataverse container in order for the language toggle to work.
+
+Note that ``dataverse.lang.directory=/dv/lang`` has already been configured for you in the ``compose.yml`` file. The step where you loaded "languages.zip" should have populated the ``/dv/lang`` directory with files ending in ".properties".
+
 Next Steps
 ----------
 

doc/sphinx-guides/source/developers/remote-users.rst

@@ -2,22 +2,27 @@
 Shibboleth, OAuth and OIDC
 ==========================
 
+If you are working on anything related to users, please keep in mind that your changes will likely affect Shibboleth, OAuth, and OIDC users. For some background on user accounts in the Dataverse Software, see :ref:`auth-modes` section of Configuration in the Installation Guide.
+
 .. contents:: |toctitle|
 	:local:
 
-Shibboleth and OAuth
---------------------
-
-If you are working on anything related to users, please keep in mind that your changes will likely affect Shibboleth and OAuth users. For some background on user accounts in the Dataverse Software, see :ref:`auth-modes` section of Configuration in the Installation Guide.
+Shibboleth
+----------
 
-Rather than setting up Shibboleth on your laptop, developers are advised to add the Shibboleth auth provider (see "Add the Shibboleth Authentication Provider to Your Dataverse Installation" at :doc:`/installation/shibboleth`) and add a value to their database to enable Shibboleth "dev mode" like this:
+Rather than setting up Shibboleth on your laptop, developers are advised to add the Shibboleth auth provider (see :ref:`add-shib-auth`) and add a value to their database to enable Shibboleth "dev mode" like this:
 
 ``curl http://localhost:8080/api/admin/settings/:DebugShibAccountType -X PUT -d RANDOM``
 
-For a list of possible values, please "find usages" on the settings key above and look at the enum.
+For a list of possible values, please "find usages" on the settings key above and look at the enum. As of this writing it's at the top of ShibServiceBean.
 
 Now when you go to http://localhost:8080/shib.xhtml you should be prompted to create a Shibboleth account.
 
+If you want to test again with the same account, you can delete it as long as you didn't create anything with it. See :ref:`delete-a-user`.
+
+OAuth
+-----
+
 OAuth is much more straightforward to get working on your laptop than Shibboleth. GitHub is a good identity provider to test with because you can easily request a Client ID and Client Secret that works against localhost. Follow the instructions in the :doc:`/installation/oauth2` section of the installation Guide and use "http://localhost:8080/oauth2/callback.xhtml" as the callback URL.
 
 In addition to setting up OAuth on your laptop for real per above, you can also use a dev/debug mode: