Hi,
In my current installation of LedgerSMB, the tables are in a schema other
than public, because I installed it in a database where there are other
data in schema public. (The reason I did that is that I want to link tables
in schema public and LedgerSMB tables, but I have not done it yet.)
I could make it work relatively painlessly with LedgerSMB 1.3 by setting
db_namespace in ledgersmb.conf.
Recently (that is, very late!) I wanted to upgrade to LedgerSMB 1.5.24
(not 1.6 because my server is still under Debian stretch). I think I could
upgrade the database correctly with setup.pl, but when running login.pl it
will not work because, according to Postgresql's logs, it insists on trying
to call the stored procedure public.setting_get, which does not exist.
Although I do not know perl, I tried to read the code to understand what
is going on. If I understood well, stored procedures are called by calling
directly or indirectly the perl function call_procedure in module PGObject,
which sets the schema to public when it is not specified. However, module
LedgerSMB also contains a function call_procedure which correctly sets the
schema, so the problem seems to be that sometimes PGObject's call_procedure
is called directly instead of module LedgerSMB's. I do not understand why,
because I do not know what constructs like $self->call_procedure or
__PACKAGE__->call_procedure do, but anyway this is very annoying for me,
because it means that LedgerSMB 1.5 just will not work with db_namespace
set to anything else than public.
Was this problem known? Is it corrected in a later version?
Regards.
Hi,
I just created a fresh virtualbox image to install ledgersmb 1.6.10 on
it.
It is really a basic image:
- Ubuntu 18.02 Server, updated on 6th of Jun, 2019
- added ppa:ledgersmb
- added postgresql repository (pgdg.list)
- postgresql 11 installed
- ledgersmb 1.6.10 installed, listens on *:5762
- created on Virtualbox 6.0, exported as OVA, basic information
included in description (login etc.), 1.7GB packed size
Todo after starting (only quick hints):
- set up network
- change users/passwords
- recreate ssh server keys
- whatever
Where can I upload officially?
Cheers,
István
Hi,
After the release of 1.7.0-alpha1 we have been working towards the 1.7.0
release as described in our community update. We feel that the 1.7.0 branch
is feature complete and while we're developing tests to find and fix
possible regressions and older bugs, no new features or major changes are
expected to be implemented before 1.7.0.
This means that the current code base (modulo any and all regressions we
can find and fix) will become 1.7.0 when it's ready. To help you find the
bugs we need to fix before the release, we have published 1.7.0-beta1. It's
available as a Docker image from Docker Hub under the tag
"ledgersmb/ledgersmb:1.7.0-beta1". See
https://hub.docker.com/r/ledgersmb/ledgersmb/builds/
Additionally, the release can be downloaded as a tarball from the download
site:
https://download.ledgersmb.org/f/Beta%20Releases/1.7.0-beta1/
Please report any issues you find in reply to this e-mail (that is, to the
mailing list) or create an issue on GitHub with your finding:
https://github.com/ledgersmb/LedgerSMB/issues/new?template=ISSUE_TEMPLATE.md
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
Hi,
It was just before New Year when I sent out the last community update, so
it's time for a follow up.
This half year, we only released 1 maintenance release for 1.6.10. With no
specific new bug reports coming in, the development team was able to focus
its efforts on 1.7.0.
On that front, a lot of development effort has gone into getting the
Multi-Currency branch ready to be merged to master. On January 20th the
long-awaited multi-currency branch merge happened, followed by the release
of 1.7.0-alpha1.
Since then, we've been developing more tests simulating user interaction
with LedgerSMB to ensure that 1.7.0 will be as good as 1.6.0 when it is
released. In the process, we have been fixing a few regressions. With the
additional tests - which include tests for AR & AP invoices and
transactions - we have increased test coverage from 29% (current on 1.6) to
40% (on master) and we're working to increase the number to well above 50%
before release.
The speed at which we're able to implement new tests is severely impacted
by the fact that we hit a continuous integration limit: Travis CI allows us
to run tests for a maximum of 50 minutes. Our test suite runs between 40
and 45 minutes in code-coverage testing mode.
A lot of effort has gone into working on this problem. We're working to
off-load the code-coverage test jobs to another Continuous Integration
service (CircleCI) which *does* allow jobs to run longer than 50 minutes.
Another direction of research was to reduce execution time of our test
jobs. And while that did turn up some bugs in our Selenium test driver, it
mainly helped the area where we didn't experience any problems (the
non-code-coverage tests were reduced from 29-30 minutes of execution to
20-21 minutes of execution).
Migrating some of our test infrastructure to CircleCI turned out to have
the additional benefit of being able to start running our tests against
Chrome and Firefox. Currently we only run against PhantomJS. While
PhantomJS implements enough of JavaScript to support our testing, it's
unmaintained and getting behind on recent standards. Being able to test
with Chrome and Firefox will help to take advantage of more modern browser
development techniques.
As part of our optimization work, we helped create new releases of Weasel,
Pherkin::Extension::Weasel and Test::BDD::Cucumber, where significant new
features were added to Pherkin::Extension::Weasel to support increased
developer efficiency.
Looking to the immediate future, we're expecting to release 1.7.0-beta1
this week: we think 1.7.0 is feature complete and we'll work simply to
stabilize it from here on. This means that 1.7.0 isn't production ready,
but we're looking for people to test-drive it and value any and all bug
reports we can get!
Regards,
Erik.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
