- devel - lists.freelock.com

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

[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