Feature Wiki

Information about planned and released features

Tabs

Qualification Object

1 Initial Problem

Compliance requires some or all employees to have a valid qualification on a specific topic. Examples are 

  • Organisation are required by law to have department officers trained in a  field like health, safety, hygiene or equal opportunity standards. They need to have a valid qualification at all times to be officer. 
  • Hospitals must ensure that all professionals operating certain point of care instruments have a valid qualification to do so. 
  • Finance or insurance outfits must ensure that all their consultants advise customers compling to a code of conduct. All consultants need a qualification in advising compliantly. 
The main difference to the garden variety of training is that these trainings are not one-off:  This qualification needs to be maintained by re-training the employees regularly i.e. yearly. This requires a sentinel watching employees whose qualifications will soon become invalid. The sentinel needs to nudge employees to re-train in time and even to escalate if this does not happen. 

2 Conceptual Summary

The Compliance object can be added in the Repository. Adding has the typical create-dialogue with new, import, copy. 
The Compliance object has the following tabs

As always

  • Do we need "Multilingualism"?
  • Do we want "Certificates"?
  • A cron job is to be implemented to ensure all reminders for all compliance reminders are delivered in one daily digest mail, as known from courses.
  • Escalating to superiors is a separate feature request.

It would be much appreciated if registering for a course within a qualification the member registered would automatically become a member of the qualification. We do not know how to make this work at the time but we want it. 

Do we need "Mail to Members"?
Do we need " Generate List"?
Do we need "Export Participants"? 

  • This suggestion only distinguished between "valid qualification" and "no valid qualification". Please consider if there really, really must be a third status "virign" to distiguish those who never started from those whose qualification expired. There are upsides and downside to both status models, that need to be carefully considered. 

Do we need Metadata?

  1. Learn or be reminded: All members of the course that have not yet completed the learning module are reminded about their remaining workload by e-mail. Those that have finished the Learning Module are not reminded. 
    • The text of reminder-mail is editable. This is important to ensure that the mail is not regarded as ILIAS SPAM but taken seriously. 
    • If this requires a conceptual debate or lots of funds we are willing to withdraw this requirement and instead immediately send a mail to the tutor / superior (step 4). 
  2. Escalate: Once the deadline is reached tutors and / or superiors (if org units are used) get an additional e-mail containing the names of those users that have not completed the Learning module.  

Mail Template 

  • Welcome Mail, 
  • Reminder Mail
  • Escalation Mail 

3 User Interface Modifications

3.1 List of Affected Views

{Please list all views (screens) of ILIAS that should be modified, newly introduced or removed.}

3.2 User Interface Details

{For each of these views please list all user interface elements that should be modified, added or removed. Please provide the textual appearance of the UI elements and their interactive behaviour.}

3.3 New User Interface Concepts

{If the proposal introduces any completely new user interface elements, you might consult UI Kitchen Sink in order to find the necessary information to propose new UI-Concepts. Note that any maintainer might gladly assist you with this.}

4 Technical Information

{The maintainer has to provide necessary technical information, e.g. dependencies on other ILIAS components, necessary modifications in general services/architecture, potential security or performance issues.}

5 Contact

6 Funding

If you are interest in funding this feature, please add your name and institution to this list.

7 Discussion

Kiegel, Colin [kiegel] 2018-11-09: This is an interesting concept. Thank you for bringing it in.

I think it's quite interesting to have a compliance object wrap different course objects. I have never thought about it, but it opens up interesting use cases for content life-cycles and more.

The mailings are not entirely clear to me

  • is it possible to have two different mail templates for invitation (informative) and reminder (warning)? IMO it's important to have at least two different mails with different tonality, not only for first-time-learners, but also for refreshers.
  • I think the escalation mail should be configurable somehow - at least _who_ is going to receive them:
    • [x] escalate to tutors
    • [x] escalate to superiors
    • [x] escalate to members themselfes
  • I don't think it's sufficient to escalate once: How will superiors know if someone is still overdue? I think escalations need to be repeated in certain intervals (configurable).
Reports
  • I am missing information in the "Status per Member" report. I think it should have a differentiation of the "no valid qualification" status in (a) "before deadline" and (b) "after deadline".

    From our experience with these kinds of processes this differentiation is very important. E.g. we've come accross scenarios, where employees don't have corporate email accounts (think of sales personnel in a store). Then it may be the job of a store manager to inform his staff about the compliance status. For this kind of communication and supervision purposes it is utterly important to differentiate between "before deadline" (friendly reminder) and "after deadline" (do it now, please). This differentiation is needed in the per-person-report. It is not enough to differentiate between first-time-learners and refreshers, because first-time-learners do have a deadline too, and it is not obvious from the current report draft.

    In aggregated reports like per-course or per-org-unit, this differentiation might also be interesting, but not as essential.
Thanks again for this interesting proposal.

8 Implementation

{The maintainer has to give a description of the final implementation and add screenshots if possible.}

Test Cases

Test cases completed at {date} by {user}

  • {Test case number linked to Testrail} : {test case title}

Approval

Approved at {date} by {user}.

Last edited: 11. Dec 2018, 09:34, Tödt, Alexandra [atoedt]