August 2017 - devel - lists.freelock.com

ledgersmb project owned repository naming
by David Godfrey 26 Aug '17

26 Aug '17

1 0

[devel] Turning off Coveralls commenting on PRs?
by Erik Huelsmann 26 Aug '17

26 Aug '17

Hi, Currently, all PRs are tested by Coveralls and Travis CI. Travis CI doesn't comment on our PRs, but Coveralls does. Initially, maybe, there wasn't a good way for Coveralls to indicate success/failure otherwise. However, since both Coveralls and Travis have the "tests in progress" section on the PR, every PR will show the latest Coveralls state right above the merge button. So, I propose we stop Coveralls from generating these comments. Anybody who does want the Coveralls notifications would need to create a coveralls account, add the LedgerSMB repo to his account and set up e-mail notification. With that, you'll receive mail notification of every Travis CI build with coverage information. If no objections by the end of Sunday, I'll modify the settings in Coveralls accordingly. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Looking at building Gentoo packages
by Chris Travers 24 Aug '17

24 Aug '17

Hi; For another project I have had to learn Gentoo packaging. I think having a LedgerSMB overlay for Portage would be very helpful in attracting development effort, and I don't expect this to be a difficult one to maintain. I could probably manage to automate everything from build testing to actual builds on our releases. However, this leads to a few questions: 1. For Gentoo should we support multiple side-by-side versions (I.e. slotting with 1.4 and 1.5 occupying different slots)? If we do, should we automate having these share a starman instance? 2. My plan is to add the CPAN dependencies unspotted and assume they may be shared. 3. From here I plan to talk with a Gentoo maintainer to see if we can get the overlap to have some sort of official status and made available out of the box by the tool layman. Any thoughts or objections? -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

1 0

Re: [ledgersmb-devel] Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account"
by David G 23 Aug '17

23 Aug '17

Your proposed change looks good to me. Sent from my Samsung Galaxy Note 4 on the Telstra Mobile network -------- Original message -------- From: Erik Huelsmann <ehuels(a)gmail.com> Date: 23/08/2017 05:22 (GMT+08:00) To: devel(a)lists.ledgersmb.org Subject: [ledgersmb-devel] Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account" Hi, While working on some of the 1.5.10-planned fixes, I'm running into the problem that the three tables in the subject have primary keys which contain non-numeric data. More specifically, in case of the bank account data, the pkey contains the bic and account number and in case of the contact data, the pkey contains a user-description of the contact item in the pkey (together with a class). Knowing about the privacy protection regulations in the EU, I think that having the bic+iban in the pkey of a table which is to describe that data isn't practical (both because it already exposes the primary data through the pkey and because it exposes heavily sensitive data to all tables which want to enable looking this data up. For the contact table, things are a bit different: I'm thinking that having an (editable) user description in the pkey simply isn't a great idea. Proposed way forward: All three tables get a serial "id" column, which is made the PKEY, where we can opt to make a UNIQUE index out of the columns which currently determine the PKEY. Comments? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP.Robust and Flexible. No vendor lock-in.

1 0

Primary key for tables "eca_to_contact", "entity_to_contact", "entity_bank_account"
by Erik Huelsmann 22 Aug '17

22 Aug '17

Hi, While working on some of the 1.5.10-planned fixes, I'm running into the problem that the three tables in the subject have primary keys which contain non-numeric data. More specifically, in case of the bank account data, the pkey contains the bic and account number and in case of the contact data, the pkey contains a user-description of the contact item in the pkey (together with a class). Knowing about the privacy protection regulations in the EU, I think that having the bic+iban in the pkey of a table which is to describe that data isn't practical (both because it already exposes the primary data through the pkey and because it exposes heavily sensitive data to all tables which want to enable looking this data up. For the contact table, things are a bit different: I'm thinking that having an (editable) user description in the pkey simply isn't a great idea. Proposed way forward: All three tables get a serial "id" column, which is made the PKEY, where we can opt to make a UNIQUE index out of the columns which currently determine the PKEY. Comments? -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

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