- devel - lists.freelock.com

LedgerSMB 1.6.22 released
by Erik Huelsmann 21 Jun '20

21 Jun '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.6.22 * Update Dojo toolkit dependency to 1.13.8 (Erik H) * Fix sorting of hierarchical income statement and balance sheet (Erik H) * Fix columns not being populated in AR/AP Outstanding report (Erik H) * Add SameSite policy on session cookie to prevent being ignored (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.22/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.22 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.22 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.22 These are the sha256 checksums of the uploaded files: 8a32c183432cdf655c536d521c6951e8e0e0265d0c1ec92d77c161061e354a9e ledgersmb-1.6.22.tar.gz ce8fa58f30a8fed180ffb41740fc6c33ec02214b06e70d31410c9206d8b62fc2 ledgersmb-1.6.22.tar.gz.asc

1 0

[ATTN] Javascript build procedure changed on master
by Erik Huelsmann 21 Jun '20

21 Jun '20

Hi, Here's a heads-up for everybody who tracks the master branch. Last night we merged the "webpack" branch. This branch changes how our Javascript is being created. To convert to the new method, please run these commands in the root of your working directory: $ rm -rf ./UI/js-src/{dojo,dijit,util} $ make dojo Or, if you run your development in a docker container: $ rm -rf ./UI/js-src/{dojo,dijit,util} $ docker exec -ti <container_name> make dojo The procedure to build our Javascript has switched from using Dojo Toolkit's "util" package to using "webpack" for the building process. The process has been extended to implement quality controls for javascript, html, css and markdown to the generation process. All in all should this switch allow us to integrate better with Javascript front-end development as it's done today. Not unimportant: we'll be able to leverage React or Vue to build our front-end! -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 0

LedgerSMB 1.8 branched / 1.8.0-beta1 released
by Erik Huelsmann 12 Jun '20

12 Jun '20

