- This line was added.
- This line was removed.
- Formatting was changed.
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 the Totara Helpdesk 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:
- Help resources within the software via the help icon shown here:
- Totara documentation located at totara.help.
- Totara Academy training located at totara.academy.
- Totara Community forums and resources located at totara.community.
- Totara YouTube channel located at www.youtube.com/user/Totaralms.
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)
- Australian Eastern
- New Zealand
|Severity Level||Severity Level Description||Response Time Targets|
|Severity 1||Inability 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 4 hours, during extended support hours.|
|Severity 2||An 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 3||Incorrect 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.|
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:
|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.
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.
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
Report only one issue per request
Reporting multiple issues in one request impedes optimal issue resolution by:
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:
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.
|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:
|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.
Quiz submission emails do not contain body content
Reported by subscriber. Replicated in Totara 2.6.5.
The strings for 'emailconfirmbody' and 'emailnotifybody' is not present in the body of quiz notification emails, only the subject is shown.
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'.
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.