January 2020 - devel - lists.freelock.com

Adding to OpenBSD. Is this a good time now?
by chris＠bennettconstruction.us 19 Nov '24

19 Nov '24

A lot of Perl modules need to be imported into OpenBSD in order for it to be installable. I plan on asking for help to do this from OpenBSD users. It seems like LedgerSMB would now be a good import with all of the development of testing, etc. Are there any big changes on the immediate horizon for 1.5? I'm not running LedgerSMB because of the work that needs to be done first. As a side note, I am working on getting the forums back up, but $$ are a bit of a problem right now. Trying to find a baremetal server outside of the USA that I can afford hasn't been successful so far. I found one, but they charge $30 for remote access for 24 hours. I can't afford $90 a month, which is most of what I am finding. Thanks, Chris Bennett

3 2

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

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