You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: conf/keycloak/builtin-users-spi/src/main/java/edu/harvard/iq/keycloak/auth/spi/services/DataverseUserService.java
+18-4Lines changed: 18 additions & 4 deletions
Original file line number
Diff line number
Diff line change
@@ -27,11 +27,16 @@ public DataverseUser getUserById(String id) {
Implemented a new feature flag ``dataverse.feature.api-bearer-auth-use-shib-user-on-id-match``, which supports the use of the new Dataverse client 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.)
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.
The [API for listing the collections a dataverse has been linked to](https://guides.dataverse.org/en/latest/admin/dataverses-datasets.html#list-dataverse-collection-links) (`api/dataverses/$dataverse-alias/links`) has been refactored to return a new Json format. This is a breaking API.
Copy file name to clipboardExpand all lines: doc/sphinx-guides/source/api/changelog.rst
+2Lines changed: 2 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -9,8 +9,10 @@ This API changelog is experimental and we would love feedback on its usefulness.
9
9
10
10
v6.8
11
11
----
12
+
12
13
- For POST /api/files/{id}/metadata passing an empty string ("description":"") or array ("categories":[]) will no longer be ignored. Empty fields will now clear out the values in the file's metadata. To ignore the fields simply do not include them in the JSON string.
13
14
- For PUT /api/datasets/{id}/editMetadata the query parameter "sourceInternalVersionNumber" has been removed and replaced with "sourceLastUpdateTime" to verify that the data being edited hasn't been modified and isn't stale.
15
+
- For GET /api/dataverses/$dataverse-alias/links the Json response has changed breaking the backward compatibility of the API.
14
16
- The way to set per-format size limits for tabular ingest has changed. JSON input is now used. See :ref:`:TabularIngestSizeLimit`.
15
17
- In the past, the settings API would accept any key and value. This is no longer the case because validation has been added. See :ref:`settings_put_single`, for example.
The Customization API is used to retrieve the analytics-code.html as well as other customization file contents.
5840
+
5841
+
See also :ref:`web-analytics-code`in the Configuration section of the Installation Guide and :ref:`Branding Your Installation`
5842
+
5843
+
The Content-Type returned in the header is based on the media type of the file being returned (example: analytics-code.html returns "text/html; charset=UTF-8"
5844
+
5845
+
Valid types are "homePage", "header", "footer", "style", "analytics", and "logo".
5846
+
5847
+
A curl example getting the analytics-code
5848
+
5849
+
.. code-block:: bash
5850
+
5851
+
export SERVER_URL=https://demo.dataverse.org
5852
+
export TYPE=analytics
5853
+
5854
+
curl -X GET "$SERVER_URL/api/info/settings/customization/$TYPE"
5855
+
5856
+
The fully expanded example above (without environment variables) looks like this:
5857
+
5858
+
.. code-block:: bash
5859
+
5860
+
curl -X GET "https://demo.dataverse.org/api/info/settings/customization/analytics"
5861
+
5862
+
.. _customization-analytics:
5863
+
5824
5864
.. _metadata-blocks-api:
5825
5865
5826
5866
Metadata Blocks
@@ -5932,6 +5972,8 @@ Notifications
5932
5972
5933
5973
See :ref:`account-notifications` in the User Guide for an overview. For a list of all the notification types mentioned below (e.g. ASSIGNROLE), see :ref:`mute-notifications` in the Admin Guide.
5934
5974
5975
+
.. _get-all-notifications:
5976
+
5935
5977
Get All Notifications by User
5936
5978
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5937
5979
@@ -5941,6 +5983,52 @@ Each user can get a dump of their notifications by passing in their API token:
The expected OK (200) response looks something like this:
5987
+
5988
+
.. code-block:: text
5989
+
5990
+
{
5991
+
"status": "OK",
5992
+
"data": {
5993
+
"notifications": [
5994
+
{
5995
+
"id": 38,
5996
+
"type": "CREATEACC",
5997
+
"displayAsRead": true,
5998
+
"subjectText": "Root: Your account has been created",
5999
+
"messageText": "Hello, \nWelcome to...",
6000
+
"sentTimestamp": "2025-07-21T19:15:37Z"
6001
+
}
6002
+
...
6003
+
6004
+
Get Unread Count
6005
+
~~~~~~~~~~~~~~~~
6006
+
6007
+
You can get a count of your unread notifications as shown below.
6008
+
6009
+
.. code-block:: bash
6010
+
6011
+
curl -H "X-Dataverse-key:$API_TOKEN" -X GET "$SERVER_URL/api/notifications/unreadCount"
6012
+
6013
+
Mark Notification As Read
6014
+
~~~~~~~~~~~~~~~~~~~~~~~~~
6015
+
6016
+
After finding the ID of a notification using :ref:`get-all-notifications`, you can pass it to the "markAsRead" API endpoint as shown below. Note that this endpoint is idempotent; you can mark an already-read notification as read over and over.
0 commit comments