Apply suggestions from code review

Co-authored-by: Omer Fahim <mfahim11427@gmail.com>

Author: pdurbin

doc/release-notes/6.8-release-notes.md

@@ -9,7 +9,7 @@ This release brings new features, enhancements, and bug fixes to Dataverse. Than
 Highlights for Dataverse 6.8 include:
 
 - Open OnDemand integration
-- Logs for dignosing PID failures
+- Logs for diagnosing PID failures
 - Link permission split off from publish permission
 - New and improved APIs
 - Bug fixes
@@ -20,7 +20,7 @@ Highlights for Dataverse 6.8 include:
 
 Open OnDemand, a web frontend to High Performance Computing (HPC) resources, has been integrated with Dataverse, allowing files to be downloaded from Dataverse installations around the world or from a specific dataset landing page if an external tool is enabled. Additionally, after computation is complete, datasets can be created in Dataverse from Open OnDemand and files can be uploaded. See the [docs](https://guides.dataverse.org/en/6.8/admin/integrations.html#open-ondemand), #11768 and #11769.
 
-### Logs for Dignosing PID Failures
+### Logs for Diagnosing PID Failures
 
 A new [feature flag](https://guides.dataverse.org/en/6.8/installation/config.html#feature-flags) called `enable-pid-failure-log` can be enabled to help diagnose PID failures. When set, Dataverse will log requests for dataset and file pages via persistentId that fail in monthly log files of the form `PIDFailures_<yyyy-MM>.log`. These potentially indicate when someone has shared a draft PID without publishing or cases where a '.' or other character has been added to the PID, which may be of interest to site administrators. The new log files can be used in concert with the [pidreport.py](https://github.com/gdcc/dataverse-recipes/tree/main/python/pid_reports) script to generate and email monthly PID failure reports. See #11601.
 
@@ -33,9 +33,9 @@ Linking or unlinking a dataset or dataverse now requires the new "LinkDataset" o
 - A bug, introduced in v6.7, that caused files to not be indexed in draft versions that were added after the initial dataset version was published, has been fixed. See #11776 and #11779.
 - The styled citations available through the "View Styled Citations" menu were including extra characters, e.g. 'doi:' in the URL form of the PIDs in the citation. This is now fixed. See #11629.
 - The updates to support keeping the history of curation status labels added in #11268 will incorrectly show curation statuses added prior to v6.7 as the current one, regardless of whether newer statuses exist. This bug has been fixed. See #11685. (As a work-around for 6.7 admins can add createtime dates (must be prior to when 6.7 was installed) to the curationstatus table for entries that have null createtimes. The code fix in this version properly handles null dates as indicating older/pre v6.7 curationstatuses.)
-- The addDataset and addDataverse API endpoints now trigger user notifications See #1342 and #11696.
-- A bug introduced in v6.5 broken Handle parsing when using a lower-case shoulder. This is now fixed. See #11592.
-- Due to changes in how the commons-lang3 Java library handles a non-ascii chararacter, two keys in the citation.properties and citation.tsv files have changed to include i instead of ɨ. `controlledvocabulary.language.magɨ_(madang_province)` has been changed to `controlledvocabulary.language.magi_(madang_province)` and `controlledvocabulary.language.magɨyi` has been changed to `controlledvocabulary.language.magiyi`. In the upgrade instructions below, we indicate that the citation metadata block should be reloaded. Translations will need make the same adjustment. See #11632.
+- The addDataset and addDataverse API endpoints now trigger user notifications. See #1342 and #11696.
+- A bug introduced in v6.5 broke Handle parsing when using a lowercase shoulder. This is now fixed. See #11592.
+- Due to changes in how the commons-lang3 Java library handles a non-ascii chararacter, two keys in the citation.properties and citation.tsv files have changed to include i instead of ɨ. `controlledvocabulary.language.magɨ_(madang_province)` has been changed to `controlledvocabulary.language.magi_(madang_province)` and `controlledvocabulary.language.magɨyi` has been changed to `controlledvocabulary.language.magiyi`. In the upgrade instructions below, we indicate that the citation metadata block should be reloaded. Translations will need to make the same adjustment. See #11632.
 - When following the container demo tutorial, it was not possible to update Solr fields after adding additional metadata blocks. This has been fixed. See #11722 and #11723.
 
 ## API Updates
@@ -93,8 +93,8 @@ The API endpoints `api/{dataverse-alias}/metadatablocks` and `/api/metadatablock
 
 The Notifications API has been updated in various ways:
 
-- The JSON returned from [listing notifications](https://guides.dataverse.org/en/6.8/api/native-api.html#get-all-notifications-by-user) now includes a "displayAsRead" boolean to indicated if a notification has been read. See #11650 and #11664.
-- You can get an count of unread notifications via a new [unreadCount](https://guides.dataverse.org/en/6.8/api/native-api.html#get-unread-count) API endpoint.
+- The JSON returned from [listing notifications](https://guides.dataverse.org/en/6.8/api/native-api.html#get-all-notifications-by-user) now includes a "displayAsRead" boolean to indicate if a notification has been read. See #11650 and #11664.
+- You can get a count of unread notifications via a new [unreadCount](https://guides.dataverse.org/en/6.8/api/native-api.html#get-unread-count) API endpoint.
 - You can mark a notification as read via a new [markAsRead](https://guides.dataverse.org/en/6.8/api/native-api.html#mark-notification-as-read) API endpoint.
 - The JSON can be returned using `inAppNotificationFormat`. See #11648 and #11696.
 - A bug was fixed where a NullPointerException was being thrown when retrieving notifications without a requestor. See #11703, and #11704.
@@ -124,7 +124,7 @@ If the dataset/file is not public, the caller must authenticate and have permiss
 
 Authentication updates listed below were introduced as we work toward allowing the [new Dataverse frontend](https://github.com/IQSS/dataverse-frontend), a React-based Single Page Application (SPA). We list them here for completeness but unless you are experimenting with the new frontend or playing with OIDC directly, they probably will have no impact on your installation.
 
-- We've strengthened the security of the `api-bearer-auth-use-builtin-user-on-id-match` feature flag. It will now only work when the provided bearer token includes an `idp` claim that matches the Keycloak Service Provider identifier. By enforcing this check, the risk of impersonation from other identity providers is significantly reduced, since they would need to be explici  tly configured with this specific, non-standard identifier. See the list of [feature flags](https://guides.dataverse.org/en/6.8/installation/config.html#feature-flags), #11689, and #11763.
+- We've strengthened the security of the `api-bearer-auth-use-builtin-user-on-id-match` feature flag. It will now only work when the provided bearer token includes an `idp` claim that matches the Keycloak Service Provider identifier. By enforcing this check, the risk of impersonation from other identity providers is significantly reduced, since they would need to be explicitly configured with this specific, non-standard identifier. See the list of [feature flags](https://guides.dataverse.org/en/6.8/installation/config.html#feature-flags), #11689, and #11763.
 - A new feature flag `api-bearer-auth-use-shib-user-on-id-match` supports the use of clients in instances that have historically allowed login via Shibboleth. Specifically, with this flag enabled, when an OIDC bridge is configured to allow OIDC login with validation by the bridged Shibboleth providers, users with existing Shibboleth-based accounts in Dataverse can log in to those accounts, thereby maintaining access to their existing content and retaining their roles. (For security reasons, Dataverse's current support for direct login via Shibboleth cannot be used in browser-based clients.) See the list of [feature flags](https://guides.dataverse.org/en/6.8/installation/config.html#feature-flags), #11605, and #11622.
 - A new feature flag `api-bearer-auth-use-oauth-user-on-id-match` supports the use of clients in instances that have historically allowed login via GitHub, ORCID, or Google. Specifically, with this flag enabled, when an OIDC bridge is configured to allow OIDC login with validation by the bridged OAuth providers, users with existing GitHub, ORCID, or Google accounts in Dataverse can log in to those accounts, thereby maintaining access to their existing content and retaining their roles. See the list of [feature flags](https://guides.dataverse.org/en/6.8/installation/config.html#feature-flags), #11671, and #11645.
 
@@ -140,13 +140,13 @@ The getDatasetFileDetails data structure now contains "directoryLabel" (file pat
 
 ### PostgreSQL 13 Reaches EOL on 13 November 2025
 
-We mentioned this in the [Dataverse 6.6 release notes](https://github.com/IQSS/dataverse/releases/tag/v6.6), but as a reminder, according to https://www.postgresql.org/support/versioning/ PostgreSQL 13 reaches EOL on 13 November 2025. As mentioned in the [Installation Guide](https://guides.dataverse.org/en/6.8/installation/prerequisites.html#postgresql), we recommend running PostgreSQL 16 since it is the version we test with in our continous integration ([since](https://github.com/gdcc/dataverse-ansible/commit/8ebbd84ad2cf3903b8f995f0d34578250f4223ff) February 2025). The [Dataverse 5.4 release notes](https://github.com/IQSS/dataverse/releases/tag/v5.4) explained the upgrade process from 9 to 13 (e.g. pg_dumpall, etc.) and the steps will be similar. If you have any problems, please feel free to reach out (see "getting help" in these release notes).
+We mentioned this in the [Dataverse 6.6 release notes](https://github.com/IQSS/dataverse/releases/tag/v6.6), but as a reminder, according to https://www.postgresql.org/support/versioning/ PostgreSQL 13 reaches EOL on 13 November 2025. As mentioned in the [Installation Guide](https://guides.dataverse.org/en/6.8/installation/prerequisites.html#postgresql), we recommend running PostgreSQL 16 since it is the version we test with in our continuous integration ([since](https://github.com/gdcc/dataverse-ansible/commit/8ebbd84ad2cf3903b8f995f0d34578250f4223ff) February 2025). The [Dataverse 5.4 release notes](https://github.com/IQSS/dataverse/releases/tag/v5.4) explained the upgrade process from 9 to 13 (e.g. pg_dumpall, etc.) and the steps will be similar. If you have any problems, please feel free to reach out (see "getting help" in these release notes).
 
 ### For Dataverse instances that Use Shibboleth as Members of the InCommon Federation
 
 Please note that most of the known Dataverse instances that support Shibboleth logins do so without being part of InCommon, and therefore are not affected. All such instances will be able to continue using the old login workflow without needing to make any configuration changes.
 
-For the relatively few instances using InCommon: Since InCommon discontinued their old-style federation metadata feed, a new Shibboleth implementation has been added to utilize the recommended replacements: the MDQ protocol and the WayFinder service. In order to continue using InCommon, such instances will need to modify their shibd configuration and their registration with Incommon, plus set a new feature flag. See the upgrade instructions below for details. See also #11404 and #11502.
+For the relatively few instances using InCommon: Since InCommon discontinued their old-style federation metadata feed, a new Shibboleth implementation has been added to utilize the recommended replacements: the MDQ protocol and the WayFinder service. In order to continue using InCommon, such instances will need to modify their shibd configuration and their registration with InCommon, plus set a new feature flag. See the upgrade instructions below for details. See also #11404 and #11502.
 
 ## New Settings