- devel - lists.freelock.com

LedgerSMB 1.7.14 released
by Erik Huelsmann 23 May '20

23 May '20

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.7.14 * Fix AR/AP account being reset to default on transaction Update-s (#4599) * Fix CSV, ODS or TXT reports being downloaded without extensions (#4613) * Fix 'To pay' amount resetting on second updates in single payments (#4633) * Fix 'Paid' amount incorrect when 'Apply discount' unchecked (#4514) * Fix income statement failing to filter on invoice reporting units (#4615) * Fix payment discount not being posted (#4616) * Fix tax base and amount doubled on printed invoice (#4645) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.14/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.14 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.14 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.14 These are the sha256 checksums of the uploaded files: 3d66daeaf62e6c236d168619d8ebf2f5f7e2adf4505c36f334ec507445614d48 ledgersmb-1.7.14.tar.gz 5969e1e883cc8339d501f74ed91da1479519237f18fd2f1fdca2874b1c338710 ledgersmb-1.7.14.tar.gz.asc

1 0

Selecting my next bug to work on
by Erik Huelsmann 17 May '20

17 May '20

Hi, As promised on my GitHub Sponsors account ( https://github.com/sponsors/ehuelsmann) I've drawn up a selection of bugs that I'm ready to take on. The community will be offered an opportunity to help select the bug that adds most value when being solved. These are up for selection: * Cannot delete business unit class A bug reported for 1.7; for details see https://github.com/ledgersmb/LedgerSMB/issues/4597 * AR Search for using salesperson doesn't filter A bug reported for 1.7; for details see https://github.com/ledgersmb/LedgerSMB/issues/4604 * Adding a reporting unit fails under some circumstances A bug reported for 1.7; for details see https://github.com/ledgersmb/LedgerSMB/issues/4614 * Payment discounts not posted A bug reported for 1.7; for details see https://github.com/ledgersmb/LedgerSMB/issues/4616 * Filtering the income statement by salesperson doesn't filter A bug reported for 1.7 as https://github.com/ledgersmb/LedgerSMB/issues/4615 Please provide your feedback by Wednesday May 20. Please note that sponsors get an actual vote; all others provide advisory feedback. If you most-wanted bug isn't in this list, please mail me directly about that and I'll check to see if I can add it to the list on its next iteration. Before you mail me, please make sure your bug is registered as a bug on GitHub (https://github.com/ledgersmb/LedgerSMB/issues) -- Thanks! Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

API design and choices
by Erik Huelsmann 17 May '20

17 May '20

Hi, Talking on our chat channel, we were talking how to best implement our API. Over the past months, the idea was to implement our new API as JSON:API. This mail serves to lay out experiences and thoughts so far. Maybe it helps to determine good next steps. As a first step, it would probably be a good idea to list why we need an API followed by what we need/want from it. The Why's: * Integration with other applications, not all provided by the project * Better support the needs from our web front-end: Vue, Dojo, react all want to be hooked to REST APIs * Development of custom front-ends What would we like our API to be? 1. Standards compliant where we can; if a generic browser could be used to "surf" the API, even better 2. Preferably well-defined semantics for good guidance on implementation 3. Resource definitions don't mirror internal table structures, but define logical concepts 4. Easy to understand and use by non-project developers 5. Easy to expand by project developers while maintaining consistency 6. Development supported by Perl libraries on CPAN 7. Supports returning the same resource in many forms (e.g. invoice as JSON, PDF or HTML) From the investigations we did, it seems JSON:API supports (1), (2), (5) and (6): it provides good guidance on the structure of resource URL naming as well as the structure of the JSON object returned. There's a even PONAPI on CPAN: Perl's implementation of a JSON:API server. With respect to (3) [resource definitions], I'm finding the standard extremely limiting: due to the structure imposed on returned documents, references to other resources are always "top level" members. I mean that the standard allows resources to be complex structures, with arrays and objects nested in the definition. However, those nested structures can't refer to other resources. As an example: if the lines of a GL journal is included in the resource definition as an array, then the lines themselves can't refer to other resources, such as accounts or batches. The standard authors solve this by making the lines separate (nested) resources, which are returned with the request for the journal. With this limitation, the resources in the api quickly start to mirror the internal table structure: GL lines need to refer accounts, invoice lines need to refer to parts and inventory. Orders need to refer to multiple addresses (billing, shipping). Journal lines need to refer to batches, payments, transactions, accounts, etc. Most examples where JSON:API explains related and nested resources, it takes a blog post with its comments. For that use-case, I understand the structure chosen. However, in the use-case of a GL transaction, the transaction *is* its lines. On the topic of (7) [support for returning multiple forms of the resource], I can be short: allowing any other mime-type on a JSON:API endpoint than application/vnd.api+json is a violation of the spec. Then there's (6) [supported by Perl libraries]. The good thing are: it's a PSGI app that can be mounted in our URL space and building the JSON:API server is work we don't have to do anymore. It seems pretty low on activity though: its latest release was in Feb 2019, with a bit of prior activity in Dec 2017, Feb 2017 and Sep 2016. The number of open issues is pretty low: 13, but none newer than 2016; from the open issues, it's clear that it doesn't support the full specification yet, because it doesn't support paging of "referred to" resources. The issue that's been untouched the longest (https://github.com/mickeyn/PONAPI/issues/45) calls for thorough investigation before we jump on this module, however: "Creating a repository is non-trivial" (a repository in PONAPI is where the data is sourced from); apparently, implementing a data source is still a lot of work, even though the framework is there. Another downside that I found from PONAPI is that it doesn't pass the web-request context on to the data provider. Normally that isn't a problem, likely, but for our project, where the web request context equals database access, this is a big problem. In short: * PONAPI is incomplete and development is slow (but has releases on CPAN dating back to 2015, so maybe it's mostly "done") * JSON:API has -by design- some serious limitations in the way we can define our resources, resulting - quite likely - in mirroring internal table structure in the resource definition * our desire to return various representations of the same resource conflicts with the JSON:API standard Given the above, I'd welcome your thoughts, opinions and reseach contributions. To address some (or all) of the short-comings of PONAPI, I've started developing our own JSON:API server component. However, there is a lot of work to be done to move that anywhere. I hope this mail will stir discussion and provide direction on whether or not to continue on our own JSON:API component, seeking contact with PONAPI or to move in a different direction entirely. Regards, Erik.

1 0

LedgerSMB 1.7.13 released
by Erik Huelsmann 06 May '20

06 May '20

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.7.13 (to be released) * Fix listing asset classes throwing an error (#4569) * Solve failure to create initial user by requiring input (#4525) * Fix links at the bottom of the CoA screen (#4568) * Fix CoA export (ODS, XLS or XLSX) throwing malformed XML error (#4580) * Fix downloaded reports missing extension (e.g. '.pdf') (#4584) * Improve performance of deleting batches (#4449) * Fix error thrown when opening reporting unit 'edit' screen (#4592) * Fix transdate being NULL in journal lines from bulk payments (#4587) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.13/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.13 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.13 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.13 These are the sha256 checksums of the uploaded files: 2378fa5870bad1d6a2f3098f27e3842e7d77c6062b8b77fd19396ae455386be5 ledgersmb-1.7.13.tar.gz ab8871c030f8fc458997e967591c65539fe9b46ddab1179b3de1d28327245ce2 ledgersmb-1.7.13.tar.gz.asc

1 0

Porting into OpenBSD
by Chris Bennett 03 May '20

03 May '20

Hello, I've submitted a number of the Perl ports for OpenBSD. Most have an OK. New imports require a second OK. At some point that will happen. I also submitted an issue with some suggested description improvements to the author of Plack::Request::WithEncoding. He liked my suggestions and that module is now at v13. There are some other dependency changes, too, which might need to be addressed for building. Or maybe not relevant. Those building changes from Module::Build to Module::Build::Tiny have now led me down the road to properly understnading those modules, so that's going to take up a little of my time. Time that's probably well spent. I'll keep submitting new modules. I doubt that I'll get everything in for this upcoming -release (OK, I'm sure I won't), but probably will get things into -current after -release. I'm having fun so far. I hope that everyone is doing OK right now. Chris Bennett

2 2

LedgerSMB 1.7.12 released
by Erik Huelsmann 27 Apr '20

27 Apr '20

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.7.12 * Reconciliation reports list now shows usernames rather than user ids (#4388) * Single payment interface throws error without open invoices (#4529) * Fix CSV data imports discading the first row (#4567) * Improve Chart of Accounts import no longer discards heading (#4567) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.12/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.12 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.12 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.12 These are the sha256 checksums of the uploaded files: 9f25e4a4ff7ac15d4cef7f9d615548b9866fc41fe40d5891c34b1d802157e532 ledgersmb-1.7.12.tar.gz 6537bd20015615a9f10e42e72bc9e1bb8d8a8d039152c2bf41a280100e97d50d ledgersmb-1.7.12.tar.gz.asc

1 0

Proposal to remove "1.3_date_auto" branch
by Erik Huelsmann 24 Apr '20

24 Apr '20

Hi, Our repository has had a "1.3_date_auto" branch for years that hasn't been maintained since 2014 (last functional commit on 1.3 branch: 2016). I'd like to remove that branch, retaining only branches that we used to provide community support for. Any objections? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 2

LaTeX::Encode versus TeX::Encode
by Erik Huelsmann 23 Apr '20

23 Apr '20

Hi Chris, Template::Plugin::Latex has an encoding routine which we're *not* using to encode data before being passed to (Xe)LaTeX. We're contemplating simplifying places in our codebase and one of the changes would be to use the built-in latex_encode. Do you have any recollection with respect to the choice for TeX::Encode and whether we should be fine to move to "latex_encode" all these years later? Regards, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 3

LedgerSMB 1.7.11 released
by Erik Huelsmann 11 Apr '20

11 Apr '20

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.7.11 * Fix inventory adjustments failing to update balances (#4467) * Fix inability to delete individual vouchers from a batch (#4448) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.11/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.11 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.11 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.11 These are the sha256 checksums of the uploaded files: 8df5172a1360e30ae8513766d3c42a2b0612c07f8e2810d0c55c59a9fe67dde2 ledgersmb-1.7.11.tar.gz 94417b9baedee37f76f5578e15e4fd8ce0a3a4870b174008d4c6bc987c1ce4ad ledgersmb-1.7.11.tar.gz.asc

1 0

Using Vue to drive our Single Page Application (SPA)
by Erik Huelsmann 22 Mar '20

22 Mar '20

Hi! Since 1.4 (released in september 2014), we have used Dojo Toolkit with its Claro theme for a professional (business) look-and-feel as well as providing users with more direct feedback on their actions (such as checking that required fields are correctly provided). Even today, we're using Dojo 1.16 to support our 1.8 development. Although Dojo is serving us well, the world has moved on. Even the Dojo developers have moved to developing Dojo 2 - a toolkit which is technically completely incompatible with Dojo 1, although it is built on the same philosophy of what's required for professional-looking web applications. For quite some time, it has been apparent that we need to switch to something other than Dojo 1, even if it is only because Dojo 1 drags lots of cruft with it. Switching to Dojo 2 is - due to its incompatible nature with Dojo 1 - a similar effort as switching to something completely different. For that reason, I have been evaluating a number of options, along the following list of requirements: 1. *Separate framework, loader and widget library* With Dojo 1, Dojo and its Dijit library are all of the above. They are also very tightly integrated. 2. *Support our Dijit widgets and declarative code* There is too much dijit-html in our code base to make a step to a different widget library at this point: especially in 'old code' html is still being composed "inline", which means that we're not ready to make templates for all our code yet - an assumption that most current frameworks seem to depend on 3. *Support our desire to create new code using a service-based SPA approach* In order to move forward, we are implementing services for our 1.8 rewrites. This means we're investing in new technology and we should want to take advantage of the full capabilities of the new framework we will be selecting. In addition, I'd like to stick to developing our UI through some kind of templating as we have been doing so far using Dojo's declarative syntax -- Dojo also supports a programmatic syntax, but we have explicitly not gone there. Over time, I have been looking at the following frameworks to replace our Dojo 1 setup: * Dojo 2 * React * Vue * Svelte And skimmed over a lot of others. Going over the alternatives, I started with Dojo 2 -- this is several years ago, when Dojo 2 wasn't final yet. Back then, the developers were using a "build the application in code" (instead of templates) approach. When asked about it, they declared that templating can be bolted on, but it's not a concern of theirs. When I looked at React, it looked overwhelming, is/was using inline templates using JSX (plain, unquoted HTML inside JavaScript), which very much felt like our old code, but in JS instead of in Perl. I looked at Vue several times over the past years. Its templating system is relatively quickly understood. The first few times I went out to find widget libraries to go with it, however, each time I found that we still need to support Dijit widgets too -- and I'd hate to have mixed looks for newer and older code where older code would use Dijit widgets while new code would use Vuetify or similar. Last week, based on recommendations from John, I looked at Svelte. It looks extremely appealing as it doesn't prefer one widget library over another and has as its focus to send as little code over the wire to the client as possible. It achieves that by precompiling templates into optimized/targetted JS functions. Remained the question on how to use our Dijits with it. This morning, I decided to a proof-of-concept with one of these libraries. As I found instructions for Vue on how to create its renowned 2-way data bindings for non-native components, that's where I decided to start. Over the course of a single day, I was able to: * Load Vue and Dojo into the same page (without conflicting, ready to be used) * Create a Vue app out of the login page (no functionality yet) * Tie a Vue action to the login form submission (which required it to stop being a Dojo widget) * Create 2 Vue components encapsulating Dijit widgets to deal with 3 types of UI elements: 1. Button 2. TextBox (for text and password) * Find out how to propagate the content of the Vue button component to the Dijit Button widget to be used as the button caption * Set up two-way data binding between the Dijit TextBox widget and the Vue textbox component ... and it's only 4pm right now! :-) I've committed my code to https://github.com/ehuelsmann/LedgerSMB/tree/vue-with-dijit . Based on the experience above, I'm now quite happy with Vue as our main option to take the next step into expanding our SPA. In order to determine the right way forward for the application as a whole, though, further experimenting will be required: something as "simple" as our login page obviously is no match for the logged-in application which has a menu, error popup and main application section, each with its requirements to support this mixed setup. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0