Details
-
Type:
Bug Fix
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: None
-
Fix Version/s: Backlog
-
Component/s: Development
-
Labels:
-
Similar issues:
KULRICE-13077 Investigate Implementing Super User Screen KULRICE-8300problems with implementation of super user tab KULRICE-12866 Implement Super User Functionality in KRAD KULRICE-5740Verify that super user document search is working properly after the doc search framework refactoring KULRICE-5341 UserSession 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-14165 Super User Validations on Documents KULRICE-1366When an EDocLite is opened for viewing, attribute content is cleared KULRICE-1911Javascript 'onblur' with 'alerts' causes browser misbehavior in EdocLite customValidator functions. KULRICE-2374Make sure that all KEW super user actions are available on WorkflowDocument -
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
I think this will be a good feature to get in. However, as far as number 2 above and as far as editable is concerned, I think we should add some configuration to the document to allow them to turn this off if they don't want it to happen automatically. They can always check super user membership in the stylesheet themselves if they want to make just a portion of the form editable to super users.
reviewed at 12/13/13 leads meeting. still useful.
Additionally, the "Save" button should be available to super users. This might happen automatically as part of addressing number 2 above.