- devel - lists.freelock.com

Cleaner tree for UI/ ?
by Erik Huelsmann 26 Aug '17

26 Aug '17

Hi, Since we moved to being a single-page app on the main app, I'm looking to improve clarity in the UI/ tree. What's the problem? I see a number of things being unclear: * Out of all the files stored in UI/, only these are actual "top level" documents: - UI/login.html - UI/logout.html - UI/main.html - setup/*.html * All files, also the bits that are "html fragments" these days, include a full html start- and end-tags as well as a header definition (which are being thrown away upon receipt!) * There are non-HTML documents (ODS, XLS, CSV, ...) in that directory (which suggests that it's not solely about UI, but also about data-export/report generation) Apart from the mix of HTML documents, the directory contains assets that *are* being served: javascript/images/css/... . Should we separate the HTML fragments in order to clarify the status as being a "non-toplevel document"? Another thing: I think we should separate out the templates which have not *just* an HTML representation, meaning that they are not (primarily) UI related elements. Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

3 5

Setting a policy for our dependencies
by Erik Huelsmann 26 Aug '17

26 Aug '17

Hi, Sending this mail to the mailing list, because I think that's where we need to set our policies. I'm starting this topic because I feel like it's come up several times now and I think it's time to set a policy, with documented reasons as to why we're working the way we do. First, let me re-iterate what I think are our shared goals for LedgerSMB (as related to our choice of dependencies). We want: LedgerSMB to be easy to install, meaning * On as many platforms as possible * Allowing people to use their distro's packages as much as possible * Running first and foremost on Perl versions in most distros * Allowing for a wide range of PostgreSQL versions * Integrating (through PSGI/reverse-proxy) with people's favorate webserver Translating the above into requirements for modules we depend on, I think we want to: * Use modules which have been around for a while (to increase chances of being packaged) * Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range * Require as few a possible modules in the expanded dependency tree (prefer modules as direct dependencies which are already depended on implicitly) * Not depend directly on modules which have overlapping functionalities * Not require modules which only provide nice-to-have functionality * Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation) With respect to modules used in development, I'd like to be less strict, but only marginally so: we want it to be "simple enough" to create a development setup for LedgerSMB. Comments? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

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