- devel - lists.freelock.com

Test version ledgersmb-1.5 v1.5.9-2~1
by Robert J. Clay 14 Aug '17

14 Aug '17

On Sun, Aug 13, 2017 at 7:05 PM, Robert J. Clay <rjclay(a)gmail.com> wrote: > Note that this version does not include ledgersmb-1.5-apache for > the Apache proxy configuration as there was still an issue with that A test package of ledgersmb-1.5 that does include the problem ledgersmb-1.5-apache deb was also uploaded to our apt repository last night. That's in 'test' instead of 'main' and is version 1.5.9-2~1. That's also associated with the temporary branch 'dev/ApacheProxy' at https://github.com/ledgersmb/pkg-ledgersmb-1.5, as well as the open issue https://github.com/ledgersmb/pkg-ledgersmb-1.5/issues/2. At our apt package repository in 'test', for 'stretch': ledgersmb-1.5_1.5.9-2~1_all.deb ledgersmb-1.5-apache_1.5.9-2~1_all.deb ledgersmb-1.5-nginx_1.5.9-2~1_all.deb I emphasize that this is only a test version (and may not end up being the only one, depending on how the troubleshooting goes) for an issue with the apache proxy configuration associated with the legdersmb-1.5-apache package. Once that issue has been resolved, it will be released in a new non-test version. -- Robert J. Clay rjclay(a)gmail.com jame(a)rocasa.us 4096/198CAB6F43B7EA9A

1 0

Release of ledgersmb-1.5 v1.5.9-1
by Robert J. Clay 13 Aug '17

13 Aug '17

The initial version of the debian pkg for legdgersmb-1.5, version 1.5.9-1, has been released and uploaded to our apt package repository for 'main' in stretch. It has also been uploaded to our PPA, for artful (the future v17.10). Note that this version does not include ledgersmb-1.5-apache for the Apache proxy configurtion as there was still an issue with that but does include ledgersmb-1.5-nginx for the Nginx proxy configuration. At our apt package repository: ledgersmb-1.5_1.5.9-1_all.deb ledgersmb-1.5-nginx_1.5.9-1_all.deb At our PPA: ledgersmb-1.5_1.5.9-1~ubuntu17.10.1_all.deb ledgersmb-1.5-nginx_1.5.9-1~ubuntu17.10.1_all.deb -- Robert J. Clay rjclay(a)gmail.com jame(a)rocasa.us 4096/198CAB6F43B7EA9A

1 0

[ledger-smb-devel] Storing test-data for migrations?
by Erik Huelsmann 11 Aug '17

11 Aug '17

