The Totara Helpdesk is a web based system used to provide formal, ticketed support for Totara Partners and Direct Subscribers. It is the only official communications channel for Totara Support and other channels such as forums, email, chat and phone based support are not currently provided.

Using the Totara Helpdesk

The Totara Helpdesk can be used to:

  • Submit support requests.
  • Check on the status of previously created requests.
  • View the history of previously created requests.

Accessing the helpdesk

Visit totara.support and enter your username and password.

The Forgot your password? link can be used to reset your password.

Totara staff cannot obtain or reset your password for you.

Creating a support request

Once logged in, create a new support request by choosing the appropriate request type and completing the required fields.

The request types are:

  • Report a problem
  • Ask for help
  • Request a new feature
  • Ask for access

Request types have been designed to only capture the information required for each type of request. Instructions for each field are also displayed to help you.

Support requests are for obtaining support and are different from issues accessible via the public issue tracker. Totara Support will submit any required bug reports, new feature suggestions and improvements following submission of a request which can be viewed in the public issue tracker. See Issue tracker FAQs for further information.


Viewing existing requests

View all of your existing requests by choosing My requests.

You can filter requests by status, creator and type. It is also possible to search using keywords.


Searching and viewing troubleshooting articles

Prior to submitting a support request you can search across our troubleshooting articles for an answer to your query.


When submitting a request, articles which match the request summary are also displayed.


Select an article link to view it.

About Totara Support

Generally, Totara Support can help by investigating problems to provide assistance with technical and functional issues encountered with Totara products by Partners and Subscribers. If appropriate they will direct users to relevant self-help and training resources.

Levels of support provided vary but include:

  • Tier 1: Fielding questions and investigating issues of a general and basic nature regarding functionality.
  • Tier 2: Investigation of more complex usage issues requiring extensive and in-depth expertise.
  • Tier 3: Issues requiring the involvement of the Totara core development team which may involve software fixes for resolution.

Who can use the Totara Helpdesk?

The available tiers of support will depend on whether you are a Totara Partner or Direct Subscriber. 

Totara Partners: Tier 3 support only. Partners are required to provide Tier 1 and Tier 2 level investigation prior to escalating issues to Totara Support. 

Direct Subscribers: Eligible for Support Tiers 1-3.

Please note the services of Totara Support are available in English only. Multilingual support is not currently provided.

When should the Totara Helpdesk be used?

A support request should be submitted when:

  • Totara’s available self-help resources do not provide the assistance you need to resolve a technical issue with the Totara product you are using.
  • You need to request access or changes to Totara systems for your organisation.

Available self-help resources include:


Totara Community forums provide a mechanism for users to exchange ideas, share expertise and assist each other. Totara staff may participate in the discussions however the forums are considered a self-help resource and are not an official support channel.

Requesting access to the Totara Helpdesk

To use the Totara Helpdesk, a user account must be set and activated by the requesting user via the link provided in a system invitation email.

Totara Partners and Direct Subscribers:

Please submit a request to [email protected] and ensure you provide your:

  • Full name
  • Email address
  • Direct Subscriber name

Assisting Totara Support

You must provide reasonable assistance to us in determining and resolving problems you report. This assistance may include determination activities such as:

  • performing network traces
  • capturing error messages
  • collecting configuration information and other similar activities to allow us to reproduce the problem
  • resolution activities such as access to your personnel, remote access to the supported environment, or both.

Closure of support requests due to inactivity

Totara Support will follow up any support requests awaiting a response from you which have not been answered after 7 days. If Totara Support do not receive a response after a further 7 days, the applicable support requests will be closed due to inactivity. This is so Totara Support maintain a clear queue of work and ensure issues are being dealt with promptly.

If you believe it may take some time to gather any information requested, you may ask for a support request to be placed on hold for a period of time (as determined by you) to prevent premature closure.

You may reopen a closed support request at any time.

Support hours and response times

Support is made available from 8:00AM to 6:00 PM in the following timezones, Monday through Friday, excluding national and local holidays:

  • Pacific (US)
  • Eastern (US)
  • UK
  • Australian Eastern
  • New Zealand


