- devel - lists.freelock.com

LedgerSMB 1.5.13 released
by Erik Huelsmann 29 Oct '17

29 Oct '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.13 * Fix setup.pl showing [_1] instead of the LedgerSMB version (Erik H) * Fix contacts with attachments being inaccessible (Erik H, #3228) * Fix AR/AP Aging report failing to be generated (Erik H, #3243) * Upgrade Dojo from 1.10.8 to 1.10.9 (Erik H) * Fix HTML aging statement download not popping up 'Save' dialog (Erik H) * Fix date format 'dd/mm/yyyy' being parsed incorrectly (Erik H, #3223) Erik H is Erik Huelsmann Please note that this release updates the included Dojo Toolkit dependency in the tarball to 1.10.9 (from 1.10.8). Users tracking the GitHub git repository need to update their installed Dojo version as per the instructions at https://ledgersmb.org/content/upgrading-ledgersmb-15x-15y#upgrade-src-dojo For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.5.13/README.md The release can be downloaded from our download site at http://download.ledgersmb.org/f//Releases/1.5.13 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.13 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.13 These are the sha256 checksums of the uploaded files: b271440ed5d61851e21dee6ca2d5e32e49a2083f022a8e20dd71e9d10a885482 ledgersmb-1.5.13.tar.gz 36761ece65385e661468984b9d6fc10498c475785aeea94611233926994cf432 ledgersmb-1.5.13.tar.gz.asc

1 0

NOTICE: Updated Dojo dependency in 1.5 and master branches
by Erik Huelsmann 28 Oct '17

28 Oct '17

Hi all, This is a notice to everybody tracking their install from our GitHub repository: I've just updated the Dojo dependency to these versions: 1.5 branch: 1.10.9 (from 1.10.8) master branch: 1.13.0 (from 1.12.2) You can run $ git submodule foreach git remote update -p $ git submodule update to check out the latest dojo dependency and $ make dojo to create the dojo JavaScript artifacts. Users of the release archives (tarballs) don't have to do anything and will be updated to the new versions on the next release. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

Need a dedicated web server to restore forums
by chris＠bennettconstruction.us 23 Oct '17

23 Oct '17

The company that supplied my web server stopped services. I have backups, but I need a webserver with remote KVM access. Cheap is important. I am running OpenBSD. Any help appreciated. I am suffering from lack of a desktop or laptop. Kindle Fire tablet is miserably small and doesn't have the capabilities I need. Thanks, Chris Bennett

1 0

LedgerSMB 1.5.12 released
by Erik Huelsmann 18 Sep '17

18 Sep '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.12 * Fix depreciation method listing incorrect stored procedure (Erik H) * Fix failure to select business type details from business list (Erik H, #3154) * Require fixed asset values needed in depreciation to be entered (Erik H) * Fix the Net Book Value report listing assets by the wrong class (Erik H) * Fix the Net Book Value report incorrectly excluding some assets (Erik H) * Fix Ship To screen reporting server error and staying blank (Erik H, #2516) * Fix non-existing entry-point error on 'Approve' in fixed assets (Erik H) * Fix errors due to double 'action' field in fixed assets reports (Erik H) * Fix disposal-specific fields appearing in depreciation screens (Erik H) * Fix Parts Group drop-down and column selector in Goods Search (Erik H, #1581) * Require proceeds on disposal prevents NULL amounts on approval (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.5.12/README.md The release can be downloaded from our download site at http://download.ledgersmb.org/f/Releases/1.5.12/ The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.12 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.12 These are the sha256 checksums of the uploaded files: a73adc8ef9f4f7c6bc6546ee58b066138b11cc92f7ea6eff843da6ff7f874520 ledgersmb-1.5.12.tar.gz 45e0dada224df8d8d6ae08213d15d5597803fac6b043d3fe186127dd6a6e37c8 ledgersmb-1.5.12.tar.gz.asc

1 0

LedgerSMB 1.4.42 released (end-of-life release)
by Erik Huelsmann 16 Sep '17

16 Sep '17

