- devel - lists.freelock.com

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