Details

    • Type: Bug Fix Bug Fix
    • Status: Open Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: Backlog
    • Component/s: Development
    • Labels:
    • Similar issues:
      KULRICE-13077Investigate Implementing Super User Screen
      KULRICE-8300problems with implementation of super user tab
      KULRICE-12866Implement Super User Functionality in KRAD
      KULRICE-5740Verify that super user document search is working properly after the doc search framework refactoring
      KULRICE-5341UserSession gets bound to a thread, and eDocLite documents are not establishing user session properly
      KULRICE-2279Add support to retrieve the user authentication Id directly from the workflowUser object
      KULRICE-1366When an EDocLite is opened for viewing, attribute content is cleared
      KULRICE-14165Super User Validations on Documents
      KULRICE-1911Javascript 'onblur' with 'alerts' causes browser misbehavior in EdocLite customValidator functions.
      KULRICE-4810edoclite should give message to user when buttons are pressed
    • Rice Module:
      KEW

      Description

      Currently, super user workgroup membership is not properly considered for EDocLite documents. For example, if I am in the super user group for an EDL and I open it, I do not get button that allow me to execute "Super User Approve" and/or Disapprove actions. In order to fully support super users, we should allow the following:

      1) A variable or workflow function indicating whether or not the currently authenticated user is a super user should be made available to the stylesheet (i.e. using WorkflowFunctions)
      2) If the user is a super user than they should be permitted to edit the document (i.e. the code in edu.iu.uis.eden.edl.components.WorkflowDocumentState which sets up the value of the "editable" variable should consider super user workgroup membership).
      3) If there is a pending approve/complete request on the document for a user who is not the super user, then the approve/disapprove button should still be rendered. In this case a super user "action request" approve command (or super user disapprove) should be executed instead of a standard approval. If the super user uses this button to approve the document then they should receive a confirmation pop-up (javascript) which informs them that they are preparing to super user approve for another user and verifies whether or not they want to proceed.

        Activity

          People

          • Assignee:
            Unassigned
            Reporter:
            Eric Westfall
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:

              Structure Helper Panel