- devel - lists.freelock.com

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