- devel - lists.freelock.com

LedgerSMB 1.7.12 released
by Erik Huelsmann 27 Apr '20

27 Apr '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.12 * Reconciliation reports list now shows usernames rather than user ids (#4388) * Single payment interface throws error without open invoices (#4529) * Fix CSV data imports discading the first row (#4567) * Improve Chart of Accounts import no longer discards heading (#4567) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.12/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.12 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.12 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.12 These are the sha256 checksums of the uploaded files: 9f25e4a4ff7ac15d4cef7f9d615548b9866fc41fe40d5891c34b1d802157e532 ledgersmb-1.7.12.tar.gz 6537bd20015615a9f10e42e72bc9e1bb8d8a8d039152c2bf41a280100e97d50d ledgersmb-1.7.12.tar.gz.asc

1 0

Proposal to remove "1.3_date_auto" branch
by Erik Huelsmann 24 Apr '20

24 Apr '20

Hi, Our repository has had a "1.3_date_auto" branch for years that hasn't been maintained since 2014 (last functional commit on 1.3 branch: 2016). I'd like to remove that branch, retaining only branches that we used to provide community support for. Any objections? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 2

LaTeX::Encode versus TeX::Encode
by Erik Huelsmann 23 Apr '20

23 Apr '20

Hi Chris, Template::Plugin::Latex has an encoding routine which we're *not* using to encode data before being passed to (Xe)LaTeX. We're contemplating simplifying places in our codebase and one of the changes would be to use the built-in latex_encode. Do you have any recollection with respect to the choice for TeX::Encode and whether we should be fine to move to "latex_encode" all these years later? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 3

LedgerSMB 1.7.11 released
by Erik Huelsmann 11 Apr '20

11 Apr '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.11 * Fix inventory adjustments failing to update balances (#4467) * Fix inability to delete individual vouchers from a batch (#4448) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.11/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.11 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.11 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.11 These are the sha256 checksums of the uploaded files: 8df5172a1360e30ae8513766d3c42a2b0612c07f8e2810d0c55c59a9fe67dde2 ledgersmb-1.7.11.tar.gz 94417b9baedee37f76f5578e15e4fd8ce0a3a4870b174008d4c6bc987c1ce4ad ledgersmb-1.7.11.tar.gz.asc

1 0

Using Vue to drive our Single Page Application (SPA)
by Erik Huelsmann 22 Mar '20

22 Mar '20

