reportbuilder/spec as user stories
Reporting Spec as user stories
I've taken the content from https://docs.moodle.org/dev/reporting_spec and tried to convert them to user stories detailing what is required:
To access the data above an administrator typically needs to visit a number of Moodle contexts and interfaces to retrieve data. This is especially true where the user is participating in more than one course.
In addition, reports on activity may be required on bases other than Moodle contexts. With the exception of Groups in courses users can only be reported upon in contexts to which they are assigned or lower contexts where permissions are inherited.
Augmented reporting capability
The following are my thoughts on how interfaces to improve the current situation could be evolved. There are 3 main interface areas:
• What is to be reported on i.e. courses, activities, attempts, actions
• Who is to be reported on
• Who can view and manage reports
What is to be reported on
Report configuration screens should progressively narrow down the data required in the report.
Screen 1: Display all courses in category tree. Select courses on which report should be based.
Screen 2: Display selected courses with activities listed. By default only activities with grading mechanism should be listed. Select activities to be included in the report.
Screen 3: For each course/activity remaining, “quick report” checkboxes for commonly required report items e.g. information sent to gradebook, completion status (if enabled).
Further link to detail page where more specific report criteria can be defined.
Screen 4: Detail page for course or activity.
System example detail options for report:
• Never logged in
• First login
• Last login
Course example detail options for report:
• First access
• Last access
• Course complete
• Course grade
• Group name(s) where user is a member
• Course role
• Enrolment method (where Cohort include cohort name)
Quiz example detail options for report:
• Attempted
• Date /time of first attempt completed
• Total number of attempts
• Highest grade
• Attempt when highest grade achieved
• Date / time for attempt when highest grade achieved
• Grading method grade
• Grades for attempts i.e. grades for attempts 1, 2 and 3
• Date/time of first attempt
• Activity complete
Assignment example detail options for report:
• Submitted status i.e. submitted, draft, no submission
• Due date status i.e. lateness
• Graded status
• Date / time submitted
• Date / time graded
• Grade
• Outcomes
• Activity complete
SCORM example detail options for report:
• Attempted
• Date /time of first attempt completed
• Total number of attempts
• Highest grade
• Attempt when highest grade achieved
• Date / time for attempt when highest grade achieved
• Grading method grade
• Grades for attempts i.e. grades for attempts 1, 2 and 3
• Date/time of first attempt
• Status for (all) SCOs i.e. completed, Browsed, incomplete
• Activity complete
General:
Need options to add new, delete, copy and edit reports.
Who is to be reported on
Screens to progressively filter users:
Screen 1:
Select report i.e. What is to be reported on.
Typical defaults e.g. report on graded roles from Site admin gradebook settings.
Option to select roles to be reported upon by course
Active users (default)
Suspended users
Screen 2:
Group(s) to be included in report by course.
Option for all users
Option to include users not in a group.
Must be possible to report on more than one group per course i.e. multi-select or ability to add further single select drop-downs.
Screen 3:
Filter on standard profile user fields and bespoke user profile fields
Without specific development of functionality to associate users with an external hierarchy User profile fields are the only way I can think of to reflect this.
Who can view and manage reports
I think this will require a view and manage reports capability.
View:
Screen 1: Default option of users with view reports permissions in all of the courses included in the report because they are:
• Assigned to a permitted role; or
• Assigned to a permitted role in “Other roles”; or
• Inherit the required permissions from a higher context
Screen 2: Specific users (from pick list)
Screen 3: Users filtered on role and User profile fields
Manage:
Similar to the above?
Report format:
General considerations:
HTML table and CSV export (fancy charts can follow later)
In addition to info above option to include items ticked in User policies > Show user identity
Sortable by header
Ability to minimise column width
