The Totara Support Helpdesk is the web based system used to provide formal, ticketed support for Totara. It is the only official communications channel for Totara Support and other channels such as forums, email, and phone based support are not currently provided.
Please also note that the services of Totara Support are available in English only. Multilingual support is not currently provided.
You can access the Totara Support Helpdesk via helpdesk.totaralms.com.
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 that may involve software fixes for resolution.
Who can use the helpdesk?
The available tiers of support will depend on whether you are a Totara Partner or subscriber.
- For 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.
For direct subscribers: If you are a subscriber for a server or cloud-based Totara solution then you are able eligible for any required support.
To use the system, a user account must be set up by Totara and activated by the user using the link provided in a system invitation email.
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 that includes a suitable operating system, database server, web server, and scripting software that 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 that 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 that the functional issue exists in a plain vanilla installation of Totara, outside the context of any customisation, if raising a helpdesk ticket with Totara Support.
Clients considering developing new functionality that may be applicable to the Totara core are encouraged to contact their Channel Partner Manager to arrange a collaboration with the Totara core development team prior to beginning development.
Using the Totara Support Helpdesk
The Totara Support Helpdesk system can be used to:
- Submit support tickets.
- Check on the status of previously created tickets.
- View the history of previously created tickets.
When should the Totara Support Helpdesk be used?
A support ticket 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 site you are using.
- You need to request access 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 help.totaralms.com
- Totara Academy training located at academy.totaralms.com
- Totara YouTube channel located at www.youtube.com/user/Totaralms
- Totara Community forums and resources located at community.totaralms.com
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.
Logging in to the system
Go to the Totara Support Helpdesk URL and enter your login credentials.
The Forgot Password? Reset link (shown in the screenshot below) can be used to reset your password.
Creating a support ticket
Once logged in, create a new support ticket by navigating to the Submit a Ticket tab. Fields highlighted in red are required fields.
The Priority setting of Critical is reserved for data loss or security issues or issues involving the complete loss of a major functional component.
To ensure optimal issue investigations, please review and follow the Guidelines for Submitting Support Tickets when reporting issues to Totara Support.
Viewing your tickets
Navigate to the My Tickets tab to view a list of your tickets. You can choose to view All Tickets, only Open Tickets or only Closed Tickets.
Clicking an individual ticket number / subject displays the details of the selected ticket and allows you to navigate forward and backward through the list of tickets.
You can view/hide additional ticket details by using the More/Hide toggle.
Guidelines for submitting support tickets
Is it a bug or a feature?
Before submitting a support ticket, it is important to consider whether the ticket being raised is for a bug or a new feature request.
In the most straightforward cases, a bug is existing functionality that is clearly broken and and a feature or improvement is a desire for new or changed system behaviour that is different from the functionality that is currently implemented.
The distinction is 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 major new release.
Making such a determination is often a grey area and somewhat subjective but 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 major new 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 ticket (general)
Report only one issue per ticket
Reporting multiple issues in one ticket 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 ticket to capture and track each issue independently.
|Be clear, specific and as detailed as possible|
Totara provides complex, open source, enterprise level solutions that 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 ticket:
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 that 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 that 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 that 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 that may be required or that will assist with reproducing the problem scenario.
The issue is sporadic and/or cannot be reproduced
If a bug appears sporadically and cannot be reliably reproduced or if a data integrity issue is apparent but the causal steps that 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 often need a copy of the site database where the issue was observed.
Examples of Best Practice Bug Reports
Following are two actual Bug Reports demonstrating these best practice elements.
How does Totara provide bug fixes?
Software updates are provided via patches in minor point releases and/or major new releases.
Minor point releases (e.g. 2.7.6, 2.7.7, 2.7.8, etc.) predominantly contain bug fixes and minor improvements. These are referred to as "stable branches" and are delivered roughly on a monthly schedule.
Major releases (e.g. 2.7, 2.9, 9.0, etc.) predominantly contain new functionality and bug fixes that cannot safely be delivered in stable branches due to the nature of the software changes. These are delivered roughly 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 2.5.32, 2.6.25 and 2.7.8. However, patches are not backported to earlier point releases within the same stable branch. For example a patch that is provided in 2.7.8 will not be backported to 2.7.6.
- No labels