Report an Issue

Customer Support Portal

URL: https://support.bloomreach.com/

If you are a Bloomreach customer, please use our Customer Support Portal to report issues. Bloomreach Support will provide you with all the necessary details in the onboarding process.

JIRA Issue Tracking

URL:  https://issues.onehippo.com/projects/CMS/issues/

Internally, Bloomreach works with JIRA issue tracking software. If you are not a Bloomreach customer and you want to report an issue with the Developer Edition, please use our public JIRA for this.

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 CMS JIRA project.
• Issue type: Select only Bug, New 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 Bloomreach.
• 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 Bloomreach 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 Bloomreach.

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, Bloomreach will assume you have tested all the issues and they can be closed.