Knowledgebase: eClass For Instructors
U of A eClass Feature Requests and Custom Development

Since the eClass Learning Management System (LMS) is based on an open-source product (Moodle), the IST eClass support team has the opportunity to make local customizations and improvements. Where possible, these changes are accomplished by creating new plugins or integrations - as opposed to making core moodle modifications (which can impact our ability to keep pace with the application's regular upgrades.) The following steps outline the IST eClass team’s general process for intake, assessment, and prioritization of new feature requests for eClass.

Submitting Feature Requests

Requests for new features or improvements in eClass can be made at any time by contacting the IST eClass team at or by phone at 780-492-9372. Requests can also be contributed by the IST Executive and eClass teams, the IST Director of Learning Technologies Jeff Rawlings, as well as our governance bodies: the Information Technologies Steering Committee - Teaching and Learning (ITSC-T&L) and the Information Technologies Advisory Board (ITAC). (For more information on IT Governance for Teaching and Learning, please see here.)

Feature requests are classified as any request for improved or missing functionality in eClass. Requests can include, but are not limited to:

  • Improvements to existing features/plugins within eClass
  • Open source components such as moodle plugins or LTI modules
  • Third party services that could be integrated into eClass

The IST eClass team works on a case by case basis directly with each requester, and will contact the primary stakeholders for each feature request to inform them of progress and status changes throughout the process.

Request Approval

Once a feature request has been submitted, the IST eClass team contacts the requester to document and validate some initial details. During this phase, we work with the requester to gather basic information and answer the following questions:

  • Does the requested feature attempt to address a known issue that is already in development with
  • Does the requested feature have an achievable and reasonable workaround?
  • Does the requested feature require core code modifications in eClass?

If a feature request has already been identified and worked on by core moodle developers, or if it requires changes to core moodle code, the requested feature will likely be rejected to prevent duplication of effort. Similarly, if a requested feature has a reasonable and achievable workaround (ie. a workaround that requires less resources to implement than the requested change), it is unlikely that the request will be approved.

Whether a particular feature request is accepted or rejected depends on the evaluation by the team, approval by the IST Director of Learning Technologies, and alignment within the Teaching and Learning strategic direction established by our governance bodies (see above).

Request Prioritization

Successful feature requests that have gone through the intake phase are then triaged and prioritized by the IST Director of Learning Technologies against all other pending and backlogged feature requests.

Custom External Devlopment

Units and individuals on campus are welcome to develop their own custom solutions to meet course and department needs but are encouraged to get in touch with the team as early in the process as possible. We are often able to suggest valuable existing workarounds, provide details on relevant upstream or related work, suggest best development practices, and even identify potential contractors to complete coding. We have participated in this manner in the success of several TLEF projects, notably the new Analytics plugin in eClass.

If you have any questions about this process, development for moodle in general, or if you wish to request or suggest a new feature in eClass, please email

(0 vote(s))
Not helpful