The LedgerSMB development team is happy to announce yet another new version of its open source ERP and accounting application. This will be the last release in the 1.4 series, which has reached End-Of-Life (EOL) status on September 15, 2017; after three full years of active maintenance. The fact that the release series has reached EOL status means that no further community supported releases will be created - except for translation updates when available. Users are encouraged to upgrade to the 1.5 series which is now the community supported version. In case upgrades are not an option, support may be available through commercial support channels (https://ledgersmb.org/topic/commercial-support) This release contains the following fixes and improvements: Changelog for 1.4.42 * Fix goods/services search with AR/AP invoices (Chris T, #2938) * Fix ar/ap not searchable by part number (Chris T, #2926) * Round-trip fewer values over web requests during migration (Erik H) * Bank account info now properly HTML-escaped (Erik H, #2820) * Ensure forked sub-processes to be correctly terminated (Erik H) * Fix missing content in columns of the outstanding report (Erik H, #2585) * Fix contacts search ignores e-mail and phone filters (Erik H, #2821) * Fix contacts search by address data doesn't work (Erik H, #2490) Chris T is Chris Travers Erik H is Erik Huelsmann The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.4.42 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.4.42 Additionally, the release can also be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.4.42 These are the sha256 checksums of the uploaded files: 64b3e70559e2e66a9b1b41b2937ac3e68ef47f8b1006f092bafde60941b8a1ba ledgersmb-1.4.42.tar.gz 9129f407bb0ab372f0e0f6388e97e3765b1cd96ca0a02fe6d9e3f9a8331b7b02 ledgersmb-1.4.42.tar.gz.asc

1 0

Release of ledgersmb-1.5 v1.5.11-1
by Robert J. Clay 15 Sep '17

15 Sep '17

An initial version of the debian package for ledgersmb-1.5 for version 1.5.11-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). (The Debian source packages are available as well.) Note that this version of the package does not include ledgersmb-1.5-apache for the Apache proxy configuration as there is still an unresolved issue with that but does include ledgersmb-1.5-nginx for the Nginx proxy configuration. The ledgersmb-1.5-lighttpd and ledgersmb-1.5-varnish proxy configuration packages are also still in the process of being added. At our apt package repository[1]: ledgersmb-1.5_1.5.11-1_all.deb ledgersmb-1.5-nginx_1.5.11-1_all.deb At our PPA[2]: ledgersmb-1.5_1.5.11-1~ubuntu17.11.1_all.deb ledgersmb-1.5-nginx_1.5.11-1~ubuntu17.11.1_all.deb -- 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://apt.ledgersmb.org/ [2] https://launchpad.net/~ledgersmb/+archive/ubuntu/main/+packages

1 1

LedgerSMB 1.5.11 released
by Erik Huelsmann 12 Sep '17

12 Sep '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.11 * Rename lighttpd example configuration file for consistency (Yves L) * Fix Net Book Value report shows 'LedgerSMB::Report' as its name (Erik H, #3132) * Fix Depreciation screen not showing any assets (Erik H, #3131) * Fix fixed asset's 'Usable life' field not showing entered value (Erik H, #3130) * Fix Net Book Value report's link to asset details broken (Erik H, #3129) * Ensure forked sub-processes to be correctly terminated (Erik H) * Fix Form submission sometimes seems to hang (Erik H, #2972) * Fix missing content in columns of the outstanding report (Erik H, #2585) * Fix contacts search ignores e-mail and phone filters (Erik H, #2821) * Fix contacts search by address data doesn't work (Erik H, #2490) Yves L is Yves Lavoie Erik H is Erik Huelsmann The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.5.11 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.11 For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.5.11/README.md Additionally, the release can also be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.11 These are the sha256 checksums of the uploaded files: b483095512828683efdd6d85216ee069999e45b0e4ba9502943ac3f88c94d44d ledgersmb-1.5.11.tar.gz 6deba09673f0cefa222ae1b868a541a855ca270011b17f11fd0e950460b1b038 ledgersmb-1.5.11.tar.gz.asc

1 0

Release of ledgersmb-1.5 v1.5.10-1
by Robert J. Clay 04 Sep '17

04 Sep '17

All, An initial version of the debian package for legdgersmb-1.5 for version 1.5.10-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). (The Debian source packages are available as well.) Note that this version does not include ledgersmb-1.5-apache for the Apache proxy configurtion as there is still an unresolved 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.10-1_all.deb ledgersmb-1.5-nginx_1.5.10-1_all.deb At our PPA: ledgersmb-1.5_1.5.10-1~ubuntu17.10.1_all.deb ledgersmb-1.5-nginx_1.5.10-1~ubuntu17.10.1_all.deb -- Robert J. Clay rjclay(a)gmail.com jame(a)rocasa.us 4096/198CAB6F43B7EA9A [1] https://apt.ledgersmb.org/ [2] https://launchpad.net/~ledgersmb/+archive/ubuntu/main/+packages

