Report an Issue 

JIRA Issue Tracking

URL:  https://issues.onehippo.com

Hippo works with JIRA issue tracking software. The use of JIRA allows us to configure specific rules that ensure an efficient and timely response to all your issues.

Please use JIRA for all day-to-day issues: questions, bugs, etc.

Note: JIRA does not replace the telephone. If you need help urgently, it's best to contact us directly. Even then, it still helps a lot if you already have a JIRA issue to refer to.

Do not use our (public) JIRA system for potentially harmful security issues. See Security Issues Procedure for detailed instructions.

Issue Reporting Guidelines

When reporting an issue through JIRA please keep the following guidelines in mind.

  • Project: When raising an issue make sure you create the issue in the right JIRA project. If you have a HES you should always create the issue in your customer project. These issues are treated with priority. If you are using the community edition then you can use one of Hippo specific projects. The Hippo stack comprises multiple projects, see  Hippo Source Code to find the right JIRA project for your issue.
     
  • Issue type: Select only  BugNew Feature or Improvement. Please stick to one of these three issue types. Other values might be used by the product owner or manager.
     
  • Summary: Try to keep the summary concise. Ideally it should describe the issue in one short sentence. It is good practice to mention the feature or component name if it is not present in Component drop-down. For example you are reporting an issue with the translations dialog in CMS. In this case you can select CMS from the Component dropdown and enter the summary  "Translations: Unable to link folders".
    When reporting a regression bug, add a label "Regression" to the summary, e.g.  "Regression - Unable to create a document as author".
    Try to avoid generic terms like "CMS performance issue" if the situation occurs only under certain conditions.
     
  • Priority: An issue's priority is solely from a development and testing perspective. Please do not mix priority with severity (see below). When assigning priority remember the following points:
    1. Blocker - Release or production is blocked. There is no workaround. We cannot release the code unless this is fixed.

    2. Top - Major part of the feature is affected, it may turn into blocker if it is not fixed ASAP. We cannot release the code unless this is fixed.

    3. High - Part of the feature is not working as expected. We can release the code, but the issue must be documented as a known limitation.

    4. Normal - The feature is affected but there is a workaround. For example cosmetic defects where a feature is working as expected or information is complete, but appearance is as expected, mis-spelt or wrongly indentated etc.

    5. Low - Issue imposing loss of functionality but there is acceptable and easy work around.

    6. Trivial: Nice to have, end users will like to have it fixed.
       

  • Affects Version: This is important so do mention the version(s) in which you see the issue. It is good practice to elaborate this in the Environment field. Avoid selecting "Ongoing" or "Backlog".
     
  • Fix Version: The Fix Version will be set by the product owner once the work required by the issue is scheduled. Please leave this field empty when reporting an issue.
     
  • Assignee: When you raise an issue you can use the default which is "Automatic". It will automatically assign the issue to the Hippo Helpdesk or a project manager or product owner, who will look after it and re-assign if needed.
    If you add a comment to an existing issue to answer a question, please assign it back to the person who asked the question. Unassigned issues or issues assigned to the wrong person might be looked over by Hippo.
     
  • Environment: Provide name and version of all relevant software in the environment where the issue occurred, i.e. operating system, web browser, application server, database, Hippo CMS, Hippo Repository, HST, etc.
     
  • Description: Provide a detailed description to describe the issue at hand. In case of a bug the description should contain three sections:
  1. Scenario
  2. Steps to reproduce
  3. Result expected & actual

This makes it easier for us to understand and reproduce the problem.
A good reproduction path has:

  1. A URL or document path (including in which environment you're encountering the issue)
  2. One or more screenshots. Screenshots make it much easier to triage the issue. 
  3. Description of the steps to get to the unexpected behavior.
  4. If it's a bug and you have log files, please add those to the issue.

Please also include in the description if and how end-users are affected by the issue.

  • Attachment: Always attach screenshots and debug logs if possible, this speeds up the triaging process.
     
  • External ID: If you know a related issue or dependent issue, mention its reference.
     
  • Severity: This indicates to which degree the system is affected.
     

Maintenance Releases

Product issues that are picked up by Hippo will end up in a maintenance release. See the release notes overview page for more information.

 

Customer Project Issues

This section applies to issues that are part of a project that is maintenained by Hippo.

Once a developer is done with an issue and a tester has tested it, the issue will be marked as Resolved. Note that this doesn't necessarily mean the issue has been fixed in the acceptance environment. Usually there will be some time between the time an issue is resolved, and the time the code is released and deployed. An issue will be assigned to you once it is ready to be verified. In addition you can check the Fix Version of the issue and verify if that version has been deployed in your acceptance or production environment. You will get an email notification whenever a new version is deployed in a specific environment.

When you're done testing you can either Close the issue or Reopen it. Closing the issue means you've tested the issue and it's working as expected.
If you approve a version to go to production while there are resolved issues that are not closed or reopened, Hippo will assume you have tested all the issues and they can be closed.