Reporting by Organizational Units

1 Requirements

Currently, ILIAS only offers reporting in a restricted way that isn't suitable for the reporting needed in big companies and organizations:

• On Course level only
• All over the entire system (e.g., in "Statistics and Learning Progress > Learning Progress"):
  Even if you decided to make such views accessible for trainers, superiors etc., it would not be compliant with privacy requirements as those views contain data on all users and all courses.
• Via the Personal Desktop:
  Users holding the "Edit Learning Progress" permission of a course can view a collection of data on a specific intercept of courses. Pretty well ...
  The problem here is that you need separate courses for every organizational unit to ensure that only trainers or superiors in charge have access like that.
  However, in many cases the same educational program and content is used throughout the entire organization, so you would actually need just one course (which would spare a lot of complexity regarding repository tree and RBAC).
  

Thus, what is needed is a kind of reporting that allows to map complex organizational structures without oversizing the repository.
The approach of organizational units provides such a facility, and the reporting discussed here as a feature built upon such an organizational structure.

Aspects of a reporting by organizational units:

• Which ones of my employees have processed courses?
• Reporting within courses but filtered by employees of "my department"
• Filter by:
  • Organizational units
  • Users (of "my department")
  • Courses
  • Period (means: learning progress at the current time in a course that has taken placed in the defined period)
• Data: Learning Progress status, Certificate issued y/n

• What learning data are to be reported on what level (what object data, which filters are available, how is the data represented)?
• What management level has access to what reporting data?

This article is only a part of an entire complex of features.
Immediately related topics are:

• Bulk Course Assignment by Org Units
• Training Budget
• Course Booking/Cancellation by Superiors

2 Status

• Scheduled for: Not scheduled yet
• Funding: Required
• Development: Feature is to be developed by tbd

3 Additional Information

• If you want to know more about this feature, its implementation or funding, please contact: wischniak (at) qualitus.de

4 Discussion

Martin Studer sr.solutions, 2015-02-18: Please have a look at our reporting plugin. It's a generic way of reporting:
https://github.com/studer-raimann/Reporting
 
Video: http://youtu.be/yHBQEYW1P5E

5 Implementation

• The current (patched) reporting approaches often use a nightly cron job to migrate the data needed for the reports into extra tables. One main reason why this is needed, is that memberships of courses cannot be determined in a performant way.
• Current patches use PHPExcel since SpreadsheetWriter is not able to support very large files.
• Caching approach for high level reports need revision.
• Lots of customer related code need to be removed.
• Other code that is unused and code that need revision.

The current patches implement very complex queries for the reporting. We must analyse these queries and ensure that performance is kept.