1 0

LedgerSMB 1.5.10 released
by Erik Huelsmann 03 Sep '17

03 Sep '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.10 * Fix loading image URL taken from Dojo 1.12 (instead of 1.10) (Erik H) * Fix mails being sent with non-unique Message-IDs (Erik H, #3041) * Round-trip fewer values over web requests during migration (Erik H) * Migrate accounting <-> invoice relationship from LSMB 1.2/SL (Erik H/Yves L) * Fix 500 ISE on bottom of order when creating from vendor (Erik H, #3057) * Contact info now properly HTML-escaped (Erik H, #2820) * Add check for cr_coa_to_account primary key to 1.3 migration (Erik H, #2663) * Add work-around to PGOld for PGObject::Simple 2.x incompatibility (Chris T) * Fix missing asset classes on Depreciate and Disposal screens (Erik H, #3123) Erik H is Erik Huelsmann Yves L is Yves Lavoie Chris T is Chris Travers The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.5.10/ Additionally, the release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.5.10 or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.5.10 These are the sha256 checksums of the uploaded files: e2fcb54bcf5c93196a2b0e75c1b5d5dec72842b020c73f79c9bef636cc61da0f ledgersmb-1.5.10.tar.gz 9ba36a9c0420600cd6026f7511067626743b607c87c09164f7ab5b7255766477 ledgersmb-1.5.10.tar.gz.asc

1 0

Proposal on error handling
by Chris Travers 31 Aug '17

31 Aug '17

I was hoping to work on removing some of the difficulty this weekend but I think it would be a good to have a full discussion and hammering out of details first. As Erik pointed out in the template thread, our error handling is a mess. In some cases we are returning undef, in some cases we are throwing localised strings. The undef cases make for a few problems, but the localised strings mean we have no machine-readable error handling and is far worse. Among the problems with that: 1. If you want to, say, get the details of a GL transaction, you have to have a locale object. If you are running a program from outside the LSMB directory, that is easier said than done. 2. If something goes wrong, you cannot determine what the error was and handle it. This is a problem on both old and new code but it is a much bigger problem on old code. I think the easiest way of rectifying the situation is to recognise the code is fairly database-centric and build an error handling mechanism which largely extends the SQL State/message approach. I am going to suggest we standardise on the following: 1. We have a particular exception class (maybe an external one, maybe I write PGObject::Util::Exception). That exception class has four fields: a) an error code based on the SQL State table for current PostgreSQL b) an optional log message, and c) an optional query string d) an optional list of parameters which caused the error 2. When a database errors, we throw the sql state, query string, parameters, and a log message of class and method which caused the error. 3. Not found returns undef. If we must throw an exception we use 02000 as the SQL state. I expect that this is most common in the old code. In new code we could turn this into a 404 code if we want to. 4. Precondition checks croak with states that typically start with 22. In new code we could turn this into a 400 error code. Does this seem reasonable? -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

1 0

RFC: Formalize templates interface and split out onto CPAN
by Chris Travers 31 Aug '17

31 Aug '17

Hi; I have been thinking of what else we can/should split out sometime soon to CPAN and it has occurred to me that the interface of the templates could probably be split out (and maybe the mailer too). Both of these however contain LedgerSMB-specific assumptions and would need to be rewritten to some extent to address these. However with the templates in particular, removing these assumptions would help us get rid of a lot of the CGI assumptions we are currently making. In particular, I am thinking of the automatic output options which I think should be abstracted away or even removed. A major justification for this is that reporting endpoints for my LedgerSMB API gateway are much harder to implement across a Dancer interface than they should be, because we assume we are operating in a CGI environment. I would like to do this for the following reasons: 1. I would really like to be able to use the reporting generation in areas outside of a CGI web application, and 2. It would be nice to be able to open up additional formats to third party developers saying "Put it on CPAN and tell people they can install it like so." I would like to suggest that over the next major version or two I work on refactoring out or abstracting away the LedgerSMB-specific and CGI-specific assumptions to the templating interface, provide a dynamic format registration mechanism, and the like. And then work towards breaking these off once this is complete. Are there any thoughts on this? -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

3 9

Returning only content-type header from LedgerSMB::Template
by Erik Huelsmann 31 Aug '17

