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

KRAD application header/controls - persistence on page


    • Type: Improvement Improvement
    • Status: Open Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
    • Similar issues:
      KULRICE-9528Document how KRAD handles it's own internal classes (doc header, etc.) in terms of managing them in their own persistence unit
      KULRICE-9872Implement a simple approach for importing common KRAD JPA entities into a KRAD application's persistence context
      KULRICE-3999Need a dynamic way to add classes to kns-application-unit persistence unit
      KULRICE-7158Validation messaging - single checkbox tooltip persists/open
      KULRICE-10349The expanded/collapsed state does not persist on refreshed INITIATED documents
      KULRICE-13260KRAD Library Fixed Application Header isn't fixed
      KULRICE-6684Rename KRAD Jsp for application view
      KULRICE-5652Create KRAD Version of Create New Sample Application Travel Request Document
      KULRICE-10040KRAD Sample Application: Maintence doc displays. Route Log Section shows 404 Error.
      KULRICE-13407Fill AFT Gap: KRAD Library - Page Group
    • Rice Module:
    • Application Requirement:
    • KAI Review Status:
      Pending Review
    • KTI Review Status:
      Not Required


      KRAD/KS application header/controls - persistence on the page

      In the current design, the KRAD/KS application header/controls includes the page/branding area, "Kuali Portal Index", provide feedback link, greyed-out info line "Rice sample app ... Oracle 9i" (is this needed, in the customer version?), the "Main Menu" and "Administration" tabs, the "Action List" and "Doc Search" links, and the log-in info fields and buttons. These are universal across all pages - this is conceptually the application header/controls area.

      Similarly, there is currently a footer area that has only the copyright and acknowledgements, but in some web-apps includes navigation links to other parts of the app (the left nav contents depend on the current task, the bottom nav contents do not).

      Let's consider the trade-offs in making these areas persistent in the view, not scrolling off the page when user scrolls down or up through long form. They take up real estate, so there are reasons not to persist these areas in the view. As long as they persist at the top and bottom of each page, not vary across pages, that may be sufficient.

        Issue Links


          There are no comments yet on this issue.


            • Assignee:
              Candace Soderston (Inactive)
            • Votes:
              0 Vote for this issue
              0 Start watching this issue


              • Created:

                Structure Helper Panel