Hi! Since 1.4 (released in september 2014), we have used Dojo Toolkit with its Claro theme for a professional (business) look-and-feel as well as providing users with more direct feedback on their actions (such as checking that required fields are correctly provided). Even today, we're using Dojo 1.16 to support our 1.8 development. Although Dojo is serving us well, the world has moved on. Even the Dojo developers have moved to developing Dojo 2 - a toolkit which is technically completely incompatible with Dojo 1, although it is built on the same philosophy of what's required for professional-looking web applications. For quite some time, it has been apparent that we need to switch to something other than Dojo 1, even if it is only because Dojo 1 drags lots of cruft with it. Switching to Dojo 2 is - due to its incompatible nature with Dojo 1 - a similar effort as switching to something completely different. For that reason, I have been evaluating a number of options, along the following list of requirements: 1. *Separate framework, loader and widget library* With Dojo 1, Dojo and its Dijit library are all of the above. They are also very tightly integrated. 2. *Support our Dijit widgets and declarative code* There is too much dijit-html in our code base to make a step to a different widget library at this point: especially in 'old code' html is still being composed "inline", which means that we're not ready to make templates for all our code yet - an assumption that most current frameworks seem to depend on 3. *Support our desire to create new code using a service-based SPA approach* In order to move forward, we are implementing services for our 1.8 rewrites. This means we're investing in new technology and we should want to take advantage of the full capabilities of the new framework we will be selecting. In addition, I'd like to stick to developing our UI through some kind of templating as we have been doing so far using Dojo's declarative syntax -- Dojo also supports a programmatic syntax, but we have explicitly not gone there. Over time, I have been looking at the following frameworks to replace our Dojo 1 setup: * Dojo 2 * React * Vue * Svelte And skimmed over a lot of others. Going over the alternatives, I started with Dojo 2 -- this is several years ago, when Dojo 2 wasn't final yet. Back then, the developers were using a "build the application in code" (instead of templates) approach. When asked about it, they declared that templating can be bolted on, but it's not a concern of theirs. When I looked at React, it looked overwhelming, is/was using inline templates using JSX (plain, unquoted HTML inside JavaScript), which very much felt like our old code, but in JS instead of in Perl. I looked at Vue several times over the past years. Its templating system is relatively quickly understood. The first few times I went out to find widget libraries to go with it, however, each time I found that we still need to support Dijit widgets too -- and I'd hate to have mixed looks for newer and older code where older code would use Dijit widgets while new code would use Vuetify or similar. Last week, based on recommendations from John, I looked at Svelte. It looks extremely appealing as it doesn't prefer one widget library over another and has as its focus to send as little code over the wire to the client as possible. It achieves that by precompiling templates into optimized/targetted JS functions. Remained the question on how to use our Dijits with it. This morning, I decided to a proof-of-concept with one of these libraries. As I found instructions for Vue on how to create its renowned 2-way data bindings for non-native components, that's where I decided to start. Over the course of a single day, I was able to: * Load Vue and Dojo into the same page (without conflicting, ready to be used) * Create a Vue app out of the login page (no functionality yet) * Tie a Vue action to the login form submission (which required it to stop being a Dojo widget) * Create 2 Vue components encapsulating Dijit widgets to deal with 3 types of UI elements: 1. Button 2. TextBox (for text and password) * Find out how to propagate the content of the Vue button component to the Dijit Button widget to be used as the button caption * Set up two-way data binding between the Dijit TextBox widget and the Vue textbox component ... and it's only 4pm right now! :-) I've committed my code to https://github.com/ehuelsmann/LedgerSMB/tree/vue-with-dijit . Based on the experience above, I'm now quite happy with Vue as our main option to take the next step into expanding our SPA. In order to determine the right way forward for the application as a whole, though, further experimenting will be required: something as "simple" as our login page obviously is no match for the logged-in application which has a menu, error popup and main application section, each with its requirements to support this mixed setup. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

LedgerSMB 1.7.10 released
by Erik Huelsmann 07 Mar '20

07 Mar '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.10 * Fix error displaying NULL exchange rates (#4438) * Fix incorrect receipt totals due to number formatting (#4441) * Prevent re-approval of approved inventory adjustment (#4458) * Fix NULL transaction dates in inventory adjustment (#4463) * Fix alignment of numbers in Inventory Activity report (#4454) * Fix variance calculation on reconciliation report (#4486) * Fix CSV import through explicit version on HTTP::Headers::Fast dependecy For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.10/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.10 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.10 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.10 These are the sha256 checksums of the uploaded files: 0f8293675dd0c03d54cee80e5e65cd078b7fcf58aeb6f6443911cec7c0eb21e6 ledgersmb-1.7.10.tar.gz 02a00420a5837375ab15332171eda7df15d3c0e19b9d0af950745661b9c480ee ledgersmb-1.7.10.tar.gz.asc

1 0

LedgerSMB 1.6.20 released
by Erik Huelsmann 07 Mar '20

07 Mar '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.6.20 * Prevent re-approval of approved inventory adjustment (Erik H) * Fix NULL transaction dates in inventory adjustment (Erik H) * Fix alignment of numbers in Inventory Activity report (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.20/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.20 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.20 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.20 These are the sha256 checksums of the uploaded files: 85176d09e9f9e4a7c37c60f28239be53ab0e036ba7dd6cb28e48c15bdc291ab5 ledgersmb-1.6.20.tar.gz ca1253f8f2c62825ffc0e75ed36fff682e48b6ac37aa4a96bfce96bbdbe8d58c ledgersmb-1.6.20.tar.gz.asc

1 0

LedgerSMB 1.7.9 released
by Erik Huelsmann 10 Feb '20