31 Aug '17

With the idea to simplify our LedgerSMB::Template handler, by moving all headers (but the content-type) from there to LedgerSMB::PSGI, I went to task: In the referenced issue, you write >>> >>> The template should be responsible *only* to render the content and >>> provide a file mime type back with it. This means that the output of >>> template->render() should ... >>> >>> Assuming that "template" there corresponds to my definition of >>> "LedgerSMB Template Engine" (concluded from the fragment of the second >>> sentence), I really wonder what value the template engine is providing: our >>> template processor has a render method too; the *only* thing it lacks is >>> the content type return value. The content type can be easily added based >>> on the extension of the processed template in a generic handler elsewhere >>> though. >>> >> >> Right. >> >>> >>> In the same paragraph, you continue >>> >>> The Template MUST NOT assume HTTP, PSGI, or any other particular >>> input/output format. >>> >>> Could you have a look and https://github.com/ledgersmb/L >>> edgerSMB/blob/master/lib/LedgerSMB/Template.pm#L540 ? I think that that >>> achieves what you want. >>> >> >> Yes, though more specifically, I think if we *do not use* PSGI or output >> options we achieve something much better. What I want to achieve is a >> clearer separation of responsibility and I think this has cascading >> benefits through the rest of the application as well as making the logic >> more general. >> > > Ok. You're proposing the return value being a pair: the expanded template > and the mime-type. The current implementation is a list of headers (usually > just the mime-type), the expanded template and a success/fail indicator (a > triplet). > > If we want to go with just the pair, how are we going to report the > success/fail indicator? (In other words, how do we report error > conditions?) I'll move the handling of the cache control headers currently > in "render_to_psgi()" to LedgerSMB::PSGI. That's a positive outcome of this > discussion for sure. > I have local work-in-progress. I've successfully moved the characterset addition to (utf-8) to all "text/" mime-types as well as the headers disabling caching when "back button disabling" is enabled, to LedgerSMB::PSGI. However, I'm trying to move the Content-Disposition headers to LedgerSMB::PSGI, but that's not quite so easy: the disposition header uses knowledge from the template (the type and name of the report). This information is not available on the LedgerSMB::PSGI level. So, how do I meaningfully name the downloaded file in this new world order? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Re: [ledgersmb-devel] Setting a policy for our dependencies
by Chris Travers 30 Aug '17

30 Aug '17

As a couple notes, I would add the following expansions to this. "Allow the widest possible version range on any module, disallowing individual malfunctioning versions to further extend the range" I think we are better off documenting bugs in misbehaving versions of modules and perhaps offering a module check utility rather than disallowing certain versions of modules. I say this for two reasons: 1. Managing this list is annoying and deciding when to block a specific version of a module is going to be an annoying and political decision, and 2. A block on a module version will not prevent someone who has an older version of the module from upgrading to a blocked version since it is an install-time check and another piece of software could require a newer version and thus break the install-time check. So I would suggest deciding required versions by first-supported version and up, and providing a tool or just documentation for checking for other problems in the mean time. Secondly I would like to suggest that a focus on moving things to CPAN and breaking the application into components for better testability. "Require as few a possible modules in the expanded dependency tree (prefer modules as direct dependencies which are already depended on implicitly)" Additionally I think that when we spin things off we should shoot for modules which are simple in interface, within a year or two will likely be pretty close to bug free and unlikely to require dramatic modifications, and therefore keep spin-offs throttled so they do not cause undue chaos for packagers. " Not depend directly on modules which have overlapping functionalities" Big caveat here is that some modules that are used *because* they are overlapping might be in a different position. Moo/Moose is a good example and both are widely used enough that there is no harm in using Moo instead of Moose in spun-off modules. However we still have some old paradigms in the code that need to be cleaned up and we should also focus on this. "Not require modules which only provide nice-to-have functionality" Also, while I am happy to see optional modules used to provide nice-to-have functionality it is worth noting that there are two things that need to be guarded against here. The first are extra dependencies. The second is extra code complexity that comes with adding such options. I would say that both need to be justified before we should allow them and where we do allow them we should think about how to set up proper interfaces so we don't have lots of conditional module handling everywhere. "Group feature dependencies into their respective features as much as possible (so as to not require them for a more basic installation)" A corollary here might be that long-run a lot of the application today should be relegated to optional features as we go forward. If someone doesn't need inventory tracking, why install it? If one doesn't need more than GL, customers, vendors, and basic reporting, why install more than that? Of course we aren't there yet but I would suggest that a forward-thinking view of dependencies we might want to think about it not only regarding the dependency problems we encounter with maintaining and working on the current code but also in the question of how modularised and loosely coupled we may want the code to be in the future. Best Wishes, Chris Travers -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