Hi, As part of a change that I'm implementing for LedgerSMB 1.2/1.3 migrations (to 1.5/1.6), I'd like to create a number of LedgerSMB database dumps for the purpose of testing those migrations. I'm thinking that these schema files, if the scope of the tests is expanded to SL 2.8, 3.0 and 3.2, as well as tests including some *real* and *problematic* data, the test data set may become largish or even plain large (multiple MBs to multiple 10s of MBs). While the test data sets *are* core to testing the software during development (and as part of the Continuous Integration efforts run on Travis CI), I think that putting these in each and every repository that's being cloned around the world is probably a bad idea: many of those will never be used for testing (instead they'll be used for tracking customized versions). Some years ago, we imported the full sources of some Dojo version, which we - even though long unused - we still drag around on every clone action. To that extent, I'm thining we probably want to store these artifacts elsewhere and keep them out of the repository. Maybe starting with a directory on download.ledgersmb.org. Any ideas/comments? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 3

Excluding dotted files & directories in the release archive?
by Erik Huelsmann 11 Aug '17

11 Aug '17

Hi, Today I was looking at GitHub's option to add PR and Issue templates. Now that we have cleaned up our top-level directory, I'd rather *not* pollute it again with a largish series of documents that one of the cloud providers "requires". To that extent, GitHub offers the option to put the required documents in a ".github/" directory in the project's root. In the distribution archive, these documents wouldn't serve a purpose: the issue and PR templates only add value in the github site. The CONTRIBUTING and CODE_OF_CONDUCT files would be nothing more than pointers to our ledgersmb.org site where we publish our actual policies to that extent. I'm thinking we can remove all of the following in our release archives: - .github/ (when introduced) - .gitignore - .gitattributes - .gitmodules - .proverc - .travis.yml - .tx/ The .git/ directory already is being removed during the release process. Or should we just simply leave them in the distribution tar, letting everybody decide for him/herself and packagers for their users? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Re: [devel] Migration and Sanity checks
by David G 04 Aug '17

04 Aug '17

Sending this from my phone and being lazy, sorry for the top post. ;-) Ok. - I agree that both types of checks are required. - I think they should be two separate entry points in setup.pl just like upgrade is now. - At the end of a migration (or upgrade for that matter) There should be a screen that explains that we recommend running the sanity checks and provide a button to do so on that screen. Regards David G -------- Original message -------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: 4/08/2017 22:49 (GMT+08:00) To: "Yves Lavoie, GaYLi" <ylavoie(a)yveslavoie.com> Cc: devel(a)lists.ledgersmb.org Subject: Re: [devel] Migration and Sanity checks On Fri, Aug 4, 2017 at 2:04 PM, Yves Lavoie, GaYLi <ylavoie(a)yveslavoie.com> wrote: Hi all, Until now, our migration process consisted of: Using an existing LSMB 1.2 to 1.5 or Sql-Ledger 2.8 or 3.0 database Applying a specific migration script, with various fix possibilities using specific forms Obtaining a dataset that can be pushed into the latest LedgerSMB schema or failing completely. During the last week, Erik and I have been working on adding different edit, update, insert, cancel and override possibilities for the migration forms, in order to ease migration and try to prevent returning the user to his old application to fix data.Yes. And looking back, we seem to be adding some checks which could be classified as "sanity checks" rather than "migration checks". The difference being that "sanity checks" are not required to pass for technical reasons (i.e. the data is acceptable for the current 1.5 or 1.6 schema); however, the data doesn't make sense: e.g. reconciliation entries on a cost account. My definition of "migration checks" is that these are checks which are required to pass in order for the target schema to be able to accept the incoming data. Yves's idea was to add these sanity checks during migration. My idea was that adding these sanity checks to the migration is the wrong place to add them: users who migrated before the checks were added might also have functionally problematic data, but can't find out, because they can't re-run the migration, if we put them *only* in the migration. Also, for people who don't really care about all this, they're required to completely clean up their data beyond what's necessary to migrate to LedgerSMB (making the migration experience itself more painful than necessary). Now, some of those fixing forms are specific to each migration but some are more general and should probably fit better in a new sanitization step, to be inserted between steps 2 and 3 above. As discussed with Yves on the chat channel, this is the part where we don't exactly agree yet. We completely agree that it makes sense to have sanity checks. But the questions I have are: 1. Do we require people to go through the sanitizing experience of having to comply with both the migration checks as well as the sanity checks? 2. Even if we do, how do we make the sanity checks available to other users (such as those who migrated in the past)? 3. If we decide to break out the sanity checks into a function of their own, where do we put that function? (setup.pl? something elsewhere?) 4. If we put them in a function of their own, we obviously can't put them in Upgrade_Tests.pm, but their completely parallels the upgrade tests. In terms of code re-use, do we extract out a common abstract superclass which also holds the driver(utility) functions, making the setup.pl equivalents into simple "forwarders"? This would benefit all previous versions prevent entering bad data in the database for which we do or not have means to fixMy idea here is that it only has meaning to have sanity checks when we have feedback to provide to the user, that is, when we can offer a resolution strategy (preferably different from "contact the LedgerSMB mailing lists"). In my eyes "bad" data isn't as bad as it looks. In the cases we've run into so far, "bad data" simply meant "functionally meaningless". provide a diagnostic of the database to the owner. Such report could also be generated on demand through the admin application. allow for more complex checks than was is strictly required by migration.And - more importantly - allow for much more complex "fix-up" operations than originally intended. This is a change from the actual process for which your input would be welcomed.Yup. Also see my questions and comments above. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP.Robust and Flexible. No vendor lock-in.

1 0

[devel] Migration and Sanity checks
by Yves Lavoie, GaYLi 04 Aug '17

04 Aug '17

Hi all, Until now, our migration process consisted of: 1. Using an existing LSMB 1.2 to 1.5 or Sql-Ledger 2.8 or 3.0 database 2. Applying a specific migration script, with various fix possibilities using specific forms 3. Obtaining a dataset that can be pushed into the latest LedgerSMB schema or failing completely. During the last week, Erik and I have been working on adding different edit, update, insert, cancel and override possibilities for the migration forms, in order to ease migration and try to prevent returning the user to his old application to fix data. Now, some of those fixing forms are specific to each migration but some are more general and should probably fit better in a new sanitization step, to be inserted between steps 2 and 3 above. This would * benefit all previous versions * prevent entering bad data in the database for which we do or not have means to fix * provide a diagnostic of the database to the owner. Such report could also be generated on demand through the admin application. * allow for more complex checks than was is strictly required by migration. This is a change from the actual process for which your input would be welcomed. Yves

2 1

[devel] LedgerSMB 1.5.9 released
by Erik Huelsmann 22 Jul '17