10 Feb '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.9 * Fix authentication issue due to inconsistent cookie handling For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.9/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.9 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.9 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.9 These are the sha256 checksums of the uploaded files: 44383e829c460ef5a567e03e3a480c4c12083a0f3611f616b4cb37c9026372d4 ledgersmb-1.7.9.tar.gz b3b5c5123ad6994af2e6975df0efe44266b9773a4a3e39a37895ba59f13072b2 ledgersmb-1.7.9.tar.gz.asc

1 0

LedgerSMB 1.6.19 released
by Erik Huelsmann 10 Feb '20

10 Feb '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.6.19 * Fix authentication issue due to inconsistent cookie handling (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.19/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.19 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.19 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.19 These are the sha256 checksums of the uploaded files: 17d784a326e7963cd048e05c32d9a65ba56b43734ed72b6266d866456f225a6f ledgersmb-1.6.19.tar.gz 2822affae38bfd27c74812288bd33bac129b00c1890b2232d28794673c40bcf8 ledgersmb-1.6.19.tar.gz.asc

1 0

Splitting authentication layers
by Erik Huelsmann 08 Feb '20

08 Feb '20

Hi, As part of my preparations to introduce web services, I've found that many web APIs provide two ways to authenticate: (a) a session cookie which can be obtained by "logging in", or (b) an "API key" ; either the API key or the session cookie is then provided with each request to the API, authenticating the request with the session and/or user. It should be noted that neither requests providing an API key nor those providing a session cookie contain further credentials. For our (API) authentication, ideally, I'd like to be able to provide both the "api key" and the "session cookie" patterns for request authorization. Additionally, I'd like session authentication to be available using: - Username & password (preferably through CRAM-SHA2 or higher SHA) * Note that in this scenario, the password validation could be anything; even a Kerberos or LDAP server - WebAuth / FIDO2 - OAuth2 - Client certificate - (and more, if we come up with those) == The Problem == Our current authentication setup requires plain text username and password on the initial login and each further request. We currently use basic auth to supply these values. In addition, we use a session cookie, but that only serves to validate the session. Thus every request currently requires the username, password and session cookie. The username and password are required because those are used to set up the database connection at the start of the request handling. Most of the authentication systems above don't maintain a username/password combination visible to our server. By consequence, I'm looking for ways to eliminate the need for the username+password in the Web request. Also, if we'd want to use "API key" type authentication, that API key would need to hold in it (encrypted, but decryptable to the server) the username and password in order to be able to log into the database. Note that the previous sentence explicitly states "in the Web request": ideally, LedgerSMB authentication can happen on two different levels -- the web request level and the database connection level. Basically, I'd like to start making the distinction between the web request authentication and the database authentication in such a way that our database authorization (access control) remains PostgreSQL-role-based (that is: doesn't change from the current model). == The Proposal == My current idea is to separate the web authentication from the database authentication. The web application would use a generic user to set up the database connection, switching the session authorization to the role associated with the user, as if the user had logged in directly on the database. Technically, this is achieved by the Pg command 'SET SESSION AUTHORIZATION = username'. This means that once the session has been verified (either through the API key provided or the session cookie), authorization can be switched to the (web)authenticating user and regular processing (as we know it today) can continue. This solution using the session authorization is very similar to what the Graphile (graphile.org) project uses [they use SET ROLE instead of SET SESSION AUTHORIZATION -- there are subtle differences between their approach and my proposal]. The solution has the benefit of supporting direct connections to the database as they are today with all methods built into PostgreSQL, adding into the mix a second set of authorization options better suited to a web authentication scenario. == The Request == Please comment on the above to get a good common understanding of what I'm describing and the best possible implementation at that. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Some questions about the PGObject modules
by Chris Bennett 03 Feb '20

03 Feb '20

