Kuali Rice Development
  1. Kuali Rice Development
  2. KULRICE-3137

Several of the "Cancel" and "Close" buttons in the Portal result in 404 error.

    Details

    • Type: Bug Fix Bug Fix
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 1.0
    • Fix Version/s: 1.0
    • Component/s: User Interface
    • Labels:
      None
    • Similar issues:
      KULRICE-7257Lightbox close/cancel buttons not working
      KULRICE-4609Close/Cancel/Save button does not work correctly for Kim maintenance screens
      KULRICE-5487On an inquiry lightbox off of a maintenance doc, clicking the "Close" button causes the browser to go back to the main portal tab
      KULRICE-11924InitiatedDocumentView cancel button results in stack trace, http error 500
      KULRICE-8440404 Error when accessing a KRAD page through the portal
      KULRICE-8161Work Flow Route Rules cancel new yields 404 not found
      KULRICE-1946Close & Cancel buttons throughout should return to KIM Menu, not RICE menu
      KULRICE-341maintenance docs don't return to portal after pressing "close" button
      KULRICE-9430Lightboxes, close and cancel buttons not working as expected
      KULRICE-7894Close button on kitchen sink does not take back to portal

      Description

      Some of the return actions that return to the Portal page result in a 404 error.
      The problem appears that the action is "Portal.do" instead of "portal.do".

        Issue Links

          Activity

          Hide
          Chad Hagstrom added a comment -

          I've fixed nearly all of the links on my local copy, but there are still two links that I wanted to get feedback on before fixing them. In the "Main" tab under the "Notification" section, if the user clicks the "Delivery Types" link and then clicks "cancel", an HTTP 404 results because the link is trying to navigate to /kr-dev/ken/HomePage.form instead of the portal. Should this "cancel" link go to that KEN home page's new location (if such a page still exists), or should the link simply return to the portal?

          Also, in the "Administration" tab under the "Workflow" section, if the user clicks the "Statistics" link and then clicks "cancel", nothing happens because the "cancel" link only tries to perform a window.close operation via Javascript, instead of trying to navigate to another page. Are there situations where this page is opened in a separate tab/window, or should this Javascript command be removed from the button? And should the button simply navigate back to the portal in case Javascript is disabled or the window.close command needs to be removed?

          Show
          Chad Hagstrom added a comment - I've fixed nearly all of the links on my local copy, but there are still two links that I wanted to get feedback on before fixing them. In the "Main" tab under the "Notification" section, if the user clicks the "Delivery Types" link and then clicks "cancel", an HTTP 404 results because the link is trying to navigate to /kr-dev/ken/HomePage.form instead of the portal. Should this "cancel" link go to that KEN home page's new location (if such a page still exists), or should the link simply return to the portal? Also, in the "Administration" tab under the "Workflow" section, if the user clicks the "Statistics" link and then clicks "cancel", nothing happens because the "cancel" link only tries to perform a window.close operation via Javascript, instead of trying to navigate to another page. Are there situations where this page is opened in a separate tab/window, or should this Javascript command be removed from the button? And should the button simply navigate back to the portal in case Javascript is disabled or the window.close command needs to be removed?
          Hide
          Eric Westfall added a comment -

          In both of these cases have the close button return to the previous page (portal in this case) so that the behavior is consistent with the other pages.

          Show
          Eric Westfall added a comment - In both of these cases have the close button return to the previous page (portal in this case) so that the behavior is consistent with the other pages.
          Hide
          Chad Hagstrom added a comment -

          The links from my previous post have been fixed locally, but I had a question about one other link before committing my fixes. In the "Main" tab under the "Workflow" section, if the user clicks on "User Preferences" and then clicks "cancel", the browser gets redirected to the action list instead of the portal. However, this functionality appears to be intentional because the action list can also open this page by clicking on the "preferences" button. Should this page be modified so that it can be passed a "returnLocation" URL like the lookup pages have, allowing the preferences page to return back to the page that opened it?

          Show
          Chad Hagstrom added a comment - The links from my previous post have been fixed locally, but I had a question about one other link before committing my fixes. In the "Main" tab under the "Workflow" section, if the user clicks on "User Preferences" and then clicks "cancel", the browser gets redirected to the action list instead of the portal. However, this functionality appears to be intentional because the action list can also open this page by clicking on the "preferences" button. Should this page be modified so that it can be passed a "returnLocation" URL like the lookup pages have, allowing the preferences page to return back to the page that opened it?
          Hide
          Eric Westfall added a comment -

          Current behavior of the Preferences page is correct. Ideally it would just return to whichever page it was opened from (which will usually be the ActionList). If it's easy to have it return to the referred then go ahead and do that. Otherwise, having it return to the Action List is fine for now. Thanks for checking!

          Show
          Eric Westfall added a comment - Current behavior of the Preferences page is correct. Ideally it would just return to whichever page it was opened from (which will usually be the ActionList). If it's easy to have it return to the referred then go ahead and do that. Otherwise, having it return to the Action List is fine for now. Thanks for checking!
          Hide
          Eric Westfall added a comment -

          Bulk change of all Rice 1.0 issues to closed after public release.

          Show
          Eric Westfall added a comment - Bulk change of all Rice 1.0 issues to closed after public release.

            People

            • Assignee:
              Chad Hagstrom
              Reporter:
              Daniel Seibert (Inactive)
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - 4 hours
                4h
                Remaining:
                Remaining Estimate - 4 hours
                4h
                Logged:
                Time Spent - Not Specified
                Not Specified

                  Structure Helper Panel