Reporting an Issue in Alfresco Community Edition
Alfresco maintains a public issue tracker at
Anyone can sign up for an account.
We struggle to manage the flow of incoming issues, and need your help to keep the issue tracker a useful platform for collaboration.
In order to manage the license cost of our issue tracker, we disable accounts that have not been used for two years. If your account has been disabled, please email email@example.com and we will reenable it for you.
No Support Requests
The issue tracker is not the right place for support requests. It distracts the engineering team from working on actual issues and improving the product.
Requests for help should be made in the forums at http://forums.alfresco.com. Please help others as often as you request assistance.
If you are not getting volunteers in the forum willing to help you out, you can hire some help in one of a few ways:
- Subscribing to Alfresco Enterprise Edition,
- Posting in the Jobs and Projects sub-forum,
- Reaching out to someone recommended by the Order of the Bee.
Submitting an Issue
Community contributed reports of issues in Alfresco Community Edition should go into the ALF project.
But members of the community can comment on public issues in RM, MNT, ACE, and SHA.
Issues are created in MNT based on support requests, and so default to being private. We open them when we validate that there is no customer information.
Other open source projects sponsored by Alfresco Software, such as Activiti, Aikau, and the mobile apps, have their own projects in JIRA, or use GitHub as their issue tracker.
Guidelines on a Good Issue Report
- Please search the issue tracker before creating a new issue! If you find it is already reported, add a comment and any additional environment or version information that might help us with the issue.
- Please follow the appropriate template below. If we cannot understand or reproduce your issue, we will have to close it.
- Another reason we commonly close bug reports is because the observed behavior is as designed, even though that design isn't optimal or does not match the use case of the reporter. This is unfortunate, but we have to prioritize our efforts.
- Don't include personal information, as the issue will be public.
Bug Report Template
A bug is an observed behavior that does not match the expected behavior for the system. If we cannot reproduce the bug, then we will have to close the issue. Therefore, it is important that we have the necessary information in the format that we expect.
The best reports follow these guidelines:
- Summary: A short sentence briefly describing the problem.
- If the bug affects the security of the product, select the relevant Security Severity and read the section below.
- Priority: This will help us understand how you feel about the issue, but we are likely to change it to match our criteria after we do further analysis.
- In the Components field, select the areas of the product that are affected by the issue so that the right team gets notified.
- In the Description field include:
- Description: Provide a summary of the issue
- Steps to reproduce:
- Detailed steps that reproduce 100% of the time, or description of what has been attempted to reproduce.
- Write as if the person reading the report does not know Alfresco very well.
<ol>ordered list to
<ul>unordered lists (bullets) as one can refer easily to a given step.
- Prefer to call test users 'userX' instead of 'test', test folders 'folderY', instead of 'a12', test documents 'testZ.txt', instead of 'y123', that makes the Jira more readable.
- Expected Behaviour: What should happen and why
- Observed Behaviour: What is actually happening
- Analysis to date:
- Business impact / priority / urgency
- Is this a regression? In which version did the behavior last work as expected?
- Any notes on your analysis that we should know about, such as a work-around or proposed solution
- If you include code to fix the issue, make sure to check the Patch Attached box so that it goes to the top of our queue.
- At can be helpful to include Attachments such as log files and relevant configuration files.
- In the Environment field, add in all the relevant environment information such as operating system, browser, database, and Alfresco installation method.
- In the Affects Version/s field, mark every version of Alfresco where you have observed the problem.
Improvement Request Template
The ALF project has an issue type 'Improvement Request'. This is used for requesting an enhancement to the system that includes new functionality and is not a fix to existing intended behavior. It is very hard to prioritize the enhancement requests we got through the issue tracker, and so they rarely get attention. The best way to request a product enhancement is to purchase a support subscription and raise the enhancement request through support.
If you decide to create an 'Improvement Request', make sure to follow the guidelines for reporting bugs, but in the Description field use this template:
- Summary of the enhancement
- Steps showing the current behavior
- The desired behavior
- The business case for making the enhancement (i.e. who is going to pay for it)
- Any workarounds in the current product
Improvement Requests with the Patch Attached flag do get attention. Please follow steps to submit a contribution.
The best way to correct the documentation is to submit through the feedback form on the relevant page of the documentation.
System security is one of our highest priorities and we understand security is important to our customers and partners as well. To follow are some guidelines on reporting a security issue to us and how to ensure that we get as much information on the vulnerability as possible. This will enable us to properly investigate, possibly reproduce and rate the severity of the issue before passing through to engineering for fixing. It will also allow for a faster overall service.
- Before raising a new security related issue, please search the issue tracker to ensure that the vulnerability has not already been addressed.
- Please mark the issue with an appropriate security severity. Remote exploitable vulnerabilities should be marked High. This will cause the issue to be private so that we have a chance to review it and prepare a patch before public disclosure.
Automated Reports from Security Scans
We understand that a security report (a penetration test or code scan for example) can often give generic information on a set of possible vulnerabilities, the information that we need to be able to progress these potential exploits within our security team are as follows:
- Ensure that the security issue 'relates' to Alfresco. This sounds obvious but often security reports just give a 'possible' exploit name based on packet matching or generic information on the environment. We need to be sure that the vulnerability being raised actually relates to a specific area of Alfresco.
- Give details of the exploit(s) and a practical example of how to exploit it/them. We understand that this is not always possible, however if we don't fully understand the vulnerability details or ways to exploit it, then we will have to clarify that before we progress the issue. Giving us a detailed breakdown of the (potential) vulnerability as well as a practical and reproducible example of how to exploit it, will enable us to not only progress the issue to our security team much quicker but also help us in establishing whether or not the issue is already addressed in a later version. Please also list any tools used/required to perform or prove the exploit.
- If you have a security report, we will need the specific security issues isolated, detailed and (hopefully) hand-verified in the case (as above). Additionally, it must have been run against the most recently available version of Alfresco.
- Ensure that any relevant logging, tracing or output complementing the security issue is provided.
Issue Triage Process
The process Alfresco uses to triage issue reports is documented on a separate page