which looks a lot more modern and builds a foundation for much more fundamental separation of front and back end. Massive efforts have gone into developing quality assurance measures during the development 1.5 cycle and continue to be a focus going forward. 1.3+ Developments Prior to 1.3, there were numerous challenges in the code base, such as the fact that the Perl code generated both database queries and web pages by using a combination of string-concatenation and string-printing page snippets to compose the resulting HTML. While this functioned reasonably well, it made the interface very difficult to modify, and interoperability with projects written in other languages particularly difficult. Additionally, most state was kept in global variables which were modified all over the place, leading to unexpected results on nearly every code modification. Faced with these challenges, the LedgerSMB team developed a new architecture that addresses these issues by adding support for templates in the user interface, and moving all database calls into stored procedures. Although closely resembling model-view-controller (MVC) in structure, it is not broken down in precisely the same way as other MVC implementations. The overall design considerations included a desire to ensure that multiple programming languages could be used cross-platform to access LedgerSMB logic and that security would be consistently enforced across these applications. Thus the LedgerSMB team envisioned a "one database, many applications" environment typical of SQL. The overall approach heavily leverages PostgreSQL roles (application users are database users, and are assigned roles). Access to the database logic for new code (added in 1.3 or later) goes through stored procedures that act like-named queries. Permissions are sometimes granted on underlying relations or on the stored procedures. The stored procedures have semantic argument names, allowing for automatic mapping in of object properties. These are then exposed to the Perl code through fairly light-weight wrappers. User interface code wrapped around Template Toolkit, which is also used for generating PDF's via LaTeX, CSV files, Excel, Open Document etc. Workflow is handled through relatively light-weight Perl scripting. History The project began as a fork of SQL-Ledger when Chris Travers, dissatisfied with the handling of security bugs in SQL-Ledger, joined forces with Christopher Murtagh to produce a fix for CVE-2006-4244. This bug was apparently reported to the SQL-Ledger author, Dieter Simader, several months prior to the Chris' working on a patch. The initial release of LedgerSMB, along with full disclosure of the