Dataset Edit Terms Integration

[ChengShi-1]

What this PR does / why we need it:

This feature will mainly focus on “Dataset Terms”, “Restricted Files + Terms of Access” UI implementation.(Guestbook is not implemented for now)

⚠️

• [x] waiting for backend api to be merged
• [x] waiting for js-dataverse use case to be merged
• [x] src/dataset/infrastructure/repositories/DatasetJSDataverseRepository.ts should be updated with correct use case from js-dataverse
• [x] should update packages, changelog, merge with dev branch

Which issue(s) this PR closes:

• Closes #824

Special notes for your reviewer:

• make edit terms to be an independent route, which acts differently from JSF
• for all versions of dataset, the terms information should be the same, and always update to the latest version
• for mobile viewport of this page, it should become accordion(as the same as JSF) instead of tabs, which looks friendly to mobile users
• In Dataset page, terms of access should be able to take HTML snippets

Suggestions on how to test this:

• A edit button in dataset page, naming changed to Edit Terms and Guestbook suggested from Julian to better guide users
• License tab - should be able to select from some available standard licenses or custom terms
• Restricted Files + Terms of Access Tab - should be able to enable/disable request access, also Terms of Access for Restricted Files would be required if disable request access
• mobile viewport

Does this PR introduce a user interface change? If mockups are available, please link/include them here:

yes, should be added later

Is there a release notes or changelog update needed for this change?:

yes, should be added later

[coveralls]

coverage: 97.368% (-0.4%) from 97.795% when pulling 68f2c3cd9e6b49c4186ae7847929e4f334730582 on Edit-term-integration into 48dd9ffde75d973c1fa6a705a42b29761e8656f7 on develop.

[ekraffmiller]

Since I know you are on vacation soon, I'm adding comments of little things as I see them :) Can we add more space here between the dropdown and the license image and link?

[ekraffmiller]

The cancel buttons on the tabs are resetting the values, but I think they also need to redirect the user to the View Dataset page, since they are exiting out of edit mode. (If they are leaving the page, do the values need to be reset?)

[ekraffmiller]

In JSF, if the Dataset doesn't have any restricted files, then the Request Access and Terms of Access for Restricted Files is disabled. It doesn't do any harm to keep them enabled, but it would be nice to match the JSF

[ChengShi-1]

if the Dataset doesn't have any restricted files, then the Request Access and Terms of Access for Restricted Files is disabled.

Hi @ekraffmiller , I check the JSF again

• If there is no file at all, or no restricted file, Enable Request Access is disabled.
• If one of the file is restricted, Enable Request Access should be enabled, no matter it set Enable request access to true or false when the file is restricted in this modal

So, the goal is to detect whether any file is restricted. Right now, the only way I can find is to query each file via the file repository use cases, which could be inefficient. The dataset repository doesn’t expose a use case to check for the existence of restricted files. Is there a better pattern for identifying this, or should we request an API extension?

[ekraffmiller]

So, the goal is to detect whether any file is restricted. Right now, the only way I can find is to query each file via the file repository use cases, which could be inefficient. The dataset repository doesn’t expose a use case to check for the existence of restricted files. Is there a better pattern for identifying this, or should we request an API extension?

Thanks @ChengShi-1 , that's a good point! We don't want to query each file, so I think an API extension is a good idea. We can leave the Edit Terms behavior as is, since it's not doing any harm.

[ChengShi-1]

@ekraffmiller I agree the button can be confusing, and acts different from JSF. Since each tab submits separately in its own API and use case now, adding an unsaved-changes warning is simpler. I can add that warning now, and if we want a single save across tabs later, I can tackle that next.

[ekraffmiller]

@ekraffmiller I agree the button can be confusing, and acts different from JSF. Since each tab submits separately in its own API and use case now, adding an unsaved-changes warning is simpler. I can add that warning now, and if we want a single save across tabs later, I can tackle that next.

sounds good, thanks!

[ChengShi-1]

Hi Ellen @ekraffmiller , I've implemented the "unsaved changes" pop-up modal. It's ready for review.

I wanted to call out one behavior that might be confusing: The "Leave without saving" button prevents the changes from being submitted to the backend. However, the UI itself still temporarily saves the changes locally within the current tab. If the user navigates away and then back, the unsaved changes will still appear in the UI. I am not sure if we want this local persistence.

[ekraffmiller]

Hi Ellen @ekraffmiller , I've implemented the "unsaved changes" pop-up modal. It's ready for review.

I wanted to call out one behavior that might be confusing: The "Leave without saving" button prevents the changes from being submitted to the backend. However, the UI itself still temporarily saves the changes locally within the current tab. If the user navigates away and then back, the unsaved changes will still appear in the UI. I am not sure if we want this local persistence.

It looks good! I see what you mean, the changes are still there until you hit Save. I think that's ok, we can change the warning to "If you leave now, your changes on this tab won't be saved". The main thing is to make sure they save everything that they intend to save.