Hi, I've been working on and submitting ports, but there has been port-a-thons and hackathons right as I submit stuff. I took a long holiday this year as it rained and snowed almost non-stop. I also got delayed by my laptop having some kind of problem. I couldn't fix it, but it works fine with an older version of OpenBSD and I'm just running -current on my servers and doing this work there. I submitted PGObject a while back. Someone had to update the postgresql database test module for the testing to work. Then I realized looking closer that it does the same thing I do, it gets $dbh from elsewhere. I'm looking over the rest of these modules, but so far I am seeing mostly the same. Except for DBAdmin. So far running the database tests for that one are failing, including from the actual Perl build. I'm not sure that I am doing the tests properly. I'm going to ask and look at other ports in OpenBSD to see if I'm doing the tests correctly. We never directly use the Perl build for testing. We have a PostgreSQL testing module for that. I just saw mention of PGObject in github email. What does that mean? I haven't had a chance to look in the LedgerSMB code at the spots where those modules are being used. Otherwise, I've done a lot of work getting the modules ready. Submitted some and I've got several more ready to submit. I do have one problem. Several of the modules don't have DESCRIPTIONS. I already have one Plack that I have been asked to give a better description before it can be accepted (the encoding one). Also, the various PGObject-* are really bad on that. Is there any way to come up with something more official for the group? Perhaps like an overall description for the group with a detail for how each one fits into the group? Maybe something like: The PGObject set does ... and this module carries out the ... That would be extremely helpful. Once in the ports tree, no problems. -- Chris Bennett

1 0

LedgerSMB 1.7.8 released
by Erik Huelsmann 22 Jan '20

22 Jan '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.8 * Upgrade Dojo dependency to 1.15.1 * Load the template from the database when printing receipts * Prevent dead-locks in response to request from timed out session * Add monetary formatting to payments/receipts screen and report For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.8/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.8 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.8 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.8 These are the sha256 checksums of the uploaded files: 59a7ad10d8da1b28f298239c93ea4ca15fd348ff5d1517253dfe6a4b51d099a4 ledgersmb-1.7.8.tar.gz c91c4b3af21ac0ad8d6d5809678ed8e537596e15899d3142e196ac2a724f9876 ledgersmb-1.7.8.tar.gz.asc

1 0

LedgerSMB 1.6.18 released
by Erik Huelsmann 22 Jan '20

22 Jan '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.6.18 * Upgrade Dojo dependency to 1.13.5 (Erik H) * Prevent dead-locks in response to request from timed out session (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.18/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.18 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.18 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.18 These are the sha256 checksums of the uploaded files: e07f6afc54c33f30d5b914c7e28635640e5c246826f7f5054d0742c2f2214f62 ledgersmb-1.6.18.tar.gz 828c87904b13617f60f5011a97767dcf073be0534bb529363f28387c289ae51c ledgersmb-1.6.18.tar.gz.asc

1 0

New reconciliation rules in relation to payment changes?
by Erik Huelsmann 22 Jan '20

22 Jan '20

Hi, Over the past weeks, I've implemented a change in the way payments are being recorded: batch payments are now recorded explicitly (instead of implied) and payments entered into the invoice screen are now recorded (as opposed that they were not recorded as payments, but "just" lines on the invoice transaction). The next step in my improvement plan is to use the new payment information in Reconciliation. To understand the problem domain, there's a bit of context to be explained: technically, every invoice being paid in a payment causes its own line in the Bank GL account. These lines are grouped using a payment identification. Now that all payments are being correctly recorded in the database, we can tap into that information to summarize the bank reconciliation view: We can show payments as a single line. Where we're coming from is different: we used to aggregate lines on the Bank GL account by various fields (reference, counterparty, source reference, date, transaction type, mostly). The method we used to use, caused two payments by the same customer - entered without a source reference number - to be aggregated into a single reconciliation line. On the other hand it was impossible to post small corrections to payments through the GL: because the aggregation takes the transaction type into account, GL transactions and payment transactions (AR/AP) can't be aggregated into a single reconciliation line. I was thinking that the reconciliation could be changed to use this business rule: Aggregate into single reconciliation lines (so as to reconcile with a single bank transaction): * Payments and GL transactions on the same date with the same 'reference' * GL lines with the same date and same 'source' (source reference number) -- if the gl lines couldn't be merged with a payment This business rule allows reconciliation - as single reconciliation lines - of: * Reconciliation of payments *with their GL corrections* as a single payment line * Reconciliation of payments (without GL corrections) * Reconcilation of GL-entered lines with the same source code reference * Reconciliation of GL-entered lines individually (when no source code reference is entered) Is this what we want? It's wildly different from the criterion we currently use, where we aggregate all lines on the bank account, into lines where the differentiator is: * Date * Transaction type (ar/ap/gl) * Reference (AR/AP: internal eca ID; GL: transaction's "Reference" field) * Voucher number * Source reference number (Source field of transaction line) * Memo field content (transaction line Memo field) Note however, that in the current situation, there isn't a concept of "payment" in the database at the moment; transactions posted using regular and batch payments receive the same values for Date, Transaction type, Reference, Source reference number and optionally voucher (for bulk payments). Concluding: the old rule mostly aligns with payments, but on a different basis and may aggregate multiple payments into one. When we hash out the question above, I have a follow-up question of how the reconciliation process should work from a business process perspective. Let's try to hash this one out first. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 2

LedgerSMB 1.7.7 released
by Erik Huelsmann 12 Jan '20

12 Jan '20

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.7 * Fix currency column not being available in the parts screen For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.7/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.7 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.7 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.7 These are the sha256 checksums of the uploaded files: 3509cfa379c5752206a464abc0b04c1beaff66ee7a6b2e49c338d7808de9e08b ledgersmb-1.7.7.tar.gz b00f2b01607822d862c5ef7446c3c4e1d887204123e90d4441bec4da6e1020fb ledgersmb-1.7.7.tar.gz.asc

1 0

LedgerSMB community overview 2019
by Erik Huelsmann 28 Dec '19

28 Dec '19

Hi, As the year-end approaches, it's time to provide an overview of what our community has achieved over the past year. At the beginning of the year, in last year's overview, the hope was expressed that the MC branch would be merged this year and that the 1.7 release cycle would turn out shorter again than the previous ones. == Community interest == The hits on our web site show a stable line month-on-month, although lower than last year. Consensus has it that traditional websites get lower numbers of hits than several years ago because of mobile and other (social) media. Hits seem to be pretty stable now. During the year, we've seen the number of Watchers, Stars and Forks on GitHub slowly but steadily increase. Traffic seems to be slightly up on our mailing lists, the users mailing list especially, with questions from new users installing and configuring LedgerSMB. The number of active developers is a bit lower, than last year; some hang around in our chat channel to help evaluate changes submitted by active members, though. All in all, the community seems to be on-boarding potential and new users and experiencing its regular in- and outflux of developers. == Releases == Last year we hoped to release 1.7 in the first half of the year. With the release of 1.6.0 on June 10 2018, we hoped to be able to start doing yearly releases. We also expressed the hope to land the MC branch on master. We ended up releasing 1.7 on October 4 2019, a little less than 16 months after 1.6.0. We did reduce the release cycle, but not by as much as we'd hoped. In part, the longer-than-hoped-for release cycle was caused by the fact that the MC branch did land on master, which warranted additional test effort, especially of the database migration scripts against real-world data. All in all we released around the same number of times as we did in 2018: * 10 stable releases: 1.7.0 - 1.7.6 & 1.6.10 - 1.6.12 * 11 old-stable releases: 1.6.13 - 1.6.17 & 1.5.25 -1.5.30 == Packaging and installation == In preparation for the 1.7 release, some work was done on the Docker images to run on Debian Buster. However, we found that Buster deprecated the ssmtp package which we depended on and it was too late in our own release cycle to do any fundamental changes to our e-mail functionality. We ended up going back to Stretch to run 1.7 on. Further work will be required to make sure 1.8 offers similar functionality without depending on ssmtp. The Debian ledgersmb package for 1.6 transitioned to Buster. Which is great as Debian Stable now has a non-deprecated version in its package repository. Last week we found that the package unfortunately misses a few files. We hope to fix that really soon. == Development progress == Over the course of 2019, 40 issues were created, 19 of which remain open at this point. All 19 issues were created by the development team, many in the process of doing code reviews or development work. A total of 73 issues were closed in 2019, including issues created in prior years. From these numbers, we can see that now that the MC branch has been merged, there's time or room to work on issues not directly related to MC or the creation of infrastructure to support MC development. The development work spun off 304 pull requests on the LedgerSMB repository. The number of pull requests is a lot lower than in 2018 when the number was around 480. The 304 PRs triggered nearly 1000 builds on Travis CI. During the first half of the year, we developed large numbers of new tests, push coverage up from 34% in last year's report to 41% now. Although 41% still is by far not enough, we started to run into the limits of what Travis CI was able to provide us (which is: maximum of 50 minutes of run-time on each test job). We evaluated a number of other CI providers, including the option to run our own. We ended up going for CircleCI; to their service we moved our longest running test job (we left the others at TravisCI), because they account the total time to be spent by a project differently. Areas that we're currently spending time on, include: * Selection of a new translation engine which supports more than 2 plural forms * Building on last year's separation between printed-document templates and UI templates, moving more printed documents into the framework * Gradual polishing of 1.7 through regular fixes of issues left to be polished after 1.7.0 release * Polishing of the technical implementation and user experience of payments and receipts The 334 issues that are open today summarize into these statistics: * 71 are marked bite-sized; this means they should be good places to start for new-comers * 188 are marked as desirable enhancements * 43 are marked as being in our queue of design work (Note that an issue may fall into more than one category.) == New functionality and improvements == A long-standing desire was to remove code duplication in templates to generate output tables. This year, we managed to move all code using the old report table infrastructure to the new code base. While doing so, we also cleaned up fixed assets code. Another topic that we spent time on, is research on how other PostgreSQL based projects structure their authentication. One project that drew our attention was Graphile (https://www.graphile.org/) From their approach, we've come up with an approach that may help us simplify setting up the database connections and managing / reporting password expiry on login. == Looking forward to 2020 == In 2020, we'll likely release 1.8 in the second half of the year. I personally hope that we can shorten the release cycle to get to yearly releases around the middle of the year. With that schedule it'll leave a number of patch releases until the end of the year, allowing users to migrate to a stable release after closing their books at the end of the year (if they didn't migrate earlier already). For 2020, I'm also hoping that the idea to work concentrate on specific topics, moving from topic to topic to improve the software, leads to an attractive 1.8 release. The various topics have been grouped into GitHub "projects" (https://github.com/ledgersmb/LedgerSMB/projects) Topics that have my personal priority are "Payment/payment_link support for all parts of the code base" and "Polish cash and payments". The first is rather technical in nature and a prerequisite to address the issues collected into the second. For 2020, I'm hoping to complete at least one, but hopefully both projects. For 2020, I'm hoping for 1 or 2 new contributors (not necessarily developers; translators, testers, documenters or UI artists are all greatly appreciated!). If you want to contribute, but don't know where to start, please contact me. Leaves me only to wish everybody in our community - and their loved ones - a very good, healthy and prosperous 2020! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

LedgerSMB 1.7.6 released
by Erik Huelsmann 26 Dec '19

26 Dec '19

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. Please note that this release fixes an important translation bug that was introduced in 1.7.0, where only the menu was translated, instead of the entire UI. This release contains the following fixes and improvements: Changelog for 1.7.6 * Disallow rate entry for the default currency (#4236) * Fix formatting on-hand (OH) column on orders to follow user settings (#3334) * Fix UI translation other than the menu, regressed from 1.6 (#4293) * Fix missing 'Entered At' date in contact notes (#2822) * Fix removal of lines from orders and vendor invoices on entry (#3703) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.6/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.6 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.6 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.6 These are the sha256 checksums of the uploaded files: 9faa2df90c9d91610b754ec2d716e222c81f88b3dec11bff63625b7a50f2fc3f ledgersmb-1.7.6.tar.gz 4866c96a3d2e293b2585e8a5b1d30efe4ec8d579b36b9a4f5428d7f24d80793a ledgersmb-1.7.6.tar.gz.asc

1 0

LedgerSMB 1.6.17 released
by Erik Huelsmann 26 Dec '19

26 Dec '19

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.6.17 * Allow uploading of attachments with unknown mime-types (Erik H) * Fix formatting on-hand (OH) column on orders to follow user settings (Erik H) * Fix migration of assembly data from SQL Ledger 3.2 (Yves L) Erik H is Erik Huelsmann Yves L is Yves Lavoie For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.17/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.17 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.17 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.17 These are the sha256 checksums of the uploaded files: 162c1acf684a2a207ddc2042e28e2db29793855d6e8f2755ba42247b97ebeb5f ledgersmb-1.6.17.tar.gz fa5ed1d5dbf5956924086daa0c40a897caa34fa9dcbb0c496972b88824433197 ledgersmb-1.6.17.tar.gz.asc

1 0

PGObject and PGObject::Simple
by Chris Bennett 15 Dec '19

15 Dec '19

Hi, apart from these, I've started quite a few other modules too. One problem I'm seeing is that, using OpenBSD's PostgreSQL testing module (which I'm only just now getting aquainted with) is that I'm having to patch the tests for get past the skip_all. They pass the tests just fine, except that they both try to drop the test database while it's still open. I'll ask about this on the OpenBSD mailling list. I may be doing something wrong. I want to be sure and test everything with the database. Kind of important. :-} Is there a kink in the test programs or am I just doing something wrong? I can just patch things on the OpenBSD side, which is pretty commonly needed. That's not a problem. I'll get back. Been working on things in spurts. Many modules started. Now I'm working on finishing up on them one by one. Regards, Chris Bennett

2 1

1.5 release line End-Of-Life notice
by Erik Huelsmann 15 Dec '19

15 Dec '19

I'm sending notice that the 1.5 release line will reach End-Of-Life by Monday 23 December - next week. As per our community policy, there will be no further fixes applied to the 1.5 series of releases. After its initial release on December 23, 2016 and 30 patch releases - the latest released just 16 days ago on November 29 - the 1.5 release line will have received 3 years of support. Note that even though the community won't provide further releases, the software is considered highly stable and will keep working as it has. This End-Of-Life announcement has no impact on migration paths to newer versions of LedgerSMB: upgrades from 1.5 to more recent versions will remain supported for years to come. (While I'm writing this, I find that we don't currently have a policy in place governing this type of backward compatibility.) Should you want to keep running 1.5 and be in need of support or maintenance, you could try contacting one of the parties listed on the page for commercial support: https://ledgersmb.org/content/commercial-support. They may be able to provide support beyond the community commitment. Available options for versions with community support are the 1.6 release line which will receive community releases until June 10, 2021 or the 1.7 release line which will see community support until October 04, 2022. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Initializing report templates in existing companies
by Erik Huelsmann 15 Dec '19

15 Dec '19

Hi, Yesterday, I created infrastructure to customize and run Balance sheet, P&L, trial balance and "generic list" reports (in their downloadable versions) on a per-company basis. To support this use-case, they will need to be uploaded to the database, just like the invoice, order and other templates. For our code base, it's an either/or situation that we support the in-database templates (or remain with the ones on-disk). Personally, I see benefits in moving to the in-database templates, mostly because they then become customizable by end users with sufficient rights, not just system admins. Now, I'm looking for a suitable way to make the switch for everybody who already has a pre-1.8 system running when we release this functionality with 1.8. I see several options to get templates into their databases: 1. Create an SQL database upgrade script with the templates embedded This has the benefit that the templates will be there after the database is upgraded. However, when the templates change over time, the script can't be updated to include the updated templates, because that's the way our SQL schema change management works. 2. Do nothing, but fail with an error about the import needing to happen when the templates are missing upon output generation This is probably the easiest way to go by, but the error might end up with users who won't be able to address the issue themselves. 3. Create new infrastructure to test "company configuration sanity" which can be run from setup.pl at the end of the migration This solution is a lot of additional work, but can be used to indicate configuration and database health issues to admins after upgrades. One such issue would be that the templates are missing. This functionality can be used independently from upgrades as well and would address the issue that we have wanted to land database integrity/sanity checks (but didn't have anywhere to do so). Comments? Other ideas? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Selecting a next bug to work on
by Erik Huelsmann 14 Dec '19

14 Dec '19

Hi, As promised on my GitHub Sponsors account ( https://github.com/sponsors/ehuelsmann) I've drawn up a selection of bugs that I'm ready to take on. The community will be offered an opportunity to help select the bug that adds most value when being solved. Today, I'm sending out my first mail with a list of bugs I think I can take on and solve in the upcoming weeks: * Rate entry allowed for default currency Currently, when entering a rate in 1.7, the user needs to choose the currency for which this rate is being entered. Unfortunately, the default currency is included in that list. https://github.com/ledgersmb/LedgerSMB/issues/4236 * Barcode scanning on invoices/orders broken by parts drop-down Before 1.5, hitting enter in the part number field would update the invoice screen and advance the entry to the next line (for a next scan). Currently, all this is broken. https://github.com/ledgersmb/LedgerSMB/issues/1584 * New <invoice|order|...> buttons on Credit Account screen should populate customer Currently, these buttons don't populate the customer, instead returning the user an empty screen. https://github.com/ledgersmb/LedgerSMB/issues/932 Please provide your feedback as to which of these bugs adds the most value to you by Tue 17 Dec. Please note that sponsors get an actual vote; all others provide advisory feedback. If your most-wanted bug isn't in this list, please mail me directly about that and I'll check to see if I can add it to the list on its next iteration. Before you mail me, please make sure your bug is registered as a bug on GitHub (https://github.com/ledgersmb/LedgerSMB/issues) -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Selecting a next bug to work on
by Erik Huelsmann 14 Dec '19

14 Dec '19

Hi, As promised on my GitHub Sponsors account ( https://github.com/sponsors/ehuelsmann) I've drawn up a selection of bugs that I'm ready to take on. The community will be offered an opportunity to help select the bug that adds most value when being solved. Today, I'm sending out my first mail with a list of bugs I think I can take on and solve in the upcoming weeks: * Remove restriction on file types that can be uploaded Currently, only files with a MIME type already known to LedgerSMB can be uploaded With this issue fixed, files of all MIME types will be accepted https://github.com/ledgersmb/LedgerSMB/issues/1949 * Make contact type names translatable Currently, the names of contact types (Vendor, ...) are presented straight from the database without ways to translate them. https://github.com/ledgersmb/LedgerSMB/issues/2315 * 'setup.pl' shows system databases in the list of company databases Currently, when logging into 'setup.pl' without a named database, a list of databases is shown. This list includes databases not available for logging in, such as postgres, template0 and template1. Resolving this bug will remove these common databases from this list. * The "Internal notes" field on the invoice isn't scrollable https://github.com/ledgersmb/LedgerSMB/issues/3203 * Contact Notes has empty Author and Entered At fields https://github.com/ledgersmb/LedgerSMB/issues/2822 Please provide your feedback as to which of these bugs adds the most value to you by Tue 2 Dec. Please note that sponsors get an actual vote; all others provide advisory feedback. If you most-wanted bug isn't in this list, please mail me directly about that and I'll check to see if I can add it to the list on its next iteration. Before you mail me, please make sure your bug is registered as a bug on GitHub (https://github.com/ledgersmb/LedgerSMB/issues) -- Thanks! Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 2

LedgerSMB 1.7.5 released
by Erik Huelsmann 13 Dec '19

13 Dec '19

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This release contains the following fixes and improvements: Changelog for 1.7.5 * Fix failure to save tax forms (#4252) * Fix failure to undo database edits when surrounding code fails (#4253) * Allow uploads of files with MIME types unavailable in the database (#1949) * Fix failure to render (AR/AP) aging report (#4259, #4260) * Separate authentication domains for setup.pl and login.pl (#4247) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.5/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.5 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.5 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.5 These are the sha256 checksums of the uploaded files: 443e8b12eea99361dcb4479c2c62e8d54d54716f3755193df0735c1082ebfb32 ledgersmb-1.7.5.tar.gz 539caf56f8f4f8e4252b3bae7ac0ec618b4f481222308a85b27e05caa7feef2d ledgersmb-1.7.5.tar.gz.asc

1 0

Testing mailing list delivery
by John Locke 02 Dec '19

02 Dec '19

Please ignore... We've just moved the mailing lists to a new mail server, making sure it delivers and archives correctly... Cheers, John Locke Freelock (host for ledgersmb.org)

2 1