Uploaded image for project: 'Kuali Rice Development'
  1. Kuali Rice Development
  2. KULRICE-8658

KC super user action tab open by default and does not show up until document is reloaded.

    Details

    • Type: Bug Fix
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 2.1.3
    • Component/s: Development
    • Security Level: Public (Public: Anyone can view)
    • Labels:
      None
    • Application Requirement:
      KC
    • KAI Review Status:
      Not Required
    • KTI Review Status:
      Not Required

      Description

      This jira consists of multiple parts.
      1. The superuser panel on all documents is open by default. Our functional users would prefer if it were closed by default so as to not distract from other content in the document.
      2. When the document loads after a superuser action, it does not seem to have the superuser action tab to begin with but clicking the reload button on the document displays it.I noticed that this is because of the following code.

      <c:if test="${KualiForm.superUserAuthorized && not empty KualiForm.actionRequests}">
      

      The KualiForm.superUserAuthorized in the superUserActions tag comes back as false immediately after performing the action.

      3. Once the document is approved, the message ""Document was super user approved by kr" appears on the document. While this is because KR is the Rice system user that routes the document, the real approver is the user logged in session. Is it possible to display the session user instead?

      I have recreated all of these in KFS also. Please try the Budget Adjustment document in KFS or the Protocol/Award/IP documents in KC. Please let me know if you would like me to create 3 seperate jiras for this issue.

        Attachments

        1. KCProposalLog_2.jpg
          KCProposalLog_2.jpg
          209 kB
        2. KCProposalLog.jpg
          KCProposalLog.jpg
          208 kB
        3. KCProtocol_2.jpg
          KCProtocol_2.jpg
          257 kB
        4. KCProtocol.jpg
          KCProtocol.jpg
          151 kB
        5. KULRICE-8658.png
          KULRICE-8658.png
          81 kB

          Activity

          Hide
          cdenne Chris Denne added a comment -

          I too think we could note the reload requirement as a training issue/"feature"
          I assert that the required reload is still a bug, while it may not rise to the level of critical - it still breaks the implied user interface contract that page load shows you true current state of the doc - in this case, not showing the current state of s/u actions available. So, i'm okay with splitting it out as a major

          Show
          cdenne Chris Denne added a comment - I too think we could note the reload requirement as a training issue/"feature" I assert that the required reload is still a bug, while it may not rise to the level of critical - it still breaks the implied user interface contract that page load shows you true current state of the doc - in this case, not showing the current state of s/u actions available. So, i'm okay with splitting it out as a major
          Hide
          shahess Shannon Hess added a comment -

          I think I would classify it as "a side effect of asynchronous processing" rather than a bug. However, I can split the reload issue out as a major bug, but think I still need some direction on how it should be solved then. If the superuser tab is displayed when there are no action items, there is a high chance that the actions displayed are not complete and that the possible actions may change within seconds and will be invalid. Is that acceptable? Is a warning message desired in this situation then?

          Show
          shahess Shannon Hess added a comment - I think I would classify it as "a side effect of asynchronous processing" rather than a bug. However, I can split the reload issue out as a major bug, but think I still need some direction on how it should be solved then. If the superuser tab is displayed when there are no action items, there is a high chance that the actions displayed are not complete and that the possible actions may change within seconds and will be invalid. Is that acceptable? Is a warning message desired in this situation then?
          Hide
          shahess Shannon Hess added a comment -

          I talked to Gayathri a bit about this. I'm going to go ahead and split out these issues so that I can set the priority differently for each. I appreciate everyone's input on this issue.

          Thanks!
          Shannon

          Show
          shahess Shannon Hess added a comment - I talked to Gayathri a bit about this. I'm going to go ahead and split out these issues so that I can set the priority differently for each. I appreciate everyone's input on this issue. Thanks! Shannon
          Hide
          gathreya Gayathri Athreya added a comment -

          Thanks Shannon!

          Show
          gathreya Gayathri Athreya added a comment - Thanks Shannon!
          Hide
          abyrne Ailish Byrne added a comment -

          it seems like based on what chris said when you create the one about the reload, you need to include route status and route log (maybe others? - but basically it should comprehensively consider the things not immediately up to date on the document due to asynchronous processing)... and i definitely think that if we engineer something to address this (assuming it is something like making the user wait until the async processing is complete, which i think is our only option), kfs will want to be able to turn it off, with a preference for efficiency of processing and the knowledge that users are already trained on the fact that these things aren't updated immediately. thanks!

          Show
          abyrne Ailish Byrne added a comment - it seems like based on what chris said when you create the one about the reload, you need to include route status and route log (maybe others? - but basically it should comprehensively consider the things not immediately up to date on the document due to asynchronous processing)... and i definitely think that if we engineer something to address this (assuming it is something like making the user wait until the async processing is complete, which i think is our only option), kfs will want to be able to turn it off, with a preference for efficiency of processing and the knowledge that users are already trained on the fact that these things aren't updated immediately. thanks!

            People

            • Assignee:
              shahess Shannon Hess
              Reporter:
              gathreya Gayathri Athreya
            • Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: