- devel - lists.freelock.com

LedgerSMB 1.7.0-beta1 released
by Erik Huelsmann 01 Jul '19

01 Jul '19

Hi, After the release of 1.7.0-alpha1 we have been working towards the 1.7.0 release as described in our community update. We feel that the 1.7.0 branch is feature complete and while we're developing tests to find and fix possible regressions and older bugs, no new features or major changes are expected to be implemented before 1.7.0. This means that the current code base (modulo any and all regressions we can find and fix) will become 1.7.0 when it's ready. To help you find the bugs we need to fix before the release, we have published 1.7.0-beta1. It's available as a Docker image from Docker Hub under the tag "ledgersmb/ledgersmb:1.7.0-beta1". See https://hub.docker.com/r/ledgersmb/ledgersmb/builds/ Additionally, the release can be downloaded as a tarball from the download site: https://download.ledgersmb.org/f/Beta%20Releases/1.7.0-beta1/ Please report any issues you find in reply to this e-mail (that is, to the mailing list) or create an issue on GitHub with your finding: https://github.com/ledgersmb/LedgerSMB/issues/new?template=ISSUE_TEMPLATE.md -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

LedgerSMB community update
by Erik Huelsmann 01 Jul '19

01 Jul '19

Hi, It was just before New Year when I sent out the last community update, so it's time for a follow up. This half year, we only released 1 maintenance release for 1.6.10. With no specific new bug reports coming in, the development team was able to focus its efforts on 1.7.0. On that front, a lot of development effort has gone into getting the Multi-Currency branch ready to be merged to master. On January 20th the long-awaited multi-currency branch merge happened, followed by the release of 1.7.0-alpha1. Since then, we've been developing more tests simulating user interaction with LedgerSMB to ensure that 1.7.0 will be as good as 1.6.0 when it is released. In the process, we have been fixing a few regressions. With the additional tests - which include tests for AR & AP invoices and transactions - we have increased test coverage from 29% (current on 1.6) to 40% (on master) and we're working to increase the number to well above 50% before release. The speed at which we're able to implement new tests is severely impacted by the fact that we hit a continuous integration limit: Travis CI allows us to run tests for a maximum of 50 minutes. Our test suite runs between 40 and 45 minutes in code-coverage testing mode. A lot of effort has gone into working on this problem. We're working to off-load the code-coverage test jobs to another Continuous Integration service (CircleCI) which *does* allow jobs to run longer than 50 minutes. Another direction of research was to reduce execution time of our test jobs. And while that did turn up some bugs in our Selenium test driver, it mainly helped the area where we didn't experience any problems (the non-code-coverage tests were reduced from 29-30 minutes of execution to 20-21 minutes of execution). Migrating some of our test infrastructure to CircleCI turned out to have the additional benefit of being able to start running our tests against Chrome and Firefox. Currently we only run against PhantomJS. While PhantomJS implements enough of JavaScript to support our testing, it's unmaintained and getting behind on recent standards. Being able to test with Chrome and Firefox will help to take advantage of more modern browser development techniques. As part of our optimization work, we helped create new releases of Weasel, Pherkin::Extension::Weasel and Test::BDD::Cucumber, where significant new features were added to Pherkin::Extension::Weasel to support increased developer efficiency. Looking to the immediate future, we're expecting to release 1.7.0-beta1 this week: we think 1.7.0 is feature complete and we'll work simply to stabilize it from here on. This means that 1.7.0 isn't production ready, but we're looking for people to test-drive it and value any and all bug reports we can get! Regards, Erik. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

I have been held up when I discovered the lack of Docker in OpenBSD
by Chris Bennett 12 Apr '19

12 Apr '19

Hi, I've kinda disappeared for awhile because OpenBSD does not support Docker. Just as I was ready to get started, I ran into that problem right away. I have meant to send an email about that, but I was rather frustrated with the problem. I also intended to help with the Spanish translations. And didn't. The good news on that, I did find a Spanish/English dictionary specifically for business terms only. That's not a book I expected to find, much less expect to exist. As far as OpenBSD, I need to do lot of work on that. Could someone recommend a Linux distribution that works well that I can install and look at as an example as I work? What is the situation with browsers? I use mostly Firefox, but I'm finding more and more sites that really run off of only Chromium properly. Where are the right repositories located for development at? OpenBSD is running PostgreSQL 10.5 (or later when -current is released soon). Any issues with that or later versions of PostgreSQL? I discovered that some work was started on Docker by someone else quite a while back, but has not been worked on any further. I'm a little bit unclear on exactly what Docker is doing and not doing. I will spend some time looking into that. What is it doing in particular for LedgerSMB and just for this project only, can some kind of temporary workaround be used? Can I go ahead and port all of the missing modules and pass/fail the existing tests until something can be done about the Docker problem? OpenBSD has recently done a lot of work to make porting much easier to do. I do see that a lot of projects are using Docker, so it may be worth the effort to get it working in OpenBSD. People are using it with an Alpine Linux vmm from OpenBSD, but I have no experience in that. Chris Bennett

1 0

LedgerSMB packages in Debian
by Robert J. Clay 06 Apr '19

06 Apr '19

Note that due to illness; although I updated our 'ledgersmb-1.6' pkg for v1.6.10 I haven't yet updated the 'ledgersmb' pkg for that version so what's in Debian Testing is still only v1.6.9. And since the hard freeze in preparation for the Debian release of Buster as the new stable has gone active, there is no more auto migration to Testing for updated packages in Debian unstable until after the new version has been released. Besides still waiting for the last 3 debconf translations so that the pkg can be updated with them, I've also been thinking about a major change in the package; that being changing it so that it uses the dojo distributed in the LedgerSMB archive instead of that in Debian like is already being done with our 'ledgersmb-1.6' package, on the basis that the version in Debian is not the same as that actually being used by the app itself. There's not that much of a dojo related version difference with what LedgerSMB 1.6 uses (Debian testing has v1.14.2) but that's not the case for LSMB 1.7 so it's something I need to look at in any case. A ledgersmb package with major changes could always be uploaded to Debian Experimental (& our package repos, of course), so that's what I'll be looking at doing if necessary. Related to that is still getting the autopkgtest functionality done for the package. That (which does 'as installed' testing) is useful I think in any case but in particular having to do related to the different dojo versions. But that is based on my thinking that the JS code is actually being at least somewhat exercised in the 't/' and or 'xt/' testing, which I was wondering about due to something one the other devs said/ but which I've been assured that the JS code is being exercised in the bdd tests in xt/. So I figure to work on getting the t/ tests working for the autopkgtest to start off with and continue from there to the xt/ tests. Any comments/questions/etc, please let know. -- Robert J. Clay jame(a)rocasa.us rjclay(a)gmail.com

3 3

ledgersmb is marked for autoremoval from testing
by Debian testing autoremoval watch 23 Mar '19

23 Mar '19

ledgersmb 1.6.9+ds-1 is marked for autoremoval from testing on 2019-04-13 It (build-)depends on packages with these RC bugs: 923905: libdbd-pg-perl: FTBFS (failing tests)

2 1

Release of ledgersmb-1.6 package v1.6.10-1
by Robert J. Clay 20 Jan '19

20 Jan '19

An initial version of the debian ledgersmb-1.6 package version for LedgerSMB v1.6.10 has been created and uploaded to our PPA[1], for Ubuntu 'disco' (v19.04) and 'cosmic' (v18.10) as well as for 'bionic' (v18.04 LTS). (The debian source packages are available as well.) The packages at our PPA: ledgersmb-1.6 ledgersmb-1.6-apache ledgersmb-1.6-lighttpd ledgersmb-1.6-nginx ledgersmb-1.6-varnish Only the main 'ledgersmb-1.6' package is required; the others are related to which web proxy you might want to use and you only need one of them. (They depend on their respective web proxy applications and attempt to do at least some setup for them.) Note that I haven't created a ledgersmb-1.6 package yet at our apt package repository[2] for Debian 'Buster' (which is expected to be Debian v10) as that Debian version has not yet been released. It is, however, expected later this year so if people would like that I start making it available as well, please let me know. -- Robert J. Clay rjclay(a)gmail.com, jame(a)rocasa.us GPG ID: 2448 3AE0 874D 8696 6DCD ECF4 198C AB6F 43B7 EA9A. [1] https://launchpad.net/~ledgersmb/+archive/ubuntu/main/+packages [2] https://apt.ledgersmb.org/

1 0

LedgerSMB 1.7.0-alpha1 released
by Erik Huelsmann 20 Jan '19

20 Jan '19

Hi, After the merge of the (improved) Multi Currency Support branch (MC branch), we have released a preview version of LedgerSMB 1.7.0. It's not feature complete yet, but is intended as a general sense of direction for the 1.7.0 release and a way to solicit feedback. Note that you should run this version *only* on a *copy* of your database; this version is NOT intended for production use. The full changelog for 1.7.0 so far is included below. The most important feature by far is the improved multi currency support, which required quite extensive changes to the software. As such, this is the feature we're looking for feedback on most. If you need help getting set up to test 1.7.0-alpha1, please let me know! Changelog for 1.7 Series Forthcoming New functionalities * Deletion of template transactions (Nick P) * Transaction date now part of purchase history report (Chris T) * UI allows addition and removal of custom `account_link` flags (Nick P) Improved foreign currency support * Multiple rates per day per currency (Erik H) - Reversing a transaction from a closed-period on a day with different rate - Bank transfers with different banks on the same day with bank's fx rate - Migration from systems which support per-transaction or per-line fx rates * Multiple currencies in a single general ledger transaction (Erik H) - Posting an opening balance with all currencies in 1 transaction - Transferring between foreign currencies on e.g. Paypal in 1 transaction * Fixed copying of invoice copies fx rate without option to change (Erik H) * UI showing foreign and default currency amounts in transactions (Erik H) Quality Assurance * Expanded checks and resolutions for schema changes (Erik H) * Testing infrastructure and tests for schema change checks (Erik H) * Ensure correct dependency declaration (RequireExplicitInclusion critic policy) * POD documentation structure improvements, with automated checks (Erik H) * Expanded BDD tests, including payments, batches and approval (Nick P) Dependency updates * Dojo Toolkit (JavaScript UI tools) updated to 1.14.2 (Erik H) Code cleanup * Removed deprecated 'custom table' and 'custom field' tables (Erik H) * Reduce dependencies on deprecated LedgerSMB::App_State (Nick P) * Simplified deprecated LedgerSMB::PGOld (Nick P) * Remove unused LedgerSMB::DBObject and LedgerSMB::PGOld methods (Nick P) * Remove unused configuration settings in ledgersmb.conf (Erik H) * Further (compared to 1.6) reduction of warnings * Implemented tests for LedgerSMB::File(::*) modules (Nick P) * Template engine simplification by separation of UI and printed docs (Erik H) * Consistent copyright notices - with tests - on all Perl files in lib/ (Nick P) * Request handling cleanup by mapping 'flat' POST data into hierarchy (Erik H) Nick P is Nick Prater Erik H is Erik Huelsmann Chris T is Chris Travers -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

LedgerSMB 1.6.10 released
by Erik Huelsmann 20 Jan '19

20 Jan '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.10 * Apply correct layout to schema upgrade pages in setup.pl (Erik H) * Fix iteration over row data provided in schema data fixes in setup.pl (Erik H) * Fix schema upgrade with multiple failing checks looping infinitely (Erik H) * Improve wording of correction instructions of schema check failure (Nick P) * Respect tempdir when rendering ODS template (don't use current dir) (Nick P) * Add user feedback when invoice needs recalculation before posting (Erik H) Erik H is Erik Huelsmann Nick P is Nick Prater For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.10/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.10 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.10 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.10 These are the sha256 checksums of the uploaded files: 4028fcd2fd63d90988f031de013b81c4a11fe55b8908114e4c05f142ce6389a0 ledgersmb-1.6.10.tar.gz 071c780fc5d8e5b95f7009a86de8496a705e45496d3d9428bc7db25693244e26 ledgersmb-1.6.10.tar.gz.asc

1 0

MC branch merged
by Erik Huelsmann 20 Jan '19

20 Jan '19

Hi, After discussion on the LedgerSMB chat channel, it's been decided to merge the 'master-mc' branch. This means the MC changes will be in 1.7. Additionally, it means that quite extensive schema changes have landed on the 'master' branch. We're testing those changes with real-life databases to ensure good user experience upon release. We'd appreciate it if others want to join testing efforts of the 'master' branch and the new MC functionality. The current Changelog description of the merge is: Improved foreign currency support * Multiple rates per day per currency; from a single rate (Erik H) - Reversing a transaction from a closed-period on a day with different rate - Bank transfers with different banks on the same day with bank's fx rate * Multiple currencies in a single general ledger transaction (Erik H) - Posting an opening balance with all currencies in 1 transaction - Transferring between foreign currencies on e.g. Paypal in 1 transaction * Fixed copying of invoice copies fx rate without option to change (Erik H) * UI showing foreign and default currency amounts in transactions (Erik H) -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

What should the process toward merging the MC branch be?
by Erik Huelsmann 19 Jan '19

19 Jan '19

Hi, Over the past weeks, we (on the ledgersmb chat channel) have been working to complete all open tasks related to the "Phase 1" of Multi Currency support. Additionally, we have been testing the schema migration code with a number of real-life databases and fixing issues. A number of bugs and other findings have been fixed. Pre-migration versus post-migration trial-balance comparisons have been implemented as migration validations. The branch implements new tests unit tests and BDD tests. The branch implements tests for the schema migration code. The branch has undergone manual testing recently (in addition to the manual testing which happened when the code was written originally). The question now is how to proceed? Would anybody be prepared to jump in with manual testing of the branch and the migration code? Should we be merging the branch to master and find testers there? Should we be writing more tests on the branch before merging? If so, how many tests are "good enough" before we can merge? Or should we merge and develop tests on master? (Which we should anyway...) For anybody interested what it is exactly that I'm writing about, check the comparison between the master and master-mc branches: https://github.com/ledgersmb/LedgerSMB/compare/master...master-mc (statistics: 415 commits; 6417 additions, 3514 deletions, 161 affected files; first commit July 19, 2016; last commit: today.) Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 2