-
Notifications
You must be signed in to change notification settings - Fork 486
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add getZipDownloadLimit and getMaxEmbargoDurationInMonths API info endpoints #9881
Changes from 3 commits
2ec5d36
7dd6ca8
e0bac9c
75b6832
9726451
d3d305c
f754b71
7929c4f
6e08bad
703a2a0
5ce8c90
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
Implemented the following new endpoints: | ||
|
||
- getZipDownloadLimit (/api/info/zipDownloadLimit): Get the configured zip file download limit. The response contains the long value of the limit in bytes. | ||
|
||
- getEmbargoEnabled (/api/info/embargoEnabled): Know if the Dataverse instance has been configured to allow embargoes. | ||
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -3330,6 +3330,43 @@ The fully expanded example above (without environment variables) looks like this | |
|
||
curl "https://demo.dataverse.org/api/info/settings/incompleteMetadataViaApi" | ||
|
||
Get Zip File Download Limit | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
Get the configured zip file download limit. The response contains the long value of the limit in bytes. | ||
|
||
This limit comes from the database setting :ref:`:ZipDownloadLimit` if set, or the default value if the database setting is not set, which is 104857600 (100MB). | ||
|
||
.. code-block:: bash | ||
|
||
export SERVER_URL=https://demo.dataverse.org | ||
|
||
curl "$SERVER_URL/api/info/zipDownloadLimit" | ||
|
||
The fully expanded example above (without environment variables) looks like this: | ||
|
||
.. code-block:: bash | ||
|
||
curl "https://demo.dataverse.org/api/info/zipDownloadLimit" | ||
|
||
Show Support Of The Embargo Feature | ||
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | ||
|
||
Know if the Dataverse instance has been configured to allow embargoes. | ||
|
||
The endpoint checks whether the database setting :ref:`:MaxEmbargoDurationInMonths`, which enables the embargo feature, has a value that enables the feature or not. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the future, will the SPA (or some other system) need to know the value of :MaxEmbargoDurationInMonths? If so, should we return it now, as part of the endpoint we're adding? Or would we add a second endpoint to get the number of months? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. To be honest, I'm not entirely sure, but I don't think so, considering that the embargo duration is something that is managed internally by the setting, and that for now, I've only seen that the UI needs to know if the feature is enable (To show / not show related UI) or if a file is embargoed, but not the configured embargo duration. In any case, if necessary in the future, we can extend the endpoint to include the setting value or create a separate endpoint. For now I have preferred to keep it simple. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm assuming the SPA will need to perform some validation when we get to the EDIT side of the dataset page. I can imagine an error like this: "Please an embargo date before September 8, 2025" (for example) There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You are right. When creating an embargo, there is a date picker that I was overlooking where dates within the range determined by the :MaxEmbargoDurationInMonths setting are displayed. So the SPA has to know the value of the setting beforehand. I think then it is better to directly expose the setting. Something like: Then the SPA/consumer will know if the feature is enabled (by having a value set different than 0) and the embargo duration in months. What do you think? @pdurbin There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Yes, directly exposing the setting sounds good. |
||
|
||
.. code-block:: bash | ||
|
||
export SERVER_URL=https://demo.dataverse.org | ||
|
||
curl "$SERVER_URL/api/info/embargoEnabled" | ||
|
||
The fully expanded example above (without environment variables) looks like this: | ||
|
||
.. code-block:: bash | ||
|
||
curl "https://demo.dataverse.org/api/info/embargoEnabled" | ||
|
||
.. _metadata-blocks-api: | ||
|
||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Something feels off to me...
We should probably make an active decision about two things:
Another way to ask this is which of the following we want.
For reference here is a sorted list of "info" endpoints as of this PR:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems appropriate to me to add the setting subpath, and even include the colon if it is more understandable for the setting name, as long as the endpoint only reads the setting value, with no other operations around it.
For example, the
/admin/settings/{name}
endpoint returns the plain value of the setting if it exists, otherwise it returns a not found error.On the other hand, the
info/zipDownloadLimit
endpoint does more than read the setting, since if the associated setting is not found it assigns a default value. So I find appropriate to exclude the "settings" endpoint subpath/naming here.Same for the
info/embargoEnabled
endpoint, that after reading the:MaxEmbargoDurationInMonths
setting, based on its possible values, checks whether the embargo functionality is enabled or not.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@GPortas I wrote some docs to merge into this PR once we are happy with them: