BugLogHQ (v1.8)

https://github.com/oarevalo/BugLogHQ

BugLogHQ is a tool to centralize the handling of automated bug reports from multiple applications. BugLogHQ provides a unified view of error messages sent from any number of applications, allowing the developer to search, graph, forward, and explore the bug reports submitted by the applications.

Copyright 2009-2013 - Oscar Arevalo (http://www.oscararevalo.com)

Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except in compliance with the License. You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language governing permissions and limitations under the License.

BugLogHQ is a tool to centralize the handling of automated bug reports from multiple applications. BugLogHQ provides a unified view of error messages sent from any number of applications, allowing the developer to search, graph, forward, and explore the bug reports submitted by the applications. All bug reports received by BugLogHQ are stored on a normalized database, thus providing the option to the developers to further extend the application to leverage this information.

Release Notes

New in 1.8 (4/2012)

Users can now be restricted to access only specific applications assigned by the Administrator. Restricted users will only be able to see bug reports for their assigned applications and create rules for those applications.
CRUD screens to manage Severities, Hosts and Applications. These are accessed through the Settings page and are only accessible to users in Admin role.
The REST listener can now receive data in the body of the HTTP request encoded as a JSON object
Checkpoint Tracking. The CFM client now has a checkpoint() method that you can use to track checkpoints or milestones during the page execution. If a bug is sent, then those checkpoints will be displayed on the full bug report.
Remote Listener. This is a different listener type that allows the BugLog webapp and the Listener endpoint to be on separate servers, while at the same time allowing the webapp to control the listener.
Individual users can now be assigned their own API keys to submit bug reports
Added option to toggle on/off the automatic creation of hosts/severities/applications when a new bug report is received.
Rules changes are now applied immediately without the need to restart the listener service.
CFM applications using the buglog client can now set the application name explicitly, max depth for cfdumps and toggle logging messages locally.
Added a basic ANT build script for generating a ZIP file suitable for deployment.

New in 1.7 (9/2012)

A new "Dashboard" homepage.
More granular and finer timespans to view received errors.
A log of each time an alert is fired with information on the bug report that triggered the alert.
Optional HTTP Basic authentication for access to RSS feeds.
Expose the results of any search criteria as an RSS feed.
A new client written in JavaScript to allow client-side webapps to report errors to a BugLog server.
Centralized and standardized display of dates and times, including support for time zone conversion.
Display additional insights and context for each bug report (timeline, other reports from same user agent, host distribution)
Allow deletion of bug reports
Improved listing of current rules to provide a human-readable description of what they actually do.
Use jQuery and Twitter Bootstrap for the main user interface.

New in 1.6 (7/2012)

Support for "Named Instance" deployment. A Named Instance means that you can have multiple instances of BugLog running on the same server at the same time. Each instance have their own configuration and point to their own databases.
BugLog can now (optionally) run out-of-the-box on any directory (even the webroot).
Added support for PostgreSQL (contributed by Morgan Dennithorne)

New in 1.5 (2/2011)

Extensions are now stored on a database instead of an XML file
Creating a rule instance is now much more user friendly because application, host and severity codes can be selected via dropdowns; or can also be prepopulated from an existing bug report.
Added support for defining settings for multiple environments (dev,qa,prod1,prod2,etc). Once the environment is detected buglog can override any setting with custom values.
Added option to disable editing settings through the UI (useful if you have your config file versioned and only want to configure buglog that way)
Added the "BugLog Digest" which is a configurable and periodic email summary of all reports received in the last X hours.
Rewrote the "iphone" UI to be for mobiles in general (now its accessible at /bugLog/mobile), also there is an improved platform detection when going to /bugLog. If you go with any mobile browser you should get redirected to the new UI, otherwise you go to the regular desktop UI
Multiple bug fixes

New in 1.4 (11/2009)

Bug reports and rules are now processed asynchronously and not at the time they arrive. This largely increases the response and scalability of the system. The default interval for execution is 2 minutes but this can be configured easily.
Reduced the number of configuration files (only 2) and moved them to a single location.
Added a "settings" screen to the main interface to allow administrators to configure multiple aspects of BugLogHQ as well as perform user management.
Added support for integrating with JIRA. When enabled allows sending issues directly from BugLog to a JIRA instance.
Added support for multiple users in two roles: administrators and regular users.
Added option to change user password.
Added option to require an API key that each application must send in order to submit bug reports.
Added option to disable rules without having to delete them.
Added more rule types and extended configuration options for existing types.
Added option to purge history so that old data can be deleted
Multiple bug fixes.
Deprecated support for storing data in XML files (it really really didn't make any sense)
UPDATE: Added custom web interface for iPhone/iPod Touch. See /bugLog/iphone

New in 1.3

This is a release of mostly internal changes. The entire data access layer has been refactored to use an improved mechanism that makes it easier to work with different backend data storages. See: http://www.oscararevalo.com/index.cfm/2007/11/28/Using-Polymorphism-and-Inheritance-to-Build-a-Switchable-Data-Access-Layer
The BugLogHQ application (where you go to see the bug reports) has also been updated to improve performance and use the new DAO layer.
Configuration of data storage is now done via a config xml on the /buglog/config directory.The file is dao-config.xml.cfm. Here is where you can set the DSN, user, password and dbtype. From here, you can also change the storage mechanism from a database to simple XML files (maybe for a quick test drive)
Fixed bug that would throw errors if the email addresses for top-level error reporting were not defined.
Added a directory /bugLog/tests that contains files to test both the client and server side of buglog, and also can be used as a refence as to how to implement the client side of bugLog.
BugLogListener now uses memory caching to improve performance and process bug reports faster
Fixed sql scripts for MSSQL, all tables should now be configured with primary keys defined as numeric identity values
bl_source table no longer needs to be populated with pre-defined values. The listener will insert these as needed.
Added bugLogProxy.cfm for integration with BugLogMini ( http://buglogmini.riaforge.org/ )

New in 1.2

Support for a configurable and extensible rules system. Rules are processes that are applied to each bug report as it is received. Rules can be defined for tasks such as sending notifications when a bug of given conditions is received; when the amount of bugs received in a given timeframe is greater than a defined threshold, etc. The rules system is extensible in the sense that each rule is implemented as a CFC with a common interface. For more info on rules see: http://www.oscararevalo.com/index.cfm/2007/10/2/BugLogHQ-New-Rules-feature

Integrating BugLogHQ into your Applications

Applications can send bug reports to BugLogHQ via three different ways:

webservice call
http post
direct CFC call

BugLogHQ provides a CFC that can be used to send the bug reports. This CFC is located in /bugLog/client/bugLogService.cfc. This is the only file that needs to be distributed with any application that wants to submit reports to BugLogHQ. The client cfc requires at least a CFML engine compatible with Adobe ColdFusion 8.

You may instantiate and keep the instance of this CFC in some a scope such as Application and then just call the notifyService() method in it whenever the application needs to submit a bu

BugLogHQ

Install / Use

README