Severity LevelSeverity Level DescriptionResponse Time Targets
ProfessionalEnterprise
Severity 1Inability to use any major functions of the Totara Software, resulting in a critical impact on the User. Time to respond is 1 Business Day.Time to respond is 6 hours, during extended support hours.
Severity 2An important existing functionality is not available and there is not an acceptable workaround. (E.g., a course cannot be published or a previously published course is otherwise unavailable, or an administrator menu feature is not available.)Time to respond is 1 Business Day.Time to respond is 6 hours, during extended support hours.
Severity 3Incorrect behaviour of the Totara Software. (E.g. a cosmetic problem, applicable help files or an important existing functionality is not available but there is an acceptable workaround.)Time to respond is 5 Business Days.Time to respond is 5 Business Days.

Escalating issues

Please see the 'Escalation Process' section of your Subscription or Partner Agreement.

What does Totara Support not cover?

Specifically, Totara Support does not provide support for the following:

Issue typeDescriptionNotes
System engineering issues

Totara server based installations must be run on a platform which includes a suitable operating system, database server, web server, and scripting software which are configured to meet the needs of each installation. Beyond specifying minimum requirements and recommended specifications, Totara Support does not provide investigation of or assistance with system engineering issues related to the underlying platform on which the Totara instance is deployed.



This exclusion does not apply to subscribers of Totara Cloud solutions which include full platform support.


3rd party plugins

Plugins which are provided as part of the Totara software installation package are the only plugins which are supported by Totara Support.

Any and all other plugins are used at your own risk and are not supported by Totara Support.

-
Customisations

As open source software, Totara instances are often customised to meet business specific functional needs. While Totara fully endorses the open source ecosystem, such code level customisation are beyond the scope of the core Totara system.

Therefore, Totara Support does not assist with or provide support for such customisation. If you encounter an issue you think is a bug in Totara while working on a customisation, you must demonstrate the functional issue exists in a non-customised  installation of Totara, outside the context of any customisation, if raising a helpdesk ticket with Totara Support.

Customisation includes manipulation of data within the Totara database by non-Totara core software, scripts, or manual processes. Totara’s data schemas are complex and such external data manipulation may introduce data integrity issues which are not resolvable and are beyond the scope of Totara Support.

Clients considering developing new functionality which may be applicable to Totara core are encouraged to contact their Channel Partner Manager to arrange a collaboration with the Totara core development team prior to beginning development.

Guidelines for submitting support requests

Is it a bug or a feature?

Before submitting a support request, it is important to consider whether the request being raised is for a bug or a new feature.

In the most straightforward cases, a bug is existing functionality which is clearly broken and a feature or improvement is a desire for new or changed system behaviour which is different from the functionality currently implemented.

The distinction might seem like semantics as they will both ultimately require code changes, however the distinction is important as it determines whether or not the code changes can be delivered in a minor point release or only delivered in a new major release.

Making such a determination is often a grey area and somewhat subjective, however it must take into account not only the desired behavioural change but technical aspects of the underlying implementation as well. Totara is open source and individual instances are often heavily customised, therefore consideration must be given to the potential impacts any such technical changes would have across the entire customer base.

Such technical considerations include whether or not the software changes would:

  • Produce a change to the user interface.
  • Require a database schema change.
  • Require an API change.
  • Have a high risk of introducing regression errors due to the area of code to be modified.

These are often overriding factors in what appears on the surface to be a minor functional change and determine whether or not the code changes can be delivered safely in a minor point release or will only be delivered in a new major release with a full quality assurance process across Totara .

Totara senior architects and developers ultimately make the call taking into consideration all the factors noted above.

In general, due to complexity, code dependencies and UI / UX changes, new features and improvements are not backported into earlier releases.

Guidelines for raising a request

GuidelineDescription

Report only one issue per request

Reporting multiple issues in one request impedes optimal issue resolution by:

  • Creating unnecessary communication delays while trying to clarify the issues.

  • Creating unnecessary communication confusion when trying to track the progress of the issues.

  • Creating the potential for issues to become lost in the mix if one of the issues turns out to be complex and requires significant, further joint investigation.

  • Limiting our ability to assign the issues across our global team to allow them to be worked in parallel.

Sometimes what initially appears to be a single issue, after further investigation, reveals itself to be a collection of separate issues.  In this case, Totara Support staff will split the request to capture and track each issue independently.

Be clear, specific and as detailed as possible

Totara provides complex, open source, enterprise level solutions which have highly configurable functionality.

To minimise the potential for confusion and avoid unnecessary information gathering delays, try to answer these questions as comprehensively as possible when creating a helpdesk request:

  • Exactly what are you trying to achieve?
  • Exactly how are you trying to achieve this?
  • Exactly what, if any, negative behaviour are you encountering which is preventing you from achieving your goal?
  • Exactly what behaviour were you expecting?
  • What screenshots demonstrate the problem scenario clearly (including settings pages and error messages)?

