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)

Which issue(s) this PR closes:

• Closes Dataset Edit Terms Integration #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 68f2c3c on Edit-term-integration
into 48dd9ff on develop.

[ekraffmiller]

Hi @ChengShi-1, it looks really good! See comments about suggested changes.
Sorry it took so long for this review, please don't worry about it till you are back from vacation! :)

[ekraffmiller]

Hi @ChengShi-1, all your changes look great, I just had another thought about the UI when testing this.
Currently, a user can make an edit on one tab, then click over to another tab without saving changes. I could see where a user would be confused, and think that 'Save Changes' means to save the changes made in all tabs within Edit Dataset Terms page.
If the user goes to a second tab without saving the first tab, then the changes will be lost.
I think the best solution for the user experience is to update "Save Changes" so it saves the data from all the tabs, but I realize that might be a big change. An alternate approach would be to warn the user if they click on another tab while unsaved changes exist on the current tab. We do something similar in the UploadFiles page - if the user attempts to navigate away from the page, we show a popup warning them, and giving an option to "stay on the page".
What do you think? Does one solution seem easier to implement than the other?

[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.

[ekraffmiller]

looks good!