22 Jul '17

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.5.9 * Fix goods/services search with AR/AP invoices (Chris T, #2938) * Fix inventory activity report drill down over-inclusive (Chris T, #2926) * Fix Ship/Receive column alignments (Chris T) * Fix mailing recurring invoices shows invoice in-screen (Erik H, #3004) * Fix missing column SQL error when posting recurring invoices (Erik H) * Show an error when page assets (Dojo) are missing (Erik H) * Fix new welcome page being referred to by absolute path (Erik H, #2994) * Fix 'Not an ARRAY reference' error in recurring AP processing (Erik H, #2973) * Fix recurring AP invoices posted but 'next date' unchanged (Erik H, #3019) * Fix the fix for '.' missing in @INC (Erik H) * Add lighttpd example config (Yves L) * Fix regression in setup.pl with LedgerSMB 1.2 or SQL Ledger db (Yves L) * Fix error when adding customer-specific price to customer (Erik H, #2643) * Fix can't edit sales & purchase quotation through web UI (Erik H, #2617) * Fix string match operator typo in company searches (Erik H) * Fix LedgerSMB 1.2->1.5 migration script syntax errors (Erik H) * Add migration non-standard (gl) 'account links' for 1.2->1.5 (Erik H) * When including code with 'do', don't silently skip errors (David G, #3020) Chris T is Chris Travers Erik H is Erik Huelsmann Yves L is Yves Lavoie David G is David Godfrey The release can be downloaded from our download site at http://download.ledgersmb.org/f/Releases/1.5.9/ Additionally, the release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.9 or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.9 These are the sha256 checksums of the uploaded files: 48977307f6bb1cd60b5d43bfe763b373402115b11435afe5fde837a9c142f5ef ledgersmb-1.5.9.tar.gz 9236a6aaf650f5918e6e1bbfe4a149e7f17917363e7a7da8e0cffd3f0fad7a88 ledgersmb-1.5.9.tar.gz.asc

1 0

[devel] Product traceability
by Kaare Rasmussen 16 Jul '17

16 Jul '17

Hi We need to trace to whom we sell our products but I can't find any product sales breakdown The closest I can find is in Goods and Services -> Reports -> Inventory Activity, where I seemingly can see the number of sold items during a time period. But when clicking the number, I just get a full list of all invoices, NOT only the ones containing the requested part, -- Med venlig hilsen Kaare Rasmussen, Jasonic Jasonic: Nordre Fasanvej 12, 2000 Frederiksberg

1 1

[devel] New 4k RSA key for apt.ledgersmb.org repository
by Robert J. Clay 12 Jul '17

12 Jul '17

It had been commented by various people that they have been seeing error messages regarding the apt.ledgesmb.org repository key being too small or too "week" when the repository was being accessed, like the following example comment: apt update returns W: http://apt.ledgersmb.org/dists/xenial/InRelease: Signature by key 1ED705D54028F70F45E32340D0F530B7F93ECF4F uses weak digest algorithm (SHA1) at the end I've created a 4K RSA key for the repository and have added it to the configuration there, and updated the home page about it. Will be using both the old and the new key for a bit, but then the old key will be removed from the configuration. -- Robert J. Clay rjclay(a)gmail.com jame(a)rocasa.us

1 0

[devel] Debian packaging for LedgerSMB v1.5.x
by Robert J. Clay 03 Jul '17

03 Jul '17

Since the release of LedgerSMB v.1.5.8, which dropped the requirement for App::LedgerSMB::Admin, I have been working on finishing the Debian packaging for the new version, for both the ledgersmb package for Debian itself as well as the new ledgersmb-1.5 package which is just for release by our project. Note that the git packaging repositories for both are at GitHub [1][2]. This email is to start a discussion as necessary regarding the packaging, starting with some notes about how it's proceeding. The intent of the debian/watch file plus the get-orig-source target in debian/rules is to provide a way to automatically create an *.orig.tar.gz file, especially for when new versions of LedgerSMB comes out. Using that, the process will check for a new version. If one is found; it will download the new archive as well as its associated *.asc pgp signature file. Then verify the pgp signature against the downloaded archive. Then repack it as necessary (needed for ledgersmb, possibly also useful for ledgesmb-1.5) if the verification is good. This had been working for both packages prior to the move from SourceForge. I've been able to do some updating for the debian/watch file (just in ledgersmb-1.5, so far) but not to where I can get the verification step to work properly, although it does find the new version in the new location at GitHub. (In order to proceed with the packaging, I manually downloaded and verified the new 1.5.8 version.) One big difference between LSMB v1.4.x and v1.5.x is that LedgerSMB is now being run by Starman instead of by Apache; this is more an issue for the ledgersmb package since it needs to also handle upgrades from v1.4.x. I originally thought to handle the choice between which web proxy to use, Apache or Nginx, by asking a question about it during the package install and then proceeding from there. To that end, I added a debconf question about it which defaults to 'None'. However, I could not figure a way to take advantage of that selection during the package install in order to get either apache or nginx to be installed as necessary. So what I've ended up doing (and am in the process of testing with the ledgersmb-1.5 package) is adding the creation of additional binary packages that provide for the installation and configuration for apache or nginx and those depend on the main package. (I wonder if they should be made mutually exclusive...) That debconf question about a web proxy selection is not needed now and will likely be removed. -- Robert J. Clay rjclay(a)gmail.com jame(a)rocasa.us [1] https://github.com/ledgersmb/pkg-ledgersmb [2] https://github.com/ledgersmb/pkg-ledgersmb-1.5

1 0