General rules of reporting issues:

Test bugs in the latest version
- A bug can be reported only if it is repeatable in the latest version (current release version available on StandardInstall.com). But please test also the latest development version if you have access to development versions.
- No bug fixing is done in older versions, the solution is to upgrade to the latest version available.

Report bugs that can be repeated in sample data
- Repeat and report bugs using sample data.
- Don't report customer-specific bugs that can only be repeated using customer's Halcust, data or hardware. Contact a Development Manager to find a solution for addressing such issues.
- Never attach text backups with customers data to bug reports.

Dos and Don'ts for reporting an issue:

• - DO report bugs and wishes in English and using correct system terminology.


• - DO NOT report a bug where the programmer has to do 15 steps, and then the 16th step is the actual bug.
  Create a text backup with the 15 steps already done, so that only the 16th step needs to be done to see the bug.
  This wastes a lot of programmer time and will likely result in the bug not getting fixed.


• - DO NOT assume that the expected result is obvious. DO always add explanation for both "Bug" and "Expected" sections in the description.


• - DO rename your text backup files, instead of TB.TXT rename the file to a shortened version of the bug title. An keep in mind the OS filename symbol limitations.
  The reason for this is that a programmer may end up with 50 text backups in downloads folder and all with the same name TB.TXT, and will not know which backup relates to which bug.
  Add the name of the text backup in the bug report's description's first or second step.


• - DO NOT attach screenshots with names like "Screenshot 2023-09-24 at 16.24.55.png", DO rename screenshots and other attached files similar as with backup files.


• - DO NOT attach an un-zipped backup to the mail. It takes much longer to download.
  Zip your text backup, but make sure that it has been renamed BEFORE zipping.


• - DO NOT leave out any steps when explaining how to repeat the bug.
  Left out steps may seem obvious to you, but will not always be obvious to the programmer who is trying to fix the bug.


• - DO attach a backup when it might be needed for a wish development.
  Example would be for an integration improvement wish - such text backup would be based on sample data and contain all the integration setup.


• - DO use the correct module or function Tags when reporting the bug.
  This makes searching for related bugs much easier.


• - DO NOT change the bug or wish title.
  If the title is clearly wrong then change the title, but add a comment describing what was the old title before it got changed.


• - DO add in comments a related bug or wish title for reference.


• - DO NOT write long stories and thoughts in description fields. Use the comment section for that.


• - DO use the comments section to add comments like "still repeatable in version X" or if there is a discussion or when a new file got attached.


• - DO use the "Groups" feature. You can create a team with multiple StandardID users to give them access to certain bugs and wishes.


• - Avoid using double quotes in bug titles.


• - If the bug report is about a report, maintenance, export etc. that needs a reporting period, put the required date period at the top of the reporting periods setting in the back up so it is the default.


• - If the bug report needs a back up to be imported several times (i.e. repeated testing), put the relevant module at the top of access groups.


• - If it will be helpful, sort and save the relevant browse window so that the test record is at the top.