Configure External Auditor Access

From C3 Wiki

[edit] Summary

At various times it becomes necessary to make a site available to an external auditor. It's important to ensure that your site is prepared before the request is made if you're going to be able to provide a flexible but fine-grained solution. While there are multiple good options for approaching this task, Wake Forest has implemented an activity driven approach for adding and removing auditor access.

[edit] Required Elements

• New user role External Auditor
• New set of type Person on Study project type
• Activity on Study project type
• New security policy and corresponding custom search on each project type on which access will be granted

[edit] Configuration

• Use activity on Study to expose the set of person. Filter the set of person with a custom search that returns only persons with role External Auditor. Expose activity notes to record any details of why the auditor was added/removed. Set permissions on activity to allow IRB Director or Staff to manage auditor access.
• Create security policies for each project type. The corresponding custom search should return projects where the set of person contains the logged on user. Child project types of Study can look at the parent study. It's also important to note that if you have an Amendment workflow that contains a Modified Study, the Study project type's security policy should take this into account; you can access the parent study from a modified study as follows: Modified Study.Parent Amendment.Parent Study. This will ensure that all modified studies are made available to the auditor.
• If your Study workflow has an Original Study, this also needs to be taken into account. Original studies are not aware of the active study by default, so a custom search cannot be used in this case. The best way to do this is to use script on the activity to manipulate the set on the Original Study. The following script is an example of this technique:

 //SEM 5-19-2008: Add auditor to original study
// Because of the application object model (there is no application.parent study), we can't build a security policy 
// to allow an original application to be aware of a custom attribute on the active study. 
// For this reason, we need to manually maintain update set on the original app to be consistent with the active study.

var setAuditorsOnActiveStudy = targetEntity.getQualifiedAttribute("customAttributes._attribute265.customAttributes.ExternalAuditors");
var setAuditorsOnOriginalStudy = targetEntity.getQualifiedAttribute("customAttributes._attribute185.customAttributes._attribute265.customAttributes.ExternalAuditors");
var OriginalStudy =  targetEntity.getQualifiedAttribute("customAttributes._attribute185")

var newSet = ApplicationEntity.getTypeNamed("Person").createEntitySet();
if (setAuditorsOnActiveStudy != null) {
   var col = setAuditorsOnActiveStudy.elements()
   for(var i=1; i<= col.count(); i++) {
      newSet.addElement(col.item(i))
      wom.log("Populating set with item " + i);
   }
}

//Ensure the original study exists before setting the attribute. It won't exist if the study is not yet approved
if (OriginalStudy) {
   targetEntity.setQualifiedAttribute("customAttributes._attribute185.customAttributes._attribute265.customAttributes.ExternalAuditors", newSet);
}