4 11

Sharing experiences packaging for Gentoo
by Chris Travers 29 Aug '17

29 Aug '17

Hi For various reasons I have started to package some other software for Gentoo and decided to put together an overlay for LedgerSMB. I wanted to share my experiences here and also looking at where the efforts I have seen on Debian, etc where we can probably make some improvements. First the good: Packaging the dependencies for LedgerSMB from CPAN was super-easy and straight-forward. It is as simple as using g-cpan to generate an initial ebuild, editing that to ensure that we aren't over-promising, and then writing a metadata.xml. I spent around an hour packaging all of our span dependencies. It was really, really easy. As a side note, one of the impressions I get from Jame (please correct me if I am wrong) is that one of the headaches here is legal: making sure we have all the right copyright information on all the right documentation, and this right now is a manual process. I will come back to that later. Packaging LedgerSMB is, on the other hand, very different. On one hand, these are not shared libraries so the build cannot go in vendor perl, and I am trying to support running multiple versions in parallel. Managing the direct dependency tree itself has been as much effort as packaging all of the dependencies. My approach is basically to: 1. Create an ebuild 2. Create a makefile which will overwrite the project makefile 3. Clobber the existing makefile with the new one in the ebuild 4. Point it at a directory (/usr/share/ledgersmb-1.4 for example) 5. Set up Plack (probably Starman at first. 6. Use an OpenRC init script (similar to Sys-V) to start Starman with each of the installed versions Right now I am on stage 2. Since there is a presumption against bundling, I will use any existing dojo ebuilds and this makes some things harder as well. However already packaging LedgerSMB has proved much more effort than packaging all the dependencies combined. One of the reasons I would like to see more stuff on CPAN from us is it would probably simplify this a lot. It's easier to have 2-3 optional dependencies each with 4 dependencies than to have 8-12 optional dependencies in 2-3 groups. Also, tracking which options have been enabled poses some complexity. From a Gentoo packaging perspective, the more we can put on CPAN the better. (Yes, g-cpan is not perfect, but it handles 90% of the cases nearly perfectly and once you get an ebuild, updating to a new version is super-easy). On to where I see some issues with the spinoff modules. 99% of the time I have been contacted by packagers (usually Jame) over packaging questions it is the nuts and bolts of things like copyright dates, changelog entries, etc. I would like to suggest that these can be subject to automatic testing. I would like to suggest the following global rules we can enforce by Travis or a git hook: 1. Copyright dates *MUST* include the current year for *all* modules changed, checked on every commit to master. This is something maybe we could enforce with a git hook. 2. Every tag MUST have a have an associated changelog entry. Again, something we could enforce via a git hook. There is one specific gentoo situation which is that source urls, being what they are, do not support backpan and cpan transparently together. Therefore I have to keep the overlay current regarding all currently supported versions and change urls to backpan were needed. That's a minor issue though. On the whole I expect working Gentoo packages in not too much longer and look forward to how we can help make packaging less work. -- Best Wishes, Chris Travers Efficito: Hosted Accounting and ERP. Robust and Flexible. No vendor lock-in. http://www.efficito.com/learn_more

1 0

customizations
by R. Ransbottom 27 Aug '17

27 Aug '17

Hello. Sorry to be away. Various infections and physical traumas have left me doing only the basics for about seven weeks. That seems to be passing. Re: 1.5.9 What are recommendations for customizing and adding tables (and all that follows)? Tools? Naming conventions? etc. For parts, adding about 25 fields and 4 constraining tables similar to salutations. Lesser invasions to vendors and customer data. Suggestions and references will also be appreciated. Thanks, Rob

1 0

When to factor out code into a stand-alone CPAN release?
by Erik Huelsmann 27 Aug '17

27 Aug '17

