[KULRICE-1744] Implement proper Super User support in EDocLite Created: 13/Mar/08  Updated: 16/Jan/15

Status: Open
Project: Kuali Rice Development
Component/s: Development
Affects Version/s: None
Fix Version/s: Backlog

Type: Bug Fix Priority: Major
Reporter: Eric Westfall Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: Old
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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.



 Comments   
Comment by Eric Westfall [ 13/Mar/08 ]

Additionally, the "Save" button should be available to super users. This might happen automatically as part of addressing number 2 above.

Comment by Eric Westfall [ 24/Jul/08 ]

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.

Comment by Jessica Coltrin (Inactive) [ 13/Dec/13 ]

reviewed at 12/13/13 leads meeting. still useful.

Generated at Fri Jul 03 18:04:06 CDT 2020 using JIRA 6.1.5#6160-sha1:a61a0fc278117a0da0ec9b89167b8f29b6afdab2.