Using our support issue logging system
1. Make sure your subject contains detail on the issue
When browsing lists of issues only subjects are shown, so it is important that your subject contains enough detail to identify the issue. Some examples below:
|404 error when trying to access the log-in page.
|Add a terms and conditions page to the footer.
|Title on the events block on the homepage should be click-able.
|News items no longer appear after adding block onto the news page.
2. Make sure the issue description contains a URL where possible
Adding a URL to your issue with save our engineers valuable time as they won't have to search your site in order to find the page you are referencing. In addition, including a URL will remove any potential confusion that might occur over exactly which page is being referenced to.
3. Set the priority appropriatley
When working on your site, our engineers will typically work through bugs in priority order.
4. Let us know your browser version
If the issue you are reporting is related to the style / layout of the site - then there is a chance that it is browser specific. In which case if you could include the browser name and version that you are using this will help our engineers to replicate the issue.
A quick method of obtaining your browser information is by using a site such as http://www.thismachine.info/
5. Include screenshots where appropriate
It can be hard to describe visual issues, adding a screenshot can quickly and easily demonstrate your issue. Adding a screenshot in a compressed format, such as png, gif or jpeg (rather than bmp) will ensure the screenshot will be much quicker to upload. This site has useful information on how to take a screenshot on various platforms http://take-a-screenshot.org/
|Issues in this status will be picked up by our engineers and dealt with accordingly.
|Issues in this status will be worked on by one of our engineers
|When an engineer is working on an issue the status will be set to in progress.
|Issues in this status typically have a question on them that requires feedback. For example if our engineer cannot replicate your issue they will add a comment asking for more details on how to replicate the issue.
|If an issue is not actually an issue, or has already been raised previously, then the issue will be set to ‘rejected’. Issues in this status will not be worked on further by our engineers.
|Fixed pending update
|Issues that have been fixed by an engineer in a development environment will be marked as ‘fixed pending update’. It is important to note that the fix will NOT be available to the client until the next release. Please do not attempt to re-test issues that have been marked as fixed pending update. Issues in this status will not be worked on further by our engineers.
|Issues in this status have been fixed and released into your testing environment for approval. After testing the issue the client should either change the status to ‘Approved’ or ‘For resolution’ depending on the outcome of the testing. Issues in this status will not be worked on further by our engineers.
|Issues in this status have been approved by the client and are ready for release into the live environment. Issues in this status will not be worked on further by our engineers.
|Resolved and Released
|After an issue has been released into the live environment it’s status will be changed to Resolved and Released. Any further problems with the issue should really be raised as new issues. Issues in this status will not be worked on further by our engineers.
1. Responding to a question
If an issue has been assigned to you in the status of ‘More information’, respond to the question by adding a comment to the issue and then re-assign the issue back to the engineer who asked the question.
2. Approving an issue
If an issue has been assigned to you with the status of ‘Pending approval’ and after testing the issue you are happy with the fix, please changed the status on the issue to ‘Approved’ and assign back to the engineer who previously set the issue to ‘Pending approval’