Hi all, In preparation of the final release of LedgerSMB 1.8, the release branch has been created for a period of stabilization. In order to release the most stable version released by the project ever released, a preview version was published earlier today: 1.8.0-beta1. Users are encouraged to download the Docker images (tag: ledgersmb/ledgersmb:1.8) or the tarball ( https://download.ledgersmb.org/f/Beta%20Releases/1.8.0-beta1/) for evaluation purposes. Bugreports either in response to this mail or as GitHub issues are highly appreciated! The 1.8 release shifts away from HTTP Basic authentication, using encrypted cookies instead. This eliminates the popup authentication dialog on expired sessions. Additionally, does it provide a broader range of settings for outgoing e-mail and has support been added to upload logos and other files which can be used in downloadable documents. Please test LedgerSMB 1.8.0-beta1 with your use-cases (but not in production) and report any issues you're experiencing so they can be fixed before the final 1.8.0 release! Thanks, -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 2

LedgerSMB 1.7.15 released
by Erik Huelsmann 31 May '20

31 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.15 * Fix tax on invoice differs from search results (#4651) * Fix COGS for purchased-in-arrears parts (#4658) * Update Dojo to 1.15.3 IMPORTANT The COGS fix addresses a bug which results in incorrect accounting in case inventory is used and parts are sold before they are purchased. This problem doesn't impact services or GL-only accounting. While this fix addresses the core problem, it doesn't fix any data that may have been recorded incorrectly! If you use inventory *and* have sold parts before buying them (such that inventory ended up being negative), LedgerSMB may have debited income and credited expenses instead of crediting inventory and debiting expenses. This leads to too high inventory, too low income and too low expenses. The LedgerSMB team recommends consulting an accountant if this bug affects your books or contact a LedgerSMB consultant to identify if your books are affected (e.g. from https://ledgersmb.org/content/commercial-support) Downloads For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.15/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.15 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.15 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.15 These are the sha256 checksums of the uploaded files: 868cfb31edfb62a404d5f264327c84e5ea5999aeb56a4adac5c7ac532c156f8d ledgersmb-1.7.15.tar.gz f28a92326f99a4440f1be9ba74187ae4e61101a28262b8287ac8fca08e3e6d11 ledgersmb-1.7.15.tar.gz.asc

1 0

LedgerSMB 1.6.21 released
by Erik Huelsmann 31 May '20

31 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.6.21 * Fix COGS for purchased-in-arrears parts (Erik H) * Update Dojo toolkit dependency to 1.13.7 (Erik H) Erik H is Erik Huelsmann IMPORTANT The COGS fix addresses a bug which results in incorrect accounting in case inventory is used and parts are sold before they are purchased. This problem doesn't impact services or GL-only accounting. While this fix addresses the core problem, it doesn't fix any data that may have been recorded incorrectly! If you use inventory *and* have sold parts before buying them (such that inventory ended up being negative), LedgerSMB may have debited income and credited expenses instead of crediting inventory and debiting expenses. This leads to too high inventory, too low income and too low expenses. The LedgerSMB team recommends consulting an accountant if this bug affects your books or contact a LedgerSMB consultant to identify if your books are affected (e.g. from https://ledgersmb.org/content/commercial-support) For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.21/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.21 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.21 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.21 These are the sha256 checksums of the uploaded files: d64ae4d5a457a8bc6096982b0fde6d8002df29b59831a0940136519b915ed482 ledgersmb-1.6.21.tar.gz 2cca4d598c02e701c0e80e562ce7c23f83ce40f8aadc1ea27b40273311b0ddc0 ledgersmb-1.6.21.tar.gz.asc

1 0

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

LedgerSMB 1.7.10 released
by Erik Huelsmann 07 Mar '20

07 Mar '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.10 * Fix error displaying NULL exchange rates (#4438) * Fix incorrect receipt totals due to number formatting (#4441) * Prevent re-approval of approved inventory adjustment (#4458) * Fix NULL transaction dates in inventory adjustment (#4463) * Fix alignment of numbers in Inventory Activity report (#4454) * Fix variance calculation on reconciliation report (#4486) * Fix CSV import through explicit version on HTTP::Headers::Fast dependecy For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.10/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.10 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.10 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.10 These are the sha256 checksums of the uploaded files: 0f8293675dd0c03d54cee80e5e65cd078b7fcf58aeb6f6443911cec7c0eb21e6 ledgersmb-1.7.10.tar.gz 02a00420a5837375ab15332171eda7df15d3c0e19b9d0af950745661b9c480ee ledgersmb-1.7.10.tar.gz.asc

1 0

LedgerSMB 1.6.20 released
by Erik Huelsmann 07 Mar '20

07 Mar '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.6.20 * Prevent re-approval of approved inventory adjustment (Erik H) * Fix NULL transaction dates in inventory adjustment (Erik H) * Fix alignment of numbers in Inventory Activity report (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.20/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.20 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.20 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.20 These are the sha256 checksums of the uploaded files: 85176d09e9f9e4a7c37c60f28239be53ab0e036ba7dd6cb28e48c15bdc291ab5 ledgersmb-1.6.20.tar.gz ca1253f8f2c62825ffc0e75ed36fff682e48b6ac37aa4a96bfce96bbdbe8d58c ledgersmb-1.6.20.tar.gz.asc

1 0

LedgerSMB 1.7.9 released
by Erik Huelsmann 10 Feb '20

10 Feb '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.9 * Fix authentication issue due to inconsistent cookie handling For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.9/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.9 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.9 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.9 These are the sha256 checksums of the uploaded files: 44383e829c460ef5a567e03e3a480c4c12083a0f3611f616b4cb37c9026372d4 ledgersmb-1.7.9.tar.gz b3b5c5123ad6994af2e6975df0efe44266b9773a4a3e39a37895ba59f13072b2 ledgersmb-1.7.9.tar.gz.asc

1 0

LedgerSMB 1.6.19 released
by Erik Huelsmann 10 Feb '20

10 Feb '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.6.19 * Fix authentication issue due to inconsistent cookie handling (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.19/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.19 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.19 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.19 These are the sha256 checksums of the uploaded files: 17d784a326e7963cd048e05c32d9a65ba56b43734ed72b6266d866456f225a6f ledgersmb-1.6.19.tar.gz 2822affae38bfd27c74812288bd33bac129b00c1890b2232d28794673c40bcf8 ledgersmb-1.6.19.tar.gz.asc

1 0

Splitting authentication layers
by Erik Huelsmann 08 Feb '20

08 Feb '20

Hi, As part of my preparations to introduce web services, I've found that many web APIs provide two ways to authenticate: (a) a session cookie which can be obtained by "logging in", or (b) an "API key" ; either the API key or the session cookie is then provided with each request to the API, authenticating the request with the session and/or user. It should be noted that neither requests providing an API key nor those providing a session cookie contain further credentials. For our (API) authentication, ideally, I'd like to be able to provide both the "api key" and the "session cookie" patterns for request authorization. Additionally, I'd like session authentication to be available using: - Username & password (preferably through CRAM-SHA2 or higher SHA) * Note that in this scenario, the password validation could be anything; even a Kerberos or LDAP server - WebAuth / FIDO2 - OAuth2 - Client certificate - (and more, if we come up with those) == The Problem == Our current authentication setup requires plain text username and password on the initial login and each further request. We currently use basic auth to supply these values. In addition, we use a session cookie, but that only serves to validate the session. Thus every request currently requires the username, password and session cookie. The username and password are required because those are used to set up the database connection at the start of the request handling. Most of the authentication systems above don't maintain a username/password combination visible to our server. By consequence, I'm looking for ways to eliminate the need for the username+password in the Web request. Also, if we'd want to use "API key" type authentication, that API key would need to hold in it (encrypted, but decryptable to the server) the username and password in order to be able to log into the database. Note that the previous sentence explicitly states "in the Web request": ideally, LedgerSMB authentication can happen on two different levels -- the web request level and the database connection level. Basically, I'd like to start making the distinction between the web request authentication and the database authentication in such a way that our database authorization (access control) remains PostgreSQL-role-based (that is: doesn't change from the current model). == The Proposal == My current idea is to separate the web authentication from the database authentication. The web application would use a generic user to set up the database connection, switching the session authorization to the role associated with the user, as if the user had logged in directly on the database. Technically, this is achieved by the Pg command 'SET SESSION AUTHORIZATION = username'. This means that once the session has been verified (either through the API key provided or the session cookie), authorization can be switched to the (web)authenticating user and regular processing (as we know it today) can continue. This solution using the session authorization is very similar to what the Graphile (graphile.org) project uses [they use SET ROLE instead of SET SESSION AUTHORIZATION -- there are subtle differences between their approach and my proposal]. The solution has the benefit of supporting direct connections to the database as they are today with all methods built into PostgreSQL, adding into the mix a second set of authorization options better suited to a web authentication scenario. == The Request == Please comment on the above to get a good common understanding of what I'm describing and the best possible implementation at that. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

2 1

Some questions about the PGObject modules
by Chris Bennett 03 Feb '20

03 Feb '20

Hi, I've been working on and submitting ports, but there has been port-a-thons and hackathons right as I submit stuff. I took a long holiday this year as it rained and snowed almost non-stop. I also got delayed by my laptop having some kind of problem. I couldn't fix it, but it works fine with an older version of OpenBSD and I'm just running -current on my servers and doing this work there. I submitted PGObject a while back. Someone had to update the postgresql database test module for the testing to work. Then I realized looking closer that it does the same thing I do, it gets $dbh from elsewhere. I'm looking over the rest of these modules, but so far I am seeing mostly the same. Except for DBAdmin. So far running the database tests for that one are failing, including from the actual Perl build. I'm not sure that I am doing the tests properly. I'm going to ask and look at other ports in OpenBSD to see if I'm doing the tests correctly. We never directly use the Perl build for testing. We have a PostgreSQL testing module for that. I just saw mention of PGObject in github email. What does that mean? I haven't had a chance to look in the LedgerSMB code at the spots where those modules are being used. Otherwise, I've done a lot of work getting the modules ready. Submitted some and I've got several more ready to submit. I do have one problem. Several of the modules don't have DESCRIPTIONS. I already have one Plack that I have been asked to give a better description before it can be accepted (the encoding one). Also, the various PGObject-* are really bad on that. Is there any way to come up with something more official for the group? Perhaps like an overall description for the group with a detail for how each one fits into the group? Maybe something like: The PGObject set does ... and this module carries out the ... That would be extremely helpful. Once in the ports tree, no problems. -- Chris Bennett

1 0

LedgerSMB 1.7.8 released
by Erik Huelsmann 22 Jan '20

22 Jan '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.8 * Upgrade Dojo dependency to 1.15.1 * Load the template from the database when printing receipts * Prevent dead-locks in response to request from timed out session * Add monetary formatting to payments/receipts screen and report For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.8/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.8 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.8 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.8 These are the sha256 checksums of the uploaded files: 59a7ad10d8da1b28f298239c93ea4ca15fd348ff5d1517253dfe6a4b51d099a4 ledgersmb-1.7.8.tar.gz c91c4b3af21ac0ad8d6d5809678ed8e537596e15899d3142e196ac2a724f9876 ledgersmb-1.7.8.tar.gz.asc

1 0

LedgerSMB 1.6.18 released
by Erik Huelsmann 22 Jan '20

22 Jan '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.6.18 * Upgrade Dojo dependency to 1.13.5 (Erik H) * Prevent dead-locks in response to request from timed out session (Erik H) Erik H is Erik Huelsmann For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.6.18/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.6.18 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.6.18 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.6.18 These are the sha256 checksums of the uploaded files: e07f6afc54c33f30d5b914c7e28635640e5c246826f7f5054d0742c2f2214f62 ledgersmb-1.6.18.tar.gz 828c87904b13617f60f5011a97767dcf073be0534bb529363f28387c289ae51c ledgersmb-1.6.18.tar.gz.asc

1 0

New reconciliation rules in relation to payment changes?
by Erik Huelsmann 22 Jan '20

22 Jan '20

Hi, Over the past weeks, I've implemented a change in the way payments are being recorded: batch payments are now recorded explicitly (instead of implied) and payments entered into the invoice screen are now recorded (as opposed that they were not recorded as payments, but "just" lines on the invoice transaction). The next step in my improvement plan is to use the new payment information in Reconciliation. To understand the problem domain, there's a bit of context to be explained: technically, every invoice being paid in a payment causes its own line in the Bank GL account. These lines are grouped using a payment identification. Now that all payments are being correctly recorded in the database, we can tap into that information to summarize the bank reconciliation view: We can show payments as a single line. Where we're coming from is different: we used to aggregate lines on the Bank GL account by various fields (reference, counterparty, source reference, date, transaction type, mostly). The method we used to use, caused two payments by the same customer - entered without a source reference number - to be aggregated into a single reconciliation line. On the other hand it was impossible to post small corrections to payments through the GL: because the aggregation takes the transaction type into account, GL transactions and payment transactions (AR/AP) can't be aggregated into a single reconciliation line. I was thinking that the reconciliation could be changed to use this business rule: Aggregate into single reconciliation lines (so as to reconcile with a single bank transaction): * Payments and GL transactions on the same date with the same 'reference' * GL lines with the same date and same 'source' (source reference number) -- if the gl lines couldn't be merged with a payment This business rule allows reconciliation - as single reconciliation lines - of: * Reconciliation of payments *with their GL corrections* as a single payment line * Reconciliation of payments (without GL corrections) * Reconcilation of GL-entered lines with the same source code reference * Reconciliation of GL-entered lines individually (when no source code reference is entered) Is this what we want? It's wildly different from the criterion we currently use, where we aggregate all lines on the bank account, into lines where the differentiator is: * Date * Transaction type (ar/ap/gl) * Reference (AR/AP: internal eca ID; GL: transaction's "Reference" field) * Voucher number * Source reference number (Source field of transaction line) * Memo field content (transaction line Memo field) Note however, that in the current situation, there isn't a concept of "payment" in the database at the moment; transactions posted using regular and batch payments receive the same values for Date, Transaction type, Reference, Source reference number and optionally voucher (for bulk payments). Concluding: the old rule mostly aligns with payments, but on a different basis and may aggregate multiple payments into one. When we hash out the question above, I have a follow-up question of how the reconciliation process should work from a business process perspective. Let's try to hash this one out first. -- Bye, Erik. http://efficito.com -- Hosted accounting and ERP. Robust and Flexible. No vendor lock-in.

1 2

LedgerSMB 1.7.7 released
by Erik Huelsmann 12 Jan '20

12 Jan '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.7 * Fix currency column not being available in the parts screen For installation instructions and system requirements, see https://github.com/ledgersmb/LedgerSMB/blob/1.7.7/README.md The release can be downloaded from our download site at https://download.ledgersmb.org/f/Releases/1.7.7 The release can be downloaded from GitHub at https://github.com/ledgersmb/LedgerSMB/releases/tag/1.7.7 Or pulled from Docker Hub using the command $ docker pull ledgersmb/ledgersmb:1.7.7 These are the sha256 checksums of the uploaded files: 3509cfa379c5752206a464abc0b04c1beaff66ee7a6b2e49c338d7808de9e08b ledgersmb-1.7.7.tar.gz b00f2b01607822d862c5ef7446c3c4e1d887204123e90d4441bec4da6e1020fb ledgersmb-1.7.7.tar.gz.asc

1 0