fix jsf guestbook response cancel button

[stevenwinship]

What this PR does / why we need it: Pressing 'Cancel' button on JSF Guestbook Response screen (preview, download, or request access) does not cancel the dialog

Which issue(s) this PR closes:#12205

• Closes Guestbook Response JSF popup Cancel button not working #12205

Special notes for your reviewer: lines prior to 291 are just reformatted because the spacing was off. No code changes were made. The new code comes after line 291

Suggestions on how to test this: Make a dataset require a guestbook response. Try to preview the file. Try to download the file. Also with dataverse.files.guestbook-at-request=true try to request access to a restricted file. Old version - cancel does nothing. This version - Cancel closes the tab/dialog and returns you to the files tab.

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

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

Additional documentation:

[coveralls]

Coverage is 25.409% — 12205-guestbook-response-jsf-popup-cancel-button into develop. No base build found for develop.

[pdurbin]

/push-image

[github-actions]

📦 Pushed preview images as

ghcr.io/gdcc/dataverse:12205-guestbook-response-jsf-popup-cancel-button

ghcr.io/gdcc/configbaker:12205-guestbook-response-jsf-popup-cancel-button

🚢 See on GHCR. Use by referencing with full name as printed above, mind the registry name.

[youseihuayu-wonderful]

Re-posted the Terms of Access suggestion on current HEAD. 257febc undid e2fe762 and put the regression back; the JSF Select All failure is a separate issue.

[youseihuayu-wonderful]

Update: Steven applied the two-line restoration directly in bf019c4 and then merged the latest develop into the branch (ad315c1).

The current official checks pass:

• JSF: 43/43 passed, including 13-dataset-actions on Chromium, Firefox, and WebKit: https://github.com/IQSS/dataverse/actions/runs/31705546363
• Integration tests: passed: https://github.com/IQSS/dataverse/actions/runs/31705546389
• CodeQL: passed

The earlier trace showed no filesTable toggleSelect request and no JSF/EL/bundle error. That fixture also does not render this Terms of Access block. With the restoration now present on #12220 and its current CI passing, #12608 is superseded.

[pdurbin]

@stevenwinship can you please decide if you'd like to merge this PR by @youseihuayu-wonderful ...

• Restore Terms of Access rendering in PR #12220 #12608

... into this one (#12220)?

[stevenwinship]

merged the latest suggested code

[qqmyers]

Given the onclick method, this doesn't appear to have any effect.

[stevenwinship]

Without this code there is no cancel button. Only an "accept" button. To cancel you must click the browser's back button.

[stevenwinship]

Removed the cancel button

[qqmyers]

FWIW: The comment was on line 316 where the code is trying to make a call to he server to update the tab view while your onclick was sending people to another page.

[qqmyers]

If I navigate to the datafile page, and then click cancel, I end up back on the dataset page, which seems counter-intuitive as I wouldn't expect to get pushed back to the dataset page (I have to accept or just ignore the dialog and switch to another pane to stay on the file page).

Same concern if I start from a search page - clicking cancel pushes me back to the search result page.

Going back to the dataset page makes some sense if I just click the preview button, since I started on the dataset page in that case, but I think it might be better to just stay on the datafile page and switch to the metadata tab. This onclick would do that: onclick="var metadataTab = $('a[href$="metadataMapTab"]'); if (metadataTab.length) { metadataTab.click(); } else { history.back(); } " I suspect the check that the tab exists and the option to still use history.back() if not isn't really needed (if you have a previewTab so this button is rendered, the metadataTab has to be there too.).

The one minor weirdness in doing this is that the large thumbnail on the metadata pane is also labelled "Preview" so it appears that when you to cancel while trying to see the preview, you see it anyway (you don't - it's a 400px thumbnail for types that have one). I'd suggest just changing that label on the metadata tab to "Thumbnail" to address this. It's the file.metadata.preview entry in the Bundle.properties

[stevenwinship]

The purpose of this cancel button was to send you back to the place you started (Dataset Page Files Tab). Since that's not what you want I will remove the button so the user can choose to go back with the back button or select the metadata tab.

[stevenwinship]

Since this PR is to fix the "cancel" buttons that don't work and this "cancel" button was never there it will be restored to the original functionality

[qqmyers]

The point in my comment is that people are not always starting from the same place - could even be an external site. It's worse if I go to the file page manually and then click the cancel (history.back) button, I'm sent away from the page I navigated to, possibly back to some other site, rather than being able to see the rest of the data file info on the page. My suggestion was to redirect people to the metadata tab instead, which avoids leaving them on a non-working preview tab.

[stevenwinship]

Understood. My point is that clicking a button that does nothing is a bug. If the button never existed there is no need to fix it

[qqmyers]

For all three p:CommandButtons added in this PR: they need a type="button" attribute. Without that, they make an extra ajax call to the server (as they act as a submit button by default). I confirmed this in QA (and also noted that one can achieve ~the same thing by having the onclick javascript have a return false; at the end, but using the type attribute is cleaner.)

[stevenwinship]

added type="button"

[qqmyers]

This would change with the suggested updates - ... when on the file page, clicking cancel on the preview tab will shift the view to the metadata tab.

[stevenwinship]

removed the button

[qqmyers]

With the revisions, this PR now makes the minimal change to suppress the cancel button when the guestbookAndTermsPopup is shown on the file preview tab (FWIW: the reason it didn't close before is that the widgetVar guestbookAndTermsPopup is not defined in the file.xhtml page, so the call to hide() it in the guestbook-terms-popup-fragment fails. This widgetVar is defined where the fragment is used in the dataset page.)

Not allowing a cancel on the file preview pane is a good solution - actually making the cancel button work would cause the form to disappear and not allow changing your mind without reloading the whole page. (Both options discussed earlier have this problem. The dataset page use is different since a popup is used - one can just hit download/request access again.)

The minimalist fix here would have been to just add jsf:rendered="#{popupContext != 'previewTab'}" to the one copy of the button used on the file page. That said, the other changes made in the PR are ~neutral (changing to p:commandButton) or cleanup (removing PF('blockDatasetForm').hide(); - that looks like it was cut/pasted from other dialogs but I and AI confirm it isn't ever shown when this fragment is used, so there's no need to hide it.).

In QA, I confirmed that the cancel button is gone in the preview pane, one can still navigate to/from the preview pane and click accept later. I also checked the request-at-download and request-at-access-request uses on the dataset page - clicking cancel still works. I also verified that the p:commandButtons with type="button" don't make an unnecessary call to the server (as they do w/o that type).

So - good to go - merging.