Hi, In a recent issue, Chris proposed to factor out part of the code base into a stand-alone CPAN release (which would IMO mean into a more-or-less stand alone project). The same happened some years ago when he factored out DBObject into PGObject, so, we have precedence here. The other way around (refactored our code to use releases from CPAN) has happened as well. >From my perspective, the reasons to refactor our code to make use of (pre-existing) CPAN code are clear: * Using pre-existing code from CPAN outsources maintenance (to an external maintainer) * Opens up opportunities for wider use in our own code base, because usually replaces specific with generic code * Ensures better testing of code in a wide variety of settings (hopefully with bugfixes) * Improves code-sharing in the wider Perl community (hopefully free-ing up resources to take Perl and its modules a step further) To me, the other way around would roughly work the same way. Meaning, that we should be thinking about placing our code on CPAN, if: * Our code is sufficiently generic to solve problems for others * Others can depend on us to do the maintenance of the code * Our code comes with sufficient quality assurance measures to be helpful to others * Our code is sufficiently stable not to require large refactorings to the projects (which would mean that people can't really depend on the code - yet) Especially the last point - I think - is tricky: when largish refactorings are in order, the fact that part of the code being refactored is loaded onto Travis CI through CPAN is a major limitation on the speed that can be had during the refactoring. The recent PGObject 1.x->PGObject 2.x refactoring showed that. I'm wondering: Is there anything else to be considered? (Reasons to factor out, problems to be met after having separated, etc...) Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 2

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

26 Aug '17

Hi, Currently we have 30 repositories in the LedgerSMB github project. over half of them are related to PGObject modules and are reasonably named in the form of PGObject-foo-bar However, not all of our repositories are named so sensibly. In particular we now have 4 "packaging" repositories - pkg-ledgersmb - pkg-ledgersmb-1.4 - pkg-ledgersmb-1.5 - lsmb-overlay From the names, it's obscure at best which distro etc each of those repositories is for, more confusing is the fact that the first 3 seem to be duplicates of each other, excepting for the fact that they target different releases of our code. The first 3 are for debian packages, while the fourth is the new repo Chris has added for gentoo packaging. To help with "discoverability" and generally make it more obvious what a repo is for, I'd propose a naming scheme along the following lines. $purpose-$project-$detail For true "project" repositories such as LedgerSMB, and PGObject projects $purpose may not make sense, but for others it likely does. Some examples - LedgerSMB - PGObject - PGObject-Type-DateTime - pkg-debian-LedgerSMB - pkg-gentoo-LedgerSMB - migration_test_data-LedgerSMB - docker-LedgerSMB - docker-LedgerSMB-selenium-grid - OPOS-LedgerSMB-integration - LedgerSMB-PHP-bindings I think it's probably early enough in the lifecycle of most of the repositories that could do with renaming to rename them now. I say that as the ones that would change have little use outside of our project controlled resources. As for having the pkg-ledgersmb-1.x repositories as well as the unversioned one, Unless Jame has a reason to do otherwise, I'd suggest we simply use tags in the pkg-ledgersmb repo instead. Consider the situation if we ended up with packaging repos for every different distro, and also every release series we do in the future, things would quickly become unmanageable

2 2

Fwd: ledgersmb project owned repository naming
by Robert J. Clay 26 Aug '17

26 Aug '17

Sorry, forgot to send to the mailing list as well... ---------- Forwarded message ---------- From: Robert J. Clay <rjclay(a)gmail.com> Date: Sat, Aug 26, 2017 at 2:30 PM Subject: Re: [ledgersmb-devel] ledgersmb project owned repository naming To: David Godfrey <info(a)sbts.com.au> David, On Sat, Aug 26, 2017 at 6:43 AM, David Godfrey <info(a)sbts.com.au> wrote: > Currently we have 30 repositories in the LedgerSMB github project. > over half of them are related to PGObject modules and are reasonably named > in the form of > PGObject-foo-bar > > However, not all of our repositories are named so sensibly. > > In particular we now have 4 "packaging" repositories > .... > - lsmb-overlay > > ...., while the fourth is the new repo Chris has added for gentoo packaging. For an 'ebuild' for Gentoo, which is not quite the same thing... (A "package" for gentoo looks to be just an application source archive, which an 'ebuild' for that app uses to build and install the application as necessary.) > Some examples .... > - pkg-gentoo-LedgerSMB An "overlay" is not a package it's an ebuild and having the word "overlay' in the repo name for them is very commonly related to Gentoo. (Or so it seems to be judging from a search on GitHub...) -- Robert J. Clay rjclay(a)gmail.com -- Robert J. Clay rjclay(a)gmail.com

1 0

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