Avoid cropping screenshots if possible.  Sometimes surrounding information (such as the URL of the page or browser version) can be very valuable in understanding the problem.

We recognise helpdesk users have a wide range of knowledge and technical skills so we will request any additional information needed to progress issue investigations.

Guidelines for reporting bugs

For reporting bugs, there are two key criteria to address in order to get from reporting the bug to a software fix as quickly as possible.  

GuidelineDescription
Clearly and unambiguously state the issue

A clear and unambiguous statement of the issue, including a description of the negative behaviour which is apparently revealing a bug and the expected behaviour, aids in focusing efforts towards a software fix.

A bug report ticket is not simply a mechanism to capture information.  It is the mechanism used to communicate the issue you have encountered to someone else to a degree in which they can successfully progress towards a software fix.

As part of the issue description, consider and include if relevant:

  • The software version affected (required).
  • Is the installation non-customised or has it been customised?
  • Is the issue being experienced on a single or multiple installations?
  • Is the functionality broken or simply inconsistent with other system functionality?
  • Any settings changed relating to the area of functionality which could have an impact.
  • Any screenshots which help demonstrate the problem scenario, of relevant settings pages or any error messages, or both.

    Avoid cropping screenshots if possible.  Sometimes surrounding information (such as the URL of the page or browser version) can be very valuable in understanding the problem.

  • Any debug information available.
  • Elements of a fix if available (for technically advanced helpdesk users).
Provide step-by-step instructions to reproduce the problem scenario

The issue is consistently reproducible

In most situations a bug fix cannot effectively be tested if the reported problem scenario cannot be reliably reproduced. 

Clear, unambiguous reproduction steps allow a fix to be investigated, implemented and quality assurance tested without any delays due to the need to gather additional information to reproduce the problem scenario.

Attach any associated files which may be required or will assist with reproducing the problem scenario.

The issue is sporadic, cannot be reproduced, or both

If a bug appears sporadically and cannot be reliably reproduced, or if a data integrity issue is apparent and the causal steps which created the issue are unknown, provide as much detail as you can surrounding the observation of the issue.  If possible provide step by step instructions on what was being done when the issue was observed.

To investigate issues of this nature we sometimes need a copy of the site database where the issue was observed.

Best Practice bug report

Following is a real bug report example demonstrating best practice elements.


Example

Quiz submission emails do not contain body content

Reported by subscriber. Replicated in Totara 2.6.5.

Overview

The strings for 'emailconfirmbody' and 'emailnotifybody' is not present in the body of quiz notification emails, only the subject is shown.


Reproduction

Requisites:

  1. Create a course.
  2. Create 2 test users.
  3. Create a quiz with one question.
  4. Assign one test user to the course with a role of 'Trainer/Teacher' and assign the second test user to the course with a role of 'Learner/Student'.


Steps:

  1. Go to 'Course > Users > Permissions'.
  2. Select 'Learner/Student' from the 'Advance role override' drop-down and set 'mod/quiz:emailconfirmsubmission' to 'Allow'.
  3. Select 'Trainer/Teacher' from the 'Advance role override' drop-down and set 'mod/quiz:emailnotifysubmission' to 'Allow'.
  4. Log in as test user with 'Learner' role and complete quiz successfully. See Current behaviour.


Current behaviour

Emails should be received for both the Learner and Trainer users, but no body content shown which should contain the content for strings 'emailconfirmbody' and 'emailnotifybody'.


Expected behaviour

Emails should be received for both the Learner and Trainer users, with body content shown from strings 'emailconfirmbody' and 'emailnotifybody'.

How does Totara provide bug fixes?

Software updates are provided via patches in minor point releases, new major new releases, or both

Minor point releases (e.g. 12.0, 12.1, 12.2, etc.) predominantly contain bug fixes and minor improvements. These are referred to as 'stable branches' and are typically delivered on a monthly schedule.

Major releases (e.g. 9.0, 11.0, 12.0, etc.) predominantly contain new functionality and bug fixes which cannot safely be delivered in stable branches due to the nature of the software changes. These are typically delivered on an annual basis.

As determined by the development team, patches may be backported to multiple releases. For instance the fix for a given issue may be provided in 10.15, 11.11 and 12.2. However, patches are not backported to earlier point releases within the same stable branch. For example a patch provided in 12.2 will not be backported to 12.1.

On this page

  • No labels