Re: [Ledger-smb-devel] Beyond 1.5

[John Locke]

Hi,

Overall I'm completely in favor with just about everything in this 
thread. To summarize, as I see it:


- Create a 2.0 branch, which at first may be used for experimentation 
around how to best clean up the schema/support new features/etc, and 
gradually solidify that into the next major version.


- Don't guarantee backwards compatibility in this branch, but don't 
break things for no good reason.


- Eventual upgrade path will be a data migration (and to take a step 
further, perhaps we only specify full support for migrating Accounts, 
ECAs, parts/services, GL/AR/AP/payments -- the core 
accounting/bookkeeping stuff, while possibly suggesting a clean break 
for the other items if they prove difficult to migrate?)


- 2.0 should focus on the optimal accounting design, providing an API 
and a plugin framework to keep extensions separated enough to be easily 
maintained outside core


- 2.0 should be spec-driven -- we should build out in tandem with 
documented user stories, living schema, API documents, and tests. Those 
may be unstable until we're all satisfied they are sufficient, but we 
should avoid a "code first" development pattern for anything beyond 
experimentation.



I think this last point should be the main thing that coordinates our 
efforts across the 1.x and 2.x branches -- we should be able to take our 
BDD tests for 1.x, evaluate whether there are steps to eliminate or 
improve, and use those as a starting point for 2.x (never mind that they 
will all fail at first). Then flesh out the tests for the core 
accounting functionality that we may not have gotten test coverage for 
yet, particularly those areas that are giving us trouble in 1.x and need 
to solve for 2.x. And then go from there...



Regarding the 1.x feature freeze and support for managing 
customizations, I really don't have anything to add -- it's not an issue 
for us, and we aren't working with any clients on LSMB (let alone any 
with customizations to maintain).



The only thing in the thread I'm not sure I'm entirely seeing the need for:


On 12/13/2016 12:46 PM, Erik Huelsmann wrote:


3.  The way things are split up gives us no real hard enforcement
of referential integrity. We have partial enforcement but not what
I think we need.


Can you be more specific on this one? It's definitely one of the 
things I'd like to the document collecting notes about the existing 
database schema.




I come from the fast-and-loose PHP world where pretty much nobody uses 
referential integrity. Mainly because it wasn't even supported in MySQL 
until well into the lifetime of the major projects.


One thing comes to mind that might be a problem for having the database 
enforce referential integrity, and it goes straight to the heart of 
supporting pluggable extensions (and shows my lack of experience with 
this level of database administration) -- can you have referential 
integrity for a column referring to columns in one of several different 
tables?


The scenario I'm picturing is CRM. I can see having a really basic 
contact management plugin that is closer to SQL Ledger than what we have 
in LSMB 1.4 -- essentially just ECAs, no entities. And other plugins 
that might supply contacts, companies, or whatever. I'm picturing that 
instead of a single column on one of the core finance tables that links 
to an ECA ID, instead, we have two columns -- one for the ID, and the 
other for the table this ID belongs to. This would allow a plugin to 
define their own table, and use it as an alternative to our built in 
ECA. But unless I'm mistaken, this won't work if we enforce referential 
integrity on the eca_id column.


... and a step further, why do we need referential integrity? Isn't the 
point being able to cascade delete all data related to a particular row 
in one table -- and prevent deletions of rows that are referenced in 
other tables? I think of the accounting system as an append-only log, 
there should never be any actual deletion, just correcting transactions 
added to the journal. So I'm failing to see why this is useful to us at all.


Otherwise, I think we're all in violent agreement here...

Cheers,
John Locke
http://www.freelock.com

--
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal for 1.6 and above: small new-code-only developer release

[John Locke]

ew code isn't built yet, build the parallel functionality in the 
current release and migrate stuff over a chunk at a time?





Basically, from a development point of view, I've taken exactly this 
approach, btw: I've been working around the old code, putting a 
foundation in place which can replace the old code after we rip it 
out, without ever needing to touch the old code. In that sense, the 
existence of the old code in the code base hasn't bothered me much 
over the past year, other than that I have had to fix bugs in our old 
code, because people were running into problems.


Yes, exactly -- I think we should continue this approach.




As for removal of old code: I don't see that as a goal by itself. I 
see it simply as a means to move the LedgerSMB code base to a point 
where we can have a much better agility in bug-fixing, where we can be 
much more extensible and open to integration with surrounding systems.




Agreed...

Happy to add more later, but gotta run, camping weekend ahead!

Cheers,
John Locke
http://www.freelock.com
--
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports.http://sdm.link/zohodev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Changes to the ledgersmb.org website

[John Locke]

(resend from my subscribed email address...)

Hi,

I've made the following changes:

* Allowed much bigger user pictures to upload, but set a server-side 
preset (the unused Square Thumbnail) to resize user pictures to 44x44, 
which is what 4em generated in Chrome)
* Turned on "Panelizer" and applied to article teasers -- with no 
further configuration, this removed the authoring info on the teasers
* Set up a Visual Regression Testing tool (but did the baseline at this 
point, after making the previous changes)
* Applied the two remaining CSS fixes from Erik: making the user image 
"display: inline-block" and giving them 4px rounded corners


* Ran the visual regression testing, you can see the results here: 
http://ledgersmb.org/lsmb_shots/gallery.html


Regarding best practices, I think we already have a view of content that 
takes a tag name from the path to filter, so you probably didn't need to 
create that. http://ledgersmb.org/topic/installation ... it looks like 
your view filters down to only articles, so it shows less -- no harm 
having that here, especially if you want to curate further...


Cheers,
John


On 05/07/2016 05:30 AM, Erik Huelsmann wrote:

Hi John,


In preparation of the 1.5 release, I've been looking at ways to 
publish installation instructions and notes. While doing so, I found 
that there wasn't really a structure for showing installation 
instructions on the ledgersmb.org  site. Under 
the Documentation menu item in the Main menu, there's now an 
"Installation" link which points to http://ledgersmb.org/installation. 
It's a new view I created by collecting all contents of type "Article" 
with the tag "Installation".


Would you say that that's the right way to go? Or should I have 
created a separate content type? I'm thinking that may be overkill.


One thing that I've noted and never brought up before: I think the 
"user picture" on each article is *way* too big. It takes up a lot of 
valuable screen estate. Can we do away with it in the teaser layout, 
only showing the textual submission data (user and date)? Then maybe 
shrink the image to 4ems-width max, with the submission data on the 
right of it, instead of on the next row? (Saves some vertical more 
screen estate.)


In my browser I added two rules to achieve the bit of the user picture 
in the regular ("Content") view:


.user-picture img {
width: 4em;
}
.user-picture {
display: inline-block;
}


I was able to achieve the bit I mean about the teaser section with 
this rule:


.node-teaser .meta.submitted img {
display: none;
border-radius: 3px;   // the pictures look a lot more friendly 
when I add that

}

I hope you all agree this step makes the site's content much more 
accessible; an improvement.


Could you put these into effect?



--
Bye,

Erik.

http://efficito.com  -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial!
https://ad.doubleclick.net/ddm/clk/302982198;130105516;z___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] LedgerSMB 1.4.27 released

[John Locke]

Docker image for 1.4.27 is available, as ledgersmb/ledgersmb:latest, 
1.4, and 1.4.27.



On 04/10/2016 05:00 AM, Erik Huelsmann wrote:
> 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:
>
> * Added note to batch list that all are locked (Chris T)
> * Allow multiple logins per user, all with own locks (Chris T, #1418)
> * Fixes meaningless subtotals on recon search results (Chris T, #995)
> * SQL Ledger 3.0 migration support (Yves L/Erik H)
> * Fix random column ordering in PNL & B/S comparison (Yves L)
>
>   Special thanks to Stig Berg for finishing the Norwegian Bokmal translation
>
> Chris T is Chris Travers
> Yves L is Yves Lavoie
> Erik H is Erik Huelsmann
>
>
> The release can be downloaded from sourceforge at
>https://sourceforge.net/projects/ledger-smb/files/Releases/1.4.27/
>
> These are the sha256 checksums of the uploaded files:
> d12d846a4813785139b96c58f9d71dbd843c9743f1d9ac04bc1bec25be668a1b  
> ledgersmb-1.4.27.tar.gz
> 724ee1e6937bc340cbf390f52c8e5b7570060edad21c7a718184667f8f2e7e0d  
> ledgersmb-1.4.27.tar.gz.asc
>
>
> --
> Find and fix application performance issues faster with Applications Manager
> Applications Manager provides deep performance insights into multiple tiers of
> your business applications. It resolves application problems quickly and
> reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
> gampad/clk?id=1444514301=/ca-pub-7940484522588532
> ___
> Ledger-smb-devel mailing list
> Ledger-smb-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
Find and fix application performance issues faster with Applications Manager
Applications Manager provides deep performance insights into multiple tiers of
your business applications. It resolves application problems quickly and
reduces your MTTR. Get your free trial! http://pubads.g.doubleclick.net/
gampad/clk?id=1444514301=/ca-pub-7940484522588532
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Deciding on a default company setup for BDD tests

[John Locke]

Hi,

On 01/23/2016 08:12 AM, Erik Huelsmann wrote:

Hi,


What we're really talking about here is how to set up test data --
whether we ship a test database already containing data our tests rely
upon, or have those dependencies created when running the tests.

I pretty strongly advocate the latter -- create the
configurations/data
we are testing for at the start of a test run, if they don't already
exist. And make it safe to re-run a test on the same database.


This might be a bit of extra effort to achieve: Since we can't remove 
some data in the database (e.g. transaction deletion is an absolute 
no-no), it might not always be possible to re-run a test.


What I have in mind is along the lines of "orders that get created get 
closed", "invoices that get created get fully paid", that sort of thing. 
So when your test expects to see one open invoice, it doesn't then see 
two the next time.


I think it's reasonable to say that running tests on a production 
database will change your overall balances (e.g. don't do that!) but I 
find that during testing, especially when trying to resolve a thorny 
issue I don't understand, there's lots of small iterative incremental 
changes. I don't want to have to wipe and reload the database every 
time, especially when I don't get it right the first time.



I think the main point here is that for a lot of the setup steps, the 
step definitions check to see if it exists before creating -- 
particularly things like test accounts, test customers, test parts, test 
warehouses, etc.


And this will need to be split out into features -- e.g:

Feature: create a customer and vendor

-- this feature should test the interface for creating customers and 
vendors, and should not rely upon steps to set these up in the 
background, because they are testing the interface. At the end, should 
delete the customers and vendors created. (hmm, not seeing this is 
possible...maybe set the end date for the customer to the past?)


Feature: create parts/services

-- this feature tests the interface for adding/editing parts. In its 
background steps it creates the appropriate income/cogs accounts that 
will be used. The setup steps for the background creates the accounts if 
they do not exist, and succeeds without changing anything if they do 
exist -- for example:


Background:
  Given accounts:
  | accno | name | flags|
  | 2410 | COGS - parts | AR_paid,AP_paid|

(or whatever)...

At the end of the feature, mark all created parts obsolete, so the next 
test run can re-insert with the same skus, etc.



Feature: Create sales orders:

-- this feature would put the parts and customers it uses into the 
background section, using steps that populate parts, accounts, and 
customers as before -- create them if they don't exist, pass without 
changing anything if they do exist.




In other words, I'm proposing that each feature tests one module (or 
workflow), and uses background steps to provide the necessary supporting 
data. And that it should be possible to run each feature multiple times 
in the same database -- what we're actually testing should be cleaned up 
sufficiently to actually run again without throwing errors/failures. But 
allow the supporting data used in each feature to persist for future runs.


And each of those background data steps needs to have its own feature to 
test that the interface works correctly -- and these features do need to 
clean up for future runs...



I don't mind cleaning up test data if a test fails in development, but
as long as tests are completing, they should be able to be run
multiple
times on the same db.


Well, if we clean up behind succesfully run tests, that could also 
mean we simply delete the test databases in the cluster. Then, we can 
run the same tests again and again on the given cluster. I'm thinking 
we will eventually need different databases because we need different 
company set-ups to test all available features. However, to start, we 
need a setup with a CoA, accounts and some data, with which we can get 
an acceptable testing scope in place.


This kind of testing I think reaches the limits of BDD. We're not going 
to be able to verify that the math is handled correctly through every 
phase, on copies of different databases, through BDD.


We have unit tests for testing individual module functionality, and BDD 
is good for user interface testing... MIght need another layer for the 
business logic testing -- integration testing... For those kinds of 
tests, having a clean/well-known starting point for the database seems 
necessary.


Cheers,
John Locke
http://www.freelock.com



--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now

Re: [Ledger-smb-devel] Deciding on a default company setup for BDD tests

[John Locke]

Hi,

On 01/21/2016 05:54 PM, David G wrote:
> Hi All,
>
> I agree with Michaels comments, with a couple of extra thoughts inline
> below.
>
> On 19/01/16 09:13, Michael Richardson wrote:
>> Erik Huelsmann <ehu...@gmail.com> wrote:
>>
>>
>>  > To start with the first and foremost question: do we want our tests 
>> to run
>>  > succesfully on a copy of *any* company (as John stated he would like, 
>> on IRC)
>>  > or do we "design" the company setups we want to run our tests on, from
>>  > scratch, as I was aiming for? (Note that I wasn't aiming for 
>> regenerating all
>>  > setup data on each scenario or feature; I'm just talking about making 
>> sure we
>>  > *know* what's in the database -- we'd still run on a copy of a 
>> database set
>>  > up according to this plan).
>>
>> By *any* company, you mean, I could run it against (a copy of) my database?
>> I think that is not useful to focus on right now.
> I agree that it's probably not a good thing to focus on right now,
> but,
> I think it would be worth keeping in mind so the tests aren't written to
> exclude this as a possibility.
> In the long run, I think rather than the tests being designed to be run
> on a *live* database they should,
> if run on a "non test" database copy the DB to a new DB ${name}-bdd-test
> and run against the copy.
>
> I think this is a better long term solution as for many scenarios it may
> be impossible to properly remove entries from the database due to the
> Audit Features we have.

Drupal has a tremendous amount of variation between sites, and lots of 
configuration that ends up in the database. This certainly colors my 
perspective -- and that's why I think it's important to be able to run 
BDD tests on a copy of any production database.

I'm not sure that's the same for LedgerSMB -- but it would certainly 
help track down issues if people customize their database in ways we 
don't expect.

What we're really talking about here is how to set up test data -- 
whether we ship a test database already containing data our tests rely 
upon, or have those dependencies created when running the tests.

I pretty strongly advocate the latter -- create the configurations/data 
we are testing for at the start of a test run, if they don't already 
exist. And make it safe to re-run a test on the same database.

I don't mind cleaning up test data if a test fails in development, but 
as long as tests are completing, they should be able to be run multiple 
times on the same db.

>>  > Additionally, John and I were talking about supporting test 
>> infrastructure
>>  > and we agree that it would be tremendously helpful to be able to see
>>  > screenshots of failing scenarios and maybe to be able to see 
>> screenshots of
>>  > various points in non-failing tests too. Since Travis storage isn't
>>  > persistent, we were thinking that we'd need to collect all 
>> screenshots as
>>  > "build artifacts" and upload them into an AWS S3 account for 
>> inspection.
>>
>> Email to ticket system?
>> Or S3...
> Michael makes a really good point here.
> Perhaps the easiest way of capturing the screenshots is not to use S3,
> but have a github project (eg: ledgersmb-bdd-results) that we can raise
> a ticket against for failing builds with associated screenshots attached.
> At the same time we could use "git annex" to store all screenshots for a
> test in a new git branch (or just simply a tag) in the
> ledgersmb-bdd-results project repository.
>
> Storing "good" results probably should only be done if a specific flag
> is passed in the PR commit message.
> While all screenshots (good and bad) should be stored if a single test
> fails.

However we store them, I suggest we at least store "good" results for 
each release. Especially of screenshots. This will allow comparing 
version-on-version, as well as give you a place to go back to see "what 
did this look like in version x?"

S3 storage seems to be built in to many test runners like Travis, I'm 
guessing that's the fastest/easiest to get up and running.

The Matrix project uses Jenkins as a test runner, and the runs are 
public, so you can access artifacts just by visiting their jenkins 
instance, no logins necessary. Can Travis do the same?

Cheers,
John Locke
http://www.freelock.com

--
Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311=/4140
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.5.0-beta4 over due / consequences for RC1?

[John Locke]

Hi,

On 01/02/2016 01:44 PM, Erik Huelsmann wrote:
> Hi,
>
> The 1.5.0-rc1 milestone is set for the middle of January, with the 
> last beta to be released by the end of December last year.
>
> Obviously, we didn't make the deadline for last year :-) There are 
> still 3 bugs open that are marked 'blocking', after I triaged some to 
> be solved by RC1 and others even later.
>
> With these 3 bugs still open (1 documentation, 2 real code changes, 
> one of which I think even needs a bit of design), I'm wondering: 
> should we reschedule the release of 1.5.0-RC1? If so, by how many 
> days/weeks? Or should we defer the Sqitch-like (or really sqitch) idea 
> to 1.6 and just solve the documentation issue and the broken Salary 
> screens?
>

I think you've gotten little comment because nobody's actually gotten to 
the point of actually using it... given all the setup challenges, I 
think it's only now getting to the point where it's getting there...

But I think it's got a ways to go before it can be considered an RC.

It looks great, I like how speedy it is, and I can see that it's coming 
along nicely. But I just tried to do the common things I do in Ledger 
day in and day out, and I couldn't complete any task other than some 
reporting.

I just filed a slew of issues of what I've found so far -- but most of 
the workflows we do, I couldn't even get very far, I'm sure there's a 
bunch more.

I did try the current HEAD of the master branch, and the UI wouldn't 
even render. I had to go back to 1.5-beta3 to get the screen to load up, 
so that's what the feedback is for.

Regarding environment, I did this all in the latest Docker container, 
against an older copy of our production database from 1.4.

It could be there's something related to my environment -- if so, please 
do comment on the Docker environment as built here: 
https://github.com/ledgersmb/ledgersmb-docker/blob/master/Dockerfile


... if anyone else wants to spin up a version to test with, the Docker 
image is getting fairly useful for getting up and running quickly 
(though note that it's a 1GB download for the full image, the first time 
you download it). Here are some variations you can use to start the 
container with different configurations, in addition to the "from 
scratch/with Postgres docker container" instructions on the Docker Readme:

### New docker container pointing to existing Postgres server:

 > docker run -e POSTGRES_HOST=192.168.0.22 -v 
/home/john/git/LedgerSMB:/srv/ledgersmb -p 5000:5000 
ledgersmb/ledgersmb:dev-master

(Make sure you're using a backup copy of your main database!!!)

Use the -e POSTGRES_HOST switch to point to an IP address or hostname of 
your postgres server. Or, you can use --link postgres-container-name to 
use a Postgres Docker container. If you're running your own Postgres, 
make sure to allow access in your pg_hba.conf file for the docker 
container's IP address. Note that this gets set up when the container is 
started, but only if there is no ledgersmb.conf file already -- if you 
are mounting a local dev copy, you may need to set this yourself.

Use the -v /path/to/localcopy:/srv/ledgersmb to use the Docker container 
purely for dependencies, and mount a local copy of the LedgerSMB git 
tree. This is very useful for development. Remember to restart the 
Docker container (or start a new one) after making changes that might 
get cached.

The -p switch exports port 5000 to the host's network stack so you can 
log in at http://localhost:5000/login.pl, or run setup at 
http://localhost:5000/setup.pl.

You can also pass a --name lsmb to name the container "lsmb" for easier 
management. And if you want to gain a shell inside the container, you 
can get it with "docker exec -ti lsmb bash".


So... in short, I would say 1.5 is on the cusp of between an alpha and a 
beta release -- it's a ways from being a release candidate, as you can't 
actually get work done. It is coming along nicely, though, and may come 
together quickly. But for now, I think an RC has to wait.

Cheers,
John Locke
http://www.freelock.com

--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Cleaning up the repository. How does the community feel about it?

[John Locke]

Hi,

On 01/01/2016 09:57 AM, Erik Huelsmann wrote:



On Fri, Jan 1, 2016 at 6:45 PM, Robert James Clay > wrote:


On Thursday, December 31, 2015 09:50:59 AM David G wrote:
>
> It is worth pointing out that it is undesirable to use an OS
package to
> provide dojo as there are known to be issues from minor release
to minor
> release that would break LedgerSMB.

  What are those issues and how do they break LedgerSMB? That is; 
how is that

being tested and what does that find?  And why are those minor
releases"  being
used, if they cause such issues?

John says he has experience that there are slight incompatibilities 
between versions 1.7, 1.8, ...  and that very careful testing is 
required to be sure your code remains working. Assuming that's true, I 
can be nothing but extremely disappointed about the development 
processes used.
One of the questions that come to mind though is: how do they keep 
their own stuff working if the various versions break expectations? It 
seems some widgets haven't been changed since the early days of Dojo. 
Surely those would be broken now if this goes on too long?


So I actually have not even used 1.9 or 1.10, my experience is based on 
moving from 1.2 to 1.3, to 1.5, to 1.7... every time we upgraded our 
single-page app, stuff broke and needed to get rewritten.


The stuff that broke were largely custom widgets we wrote, using 
underlying Dojo classes for widgets and templates -- they kept 
refactoring these and changing the API in subtle ways that broke our 
custom code.


For LSMB this might not be much of an issue -- yet. At least not before 
LSMB 1.5. But 1.5 relies upon Dojo far more than any previous version 
(is it even in 1.3? And for 1.4, it's only used for simple form elements 
and some layout stuff in the Contacts area -- I don't think we've built 
any actual custom complex widgets).


It's certainly possible that things have shaken out and gotten more 
stable -- as it is the jump from Dojo 1.5 to 1.7 (which introduced AMD) 
was so great we still have not completely upgraded our internal app, and 
are still using 1.5.


And then also realize that there's no server-side testing that would 
reveal a problem with Dojo -- it's purely client-side. So testing it 
properly is largely visual regression testing, stuff on top of 
Selenium/PhantomJS or similar, or using writing tests for Dojo's own 
test runner, DOH (if that's still around... looks like they now promote 
"intern" which looks interesting...)


Dojo does have its own test suite. But the problem I've experienced with 
Dojo upgrades is in its base widget classes (dijit/_Templated, 
dijit/_Widget, etc) which have changed far more than you would think 
should be acceptable within a minor release. If we're not extending 
those, then we're not affected -- yet. But the ability to extend those 
to have smart widgets is the main reason I was advocating for Dojo in 
the first place, over simpler widget systems like jquery.ui and the like.


And as previously noted, I have not experienced any issues with updating 
a patch release within the same minor version (e.g. 1.5.1 to 1.5.3), 
only between the minor versions (1.5 to 1.7). And Dojo itself is still 
releasing patch releases for 1.5 -- if they expected everyone could 
upgrade easily, they would not still be issuing patches for 1.4



Remember that JS libraries don't need to only consider what else is on 
the Linux server -- it's something that needs to support all major 
browsers on all operating systems. Microsoft Edge, IE11, IE10, Safari, 
Chrome, Firefox on Windows, Mac, Linux, Android, iOS, ChromeOS, etc. As 
Javascript itself evolves into ECMAScript 6, with greatly varying 
degrees of OS support, JS libraries need to evolve and change much 
faster than probably any other package on a Linux server. And HTML5 was 
in its infancy 5 years ago -- we were still mostly doing XHTML. And 
unfortunately, sometimes JS libraries have functions that get turned 
into reserved words in newer JS version or particular browsers... jQuery 
has the same issues with upgrading between minor version releases.


Can you point me to any major web application that actually depends upon 
the Debian dojo or jquery packages, instead of bundling the exact 
version they have fully tested? What I see using apt-rdepends are a 
bunch of local applications -- so many desktop toolkits work with 
Javascript, it makes sense to use a system JS library for a desktop app. 
Not for a web app with a huge range of other targets... Drupal and 
WordPress both have Debian packages, and both ship/use jQuery... and do 
not require or reference the Debian libjs-jquery (or any other jquery) 
package.


Cheers,
John
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net

Re: [Ledger-smb-devel] New branch: master-mc [a forward-port of 1.4-mc]

[John Locke]

Hi, Erik,

On 11/08/2015 10:58 AM, Erik Huelsmann wrote:
> Hi all,
>
>
> This weekend, I've taken the time to forward-port all the 1.4-mc work 
> onto the master branch, resulting in a master-mc branch in my repository.
>
> My plans are to keep this branch in sync with master, with an 
> extremely preferred workflow to have fixes on master first, then merge 
> to 1.4 and master-mc and from master-mc to 1.4-mc.
>
> I'm expecting the master-mc branch to be branched into a 1.5-mc branch 
> alongside the 1.5 branch similarly to 1.4-mc now existing alongside 
> 1.4. Then, early in the 1.6 development cycle, I'm envisioning the 
> branch to be merged into master. The time remaining between the 
> master-mc merge and the 1.6 release, I'm expecting to spend on 
> development of test infrastructure, UI improvements (including the 
> services required) and upgrade/migration scripts.
>
> In order to give the branch its required hours of use, I expect to 
> start using it in production pretty soon. Although I'll be using it, 
> any bug reports are still very welcome of course.
>
> Question: currently, the 1.4-mc and master-mc branches reside in my 
> repository only. Do we want to move these to the main repository? 
> [I've tried creating a new "LedgerSMB-mc" repository within LedgerSMB 
> org in order to be able to run branches by the same names, but 
> creating a second repo within the same org turns out to be impossible.]
>

I don't see why not... that's what branches are for!


Is it drastic enough of a change to not work towards merging into 
1.4/1.5 branches sooner than 1.6?

Cheers,
John Locke
http://www.freelock.com

--
Presto, an open source distributed SQL query engine for big data, initially
developed by Facebook, enables you to easily query your data on Hadoop in a 
more interactive manner. Teradata is also now providing full enterprise
support for Presto. Download a free open source copy now.
http://pubads.g.doubleclick.net/gampad/clk?id=250295911=/4140
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Initial steps for 1.6, and some longer-term questions

[John Locke]

andy in a number of cases, not only hosting 
itself but holding companies, subsidiaries, etc. where you have an IT 
team which can use tools like this to automate the update process.  It 
also helps where the web server does not have superuser access to the 
db for security reasons.


And I have run into enough cases where this was necessary to know that 
updating and creating dbs from the command line is very helpful.





Agreed...

Thinking about what I do with drush (the Drupal shell tool), here are 
some other really useful ones:


* Password reset links (or ability to reset passwords)
* Download/Enable/disable plugins


I'm not sure command line/shell tools are the real need -- I think
the critical thing is to get an API in place, bit by bit. We can
certainly wrap those with a shell tool, but I think the real need
is for a solid API.


I totally agree about the need for a solid API.

For the admin tools, the approach I took was:

1)  An admin library
2)  CLI tools that use it
3)  A dancer-based web interface.

My proposal is that we extend these tools nd replace our existing 
management tools with them.




Sounds fine with me, though I think we'll need to keep some sort of 
web-based admin tool for those not comfortable in the shell -- but with 
a good API this could be pretty minimal (as it currently is).


Was going to write more about why we should focus on the API, but...


I'm seeing the API as functional scaffolding to help with the
financial rewrite, as well as being an end in itself...


Agreed entirely.


Enough said!

Cheers,
John Locke
http://www.freelock.com


--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Initial steps for 1.6, and some longer-term questions

[John Locke]

 all our tools together.  In this case you still
   run the same program which checks your system, sees whether it can
   run a web server and if not gives information as to why not.  Such a
   program would then typically not update a system but could change
   file permissions after running and setting things up.

   In both cases, the installer checks external prerequisites, CPAN
   dependencies, and can either solve or advise on how to solve missing
   dependencies.  I would like LedgerSMB 1.6 to be easier to install
   than SQL-Ledger 2.6 was. Mostly this is hand-holding, providing
   clear feedback on how to resolve problems, and a nice interface for
   showing the information.

I would argue that we should skip all the dependency-checking, etc, and 
point people either to packages for Debian/RHEL/etc, or the Docker images.


Where we do need to spend time hand-holding is once the system is up and 
running -- setting up the Chart of Accounts, providing guidance on user 
permissions, how to set up bulk imports, etc. Nice interfaces for 
showing best accounting practices, templating guidance, etc.



> I also want to make sure we have both command line and web
   tools.  Command line tools give experienced administrators a
   productivity edge here (because it is easier to quickly send complex
   information to the program), but web tools give new users an ability
   to get up and running with less immediate knowledge.


By "command line" tools, do you mean something more than what's already 
there -- the ability to run any of the .pl scripts directly and pass in 
info using a Bash script, for example?


I'm not sure command line/shell tools are the real need -- I think the 
critical thing is to get an API in place, bit by bit. We can certainly 
wrap those with a shell tool, but I think the real need is for a solid API.


The rest of the mail goes into specifics, which all seem appropriate to 
me. I just wanted to make the point that an API can help us clean up the 
legacy code. If we start developing a solid API, module by module, and 
using that to interact with the existing financial code, then it becomes 
far easier to swap out the implementation when we get there. I know this 
is easier said than done, given the spaghetti logic in there ;-)


Perhaps the API can be done as a 2-step approach? I'm thinking we 
already discussed tagging the API with a version. What if we start a v2 
right now -- v1 being essentially a wrapper around the existing POST 
variables that all the forms currently expect, and v2 being what we 
think it should look like, where this varies? Then for each module, we 
could go through the current code, and replace each variable in the 
module that comes from the browser/form post with something that we set 
in the API handler for that module -- and can then create both v1 and v2 
at the same time. Once we have a stable v2 API across the board, then we 
have a great framework for unit testing in place and can far more 
reasonably rip out and rewrite the core logic.


I'm seeing the API as functional scaffolding to help with the financial 
rewrite, as well as being an end in itself...


Cheers,
John Locke
http://www.freelock.com

--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Enforce single line-ending style across source files?

[John Locke]

+1.

There's a .gitattributes setting we can do that will clean these up on 
commit -- probably something to do when there are no other changes being 
committed.


Ah, here's a simple recipe for doing this:

https://help.github.com/articles/dealing-with-line-endings/

Cheers,
John

On 09/18/2015 04:52 AM, Erik Huelsmann wrote:

Hi,

Today I found that at least 1 file in our Perl code base has a DOS 
line-ending style. Should we want to enforce a single ("Unix") 
line-ending style? This should come in handy when others - like me - 
develop on Windows, but - unlike me - don't know how to control their 
editor to write out Unix line endings. Also, diffs will show all lines 
changed if someone recodes *all* line endings.


Comments?

--
Bye,

Erik.

http://efficito.com  -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.


--


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] [DESIGN] Proposed structure fol LedgerSMB web services

[John Locke]

 resources can 
be excluded/included/expanded in which requests, and what is included by 
default.


Cheers,
John Locke
http://freelock.com
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Request handling using routes, containers, (internal) services

[John Locke]

On 06/22/2015 02:53 PM, Erik Huelsmann wrote:

Hi
Chris, John,

In the other thread, John mentioned the structure that web apps are 
growing to in general to have these components to facilitate growth 
beyond a certain size:


So... the patterns we're discussing I'm seeing put in widespread
use. I'd say those 3 things are crucial for us to define/decide
how we're going to implement (and perhaps find some Perl framework
to assist if those we're currently using are insufficient):

* Request routing
* Service container to make it easy to register and load services
* Response object (which needs to include the definition of how to
return exceptions).


So, I'm now thinking how we can apply these concepts to LedgerSMB with 
or without the context of using Plack and/or Starman. I'm imagining 
that we will have to handle a certain amount of it ourselves 
internally and that we possibly could hand off some of it to Plack's 
middleware modules.


What I've been thinking about for some time now is that we might want 
to virtualize our current module names 'aa.pl http://aa.pl' etc. 
into routes. For aa.pl http://aa.pl, there really are physical 
files, but for other routes, we may not want to handle the route 
processing the same way.


Is this something that we need to address now (as in: design it asap 
and simply continue working on the code base, but use this as a 
paradigm for all code that's being (re)written)?


I don't have an answer to that specific question...

But most webapps I've worked with have a single endpoint that receives 
all requests. The webserver reroutes any paths that don't exist on the 
disk to that endpoint.


Given that all of those little module name endpoints we currently have 
are copies of one of two different actual endpoints, it does seem like 
we should be able to pretty easily eliminate those... and just make the 
single remaining endpoint smart enough to know which way to handle the 
request...


I would assume Starman could handle something like that?

For Drupal, Apache first looks for a file on the disk... if it doesn't 
exist, it rewrites the path to /index.php?q= (and then adds the original 
path). This is done internally, not as a redirect, so the browser never 
knows...


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal to use SASS for writing our CSS

[John Locke]

On 06/22/2015 02:10 PM, Erik Huelsmann wrote:



It sounds like you were using Compass for more than just it's 'watch' 
command for real-time compilation? I'm aware that compass has much 
more to offer than just real-time compilation. I value your feedback - 
which I interpret as go there when you know what you're doing - but 
wasn't suggesting we should start using Compass as a CSS library; more 
as a CSS compiler/developer tool. I'm not aware in what extent Compass 
and Dojo's Claro theme conflict, so without experimenting, I don't 
know anything about the validity of such a step.


I doubt there's much of a conflict here. We may end up with the 
dojo-built CSS, + our compass-built CSS, but if we just define which 
order we load, shouldn't be any conflicts to speak of...




My best recommendation is to use RVM to manage ruby environments, and
Bundler to install the necessary gems into the environment.
Otherwise we
get on a conveyor belt of a constantly moving Ruby Gem version target,
and far too much upkeep...


Well, since we have more than enough to do as it is - and taking into 
account that I'm happy with the Claro theme - I'm now reading don't 
go there into your words here. So, for now, let's not go there.




I do have this dialed in pretty well here. I think the main thing is, 
when you're dealing with Compass, you're getting into Ruby, at least at 
a config management level. For that reason, I suggest that we commit the 
generated CSS files, and then perhaps provide guidance on environment 
setup for those who wish to do CSS changes.


For those who don't want to delve into Sass, we can just provide a blank 
CSS file loaded after the sass-generated one, where people can make 
local changes that override everything we provide.


The Gem conflicts I've seen arise largely from gems that depend upon 
particular versions of Ruby -- which if you don't install, you need an 
older version -- which then conflicts with a different Gem, and so on... 
The toolkit gem in particular provides some handy things like an 
@clearfix mixin, stuff like that that help you lay things out quickly. 
SingularityGS is a grid system that makes it really easy to create 
custom grids.


I don't know whether using these helps or hurts our overall work here -- 
I'm not a Sass or Ruby expert by any means, but I do all the environment 
setups here for other developers, and this area has been a particular 
pain. Once I got it all working, it's really, really nice to use, so I'm 
all on board with using Sass, it's a really large improvement. And I 
could certainly do the initial setup for the project, like I did with 
Dojo... but I will need to provide those environment guidelines to get 
you up and developing with it, if we do start including other gems...


Cheers,
John
http://www.freelock.com

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal to use SASS for writing our CSS

[John Locke]

Hi, Erik,


On 06/21/2015 01:27 PM, Erik Huelsmann wrote:
 Hi,

 In my previous mail, I highlight how it's necessary to create per-page 
 CSS by enclosing the page in a DIV with a globally unique 'id' 
 attribute and scoping any CSS declarations within that.


Use the Body tag. Don't need another div for this. (Ok, that is, unless 
this is an Ajax response...)

snip
 Or even shorter (and more comprehensible):

 #account-tabs {

... Can do multiple parents at once:

#account-tabs, #contact-tabs, #part-tabs {

... this takes Sass to a much more succinct level, at least in the files 
we actually want to edit...

   @mixin account-tabs-mixin($selector) {
 #{$selector} {
snip
   }
  }
}

... we organize all the mixins into their own files. In Drupal's Omega4 
theme, it provides an organization of Sass into partials, each of which 
gets loaded in order, so later partials can rely on earlier-defined 
mixins, variables, etc. Main Sass file looks like this:

@import compass;
@import breakpoint;
@import singularitygs;
@import toolkit;

@import variables/**/*;
@import abstractions/**/*;
@import base/**/*;
@import components/**/*;

... So first it includes a lot of really useful mixins/Sass functions, 
and then it loads our partials, in a specific sequence.

Variables contain all the stuff we might consider the theme : colors, 
fonts, font sizes, etc.

Abstractions would contain your mixins for commonly used things.

Base includes general UI elements: forms, tables, lists, buttons, etc.

Components are where you put your individual page-specific CSS. It can 
use anything that was defined before...


 Unless there are objections, I'm going to create a new directory, next 
 to the css directory, called 'scss' in  which we'll store SASS files. 
 Next to that, I'll make sure to write documentation on how to compile 
 sass files into css files. There are even tools to compile sass files 
 to css files immediately when they are being saved ('compass watch' 
 from http://compass-style.org/help/documentation/command-line/).


Ah, that's where things get fun. We've had tons of issues with 
version/dependency hell with Sass libraries and Compass.

My best recommendation is to use RVM to manage ruby environments, and 
Bundler to install the necessary gems into the environment. Otherwise we 
get on a conveyor belt of a constantly moving Ruby Gem version target, 
and far too much upkeep...

Cheers,
John Locke
http://www.freelock.com

--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal to differentiate between program and processing(precondition) errors

[John Locke]

One more time!


On 06/21/2015 01:41 PM, Erik Huelsmann wrote:

 Currently, all errors generated by LedgerSMB are being raised through 
 'die'. It's an effective way, but my feeling is that it bleeds through 
 too many details of the internals. This is especially true when the 
 error is really nothing more than a reported missing configuration.

 E.g. we currently generate an error in case there's a field's value 
 missing. The generated error includes a stack dump and all!

This does seem absurd at this point -- why not just change those to 
throw exceptions? Then we can catch them at the appropriate point and 
bubble those up to the interface.


 My proposal is that in this type of error case, we're checking the 
 existence of the required fields and their values. If these don't 
 exist, we should be reporting a nicely formatted error to the client 
 -- most definitely without a stack trace.

 Also, the HTTP status code for each error-with-stacktrace is currently 
 500 -- Internal Server Error. When we *understand* the request, but 
 can't process it, we should be generating a 422 (Unprocessable entity) 
 response or alike.


 Now for the question: what would be the best way to achieve this? (I 
 think this applies equally to HTML page responses as it does to web 
 service api calls, so this is a general question that needs a general 
 solution which is applicable for a long time.)

Exceptions. Without question.

We do need separate response objects that get instantiated right at the 
start of the request. These should have some sort of ending method -- 
something like -send() -- to actually output the response back to the 
requestor, in the appropriate format.

Server side, we need a global exception handler to catch anything not 
caught during actual processing, which can attach the appropriate error 
data to the response header along with the appropriate error code. The 
response object should generally return an appropriate http response 
code, and can then pass the stack trace (if appropriate) and any other 
data necessary, on up to the browser.

The response object should be smart enough to know how much detail to 
transmit -- perhaps some other service can filter messages if we want to 
keep very sensitive stuff away from the browser, and only transmit it 
all if the site is set to 'debug'...


So really what I've described so far is how to get an exception up to 
the browser. We haven't really handled it, just transmitted it. If we're 
going single page, we really need to handle that in the browser, so most 
of the actual graceful handling of the exceptions will end up being 
Javascript.


I think one area we might want to explore further is what kinds of 
exceptions we want to handle, where. Do we need specialized exception 
classes? Do we catch some kinds of exceptions and simply log them, then 
resume processing?

Cheers,
John
http://www.freelok.com


--
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors 
network devices and physical  virtual servers, alerts via email  sms 
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Writing code for master: paradigms that work

[John Locke]

Hi, Erik,

Great stuff, love to hear you're tackling these issues head-on. I'm 
totally in favor of everything I've read from your 3 mails of today... 
and will add comments from my perspective...


On 06/21/2015 01:04 PM, Erik Huelsmann wrote:
What I learned while coding on current master, i.e. after the 
'frame-less' and 'PGObject' changes, is that, due to the 'frame-less' 
change:
 * The HTML HEAD tag is now completely useless, except for the pages 
returned by 'login.pl http://login.pl'
 * Any JS linked in the head tag as well as any JS included in SCRIPT 
tags is completely ignored

 * Any CSS linked in the head tag is completely ignored
 * Any JS or CSS directly included in the head tag is completely ignored

It's great to organize CSS/JS to work per screen/page. However, it's not 
that useful to load it per page. For the most part, I think it's best to 
simply aggregate all the JS/CSS and send out as a single file to the 
browser, and allow that to get cached.


With Dojo, we can define multiple layers in the build, so it might be 
good to exclude seldom-used scripts to their own layer, or exclude them 
from the build entirely -- as long as we're using AMD Dojo should handle 
loading them if necessary if they're not in the build. But aggregating 
everything should work well for us.



What *does* work is:
 * Put all behaviours for all elements in Dojo widgets
 * Put nothing in the response HTML other than widget references 
(data-dojo-type) and widget configuration (data-dojo-props); 
everything else should be in the widget
 * In case widgets on a page need to communicate their state changes, 
etc, use 'dojo.topic' and the publish/subscribe paradigm -- this 
creates a loosely coupled UI and reduces chances for exceptions


Pub/Sub I've found to be extremely powerful for a single-page app, and 
is exactly what I've used in the past. +1


 * Create widgets which - as much as possible - can be reused on other 
pages


+1

 * Make sure the HTML structure is valid; the Dojo AMD parser can be 
seriously confused by incorrectly nested elements

 * All CSS for any and all pages must be included in 'css/global.css'


Break this out into the SASS discussion -- I'm partial to partials ...

 * CSS can be made page-specific by wrapping the entire body of an 
HTML response's BODY tag in a DIV with a page-specific (and globally 
unique) ID attribute; that attribute can be used to attach the page's 
CSS to


I don't see any benefit to not loading all CSS for the app one time, in 
a single file. Organize all the CSS into separate Sass files per page, 
but in the end they all end up in a single CSS file.


And yes, a class attribute attached to the body tag can be a great way 
to provide per-page css, make it easy to target.




As part of the frame-less change, I've addressed a long standing 
irritation of mine: the handling of errors. Before, every time you 
entered a form's data incorrectly, you'd be shown an ERROR page, but 
not be given back the data you entered. Now, if the server reports an 
error, it's shown as a popup dialog. Because of this handling, the 
entered values now don't get lost. If processing fails, the scripts 
should therefore make sure to return an http error to the client (with 
a meaningful description in the (HTML) body).


+1

Yes. Absolutely.



Due to the PGObject change, it has become clear - if that wasn't 
already the case - that our current handling of the $request variable 
is far from ideal. Problems that we have:


 * $request is manipulated into a response by replacing values in the 
hash as processing proceeds (leading to a point that code can't be 
sure what values it's receiving!)
 * some parts of the code instantiate new hashes, expecting 
constructors to copy *everything* of $request which they are not 
providing themselves


Even though dojo-ifying the entire code base (by which I mean that we 
will be transforming everything to dojo UI and service requests from 
there) -- and thus we'll be moving away from the template based 
processing structure -- I think it's important to lay out how this 
should work as the move to PGObject caused problems in this respect.


The problems with PGObject and the $request object being mutilated 
into a response object (or being replaced by another object) are most 
apparent in relation to the template processing engine when values 
aren't copied from $request to its replacement.


Basically, my view on things is that there shouldn't be a replacement 
at all. Instead, $request should hold all the values as passed in by 
the request. $request should *always* be passed into the template 
engine in the { request = $request } variable, so templates can refer 
to the original values. These values include - most importantly - the 
name of the script from which the template is being called: 
request.script (this is required for correct form submission, most of 
the time).


In addition to the $request object, one or more objects can be and 

Re: [Ledger-smb-devel] Trouble on Perl 5.18.4 on Fedora, running Plack

[John Locke]

Hi,

Well you're using Fedora, that's your problem :-P

Just kidding...

I've been digging into Docker recently. I think I would suggest, once we 
have a pretty solid working environment, bundling that up into a Docker 
container we can distribute as a working container, for an alternative 
to normal CGI.


I think I would suggest bundling all the Perl, Starman, Perlbrew, etc 
into one container, and import environment variables to connect to 
Postgres outside the container.


Maybe we can even get Travis to rebuild the image for us...

With a Docker image, it doesn't matter what distribution we use as a 
base, it should run on any Linux (with docker installed, of course!) And 
now that templates are in the database, people shouldn't need to even 
change anything inside the container, right? (Ok, guess we need to 
figure out how to support server-side printing with this, and fix some 
of those check template bugs that still load from the demo templates).


We could bundle the other dependencies in there as well, the Tex, 
headless LibreOffice, etc.


Cheers,
John Locke
http://www.freelock.com

On 04/18/2015 12:23 AM, Erik Huelsmann wrote:

Hi Chris, everybody,


While of course this is ultimately a problem of Fedora and not ours, 
I'm a bit concerned on how this reflects on us. While I have seen your 
mail regarding Perlbrew and it's thus possible to make things work, 
I'm concerned that the first impression from users trying LedgerSMB 
will be that it doesn't work.


Does this report concern both 1.4 and master? What can we do in our 
communication to explain the situation? I'm also thinking we may want 
to help people in a way that it's easy to get a working setup. If the 
easy path of getting a working setup on Debian is to use Starman, but 
on Fedora it is to use Apache, how can we help people walk down the 
right path?



Regards,


Erik.



On Thu, Apr 16, 2015 at 5:34 AM, Chris Travers 
chris.trav...@gmail.com mailto:chris.trav...@gmail.com wrote:


Hi;

I am at this point giving up running LedgerSMB via Plack on
Fedora.  Last night I set up LedgerSMB on a Debian virtualbox
image I have.   I am not sure what the problem is but I see a lot
of issues and they go deep.

I have frankly not been very impressed with Fedora's Perl
support.  I have tried to work around them for a while but this
frustration has been growing for a while (Fedora makes it
remarkably difficult to install modules from CPAN and have them
work for example).

The issues I am seeing appear to relate to Starman not handling
sockets correctly, and processes therefore tripping over
eachother.  This causes deep recursion in printing errors and it
makes binmode unusable for cgiscript processes.  These issues do
not happen on other platforms.

When I have a little time I expect to investigate Perlbrew on
Fedroa as an alternative.  But I think we should consider stock
Perl on Fedora to be unsupported at present.

-- 
Best Wishes,

Chris Travers

Efficito:  Hosted Accounting and ERP. Robust and Flexible.  No
vendor lock-in.
http://www.efficito.com/learn_more


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live
exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual-
event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
Bye,

Erik.

http://efficito.com http://efficito.com/ -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source=Sourceforge_BPM_Camp_5_6_15utm_medium=emailutm_campaign=VA_SF


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
BPM Camp - Free Virtual Workshop May 6th at 10am PDT/1PM EDT
Develop your own process in accordance with the BPMN 2 standard
Learn Process modeling best practices with Bonita BPM through live exercises
http://www.bonitasoft.com/be-part-of-it/events/bpm-camp-virtual- event?utm_
source

Re: [Ledger-smb-devel] invoice time: templates and 1.4

[John Locke]

Hi,

There is an import tool in the Setup interface, to load templates from 
the disk... Copy over your 1.3 templates into the normal place on the 
disk, then visit the setup.pl screen, and load your templates.

There are still some issues around check templates -- e.g. at this point 
you can only edit check.tex in the database, the check_base.tex and 
check_multiple.tex get loaded from the filesystem, and I had to put my 
customizations in the demo templates.

https://sourceforge.net/p/ledger-smb/bugs/1297/
https://sourceforge.net/p/ledger-smb/bugs/1302/

... hmm, I guess I ended up doing some URL hacking to actually edit 
these in the database -- this is largely a missing menu entry...

Cheers,
John Locke
http://www.freelock.com

On 03/02/2015 11:01 AM, Nick Prater wrote:
 It's invoice time of month...  oops 1.4 doesn't seem to have my templates
 in the right place...  I tried taking my 1.3.46 templates from the old
 VM and uploading them... I guess templates in 1.4 now live in the
 database?
 They do live in the database, in the template table.

 Is there perhaps a missing process where the 1.3 templates that were on
 disk
 get sucked into the database?   Or perhaps I'm wrong.  I get a general
 failure when trying to render an invoice to pdf:
 For my own transition from 1.3 to 1.4 I manually uploaded each template
 via the System-LaTeX Templates menu.

 As far as I'm aware there is no automated tool to import templates from
 1.3 to 1.4 and this is not done as part of the upgrade process.

 I wonder if a new company installation is initialised with a set of
 default templates? Otherwise that is a barrier for new users.

 [snip]
 I should be running 1.4.10.1 from git with the one patch from Nick Prater
 to fix Fix SF Bug 1337 - Cannot post AP transactions.
 I am running that version and am successfully printing PDF invoices. That
 doesn't fix your issue, but gives at least some hope that it's possible!




 --
 Dive into the World of Parallel Programming The Go Parallel Website, sponsored
 by Intel and developed in partnership with Slashdot Media, is your hub for all
 things parallel software development, from weekly thought leadership blogs to
 news, videos, case studies, tutorials and more. Take a look and join the
 conversation now. http://goparallel.sourceforge.net/
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Getting rid of frames in 1.5?

[John Locke]

Hi,

+1 for me too, I don't think it will be that difficult to do, either...

Cheers,
John

On 10/17/2014 07:10 AM, Pongrácz István wrote:



Seems easy, especially for me :)

Fix me, but I assume this step should necessary to separate the UI 
with the core and able to use other frameworks, too, right?


Cheers

István

eredeti üzenet-
Feladó: Chris Travers chris.trav...@gmail.com
Címzett: Development discussion for LedgerSMB 
ledger-smb-devel@lists.sourceforge.net

Dátum: Fri, 17 Oct 2014 06:53:07 -0700
--



My general thinking is we may be able to wrap all the forms with this:
http://dojotoolkit.org/reference-guide/1.10/dojo/xhrPost.html

On Fri, Oct 17, 2014 at 5:19 AM, Leho Kraav l...@kraav.com 
mailto:l...@kraav.com wrote:


On 17.10.2014 13:33, Chris Travers wrote:
 Hi everyone,

 I was wondering how much effort it might be worth putting into
to remove
 frames in 1.5.  There might be a lot of HTML cleanup necessary
in old

+onemillion


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push
notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel



--
Best Wishes,
Chris Travers
Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No 
vendor lock-in.

http://www.efficito.com/learn_more


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal for infrastructure (feedback requested)

[John Locke]

+1

I'm using Jenkins hooked up to our internal gitolite server for dev work 
for similar purposes, and it has greatly improved our release process -- 
we're now enforcing a bunch of policies when rolling release branches 
and have already caught a bunch of breakages before they reached 
production. That's a web deployment workflow, rather than a product 
workflow -- I've heard good things about Travis, will be interesting to 
see how it compares with Jenkins...


Cheers,
John

On 09/05/2014 04:07 AM, Chris Travers wrote:
If you log in to travisci with your github account and set it up on 
your own repo you will get emails.


For the main repositories, the information will be posted to the 
changelogs and if you look under the branch listing, you can see the 
status on each branch.



On Fri, Sep 5, 2014 at 3:07 AM, Erik Huelsmann ehu...@gmail.com 
mailto:ehu...@gmail.com wrote:


Sounds good. How will we know about the results? Will we be
receiving e-mails?

Regards,

Erik.


On Fri, Sep 5, 2014 at 12:02 PM, Chris Travers
chris.trav...@gmail.com mailto:chris.trav...@gmail.com wrote:

I will try to set up travisci for LedgerSMB this weekend or
early next week.  I will have it run a full set of tests on
each branch when a commit occurs.


On Fri, Sep 5, 2014 at 2:54 AM, Erik Huelsmann
ehu...@gmail.com mailto:ehu...@gmail.com wrote:

Hi Chris,

Looks like a great service. It definitely sounds like we
can use this for the 1.3 and 1.4 branches to prevent breakage.

To those who don't know about the scope of our testing,
you told me that these are the types of tests that we have
currently in place:

 - number formatting
 - number parsing
 - template handling
 - basic form and request api
 - api tests that run against the db (but never commit)
 - pod
 - pod coverage

Would be good to assure that our release branches remain
stable and don't fail tests when we commit/merge changes.
I think this would be a good next step in our QA.


Regards,


Erik.




On Thu, Sep 4, 2014 at 3:03 PM, Chris Travers
chris.trav...@gmail.com mailto:chris.trav...@gmail.com
wrote:

Hi;

For one of my consulting clients, I have been running
travis-CI against some Perl projects.  It's a nice
service which gives us test cases run on every commit.

I am considering setting it up for our Github
repositories (the PGObject modules as well).

Does anyone have any feedback?  Are there any problem
that anyone wants to report before I start this process?

-- 
Best Wishes,

Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and
Flexible.  No vendor lock-in.
http://www.efficito.com/learn_more


--
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




-- 
Bye,


Erik.

http://efficito.com http://efficito.com/ -- Hosted
accounting and ERP.
Robust and Flexible. No vendor lock-in.


--
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




-- 
Best Wishes,

Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.
 No vendor lock-in.
http://www.efficito.com/learn_more


--
Slashdot TV.
Video for Nerds.  Stuff that matters.
http://tv.slashdot.org/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net

Re: [Ledger-smb-devel] Next step for invoice upload (2)

[John Locke]

Hi,

This does sound potentially useful for us as well, with two possible 
adjustments:


1. Partial shipments... perhaps an interface similar to Cash - Vouchers 
- Receipts, something to drill down into line-item detail and specify a 
qty to move to an invoice, leaving the balance on the sales order (or 
optional checkbox to close the order?)


2. Notes field.

Our scenario: twice a month we do invoicing for hourly work, always 
against open sales orders. Our sales order Notes contains more info 
about payment terms, and our invoice notes list work actually completed. 
We invoice against sales orders, and rarely close them out. This model 
would be useful for combining two open sales orders for a client at the 
time of invoice, too.


On the AP side, we use transactions far more than invoices, so for us a 
bulk upload should be able to match a template transaction and populate 
that as a draft...


Cheers,
John Locke
http://www.freelock.com

On 03/15/2014 03:54 PM, Pongrácz István wrote:



 Hi,

This is a great step forward, really :)

I read the workflow, for me it seems fine.

I just wondering, how many invoices/orders (drafts) could we manage in 
this mass checkbox?


I mean, if we upload tens of orders/invoices, it can be displayed in 
one page. But if we upload some hundreds, displaying them in one page 
is not practical/possible, but should be displayed in batches, page by 
page with reasonable amount of entries (configurable).


Cheers,

István

eredeti üzenet-
Feladó: Erik Huelsmann ehu...@gmail.com
Címzett: Development discussion for LedgerSMB 
ledger-smb-devel@lists.sourceforge.net

Dátum: Sat, 15 Mar 2014 19:55:13 +0100
--



Hi all,
As part of the idea to upload draft invoices as orders, there's also 
a requirement to bulk-convert orders to invoices. My current idea is 
to use the following approach and I'd like to hear your feedback 
about it.
By adding a column with checkmarks on the order search result page 
(for open orders), and adding a button to convert to invoices, I 
think we can support bulk conversion. After the button has been 
selected, a screen comes up which contains the fields which are on 
the invoice but are not on the orders. Currently, that would be the 
Due date and the Creation date fields. Optionally, the Invoice 
date could be required on the screen, depending on the intent of the 
fields used on the order.

So, two questions:
1. Do you think I'm missing anything major?
2. What comments do you have and would a workflow like this interest 
you as well?
(The import of invoices would support both importing draft invoices 
as orders and final invoices immediately posted.)


--
Bye,
Erik.
http://efficito.com http://efficito.com/ -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:5324da4f109194117719635!


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech

!DSPAM:5324da4f109194117719635!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:5324da4f109194117719635!


--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] What's ahead for PGObject

[John Locke]

Hi, Chris,

On 02/28/2014 03:45 AM, Chris Travers wrote:
 I don't know how much of this will get used for 1.5 but it may be 
 really handy for 1.6 but here are the new features I am working on:

 1.  Serializing and deserializing of arrays and composite types, 
 allowing nesting of arrays in tuples to arbitrary depth.

 2.  Composite types could then be serialized and passed into db calls 
 as objects without the need for things like cross-indexed arrays and 
 the like.


That sounds very intriguing, I could really see this working well for 
the web services angle in particular -- being able to represent an 
entire invoice with line items and possibly payments as a single JSON 
object, post that to the web service, which in turn simply uses this 
interface...

Cheers,
John Locke
http://www.freelock.com

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id=126839071iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Towards a rental tracking module

[John Locke]

Hi,

While I haven't actually built something like this, we have done some 
preliminary planning and use case analysis on a couple different 
projects along these lines.


I would suggest a couple terminology changes -- instead of individual 
units being slots, they should be Inventory. E.g. a hotel has a room 
inventory.


Slots refers to the time slots then.

So you're missing a dimension in this problem, at least if you're trying 
to manage bookings.


Fixed Assets - Inventory (Rental, perhaps a different inventory than 
goods for sale)


Time slots for booking (hour, day, week, month, year) - Slots define 
the granularity based on the business model


Booking - Service -- A booking consists of an inventory item and 1 or 
more consecutive slots. You might have a variety of services that can be 
used for booking -- an hourly rate, a daily rate, a weekly rate, a 
student rate, an employee rate, not to mention different prices for 
different inventory, or prices that change based on how far in advance 
they are purchased, etc.



I am unlikely to use this add-on, as we would just build it in Drupal 
and create an order/invoice in LSMB via a REST call. And we would build 
it to fit the needs of the specific business. But as far as I can tell, 
inventory slots and bookings have specific meanings in the 
rental/hospitality industry, so I would suggest adopting that terminology.


Also, a booking makes a nice object to relate everything to, and might 
change your user stories a bit...


With this model, it's fairly easy to pull up a screen showing all 
inventory available or booked in a grid showing your time period. But 
there are so many other variables to consider...


-- is there a setup/cleanup time period necessary before or after a 
booking, before the next booking?


-- Deposit management

-- filters for inventory type (e.g. 2 beds vs 1 bed vs suite)

-- handling non-consecutive slots (e.g. teach a class in a room every 
Tuesday evening) -- conflict detection


-- multiple configurations -- e.g. the banquet room that can be split 
into multiple small rooms rented individually or combined into a single 
big room, or room blocks in a hotel, reserving a floor at a time for a 
specific group



... those are the variations that come to mind off the top of my head. I 
would suggest if you have a specific customer you're building it for, 
coming up with a generically applicable solution is going to be... 
challenging.



So for me, what would be most useful to have in LSMB is really good 
deposit management, and possibly asset management of the rental 
inventory. The actual booking system to my mind has too much variation, 
but there's also a lot of value making it available to customers (or at 
least a broader range of staff/partners), so we would build those in a 
customer-facing system, not LSMB.


Cheers,
John Locke
http://www.freelock.com


On 02/25/2014 03:13 AM, Pongrácz István wrote:



 Hi,

This seems a good one :)

As I can see, this is similar or could be used for recurring services, 
like rent a virtual machine (monthly), a domain (yearly or two years), 
workstation (monthly) etc.


Example real life scenario could be handy to see.

One example:

  * rent a service, monthly fee, not for fixed period - like renting
a virtual machine or a hosted ledgersmb, without time limit - it
ends when the customer cancel his subscription, for example 30
days before,
  * rent a car for a year, monthly fee, fixed 1 year period
  * house cleaning until cancellation (similar to the first one) - monthly
  * accounting service - monthly
  * rent a smartphone :)

Are these examples suitable for the idea?

Of course, some of the situation there are fixed assets units 
(computer, phone, car, building, whatever), in other cases not.


Cheers,

István

eredeti üzenet-
Feladó: Chris Travers chris.trav...@gmail.com
Címzett: Development discussion for LedgerSMB 
ledger-smb-devel@lists.sourceforge.net

Dátum: Tue, 25 Feb 2014 02:47:28 -0800
--



Hi everyone,
I am beginning work on an add-on for 1.4 regarding tracking rental 
equipment, etc.  I wanted to toss my ideas in here for feedback.

MODELLING
I think the best way to model this would be to track rentals against 
fixed assets.  I.e. you rent out a fixed asset, and this should allow 
you to do more fine-grained profit/loss reporting on individual 
rentals than otherwise possible.

So my thinking is that you would have:
Fixed assets - multiple rental slots (i.e. units available for 
rental).  For example, a building might be available to be rented for 
x events, but a piece of construction equipment might be available to 
be rented only once at a time.
Rental slot - Service. Each rental slot would be associated any 
number of services.  This could be changed over time to include more 
services, but for now I only expect to support a 1:1 mapping in the 
front-end
Rental

Re: [Ledger-smb-devel] Towards a rental tracking module

[John Locke]

Hi, Chris,

On 02/25/2014 05:47 PM, Chris Travers wrote:




On Tue, Feb 25, 2014 at 8:32 AM, John Locke m...@freelock.com 
mailto:m...@freelock.com wrote:


Hi,

While I haven't actually built something like this, we have done
some preliminary planning and use case analysis on a couple
different projects along these lines.

I would suggest a couple terminology changes -- instead of
individual units being slots, they should be Inventory. E.g. a
hotel has a room inventory.





Time slots for booking (hour, day, week, month, year) - Slots
define the granularity based on the business model


My initial thinking was that the services could handle that.


By Services are you referring to services under Parts  Services?

I think a service can certainly be used for pricing -- e.g. Lawnmower 
Rental, hourly, Lawnmower Rental, daily, with qty fields working as 
needed.


But it does not capture the time period of the booking -- or else you 
would need to create a new service for every rental...


You still need something representing a time slot, to know whether 
something you want to rent is available or not. In my modeling, I've 
used Slots to define the available time periods, and then a booking 
can occupy 1 or more slots and associated rental objects.


You essentially need to create a slot for every possible time period you 
want to make available for booking, for as far out as you want to allow 
scheduling. And then create new slots with a scheduled job (or on demand 
when you get a booking further out than you have defined slots). At 
least that's how I've handled creating an availability matrix.




Booking - Service -- A booking consists of an inventory item and
1 or more consecutive slots. You might have a variety of services
that can be used for booking -- an hourly rate, a daily rate, a
weekly rate, a student rate, an employee rate, not to mention
different prices for different inventory, or prices that change
based on how far in advance they are purchased, etc.


For now (trying to keep this simple and reasonably achievable in the 
first iteration), what about tying it to an order where other goods 
and services can be added?  I.e. we track the service rate with the 
rental in the rental module and link to an order for other add-on 
services.


Well, I would tend to think that you would track the bookings and slots 
in the rental module, and use a sales order to track the service rate 
(along with some link to the corresponding booking in the rental module 
-- serial number?)


In my use case, I would handle the booking and slots in a completely 
external system, for managing availability, and then just generate a 
sales order with the appropriate services to capture payment details, 
and turn into an invoice for the actual charge.



So for me, what would be most useful to have in LSMB is really
good deposit management, and possibly asset management of the
rental inventory. The actual booking system to my mind has too
much variation, but there's also a lot of value making it
available to customers (or at least a broader range of
staff/partners), so we would build those in a customer-facing
system, not LSMB.


Right.  Two thoughts here is that a full booking module may be rather 
beyond the scope of what I am likely to want to do on this current 
project.  I am thinking that (unless there are others who want to jump 
in and offer funding to build such a thing), the best option would be 
to get a rental module done first and then look at building a booking 
module on the top of it down the road.


I guess my question here would be what use cases does the rental 
module have, if you're not going to build booking functionality? E.g. 
for your Renting Unit workflow, how are you going to determine what 
rentals are available, if you aren't tracking time slots and bookings? 
Is this more of a library model, a simple check-in/check-out system?


By all means, if you have a customer asking for this, I completely 
understand putting time into it. But if not, I would really like to see 
the precursors that are coming up in this thread dialed in before 
expanding the scope of the system:


1. Deposit/pre-payment management
2. Asset management covering purchase, depreciation, and disposal of 
rental equipment (I'm sure this can be done now, but I don't know how...)

3. Options/product modifiers

Actually charging for rentals seems pretty straightforward without an 
add-on!


Cheers,
John Locke
http://www.freelock.com

--
Flow-based real-time traffic analytics software. Cisco certified tool.
Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer
Customize your own dashboards, set traffic alerts and generate reports.
Network behavioral analysis  security monitoring. All-in-one tool.
http://pubads.g.doubleclick.net/gampad/clk?id

Re: [Ledger-smb-devel] proposal: xsrf protection for restful web services

[John Locke]

Hi, Chris,

On 02/20/2014 11:24 PM, Chris Travers wrote:
 Right now, the current 1.4 web services don't provide a great deal of 
 strong protection against xsrf.  The current approach is not really 
 safe enough, and so right now, unless we find a way to fix this, we'd 
 need to recommend opening up that section of urls only to trusted 
 hosts (i.e. servers).  While this seems like a big limitation, if you 
 restrict by client-side certificate you could allow access from 
 dedicated non-browser mobile clients but not web browsers.

 There is another option though, in that we could allow for some sort 
 of digital signing of a component of a request. Unfortunately, this is 
 going to require going with perl modules (which don't have a perfect 
 cpantester record) or pgcrypto as an extension.  However, you could 
 have a public key, and you could check the signature of a specific set 
 of information.

 A third option would be a pre-shared auth key that would be submitted 
 with every request, and tied to the user.  The positive side is that 
 it would be simple.  The negative side is that the tokens would be 
 long-term valuable and if compromised would provide a means to exploit 
 xsrf via the browser if the user accounts are shared.

 For now (1.4) I think recommending client-side certs would provide the 
 most protection, but while this provides good protection for dedicated 
 clients it means effectively locking browsers out of the restful web 
 services.

 Our current csrf protections for the web app, while better on the 
 browser than any others that could be implemented there with RESTful 
 principles, is certainly not RESTful, as it requires effectively 
 pre-authorizing every write request (i.e. get the authorization token 
 then add it to the post request).  This requires a double-round trip 
 to make a write effective.

 Anyway, feedback is requested.


This is an area I was overdue for investigating ;-)

I found a bunch of useful links on preventing CSRF on REST APIs, and 
based on that, I think we should handle this a couple different ways.

First of all, if we're going to move more application management to the 
browser (for example, build an invoice with Javascript and post the 
result as JSON into the back end when done, which is a pattern Erik and 
I were discussing yesterday) we want to support having browsers use the 
RESTful web services. And of course, what use is an API if you can't use 
it from another service? So yes, we want something relatively simple to 
implement for both cases. A client-side certificate seems like a lot of 
extra work when writing a client, and not a common pattern.

So we need to cover two cases when authenticating a request: a request 
from a user logged into the web site, and a request from anywhere else.

We already use a session identifier for the web site, so we can detect 
if a user has recently logged in. To cover this case, I am thinking the 
double-submit pattern described here would be sufficient: 
http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html 
(and make sure we don't require that for GET requests). That is, the 
client sends the same value in a Cookie as well as in the data of a 
POST, PUT, or DELETE request. That does not even need to be generated 
server side to prevent CSRF -- the server should just verify that for 
authenticated sessions, these values match.

For API calls that do not involve a session, we already require 
authentication. I think it's reasonable, if we require a session for 
authentication, for a web service client to either do a double-submit or 
a synchronizer token (which I think describes our current anti-CSRF 
protection) -- the client can route all requests through a central 
broker to apply the next token to the data before submitting.

Here's what I found useful:

http://appsandsecurity.blogspot.com/2012/01/stateless-csrf-protection.html
https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29_Prevention_Cheat_Sheet
https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
http://security.stackexchange.com/questions/20187/oauth2-cross-site-request-forgery-and-state-parameter

The key thing for CSRF attacks is the attacker does not have access to 
the credentials themselves, or any cookie values. If we can detect all 
requests coming from our app and double-check against state that cannot 
be accessed from a different site, we block a CSRF attack. For any other 
API consumer, the app already needs to supply authentication.

Cheers,
John Locke
http://www.freelock.com


Cheers,
John Locke

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel

Re: [Ledger-smb-devel] 1.3: Taxes, sub cent invoice amounts and non sub-cent payments

[John Locke]

On 02/20/2014 05:29 PM, Chris Travers wrote:

 In 1.5 I think we need to have currency-specific display precisions, 
 plus the following:

 1.  Tax-specific rounding precisions (so we can unify the Rounding and 
 Simple modules).

 2.  A rule which says that the total invoice amount, unless specified 
 otherwise, will be rounded to the default currency precision.  The 
 difference would need to be recorded against a rounding balance 
 account (equity?).

 This should be sufficient to cover every case out there.


Agreed, this seems like a fine approach.

Cheers,
John Locke
http://www.freelock.com

--
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.3: Taxes, sub cent invoice amounts and non sub-cent payments

[John Locke]

Hi,

Just to clarify my position, I believe that the current behavior of 
storing sub-cent amounts in acc_trans is flat out wrong. We don't 
invoice the customer in sub-cent amounts -- we invoice and collect an 
amount rounded to the nearest cent. Anything more precise than that does 
not reflect the reality of our books.


Rounding errors are going to occur, when in tax collection you round for 
each invoice, but on tax payment, you round based on the total. The 
question is, is this amount ever enough to cause you to want to know 
exactly how many pennies more you might need to send to the tax authority?


The current state leads to confusing books, because they don't reflect 
the real transactions. Balancing out rounding errors is a common enough, 
and understandable thing for an accountant to handle (and I'm sure they 
have to do this with other accounting systems). While it may be nice 
to know the actual liability you've accrued for tax purposes, does this 
ever amount to enough to be worth our time? In my case it's never more 
than one or two cents, and just plain not worth any time spent on it 
whatsoever -- but the current case can lead to maddening state of the books.



But I think we can't make a blanket precision for rounding. This is an 
easy question for USD, and many currencies. It sounds like for Erik/EUR, 
there are different rounding rules that might add up to more -- what's 
the worst-case amount for rounding to be a problem?


And, as we start to delve into BTC, we need to allow far more precision 
there. Perhaps we need currency-specific, configurable rounding precisions?


(by the way, there might be a large new user base if we support BTC out 
of the box...)



I guess my interest is having my books match my bank statements and any 
customer invoices. I don't want phantom fractional transactions 
appearing -- they should reflect exactly the transaction that took 
place, and any other behavior is wrong, IMO.


 
--

John Locke
Principal, Freelock
Web Sites That Make Your Organization Run Better
http://www.freelock.com

On 02/20/2014 12:01 PM, Erik Huelsmann wrote:


Hi all,


The other day, John and I were chatting on IRC, discussing the issue 
of sub-cent transaction amounts that may be calculated and posted by 1.3+


So, let me start to explain the issue: when LedgerSMB calculates 
taxes, it doesn't round the resulting tax amount. This means the tax 
liability is increased by sub-cent amounts in such cases. On the other 
hand, the AR or AP summary account is also posted with this sub-cent 
amount. The printed invoice doesn't show this accuracy, not is the 
customer expected to pay with sub-cent accuracy. By consequence, the 
AR account has a lot of sub-cent items which are to be considered 
closed. They will never be cleared beyond the level that they are.


So, why does LedgerSMB work this way? Imagine owning a business with 
many small transactions. Let's assume they ask get rounded down with 
respect to the tax. Since the tax authorities calculate the total tax 
to be paid over total sales, not per transaction, each invoice 
increases the tax liability account by a little too little, if 
rounding is applied.


What issues do we have with the current behavior?

 1. Open items with sub-cent amounts due will never be completely closed
 2. Because of (1), AR and AP summary accounts may accrue amounts to
stay there forever
 3. There is no way to entirely clear the AR/AP summary account nor
the tax account, since the only way to enter sub-cent amounts into
the books is by creating AR/AP transactions (GL transactions don't
allow sub-cent values)
 4. Due to number (3), there's no way to clear the tax liability
account as part of the year-end books-closing procedure that both
John and I seem to have.


Now, to solve these issues, John suggested we should never record the 
tax liability with greater precision than what has to be paid to the 
tax authorities. In John's case (US), that would make sense, because 
every penny he calculates in sales tax, he has to submit back to the 
tax authority. However, in my case, it doesn't make sense, because I'm 
allowed to cut off the cents of my VAT before reporting to the tax 
authority (NL). In my case, it would mean that we'd never record more 
precision than 1EUR; with VAT rates of 21% and 6%, no tax would get 
recorded for sales below 4.76EUR and 16.67EUR respectively :-)


Personally, I do see the benefit of getting a cumulatively correct 
tax calculation (ie. something roughly similar to what we do now). 
This feature would be especially important for shop sales with high 
transaction volumes and low average invoice amounts. It means that I 
can simply trust my books to give me the right tax liability figures 
and I don't have to redo them at the end of each quarter (apart from 
rounding). I do perceive the 4 mentioned issues as real issues though.


Please provide your feedback as to whether you see other issues

Re: [Ledger-smb-devel] 1.3.38-rc1 on Monday?

[John Locke]

What is the rationale for:

* Reports all default to detail instead of summary (Erik H)

... I noticed this change on our production instance, and I'm actually 
finding it a bit annoying, most of the time I would prefer a summary by 
default, at least on the open invoice reports, which we run 10 times as 
much as all the rest of them...


Cheers,
John Locke
http://www.freelock.com

On 02/15/2014 05:44 AM, Erik Huelsmann wrote:


Hi Chris,

No testing from my side yet, but looking at the list, I'd say this 
makes a nice release.


Erik

sent from my phone

On Feb 15, 2014 2:17 PM, Chris Travers chris.trav...@gmail.com 
mailto:chris.trav...@gmail.com wrote:


Hi;

Any objection to me releasing 1.3.38-rc1 on Monday my time?  The
changelog is currently fairly long, and this would give some time
for review and adding anythng that may have been missed.  I would
expect that all currently open 1.3 bugs would be fixed for 1.3.39.

The complete, current changelog is:

Changelog for 1.3.38
* Fixed AR/AP transactions resetting currency/exchange rate (Chris T)
* Reports all default to detail instead of summary (Erik H)
* Fixed adding vouchers not checking for locked/approved batches
(Chris T 1025)
* Fixed can't delete pricematrix entries from customer screen
(Chris T, 893)
* Fixed language change on order to invoice conversion (Chris T, 896)
* Fixed ar/ap tax check inconsistency (Chris T, 919)
* Fixed inputs ignored for email addresses sending statements
(Chris T, 920)
* Fixed negative overpayments showing as positive (Chris T, 926)
* Fixed permission denied errors after upgrading copied db (Chris
T, 956)
* Fixed access denied when deleting unused tax account (Chris T,
967)
* Fixed GL Report fails before entering transactions (Chris T, 977)
* Fixed start and end dates not shown on contact screen (Chris T, 979)
* Fixed employee showing up several times on search list (Chris T,
980)
* Fixed contact description not preserved on edit (Chris T, 981)
* Fixed useless buttons on credit div when no account active
(Chris T, 1001)
* Backported requires() and requires_series() APIs from 1.4 (Chris T)
* Updated INSTALL to reflect better instructions for Apache 2.4
(Chris T)
* Fixed printed invoice not matching posted when 0 manual tax
(Nick P, 1051)
* Updated Hungarian translation (P. Isvan)

Chris T is Chris Travers
Erik H is Erik Huelsmann
Nick P is Nick Prater
P. Isvan is Pongracz Istvan

Any commiters who note anything is missing please let me know.

-- 
Best Wishes,

Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No
vendor lock-in.
http://www.efficito.com/learn_more.shtml


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

!DSPAM:52ff6f6d180851001410076!


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk

!DSPAM:52ff6f6d180851001410076!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:52ff6f6d180851001410076!


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.3.38-rc1 on Monday?

[John Locke]

Hi, Eric,

Oh, interesting. I think you and I are after exactly the same thing, but 
we're starting with a different report.


I use AR - Reports - Transactions (summary).

I'm guessing you use AR - Reports - Outstanding (detail).

A summary report on the first is almost exactly the same as a details 
report on the second. Almost, but not quite...



So yes, I see AR - Reports - Outstanding - summary as not something I 
need all the time -- and if it's misleading, that should get fixed.


AR - Reports - Transactions - detail has too much detail -- it 
expands all of the line items on invoices, so it's now much longer.



I'm seeing one difference between the two: Transactions is showing 
transactions that are out of balance by a fraction of a cent (the old 
invoices with calculated sales tax) while Outstanding omits them.


Otherwise we often are using Transactions to get a customer invoice 
history, by selecting the closed checkbox. For that reason alone, I 
would like to preserve the summary default there, though I can have 
people switch to the Outstanding report for the more typical use...



I wonder if it might make sense to actually split these into 3 reports? 
Seems like it would be confusing to have two reports lead to pretty much 
the same thing -- both with summary and detail options that do 
different things. What we have here are four different reports with two 
that are the same. How about splitting into something like:


- Invoices/Transactions (with options for open and closed, the report 
both you and I use)
- Customer outstanding totals (outstanding summary, hopefully fixed to 
only include open transactions)

- Items (Transaction detail report)

Not sure the second one is necessary, with the aging report also 
available...


Cheers,
John Locke
http://www.freelock.com



On 02/15/2014 12:56 PM, Erik Huelsmann wrote:

Hi John,


On Sat, Feb 15, 2014 at 8:03 PM, John Locke m...@freelock.com 
mailto:m...@freelock.com wrote:


What is the rationale for:


* Reports all default to detail instead of summary (Erik H)

... I noticed this change on our production instance, and I'm
actually finding it a bit annoying, most of the time I would
prefer a summary by default, at least on the open invoice reports,
which we run 10 times as much as all the rest of them...


The reason I made this change is really *because* of the summary open 
invoice report. For a number of reasons:


1. There is no way to click through to the details report on the 
summary, which confuses new users (they can't find their invoices)
2. The numbers on the open invoice summary are off: the amounts of all 
invoices (even the closed ones) are included.
3. The change didn't seem too invasive from where I stand: my 
bookkeeper and I only select the summary by accident (ie we only use 
details).


However, if this change breaks workflow for a large number of people, 
I'm not against adding a drill down into the details in some column. 
However, than still leaves the issue of the numbers of the summary 
being off (which has thrown me off more than once).


That's the rationale. Now, with the above on the table, how do you 
want to proceed? Do you want it removed from the release? Do you see 
other options to address the issues above?


Thanks for bringing up the discussion before the release! :-)

--
Bye,

Erik.

http://efficito.com http://efficito.com/ -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
!DSPAM:52ffd4a318811706712176!


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk

!DSPAM:52ffd4a318811706712176!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:52ffd4a318811706712176!


--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] What to do about accidental inclusion of Carp::Always

[John Locke]

On 01/25/2014 06:38 PM, Chris Travers wrote:
 Hi;
 From a support perspective, I am thinking having them as dependencies 
 makes a lot of sense.  It makes it very easy to enable stack dumps for 
 error messages and perhaps in 1.5 we could even do this as a 
 configuration option.  It also makes the code a bit more reliable in 
 the sense that if something gets missed users don't get internal 
 server errors.


This sounds like reason enough to require it as a dependency -- 
internal server errors without explanation sound like a terrible user 
experience...

Cheers,
John Locke
http://www.freelock.com

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.3.37: creating a 4-item invoice

[John Locke]

Hi, Erik,

I just tried this on my production install, updated to 1.3 HEAD this 
morning, and do not see this behavior -- all working fine here as far as 
I can tell. I did not post the invoice.


Cheers
John Locke
http://www.freelock.com

On 01/26/2014 03:53 PM, Erik Huelsmann wrote:

Hi Chris,


Today I'm experiencing a problem which I don't know if it's completely 
new in 1.3.35 through 1.3.37(branch). But the problem wasn't there 
before: I'm unable to create an invoice for 4 items. The invoice has 
automatic tax calculation, but it seems to happen with manual tax 
calculation as well.


What happens is: I enter a product number/code on the first line (hit 
enter to fill the other fields). I fill out the amount.
I enter a second product number/code (hit enter/update). I fill out 
the amount field and hit update.

Poof -- all lines of the invoice have disappeared now!

I do have local changes, but none in bin/*, script/* or LedgerSMB/*...


--
Bye,

Erik.

http://efficito.com http://efficito.com/ -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
!DSPAM:52e5a007212261532919366!


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk

!DSPAM:52e5a007212261532919366!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:52e5a007212261532919366!


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Plans for financial rewrite in 1.5

[John Locke]

Hi,

On the whole, this all seems like a good strategy, and for what I 
understand of the system, I'm entirely on board. Couple comments:



On 01/23/2014 02:37 PM, Erik Huelsmann wrote:

Hi Chris,


On Thu, Jan 23, 2014 at 3:48 AM, Chris Travers 
chris.trav...@gmail.com mailto:chris.trav...@gmail.com wrote:


Hi all;




1.  We need to be able to handle arbitrary two-currency or even
three currency transactions.  For example, if one has one's books
in USD and transferring money from a GBP to an EUR account, this
must be supported.

Right. What's more, I'd like the design (although possibly not the 
immediate implementation) to allow for assets to be held in non-base 
currencies. E.g. to hold a USD current account in a company which is 
EUR based. Part of this requirement is the need to be able to revalue 
the asset -- report it as having a different current value than the 
value that it had when the posting was originally created.


2.  We need to be able to handle per-transaction exchangerates.

Right. I'd say that we need a per-date default exchange-rate as well 
-- one that's picked up if no other exchange rate is specified.

To me, this requirement solves the following use-cases:
- different banks (or bank and credit card) with different exchange 
rates for the same currencies on the same date
- FX transaction reversal of a transaction in a closed period with a 
currency different from the current default


 One new consideration: Bitcoin. I just attended a talk yesterday that 
really made me see the value of digital currencies in terms of fraud 
prevention -- compared to credit cards, it's a much, much better deal 
and far less risky for merchants. But its value, obviously, fluctuates 
dramatically at any time.


At least being able to store and report on accounts stored in BTC would 
be an easy way to become an early accounting system with support for 
it... then we could add a digital wallet support later as an add-on or 
something... See some of my thoughts here: 
http://www.freelock.com/blog/john-locke/2014-01/bitcoin-future-e-commerce




 * A functional interface (before a webservice interface), so we get 
per posting/transaction integrity checks in place




Not sure I agree with this one. If we make the web service interface 
essentially extend an ORM to http, we can use http requests for testing. 
It's pretty easy to put together a generic test harness that would allow 
us to test requests and responses, aside from any UI issues. By 
functional do you mean functions in the database, or functional forms 
for user input? If the first, ok. If the last, I would like to see the 
REST interface use exactly the same code as the form handlers -- the 
form handlers just providing an HTML client layer that shares the same 
business logic.


Cheers,
John Locke
http://www.freelock.com
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] My post-1.4 priorities

[John Locke]

Hi,

I'm all for ripping out the financial code and replacing it. And I share 
Erik's concerns about stability.


Would it be possible to start by defining an API that wraps the current 
code, write some tests against that API, and then be able to use that to 
verify that the new code works correctly?


I'm thinking either a database API of stored functions, or a web 
services API. If we could get that in place with some decent tests, we 
can then totally change the underlying schema and know when we have it 
successfully built. TDD. And we know we want both -- much of the app in 
the database, as well as a REST API.


Just a thought...

Cheers,
John Locke
http://www.freelock.com

On 01/22/2014 12:55 AM, Chris Travers wrote:




On Wed, Jan 22, 2014 at 12:34 AM, Erik Huelsmann ehu...@gmail.com 
mailto:ehu...@gmail.com wrote:



On Wed, Jan 22, 2014 at 9:14 AM, Chris Travers
chris.trav...@gmail.com mailto:chris.trav...@gmail.com wrote:

Two more thoughts:


Ok. This is a big one. Even though I think it's a great
goal to set, if it were up to me, I'd like to split this
up in smaller tasks, if possible.\


At this point I don't think it is possible.  The db has to be
redesigned from underneath and making that
backwards-compatible is going to take almost as much time as
the full rewrite.

One thing that I think is important for the project as a
whole is that we can maintain a reasonable level of
stability during the entire rewrite -- it helps with the
acceptance of the final 1.5 end result.


Sure, but I would highly suggest that we not make the
financial logic a moving target and try hard to avoid any new
reports against financial tables in the mean time.  Otherwise,
if it is a moving target, it will never get done.


Well, my point is merely that we should strive to keep trunk in
working order. Maybe we should/can start this work on a branch so
that even if this work turns out to be infeasible (or rather: the
resources to finish it turn out to be unavailable), we'll still
have a working trunk version.

Does that sound like an approach?


Sure.  Just noting the moving target problem may mean delaying feature 
requests until it gets done, or doing those in the feature branch as well.


Here's my estimate as far as the minimum which will need to be redone 
at once:


1. We need a new db design of the following underlying tables: ar, ap, 
gl, acc_trans, invoice payment, payment_map, overpayment.  Providing 
read-compatibility may be possible, but write compatibility is not 
really feasible.


This means that the following have to be rewritten:

Financial transactions and sales/purchase invoices
Reconciliation
Payments
The reporting queries will need to be gone through and ported to the 
new codebase.


The first three replace about 12000 lines of Perl code, most of it old 
SQL-Ledger code as well as about 1600 lines of 1.3 SQL code.


The second involves review of another 1600 lines of SQL or so.



-- 
Bye,


Erik.

http://efficito.com http://efficito.com/ -- Hosted accounting
and ERP.
Robust and Flexible. No vendor lock-in.


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
mailto:Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel




--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor 
lock-in.

http://www.efficito.com/learn_more.shtml
!DSPAM:52df877f173469724526679!


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk

!DSPAM:52df877f173469724526679!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:52df877f173469724526679!


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads

Re: [Ledger-smb-devel] Looking at putting together an add-on for Washington State's sales tax

[John Locke]

Hi, Chris,

The problem might be getting a bit more complicated than just 
Washington: 
http://www.marketplacefairness.org/what-is-the-marketplace-fairness-act/


... this act was approved by the Senate last spring, and is in committee 
in the House, expected to pass but there are other priorities ahead of 
it. Once it does, the quarter starting 6 months after passing will be 
when it goes into effect.


https://taxcloud.net/default.aspx

is a free web service sponsored by the participating states to handle 
determining what is taxable and at what rate, based on the destination 
address.


Providing a tax module that talks to this service, and setting up parts 
so that they can be tagged with the appropriate code, might be a big win 
for the project if this legislation passes.


For #1, to me this is the main difference between a Point-of-sale and a 
shipping system. I would say something along the following lines, in 
sequence (first match wins):


* Transaction done using POS: use store address
* Use ship-to address if exists
* Use billing address if exists
* Use store address

... perhaps we have a Ship-to that can be the store address?

... as I look at the sales invoice, I'm not seeing an option to select a 
shipping address. Shouldn't it be possible to have multiple shipping 
addresses associated with a customer? Then we could populate a 
drop-down, one of the addresses can be set as default, and the store can 
be an option.



#2, not sure what you're asking, what's wrong with the current display? 
I think the main thing is we need the rate, the basis, the location 
code, and probably the taxing authority. I don't know that there can be 
different rates within the same order (same destination) -- as far as 
I'm aware, there are not different rates for different kinds of products 
-- but if there are it might be necessary to have multiple tax lines. 
One consideration is whether shipping/handling is taxable or not...


Cheers,
John Locke

On 01/09/2014 02:55 AM, Chris Travers wrote:

Hi everyone;

I know we still have some users in Washington State.  I would like to 
modularize this so that other location-based tax systems could work as 
well.  My thinking is to put together a class which handles locations 
(and delivery vs non-delivery handling) and then inherit from that 
something that would look up the tax code and rate for a jurisdiction.


This leads to a couple of important questions:

1.  How do we want to address delivered vs nondelivered?  A default in 
defaults?  Just use the presence of a ship-to address (my preference)?


2.  How do we want to handle display?

--
Best Wishes,
Chris Travers

Efficito:  Hosted Accounting and ERP.  Robust and Flexible.  No vendor 
lock-in.

http://www.efficito.com/learn_more.shtml
!DSPAM:52ce801f35501629111686!


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk

!DSPAM:52ce801f35501629111686!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:52ce801f35501629111686!


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] PNL report grouped by week/month/quarter/year

[John Locke]

;
   $ret-cols = $cols;
   $ret-total = $total;
   $ret-data = $data;

   // TODO: Move the following to a theme function, and return $ret
   $out = 'h2Profit and Loss, cash basis/h2';
   $out .= 'h3'.$dtstart.' - '.$dtend.'/h3';

   $out .= 'table class=timereport';
 $out .= 'thead';
   $out .= 'tr';
 $out .= 'thAccount #/ththDescription/th';
   foreach ($ret-cols as $col) {
 $out .= 'th'.$col['label'].'/th';
   }
   if (count($ret-cols)  1) {
 $out .= 'thTotal/th';
   }
   $out .= '/tr';
 $out .= '/thead';
 $out .= 'tbody';
 // flag to get an income subtotal
 $in_income = true;
 foreach ($ret-rows as $r=$row) {
   if ($in_income  $row['category'] == 'E') {
 // we are no longer in income, do a subtotal row
 $in_income = false;
 $out .= 'trth/ththSubtotal of Income:/th';
 foreach ($ret-cols as $k=$col) {
   $out .= 'th' . $col['income'] . '/th';
}
 $out .= '/tr';
   }
   $out .= 'trtd' . $row['accno'] . '/tdtd'. 
$row['label'].'/td';
   foreach ($ret-cols as $k=$col) {
 $out .= 'td';
 $out .= isset($ret-data[$r][$k]) ? $ret-data[$r][$k] : 0;
 $out .= '/td';
   }
   $out .= '/tr';
 }
 $out .= 'trth/ththSubtotal of Expenses:/th';
 foreach ($ret-cols as $k=$col) {
   $out .= 'th' . $col['expense'] . '/th';
 }
 $out .= '/tr';
 $out .= 'trth/ththTotals, income less expenses:/th';
 foreach ($ret-cols as $k=$col) {
   $out .= 'th' . $col['total'] . '/th';
 }
 $out .= '/tr';



 $out .= '/tbody';
   $out .= '/table';

   return $out;
}



Cheers,
John Locke
http://www.freelock.com

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Correct method to upgrade the database

[John Locke]

If this is a field we need to add to core, I would add the field in 
sql/Pg-database.sql, and an ALTER in sql/modules/Fixes.sql .


Cheers,
John Locke
http://www.freelock.com


On 08/28/2013 08:15 AM, Pongrácz István wrote:


Hi,

I started to modify the database and the code to meet Hungarian rules 
and this caused that, I need to add new field to the AR/AP tables.


My question is, how to handle these kind of modificatons? I found a 
subdirectory: sql/svn , where I can find correct upgrade steps, but I 
do not know the details of the file name convention.


Anyway, I still working on the latest 1.3 .

Cheers,

István

!DSPAM:521e1422296851512728087!


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk

!DSPAM:521e1422296851512728087!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:521e1422296851512728087!


--
Learn the latest--Visual Studio 2012, SharePoint 2013, SQL 2012, more!
Discover the easy way to master current and previous Microsoft technologies
and advance your career. Get an incredible 1,500+ hours of step-by-step
tutorial videos with LearnDevNow. Subscribe today and save!
http://pubads.g.doubleclick.net/gampad/clk?id=58040911iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Date input field enhancement by tavugyvitel.hu - worth to use it

[John Locke]

Hi,


On 08/10/2013 10:58 PM, Chris Travers wrote:




On Sat, Aug 10, 2013 at 2:54 PM, John Locke m...@freelock.com 
mailto:m...@freelock.com wrote:


Hi,

In 1.4 trunk, there is a Dojo date widget currently hooked up to
the Journal Entry screen. I've been planning to move this into
UI/lib/elements.html, basically create a date element that can
then be more easily hooked up, and then there's a single place
where the date format preferences can be handled for everywhere in
the application... and a nifty drop-down date widget included.


The autocomplete dropdowns were added to elements.html for the reason 
that they have a different HTML structure.  I am wondering how hard it 
would be to just getElementsByClass() and attach the scripts to these 
so that they could be more easily themed?


Yes, we can do this, and adding a class name is probably good for 
themers. It's actually more work to hook up on the JS side than just 
outputting a data-dojo-type attribute on the HTML tag (as I'm already 
doing). Dojo supports this really simple declarative syntax -- we can 
override the base Dojo objects to easily set other defaults, and then 
just leverage the parser to hook everything up.


Dojo widgets actually encapsulate a template for the HTML it generates, 
and there's a lot of theming capability built into those templates (and 
4 or 5 different themes shipping with the core). So whether or not we 
explicitly add a class to these elements, there's a lot of room for theming.




What I haven't yet figured out is how to get the user's date
format and locale preference injected into the template system. If
somebody can more easily inject that into the environment so it
can be accessed by a variable, this will be a very easy thing to
solve.


maybe we should have a namespace USER (I am trying to keep reserved 
words all upper case) which would store this info?  Easy enough to add.


That sounds great! If this can be turned into a JS object on the page, 
this should work fine. Simplest approach is probably to inline this into 
a script loaded on the page -- the Dojo parser will run after the DOM is 
ready, so this object should be available by then. Or we can load it as 
a callback, and require that data in elements that need it -- I would 
expect this would be a lot of them, though, so this probably isn't good 
from a performance standpoint, doing an extra Ajax callback on every page...




The next question then becomes, do we localize in the JS only, or
also on the server?

Here are some examples for how you can set date formats in the
date widget:

http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html
, and then Dojo could automatically convert those to a single
format that is actually submitted on the form -- this to me seems
like the easier approach. Then the form post handler can expect a
consistent format from anywhere.


For now I don't think it is likely to be feasible to stop doing 
localization on the server.  We do autodetect -mm-dd dates so any 
localization should use that format.However as we move all code 
over, I can see the benefits of moving this onto the client for data 
entry.  I think for display we will still need it on the server though 
so I am not sure it is possible to do all of this.


Oh, right. Yes, wasn't thinking of output. The dojo stuff can handle 
converting all input to -mm-dd format, but we'll still have to 
localize output on reports. To make the client side easier, we should, 
however, use -mm-dd format to provide the initial value of date 
inputs... Dojo can then convert to the appropriate locale format.


Cheers,
John Locke
http://www.freelock.com

--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Date input field enhancement by tavugyvitel.hu - worth to use it

[John Locke]

Hi,

In 1.4 trunk, there is a Dojo date widget currently hooked up to the 
Journal Entry screen. I've been planning to move this into 
UI/lib/elements.html, basically create a date element that can then be 
more easily hooked up, and then there's a single place where the date 
format preferences can be handled for everywhere in the application... 
and a nifty drop-down date widget included.


What I haven't yet figured out is how to get the user's date format and 
locale preference injected into the template system. If somebody can 
more easily inject that into the environment so it can be accessed by a 
variable, this will be a very easy thing to solve.


The next question then becomes, do we localize in the JS only, or also 
on the server?


Here are some examples for how you can set date formats in the date 
widget: 
http://archive.dojotoolkit.org/nightly/dojotoolkit/dijit/tests/form/test_DateTextBox.html 
, and then Dojo could automatically convert those to a single format 
that is actually submitted on the form -- this to me seems like the 
easier approach. Then the form post handler can expect a consistent 
format from anywhere.


There are more date parsing formats available, we could even support 
custom formats as described here: 
http://dojotoolkit.org/reference-guide/1.9/dojo/date/locale/parse.html#dojo-date-locale-parse


Cheers,
John Locke
http://www.freelock.com

On 08/09/2013 05:36 AM, Erik Huelsmann wrote:




  Much of the new code has date fields being of class date which 
is there in part to allow Javascript handles to be added 
programmatically in a central manner.


 My larger question is this:  what is the best way to allow for 
customized handles like this?


 Hmmm, I have no idea.

 If you mentioned, it is possible to hook custom javascripts for each 
class of input fields, probably a dedicated subdirectory could contain 
custom scripts. I guess it needs to develop a general framework.


 I guess you know more about the code and possibilities. :)

In my opinion, it'd be very good to include this in the discussion on 
UI improvements John, Brian, Mikkel and others are (going to be) having.


Possibly, this is just a matter of flipping a bit there (i hope :-)

Bye,

Erik.

!DSPAM:5204e505296858941011170!


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead.
Download for free and get started troubleshooting in minutes.
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk

!DSPAM:5204e505296858941011170!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:5204e505296858941011170!


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI

[John Locke]

On 07/31/2013 01:59 PM, Erik Huelsmann wrote:



Meanwhile there are a few other decisions to be made about how to
make it easy to start adding Dojo widgets -- basically defining
how to hook it up, so we can distribute this work.


Ok. So, just to verify my understanding: this is still mainly to 
address the short term needs? Or are all of you on the same page that 
this is going to be *the* approach toward 1.5?


I'm thinking that this approach would be for 1.4 and 1.5 -- that we 
introduce functionality in 1.4 and get full coverage in 1.5. And then 
re-open the broader discussion at that point on what works/doesn't work, 
and what we want to do that needs new architecture to get there.




2. Also in the top section, if there's a custom handler for this
page, set it in dojo_load, e.g. dojo_load =
lsmb/Contact/handler. This is assumed to be an AMD module that
returns an object with an init() method/function, which will be
called after the page is loaded and ready. This is optional.

From our chat on IRC, I understand this is key, however, to making the 
ECA page work intuivitely - preventing the page from jumping to the 
initial Company tab on reload, etc.?



Yes.

Also, I think there's opportunity to combine some screens this way -- 
e.g. combine several search screens with results on the same page, and 
it facilitates substantially more as well... haven't necessarily thought 
about the menu just yet though.


4. I'm thinking I'll define some new element types in
UI/libs/elements.html -- accountselector, date, currency, contact,
part. These elements will be hooked up to user locale and currency
preferences, as well as data sources back in LSMB. So once these
exist, all that will be necessary to widget-ize an element will
be to change the ?lsmb include input element_data = ... to ?lsmb
include accountselector element_data = ... There will probably be
some additional attributes for element data, such as foreign
currency for currency, contact type, etc.


Having additional elements seems like a logical next step. That way we 
make sure the selectors/... appear consistently formatted over all 
screens. (I think we have an issue there now regarding the way we 
present ECAs - sometimes by company name, sometimes using company and 
description concatenated...)


Yes, I noticed this -- and I think one server-side improvement that 
would help might be to accept just the account id, ECA id, etc in form 
posts. Probably need to preserve the ability to accept the current long 
forms of these fields as well -- but if we can fix these so that we 
don't _have_ to combine the fields exactly the same way in form posts as 
they are done now, that will make it easier to come up with richer, more 
intuitive interfaces.



Thoughts? Suggestions?


To me this plan provides a very good next step into the era of a new 
UI. It also provides the tangible results people (or at least I) would 
like to see to understand the benefits of this kind of UI conversion.


This discussion made me realise that I offered to start the discussion 
regarding the target UI and how to get there, but you, Brian, Herman 
and Mikkel are much more qualified to have that discussion than I am 
at this point. I think I should let you guys have it and draw up your 
plans! From there lets try to figure out how the plan fits best with 
the existing plans to rewrite the back-end.



Great!

Cheers,
John Locke
http://www.freelock.com
--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB

[John Locke]

Hi,

I just did a quick review of what Ember.js is, and what its strengths 
and weaknesses are, compared to Dojo. This assessment is definitely not 
coming from experience with Ember, but with a lot of Dojo experience, so 
I'm sure it's biased. But here's what I noticed:


Ember strengths:
- Routes, more opinionated management of controllers within the page
- Single DOM event listeners for entire application
- Views automatically delay re-rendering, possibly more streamlined DOM 
updates with less iterations


Ember weaknesses:
- Ember.data stores seem to be far less developed than dojo's stores and 
data objects, and still marked with an unstable warning
- Not seeing any declarative way of adding widgets to existing code -- 
means there's a lot more effort involved to get results



As I look at this, I still wonder why Dojo is shunned in so many 
circles. It is really a pioneer in this area, providing a huge amount of 
the functionality that's in Ember, and it provided it 6, 7 years ago, 
ages before this new generation of JS frameworks. And it still leads in 
areas like data management, defining APIs for paging, sorting, and 
searching that I don't see mentioned anywhere in Ember.data, things that 
will be especially useful for showing the transactions in an account (if 
I go to a chart of accounts report now on certain accounts and don't put 
in a filter for date, I need to wait for close to a minute for it to 
return a few thousand transactions!). And I really like the new 
encapsulated AMD (Asynchronous Module Definition) pattern, find it 
really effective for preventing conflicts with other libraries, keeping 
the memory footprint lightweight, and swapping out event libraries to 
target touch events and mouse events differently for different devices.


In particular, Dojo to me seems like a no-brainer because we can enrich 
the user experience with much nicer widgets, with some very small 
changes to the UI templates -- the declarative style of markup that Dojo 
provides makes this much simpler to get a whole bunch of easy wins.



And most of the things I see noted in the Understanding Ember pages 
(http://emberjs.com/guides/understanding-ember/the-view-layer/) have 
been in Dojo for years:


* Templates merged in the browser
* Automatic updates of content in templates, browser side (you do need 
to build a widget for this, but it's a very well-defined process)
* Event listeners (if anything, this sounds more complete in dojo -- 
with dojo/aspect, you can observe any function call, not just DOM 
events. Personally I use dojo/topic a lot, to create channels for pub/sub)

* Class definitions, widget lifecycles


So it strikes me that these are the arguments for going with Dojo:

* Can enhance the existing UI today, without needing to start from the 
ground up and rebuild the entire UI
* Can greatly improve a page/module at a time, without needing to build 
a single-page app
* Can still build towards a single-page app, perhaps with a bit more 
planning necessary around DOM event delegation and re-rendering triggers
* Widgets and systems already written and easy to deploy today, for 
handling thousands of rows of data, doing effective browser-side 
searches, sorts, and filtering with co-operation with the server side code
* Decent charting library that can leverage the same data models we use 
for raw data display



Cheers,
John Locke
http://www.freelock.com


On 07/30/2013 08:47 AM, Mikkel Høgh wrote:

Hi there,

I've not been very involved with LedgerSMB development so far, since 
I'm not really a Perl guy, but I have in fact been considering 
starting a project to build a modern JavaScript app as a replacement 
for the current LSMB interface.


I think the two best framework choices for this at the moment are 
Angular or Ember.js. I'm really impressed about what the Discourse 
guys have managed to accomplish with Ember.js (the forum at 
http://try.discourse.org/ is in fact a single page app, but it does 
certainly not feel like it).


I have built a few apps with Ember, so that would be my choice, but 
no matter what JavaScript framework is picked, I am willing to help 
out build it.


--
Kind regards,

Mikkel Høgh mik...@hoegh.org mailto:mik...@hoegh.org

On 30/07/2013, at 15.13, Brian Wolf brian.w...@activustech.com 
mailto:brian.w...@activustech.com wrote:



John makes some good points.
it's pretty trivial to switch between a menu bar and a tree widget.
I've developed with Dojo and can validate John's statement.  It also 
us the ability to provide multiple themes or layouts, letting each 
installation choose the one they want to use.


Sounds like we're in agreement that substantial progress can be made 
in upgrading the user experience, and that a JavaScript library like 
Dojo is a good place to start.  One-page applications have the 
advantage of a more desktop-application-like experience, with less 
page refreshes (a visual encumbrance).  However, my experience is 
that one-page apps can

Re: [Ledger-smb-devel] JS frameworks the future of the LSMB UI

[John Locke]

Oh, ok, I can't help but comment on the second point too:

On 07/30/2013 03:14 PM, Erik Huelsmann wrote:

 2. Longer term general direction for the development of the LedgerSMB UI
   This point probably requires separate discussion, because the 
 direction taken to develop a UI inherently affects the efforts 
 required for the back end. I.e. whether we from here on *only* 
 develop services on the back end, with separate front-end 
 developments, or that we develop along the current route which 
 supports to build a rich front-end eventually.

I think we should continue to maintain a plain-HTML front end as a 
fallback, at least for the near future.

I'd like to see some improvements in the JSON interface, both for 
integration with entirely outside applications and to simplify the work 
that needs to be done in the browser to make richer interfaces (assuming 
we're using things like Dojo stores to consume and update that data). 
The spec we developed that's described in rest_server.pl should work -- 
however the actual interface doesn't currently work with the one class 
that's defined (LedgerSMB::REST_Class::Contact), and I think there might 
be some easier ways to get broad coverage here -- perhaps hooking into 
the ORM model to return straight JSON from virtually any stored 
function? Or providing some REST methods on the LedgerSMB data object 
that everything else inherits...

But the biggest thing to me is not slowing down the release. The reason 
I haven't committed my changes (yet) to trunk is that I want to see 1.4 
out and working, soon, and I don't want the UI discussions to slow that 
down. There's enough improvement going on that I don't want to distract 
you or Chris too much by adding a ton more that needs to be done before 
we declare a stable release.

So if you're amenable, I'd suggest let's go ahead with introducing Dojo 
as an included library, and let me, Brian, Herman, Mikkel, and anyone 
else who's comfortable plugging away at the JS side of things improve 
one screen/module at a time, with a goal of more complete coverage in 
1.5, and then perhaps look at new UI paradigms for the release after that.

Cheers,
John Locke
http://www.freelock.com

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB

[John Locke]

Hi, Erik,

I've implemented a Dojo-based account drop-down on the GL - Journal 
Entry form on the same demo site.


For those wanting to check this out, for the time being you can see 
these enhancements at: https://intranet2.freelock.com/ledger14 -- log in 
with user demo, pw demo, company demo.


The tabs are on individual accounts, and the account selector is hooked 
up to journal entries (along with a date text box).


I'd be happy to commit these changes if welcomed...

Cheers,
John Locke
http://www.freelock.com

On 07/27/2013 11:57 PM, Erik Huelsmann wrote:

Hi John,

Just a moment ago, I showed the demo you set up with Dojo tabs for the 
ECA screen to Chris. We both like it a lot.


Chris said If he commits this, I can try to move us away from 
scriptaculous. However, if you have time to do it, that's very much 
appreciated as well. The only thing that *I* know that needs doing is 
replacing the accounts drop-down. The code for that is in 
UI/lib/elements.html.


Thanks!

--
Bye,

Erik.

http://efficito.com http://efficito.com/ -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
!DSPAM:51f4c0f4296851152612237!


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk

!DSPAM:51f4c0f4296851152612237!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:51f4c0f4296851152612237!


--
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831iu=/4140/ostg.clktrk___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB

[John Locke]

Hi,

The problem, in my view, with jQuery/jQueryUI is how much more work you 
have to do to implement it. With some clever hookups, we can write our 
own re-usable components and get contributions to finish hooking things 
up that don't involve using Javascript.

To hook up the tab container, most of the changes are adding some HTML 
attributes to the various containers - e.g. on the wrapper div, a 
data-dojo-type=dijit/layout/TabContainer and on each tab, a 
data-dojo-type=dijit/layout/ContentPane and a title. Aside from that, 
all that's necessary is to include the elements in use on the page and 
call the parser.

Dojo plays extremely well with other libraries, too. It does not change 
any prototypes, does not pollute the global namespace, and as a pioneer 
in the AMD loading pattern, only loads a minimal amount of js to the 
browser.

I'll post my code to github shortly, so you can see what changes are 
involved with adding these things.

For example, making the date box on the Journal Entry page a nice 
drop-down calendar involved two changes:

1. Add the dijit/form/DateTextBox to the modules loaded on the page
2. Add data-dojo-type=dijit/form/DateTextBox to the HTML input element 
(the LSMB preprocessor doesn't like hyphens, though, so I did change 
this to dojo_type in the UI templates)

... that's it!

The account selector widget I bundled into a custom widget complete with 
its own data feed, so turning any input into an account selector now 
involves the same exact two steps, except using 
lsmb/accounts/AccountSelector instead of the date widget. (And at 
least for now, there's a couple steps to get Dojo loaded on the page in 
the first place).


But in my view there are much better reasons to add Dojo: there are some 
opportunities for DRASTIC ui improvements. I'm picturing doing away with 
the frame, using a tree widget for the left hand side, and providing a 
persistent, context-aware search area for finding 
transactions/parts/orders/reports/etc. That can load results into one 
tab, and then we can load individual detail into other tabs that can be 
closed when you're done but kept open for comparison.

There's a really good grid available with infinite scrolling, great for 
looking at individual ledgers -- see http://dgrid.io. And there's a 
data-driven form handler, that would really streamline data entry on 
things like the contact addresses pane/contacts pane, which would let 
you select a row, populate the form from that data, store changes on the 
browser until you're ready to save the whole thing. None of this 
cumbersome page reloads.

The huge advantage Dojo has over other toolkits is its data management 
capabilities that are all done in-browser, and can then be sync'd up 
with the server through some lightweight rest calls using json. With 
jQuery, you have to wire all this together yourself, rather than simply 
connecting a widget to a data store.

And hey, there's also a great chart toolkit that can leverage the same 
data structures. See 
https://www.freelock.com/blog/john-locke/2013-06/how-structure-dojo-based-dashboard-drupal
 
for a more Drupal-centric description of what we're doing with charts -- 
it would be fantastic to get some of that going in LSMB too.

Cheers,
John Locke
http://www.freelock.com


On 07/28/2013 07:34 AM, Lyle wrote:
 On 28/07/2013 13:31, Brian Wolf wrote:
 Each Javascript library has its strengths and weaknesses; Dojo and
 Prototype / Scriptaculous are no exceptions. I've implemented some
 custom screens for LedgerSMB using Prototype / Scriptaculous, already
 in production. Do I understand that LedgerSMB will now be distributed
 with Dojo? That decision does have some impact.
 With jQuery and jQueryUI being more popular, using them would
 potentially create a larger pool of potential contributors.


 Lyle

 Thanks.
 Brian

 Brian Wolf
 Phone: 410.367.2958
 Email: br...@activustech.com
 Try out Activus Secure Payments™, our recurring payments application.
 Demo at http://demo.activustech.com
 On 07/28/2013 02:57 AM, Erik Huelsmann wrote:
 Hi John,

 Just a moment ago, I showed the demo you set up with Dojo tabs for
 the ECA screen to Chris. We both like it a lot.

 Chris said If he commits this, I can try to move us away from
 scriptaculous. However, if you have time to do it, that's very much
 appreciated as well. The only thing that *I* know that needs doing is
 replacing the accounts drop-down. The code for that is in
 UI/lib/elements.html.

 Thanks!

 -- 
 Bye,

 Erik.

 http://efficito.com http://efficito.com/ -- Hosted accounting and ERP.
 Robust and Flexible. No vendor lock-in.


 --
 See everything from the browser to the database with AppDynamics
 Get end-to-end visibility with application monitoring from AppDynamics
 Isolate bottlenecks and diagnose root cause in seconds.
 Start your free trial of AppDynamics Pro today!
 http://pubads.g.doubleclick.net/gampad/clk?id

Re: [Ledger-smb-devel] Dojo tabs demo / using dojo in LSMB

[John Locke]

Ok. Code is posted on github for the time being...

Here's the repository: https://github.com/freelock/ledgersmb

Branches:
ledger13 is the current tip of the svn/1.3 branch
ledger14 is the tip of svn trunk
ledger14-dojo contains the current additions to add the dojo stuff 
that's there so far.


You can see what I've done so far here:

https://github.com/freelock/ledgersmb/compare/ledger14-dojo

... this is so far just a demo setup, took a couple shortcuts we'll need 
to fix (like the ability to load more than one dojo file in a sane way 
-- right now it assumes you'll provide a single dojo AMD module that 
returns an object with an init() method that will invoke the parser).


But now that it's here, adding dojo to more screens is a pretty simple 
thing. Here are some notes:


* I've defined an AMD package path that maps lsmb to the UI directory. 
So now Dojo will load your js modules if you require them with this pattern:

  lsmb/accounts/AccountSelector -- loads UI/accounts/AccountSelector.js
  lsmb/accounts/init -- loads UI/accounts/init.js
* For the time being, you add Dojo to a page by creating an init module 
and adding it to the ?lsmb? processing block at the top of your UI 
template, using a include_dojo = [ 'lsmb/accounts/init' ]. This will 
trigger the template system to add the Dojo.js and require the init 
module you create.


* Your init module should require any widget definitions you want to 
use, along with dojo/parser, and return an object with an init() method. 
The init() method should call parser.parse(). See UI/accounts/init.js 
and UI/Contact/tabs.js for examples.


* The Dojo parser will populate widgets automatically with values, 
titles, ids, and names -- you really don't have to do much beyond 
declare the widget you want an element to load.



So now adding things like drop-down calendars is trivial. Next things I 
see doing include:


* Intercept the form updates on the Contacts section, post those via 
Ajax and populate the result, make the list views editable in more of a 
live way
* Create an account lookup widget for customers, vendors, employees, etc 
that connects to an appropriate data feed

* Create a parts lookup widget for orders/invoices/quotes
* Move the menu to a tree widget
* Remove the frame, and add some parameter to the page controller to 
detect whether we're getting an ajax request (return only body) or a 
page request (return menu tree and body)
* Replace General Ledger reports with a Dgrid that supports paged data, 
allowing fast lookups on thousands of rows, filtering, sorting
* Add some date comparison widgets for financial reports (PNL, Balance 
Sheet) to allow side-by-side presentation of several different time 
periods (e.g. show me last 2 years of data with quarterly summaries)
* Line charts of financials over time/pie charts of data broken out by 
account/gifi



On those notes, I do find what took me longest on the AccountSelector 
widget was trying to get a JSON feed of the accounts, since I'm not much 
of a Perl hacker. I tried using the rest_server.pl system that Chris had 
started, but could not get that to work, even for the existing Contact 
class -- it looks like the API has changed enough that the Contact class 
doesn't have the necessary methods to do a lookup of a contact or a 
search. I ended up just adding on to LedgerSMB::Scripts::journal because 
it seemed the most expedient, but a bit messy. If we can get the REST 
api working as we defined earlier, that can expose so much more richness 
to the UI with minimal JS programming, if we're using Dojo.


So for the contact lookup widget, parts lookup widget, menu, 
transactions, main thing I'm looking for is a JSON array of the data -- 
for parts, contacts and transactions it should definitely support 
searches and paging. For ledger account lists and menu items, it's 
better to load the entire json string without searching, because then 
the browser will cache that (and it's not going to be that big a data 
set). If someone can assist on the Perl side with getting those web 
services up and running, I can wire together the data handling on the 
dojo/browser side pretty quickly.


Cheers,
John Locke
http://www.freelock.com




On 07/28/2013 10:14 AM, John Locke wrote:

Hi,

The problem, in my view, with jQuery/jQueryUI is how much more work you
have to do to implement it. With some clever hookups, we can write our
own re-usable components and get contributions to finish hooking things
up that don't involve using Javascript.

To hook up the tab container, most of the changes are adding some HTML
attributes to the various containers - e.g. on the wrapper div, a
data-dojo-type=dijit/layout/TabContainer and on each tab, a
data-dojo-type=dijit/layout/ContentPane and a title. Aside from that,
all that's necessary is to include the elements in use on the page and
call the parser.

Dojo plays extremely well with other libraries, too. It does not change
any prototypes, does not pollute the global

Re: [Ledger-smb-devel] Proposal for 1.4: Removing taxable sales/non-taxable sales reports, consolidate under AR/AP Search

[John Locke]

On 12/13/2012 06:05 PM, Chris Travers wrote:

I actually do use the taxable sales report, though as long as there is

some easy way to get a total of taxable products sold and total tax
collected, happy to use another approach.


My current approach is to basically allow one to search on taxable 
sales by any or all tax accounts.  Currently what this means is you 
can get the invoice total of taxable sales for any given tax account 
(same as the tax collected report) plus the tax collected on any and 
all.  The only difference is one would go through the Search AR/AP 
screen to do it.  This would be one thing to get feedback on during beta.


Well, the invoice total of taxable sales is actually pretty useless to 
me. What I need is the total taxable sales.


IIRC, in the taxable sales report I need to use the Detail instead of 
Summary to get this -- the amount of taxable products on each invoice, 
rather than the invoice total that contains taxable products.


As long as there's a straightforward way to get that taxable total 
amount reported by any time period, I'm good...


Cheers,
--
John Locke
http://www.freelock.com
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal for 1.4: Removing taxable sales/non-taxable sales reports, consolidate under AR/AP Search

[John Locke]

On 12/13/2012 06:18 AM, Michael Richardson wrote:
 Chris == Chris Travers chris.trav...@gmail.com writes:
  Chris I am considering removing taxable sales/nontaxable sales
  Chris reports for 1.4.

 I don't use them.

 When I have to prepare VAT (GST/HST) returns, I use Chart-of-Accounts on
 the VAT liability account.  In my copious spare time, I'd like to turn
 this into a proper VAT report and process, but I haven't done that.


I actually do use the taxable sales report, though as long as there is 
some easy way to get a total of taxable products sold and total tax 
collected, happy to use another approach.

Cheers,
John Locke
http://www.freelock.com

--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Status of 1.4 and call for involvement

[John Locke]

Hi, Chris,

Is there a migration path for 1.3 - 1.4 available yet? Would like to 
run the two versions side-by-side for a bit with real numbers...


I'll definitely be happy to test, and I have a need for some cash-based 
income reports come January (and I know we'll have to do some 
adjustments to prior years' returns...)


Cheers,
John

On 11/13/2012 06:04 AM, Chris Travers wrote:



On Mon, Nov 12, 2012 at 8:17 PM, Berend Tober bto...@broadstripe.net 
mailto:bto...@broadstripe.net wrote:


Chris Travers wrote:

1.4 is coming along.  We could use more involvement.  ...

Hi;

I have committed your patches.  The one to pg-database.sql thought 
seems out of date and already applied.  Are you running last snapshot 
or from svn?


Best Wishes,
Chris Travers
!DSPAM:50a25374326914621311308!


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov

!DSPAM:50a25374326914621311308!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:50a25374326914621311308!


--
Monitor your physical, virtual and cloud infrastructure from a single
web console. Get in-depth insight into apps, servers, databases, vmware,
SAP, cloud infrastructure, etc. Download 30-day Free Trial.
Pricing starts from $795 for 25 servers or applications!
http://p.sf.net/sfu/zoho_dev2dev_nov___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Move to git?

[John Locke]

Hi,

I use git pretty much exclusively, and maintain a git mirror of LSMB here:

* Browse at: http://git.freelock.com/?p=ledgersmb.git;a=summary
* Clone from: git://git.freelock.com/git/ledgersmb.git

This repo automatically updates from the SVN master every 6 hours, so it 
should be quite up to date. Occasionally if I'm trying to address 
something specific I'll do a manual update more often...


I'd be happy to move this repo to Github if people would prefer -- and I 
probably will if a lot of people start using it. I'm sure I could set up 
our current update script to update a copy at Github...


I've been using this setup for years now, and have had no issues 
whatsoever related to working with the project. I generally use git diff 
to generate patches and then email those to Chris or Erik for 
review/commit to SVN -- when I sent some patches via git format-patch, 
Chris had trouble applying it, so since then I've stuck to manually 
generating patch files and sending them as attachments.


So while I'm definitely in favor of a move to github or equivalent, I 
don't think it's important enough to disrupt the current productivity of 
the core developers. And I'm not feeling like there's anything more 
necessary to facilitate git users -- as Jeff mentioned, git svn seems to 
work reasonably well if you do want to commit directly to svn...


Cheers,
John



On 09/05/2012 06:57 AM, Ed W wrote:

Hi


So with those thoughts in mind I want to ask two basic questions:

1)  For git users, what do we need to do today to make use of git 
with LedgerSMB more pleasant?


Simply that a well maintained Git repo is available and clearly 
documented that there is a commitment to remain up to date (eg it's 
implemented in an automatic fashion)


For mild preference I would like the git repo hosted somewhere that 
encourages forks to remain visible, eg Github.  However, there is a 
whole new can of worms by suggesting that, so I will leave that as a 
separate suggestion.



2)  For those who currently use git what sorts of processes can we 
have today, without moving currently, that will help you get more out 
of using git with ledgersmb?  This is an important one because even 
if we move in the future, it isn't clear we'd entertain direct pull 
requests.  We might use git just to make it easier for people to 
maintain mini-forks and share features between such.  (My 
understanding is this is largely how PostgreSQL uses it for main 
development, and my guess is that virtually all patches still come in 
via email.)


Opinion is divided on whether pull requests are that useful. Linux 
kernel takes external contributions via email and that is what the 
git am command is for.  Possibly this is something  you currently 
feel requires a script for svn users to implement correctly, but under 
git there should be no need, eg you might develop like this:


/// Make feature branch//
/git checkout master -b my_fork

/// do some work...//
 ...//
/git commit
/// do some work...//
 ...//
///git commit
/// rinse, repeat, etc//
/
/// Now, assuming master has moved on, ensure that our patches apply 
perfectly to HEAD//

/git fetch
git rebase master

/// Submit patches//
 Generate complete email://
/ git format-patch -1 -s
/// or send the emails as well://
/ git send-email


You the developers can apply patches using either git-am or git-apply 
(am reads the patches right out of a mail file, apply assumes you 
saved them to disk first).


So, yes, email is probably the simplest way to accept new patches with 
git, however, one of the nice things about public git hosting 
(especially github/gitorious) is that you have the option to poke 
around and do a git-pull or git-cherry-pick if appropriate.  I 
personally rarely git-pull stuff though unless I very much trust the 
upstream - mostly I work with patches



Oh, final useful thing is maintaining git-branches and git-tags that 
correspond with the actual releases.  This should come across 
automatically from SVN, but just highlighting it's a nice to have



Cheers

Ed W

!DSPAM:50475a8c313569016576474!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

!DSPAM:50475a8c313569016576474!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:50475a8c313569016576474!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. 

Re: [Ledger-smb-devel] initial draft of PHP mapper class

[John Locke]

I'd be interested in the PHP classes...

Regarding separate SF projects, that sounds worse -- what about moving 
to Github or something more flexible/easier to use?

Cheers,
John Locke
http://freelock.com

On 07/28/2012 05:52 AM, Chris Travers wrote:
 On Sat, Jul 28, 2012 at 1:32 AM, herman vierendeels
 herman.vierende...@gmail.com wrote:
 Hi Chris,

 I am interested.
 And i am still more interested in your java-implementation plans.
 As an experienced java-programmer, i might be able to help you in that field

 Hi Herman;

 I am sending you the couple of files I have.  I have not tested the
 exec_method call but I don't see why it wouldnt work.  The
 call_procedure seems to work however.

 I guess this is a question for everyone interested but would it make
 sense to create separate Sourceforge projects for each extra language
 binding?

 Best Wishes,
 Chris Travers

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:5013e0e9129416620714272!



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Where to put the PHP interop classes

[John Locke]

[Replying to more appropriate thread...]

What about Github?

Not just for the PHP classes -- the whole project?

SF is annoying, by comparison...

Cheers,
John Locke
http://www.freelock.com

On 07/29/2012 01:57 AM, Chris Travers wrote:
 Hi all;

 I am trying to decide where to put the PHP interop classes.  It seems
 we have a few possibilities:

 1)  In /addons/ maybe a new directory like /addons/languages/
 2)  In a separate open source project like ledgersmb-php on
 Sourceforge or Google Code

 I am leaning towards the latter because we could do additional
 releases on Freecode and hopefully get more interest that way.
 However, I would like to get feedback from others first.  Maybe I am
 missing something.  Maybe the other way is better, etc.  So let me
 know what you think and have your say.

 Best Wishes,
 Chris Travers

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:501500c8129411235955660!



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Where we are at on the 1.4 changelog

[John Locke]

Holy crap this sounds great!

Fantastic work.

What's your sense on stability, at this point? e.g. can we assume that 
financial logic is sound?


What does the upgrade from 1.3 look like -- are there scripts/tools for 
doing that yet?


Really looking forward to checking this out. However we're totally 
slammed right now, don't see a spare moment before August the way things 
are looking... and I don't have a server set up with Postgres 8.4+ yet...


Cheers,
John Locke
http://www.freelock.com


On 07/15/2012 06:37 PM, Chris Travers wrote:
I figured it would be worthwhile to send out the changelog and get 
feedback.


General Enhancements:
* Performance enhancements on menu routines (Chris T and Steven M)
* Added +/- selection indicators to menu CSS (Chris T)
* Changing all auth calls to hit postgres db instead of template1 
(Chris T)
* invoice.unit is now unbounded varchar to reduce errors (Chris T, 
3516235)

* Invoices with inventory subject to draft/vouchers workflows (Chris T)
* Added Equity (Temp) account type, closed at year-end (Chris T)
* Added description field to transaction and invoice screens (Chris T)
* Removed ability to repost/delete transactions (Chris T)
* Partsgroups can now be nested though this is not yet used by LSMB 
(Chris T)

* Session expiration now with configurable behavior (Chris T)

Installation/Upgrade
* PostgreSQL contrib dependencies removed, now require Pg 8.4 (Chris T)
* LaTeX format detection now run-time call, not configured (Chris T)

Code/API improvements
* scripts/* files moved to make inheritance possible (Chris T)
* Removed the Config::Std dependency and moved to Config::General 
(Chris T)

* Improved error handling using Try::Tiny and die (Chris T)
* Added dynatable.html template that can be included in templates 
(Chris T)
* Dynatable forms obtained through GET now show link back to form 
(Chris T)
* LedgerSMB-error and Form-error now show db version and company 
(Chris T)

* Simpler use of Log::Log4perl instead of LedgerSMB::Log (Chris T)
* Centralized database commit for new code (Chris T)

New RESTful Web Services Framework
* Supports XML and JSON as input formats
* Supports XML and JSON as output formats
* Supports read/write for Contacts:
   * Customers
   * Vendors
   * Employees
   * Leads
   * More

New Reporting Framework
* Easy bridge between SQL and display (Chris T)
* All reports exportable to CSV (Chris T)
* All reports exportable to PDF (Chris T)
* Unified UI for reports (Chris T)
* Enhanced trial balance allows for partial trial balance (Chris T)
* Enhanced trial balance allows for saved criteria (Chris T)

Customer/Vendor/Employee Handling and CRM
* Added sales tax id and license number fields for companies (Chris T)
* Simpified database schema (Chris T)
* Full text search of notes for customers/vendors (Chris T)
* Added file attachments to customers, vendors, employees, leads etc 
(Chris T)

* Added lead handling (Chris T)

New CSV Import Module
* Imports GL transactions (Chris T)
* Imports AP batches (Chris T)
* Imports charts of accounts entries (Erik H)
* Imports GIFI tables (Erik H)
* Imports SIC tables (Erik H)
* Imports timecards (Chris T)
* Imports initial inventory and periodic counts (Chris T)
* Extensible
* field maps can be overridden

New Business Reporting Unit System (Chris T)
* Replaces Projects and Departments
* Business reporting units may be nested
* Allows one to do funds accounting, track jobs separately from 
projects, etc
* Report on any combination of business reporting units (up to one per 
class)


Best Wishes,
Chris Travers
!DSPAM:500370c2280062201711104!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/

!DSPAM:500370c2280062201711104!


___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


!DSPAM:500370c2280062201711104!



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Next development 1.4 release coming soon

[John Locke]

Wow. Great stuff!

Did the web services stuff make it in yet, or will that be coming after 
1.4 solidifies?

Cheers,
John Locke
http://www.freelock.com

On 06/03/2012 07:38 PM, Chris Travers wrote:
 Hi all;

 Here's what's left to do on my side.

 1)  I want to move the customer/vendor history reports to the new
 framework from the 1.3 framework
 2)  I want to move the transactions/outstanding reports from old code
 to the new framework
 3)  There are some issues with database creation still that I want to resolve
 4)  There are some menu tweaks that will need to happen plus a couple
 of minor structural changes to the menu

 At that point, the AR/AP/Journal functionality should be essentially
 where it will be at the release of 1.4 aside from bug fixes, etc.
 Work will be focused on moving reports over, rewriting employee and
 user handling and (after that is done) payroll.

 After this release I will start trying to support test instances of
 1.4.  This means schema change scripts and dumps of menu_node and
 menu_attribute.

 The changelog for 1.4 is already impressive.  The shift in codebase
 has paid off.

 Best Wishes,
 Chris Travers

 The current changelog relative to 1.3 is:


 General Enhancements:
 * scripts/* files moved to make inheritance possible (Chris T)
 * PostgreSQL contrib dependencies removed, now require Pg 8.4 (Chris T)
 * Performance enhancements on menu routines (Chris T and Steven M)
 * Projects and Departments can now have subprojects and Departments (Chris T)
 * Project/department mechanism generalized to support funds, etc (Chris T)
 * Removed the Config::Std dependency and moved to Config::General (Chris T)
 * Improved error handling using Try::Tiny and die (Chris T)
 * Added +/- selection indicators to menu CSS (Chris T)
 * Added dynatable.html template that can be included in templates (Chris T)
 * Dynatable forms obtained through GET now show link back to form (Chris T)
 * LedgerSMB-error and Form-error now show db version and company (Chris T)
 * Simpler use of Log::Log4perl instead of LedgerSMB::Log (Chris T)
 * Changing all auth calls to hit postgres db instead of template1 (Chris T)
 * Centralized database commit for new code (Chris T)
 * invoice.unit is now unbounded numeric to reduce errors (Chris T, 3516235)

 New Reporting Framework
 * Easy bridge between SQL and display (Chris T)
 * All reports exportable to CSV (Chris T)
 * All reports exportable to PDF (Chris T)
 * Unified UI for reports (Chris T)

 Customer/Vendor Handling
 * Added sales tax id and license number fields for companies (Chris T)
 * Simpified database schema (Chris T)

 New CSV Import Module
 * Imports GL transactions (Chris T)
 * Imports AP batches (Chris T)
 * Imports charts of accounts entries (Erik H)
 * Imports GIFI tables (Erik H)
 * Imports SIC tables (Erik H)
 * Imports timecards (Chris T)
 * Extensible
 * field maps can be overridden

 New Business Reporting Unit System (Chris T)
 * Replaces Projects and Departments
 * Business reporting units may be nested
 * Allows one to do funds accounting, track jobs separately from projects, etc
 * Report on any combination of business reporting units (up to one per class)

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4fcc1fe4314443743763323!



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Web services revisited

[John Locke]

 should respond with a 
Content-Range header to indicate how many items are being returned and 
how many total items exist:


Content-Range: items 0-24/66


That's from here: 
http://dojotoolkit.org/reference-guide/1.7/dojo/store/JsonRest.html ... 
also some guidance on sorting on that page.




Cheers,
John Locke
http://www.freelock.com
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Web services revisited

[John Locke]

On 05/22/2012 07:06 PM, Chris Travers wrote:
 On Tue, May 22, 2012 at 12:27 PM, John Lockem...@freelock.com  wrote:

 Possible Index handler:
 GET /rest/1.0/my_company/ar_transactions/?invoice_id=N499216
 I had a thought about this one.  Suppose we allow a by= field to
 specify a non-standard id key?  In that case, your URL would look like

 GET /rest/1.0/my_company/ar_transactions/N499216?by=invnumber

 The desired result would then be to get a redirect to the the cannonical URL.

 I am thinking that this avoids issues like:
 GET 
 /rest/1.0/my_company/customers/A1234/locations/billing?customers_by=meta_numberlocations_by=location_class

 In that case instead you'd do:

 GET /rest/1.0/my_company/customers/A1234?by=meta_number

 Capture the redirect address

 then do
 [redirect_address]/locations/billing?by=location_class

 You could then either do a redirect and add the extension or pursue
 the redirect with the content type header.

 Note, by would only be valid where the field is a valid secondary key.
   The modules would be responsible for enforcing this.

Hi,

Cool idea, but I'm not sure it's something I would actually use. On the 
client side, I need a unique key for each object -- that might as well 
be the same one as LSMB uses -- and I would rather have a single, 
canonical URL for each object.

So redirects to that are good, if they don't break other expectations.

And implementing a service, it's easy to assume either individual 
objects if I have what looks like a resource path (e.g. with an id) or 
collections otherwise.

So I would say this is fine, but not something high on my list or would 
likely use. It's just as easy to do an index lookup with the search 
parameters for other keys.

The biggest question I would have would be around the defaults. For 
example, on the AR transactions screen, a search by default only shows 
open invoices. However, a search by invoice number does return closed 
invoices even when the closed button is unchecked. This is a very nice 
feature for usability, but it's also somewhat unexpected. Should either 
document these exceptions very clearly, or remove them from the web 
service -- perhaps default to returning all invoices, and force a web 
service to specify open if that's all they want?

Cheers,
John Locke
http://www.freelock.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Address formatting functionality

[John Locke]

Hi,

Just for reference (hope this HTML comes through ok -- cc'ing you 
directly Erik/Chris, just in case), here's the table schema the Drupal 
addressfield module stores its data in:



Column  TypeNullDefault Comments
entity_type varchar(128)No  The entity type this data is 
attached to
bundle 	varchar(128)	No 		The field instance bundle to which this row 
belongs, used when deleting a field instance
deleted 	tinyint(4)	No 	0 	A boolean indicating whether this data item 
has been deleted

entity_id   int(10) No  The entity id this data is attached to
revision_id int(10) No  The entity revision id this data is 
attached to
languagevarchar(32) No  The language for this data item.
delta 	int(10)	No 		The sequence number for this data item, used for 
multi-value fields
field_address_country 	varchar(2)	Yes 		Two letter ISO country code of 
this address.
field_address_administrative_area 	varchar(255)	Yes 		The administrative 
area of this address. (i.e. State/Province)
field_address_sub_administrative_area 	varchar(255)	Yes 		The sub 
administrative area of this address.
field_address_locality 	varchar(255)	Yes 		The locality of this address. 
(i.e. City)
field_address_dependent_locality 	varchar(255)	Yes 		The dependent 
locality of this address.
field_address_postal_code 	varchar(255)	Yes 		The postal code of this 
address.
field_address_thoroughfare 	varchar(255)	Yes 		The thoroughfare of this 
address. (i.e. Street address)
field_address_premise 	varchar(255)	Yes 		The premise of this address. 
(i.e. Apartment / Suite number)
field_address_sub_premise 	varchar(255)	Yes 		The sub_premise of this 
address.
field_address_organisation_name 	varchar(255)	Yes 		Contents of a 
primary OrganisationName element in the xNL XML.
field_address_name_line 	varchar(255)	Yes 		Contents of a primary 
NameLine element in the xNL XML.
field_address_first_name 	varchar(255)	Yes 		Contents of the FirstName 
element of a primary PersonName element in the xNL XML.
field_address_last_name 	varchar(255)	Yes 		Contents of the LastName 
element of a primary PersonName element in the xNL XML.

field_address_data  longtextYes /NULL/  Additional data for 
this address.



... It looks like they have a custom data entry form per country, but 
all data is stored in a table like this (this is a specific instance of 
an addressfield). Without digging deeper, I would expect to find a 
template that describes the input format and output template for each 
country, mapping to these columns. Any country that wants additional 
arbitrary fields would likely have them serialized in field_address_data.


So it sounds like the same basic approach you propose, Erik -- sounds 
totally reasonable to me.


I hope this column break-down is helpful...

Cheers,
John

On 05/07/2012 11:41 AM, Erik Huelsmann wrote:



On Mon, May 7, 2012 at 5:53 AM, Chris Travers chris.trav...@gmail.com 
mailto:chris.trav...@gmail.com wrote:


On Sun, May 6, 2012 at 8:30 PM, John Locke m...@freelock.com
mailto:m...@freelock.com wrote:
 Drupal 7 has been addressing :-P these issues with an
addressfield module
 ( http://drupal.org/project/addressfield ), which aims to
incorporate the
 flexibility of xNAL - http://xml.coverpages.org/xnal.html .

Interesting idea.  I am all for incorporating work of others into
LedgerSMB.  However, I am not sure how this would be done since I
doubt our invoices, check printing, etc. will ever move off TT/LaTeX.
it seems to me we'd have to find out what they are doing regarding
address formats and convert these into TT snippets to be used.


Chris and I evaluated xNAL this afternoon and while it seems to be a 
very good tool to help design a schema for storing names and 
addresses, it doesn't seem to concern itself with actual 
representation of address data.


Some of the links enumerated by Havard elsethread do do that. Going 
over the examples provided by BitBoost.com, we've come up with the 
following solution:


We think about creating a default address template and adding the 
option to add a template per country.


When producing an address, the template (either the default or the 
country specific one) would be processed by template toolkit to fill 
out name, street, etc. Then the result will be post-processed to 
remove any white-space-only lines from the output.


The end result being an opaque array of lines to be printed on an 
envelope, invoice or other document -- without the need to build the 
same intelligence into every template.


Would this be a suitable solution to most situations you can imagine 
using LedgerSMB?



Bye,

Erik.
!DSPAM:4fa81801314441714917295!


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed

Re: [Ledger-smb-devel] Address formatting functionality

[John Locke]

Hi,

On 05/07/2012 06:10 PM, Chris Travers wrote:

Hi;

Structure is an important problem with addresses generally.  We think 
of addresses as being structured and they are, but they aren't 
structured the same way everywhere.  Consider the Nicaraguan 
addressing system, for example, where you have no street names and 
instead reference places relative to landmarks and directions (and 
some directions are location-dependent, like El Calvario 1c al lago 
1/2c Abajo (i..e start at El Calvario, go one block towards the lake, 
and 1/2 block down, i.e. West).  Also in Ecuador you have cross 
streets (1889 Manosca #105 y Occidental, Occidental here is the 
nearest cross-street) as a part of a well-formed address.


(I wasn't sure about the Nicaraguan address problem until I checked 
web sites of restaurants in Nicaragua for their addresses.  See the 
address at the bottom of http://www.restaurantedoncandido.com/).


In general these pose problems as I see it.  The simple way to address 
this is just to put the whole address in a text field except for the 
country.  Of course if you do this it becomes hard to do reporting on 
this by post code or city, or province/state.


This is part of the reason why we adopted the idea of three free-form 
lines along with city, province, post-code, and country.  As I 
understand it xNAL allows this sort of structure, and I'd prefer to 
keep it simple (take a look at some of the examples).


Of course these areas are not ordered the same way in different places 
so I think the key question is on formatting of the fields we use at 
this point.



http://drupalcode.org/project/addressfield.git/blob/refs/heads/7.x-1.x:/plugins/format/address.inc

... That's how Drupal's addressfield is handling it. Looks like really 
only 2 free-form lines, stored as thoroughfare and premise, and then 
city, state, postal code, country stored in fairly consistent fields.


Addressfield is starting with a default layout, and then for a 
particular list of countries, changing the sequence and/or hiding postal 
code, city, state to match local conventions.


I'm sure that's not a complete list of particular country exceptions, 
but it looks like they're just doing a brute-force rearrangement/hiding 
of fields based on the local specifics that have been reported... And 
seems like a great place to start for LSMB...


Hmm. I also see an example module for extending the validation, with a 
complete city/canton/postal code validation routine for Switzerland...


Cheers,
John Locke
http://www.freelock.com

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Address formatting functionality

[John Locke]

Drupal 7 has been addressing :-P these issues with an addressfield 
module ( http://drupal.org/project/addressfield ), which aims to 
incorporate the flexibility of xNAL - http://xml.coverpages.org/xnal.html .



The challenge for xNAL is to provide the ability to handle the following:
- About 36+ customer name formats
- Addresses of 241+ Countries
- About 130+ Address Formats
- Represented in 5,000+ languages (dialects)
- Should be application independent, ie., capable of being used for a variety of
   applications ranging from simple user profiling to name and address parsing, 
matching,
   validation and postal services
- Should be Platform independent
- Should be open, and
- Should be vendor neutral.



Might as well incorporate the discovery done by others!

I haven't looked into how Addressfield stores its data -- it does have 
to deal with similar location issues for tax jurisdiction as LSMB, and 
Drupal obviously uses a relational database instead of an XML object 
database, so I'd say it's worth seeing how they modeled this problem...


Cheers,
John


On 05/06/2012 08:04 PM, Chris Travers wrote:

What about putting this template fragment in the country table?

Best Wishes,
Chris Travers

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

!DSPAM:4fa73bf0314442135420002!



--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Tentative Schedule for 1.4

[John Locke]

On 02/24/2012 05:44 PM, Chris Travers wrote:




Ideally web services, like reporting, would happen after the main
transactional functionality is stable enough for early beta testing.


I think the first step is getting a framework in place that
defines the endpoints, the formatting of the data, etc. Something
that converts a web service payload into some sort of Perl object
that can be populated based on LSMB data.


So maybe a script which:
1)  Converts XML and JSON into a $request object
2)  Converts a $request object to XML or JSON
3)  Hands off to web service modules for URL parsing and work

I am thinking those web service modules would all accept three 
arguments: $request, $url, $method



When I've done this before I've set it up slightly differently:

1. Deserialize request into some standard data structure ($request 
object) with headers, hash of data passed/deserialized request body, path
2. Main controller parses URL and uses conventions to load controller 
for a specific request, creates an appropriate response object based on 
request
3. Main controller calls standard method (determined by HTTP 
method/specific parameters) on the controller object with $request and 
$response object
4. Specific controllers load up native DB objects, populate with 
incoming data, call methods appropriate to actions, and populates 
$response object

5. Main controller returns serialized $response object

I'd say the main difference is taking the standard centralized stuff one 
step further than you've outlined, doing the URL parsing and 
establishing conventions before handing off to individual web service 
controllers.


I've also found it useful to have separate request and response objects, 
though at the moment I don't recall why. And of course have a different 
class for each type of response and request -- XML, JSON, HTML, etc. -- 
that implement standard methods that the framework can call regardless 
of type.



I am also thinking the stuff we are doing with Moose will make this 
better in the long-run.  We can use the defined data structures there 
as both the documented API and the basis for XML and JSON formats.


Excellent. Is this going to be available in 1.4?

Cheers,
John Locke
http://www.freelock.com

--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Tentative Schedule for 1.4

[John Locke]

Hi, Chris,

Sounds good! Notes/questions below...

On 02/23/2012 12:00 AM, Chris Travers wrote:
 Hi all;

 I am finishing up what is probably the last of the major 
 backwards-compatibility-breaking features for 1.4, which is the 
 rewrite of projects and departments.  I expect to have trunk in a 
 usable (for testing) state within another week.

 After that I expect to be working on payroll framework and refactoring 
 the contact management.  I hope to have these fully working on 1.4 by 
 the end of March.  After that point, all manual transaction-entry 
 parts of the web application should be ready for testing, and my work 
 will shift to reporting and CSV imports.


Really looking forward to the payroll framework, that's going to be a 
huge win for us.

Is anybody working on the web services infrastructure we discussed a 
while back? That's the other big thing we're interested in.

 I think we can consider 1.4 to be in early beta, but not 
 feature-complete at the time these areas are complete.  Reporting and 
 import logic can be worked on concurrent to testing of transaction entry.

Are you running any of your production customers on trunk/1.4? We're 
definitely tracking the 1.3 branch still, but if the core financial 
logic should stay sound, and there's work being done on web services and 
payroll in 1.4, I'd be willing to switch us over when you hit that early 
beta milestone and be an early tester again.

I would like to make some UI improvements using Dojo Toolkit, but this 
will be so much easier to do when there's a web services back end.

 I would like to hit feature freeze around the beginning of June, with 
 betas at that point being released every two weeks.  I think that if 
 things go well, we can shoot for a general release in September.

 What do people think?

I think it sounds great! Thanks for all your hard work on this.

Cheers,
John Locke
http://www.freelock.com


--
Virtualization  Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing 
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.3: 1099 reports?

[John Locke]

Attached...

I can find the item in the menu, and I can create a report -- which is
just a label and a country and a checkbox for making it default. But no
data shows up, and I don't understand what the checkbox is for or how to
get data into this report.

Also, on the menu_friendly view, when I first connected to the db as my
user account, it gave me ERROR:  permission denied for relation
menu_friendly

... used the postgres user to get the attached dump.

Cheers,
John

On 12/30/2011 01:11 AM, Chris Travers wrote:
 Can you attach a dump of what's in the menu_friendly view?

 Best Wishes,
 Chris Travers

 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual 
 desktops for less than the cost of PCs and save 60% on VDI infrastructure 
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4efd805377298169417424!


 level |   path| list_order |  label   | id  | 
position 
---+---++--+-+--
 0 | 0 |  1 | Top-level|   0 |  
  0
 1 | 0,1   |  2 |   AR |   1 |  
  1
 2 | 0,1,2 |  3 | Add Transaction  |   2 |  
  1
 2 | 0,1,198   |  4 | AR Voucher   | 198 |  
  2
 2 | 0,1,3 |  5 | Sales Invoice|   3 |  
  3
 2 | 0,1,194   |  6 | Credit Note  | 194 |  
  4
 2 | 0,1,195   |  7 | Credit Invoice   | 195 |  
  5
 2 | 0,1,4 |  8 | Reports  |   4 |  
  6
 3 | 0,1,4,5   |  9 |   Transactions   |   5 |  
  1
 3 | 0,1,4,6   | 10 |   Outstanding|   6 |  
  2
 3 | 0,1,4,7   | 11 |   AR Aging   |   7 |  
  3
 3 | 0,1,4,9   | 12 |   Taxable Sales  |   9 |  
  4
 3 | 0,1,4,10  | 13 |   Non-Taxable|  10 |  
  5
 2 | 0,1,11| 14 | Customers|  11 |  
  7
 3 | 0,1,11,12 | 15 |   Add Customer   |  12 |  
  1
 3 | 0,1,11,13 | 16 |   Reports|  13 |  
  2
 4 | 0,1,11,13,14  | 17 | Search   |  14 |  
  1
 4 | 0,1,11,13,15  | 18 | History  |  15 |  
  2
 1 | 0,16  | 19 |   Point of Sale  |  16 |  
  2
 2 | 0,16,17   | 20 | Sale |  17 |  
  1
 2 | 0,16,18   | 21 | Open |  18 |  
  2
 2 | 0,16,19   | 22 | Receipts |  19 |  
  3
 2 | 0,16,20   | 23 | Close Till   |  20 |  
  4
 1 | 0,21  | 24 |   AP |  21 |  
  3
 2 | 0,21,22   | 25 | Add Transaction  |  22 |  
  1
 2 | 0,21,199  | 26 | AP Voucher   | 199 |  
  2
 2 | 0,21,23   | 27 | Vendor Invoice   |  23 |  
  3
 2 | 0,21,196  | 28 | Debit Note   | 196 |  
  4
 2 | 0,21,197  | 29 | Debit Invoice| 197 |  
  5
 2 | 0,21,24   | 30 | Reports  |  24 |  
  6
 3 | 0,21,24,25| 31 |   Transactions   |  25 |  
  1
 3 | 0,21,24,26| 32 |   Outstanding|  26 |  
  2
 3 | 0,21,24,27| 33 |   AP Aging   |  27 |  
  3
 3 | 0,21,24,28| 34 |   Taxable|  28 |  
  4
 3 | 0,21,24,29| 35 |   Non-taxable|  29 |  
  5
 2 | 0,21,30   | 36 | Vendors  |  30 |  
  7
 3 | 0,21,30,31| 37 |   Add Vendor |  31 |  
  1
 3 | 0,21,30,32| 38 |   Reports|  32 |  
  2
 4 | 0,21,30,32,33 | 39 | Search   |  33 |  
  1
 4 | 0,21,30,32,34 | 40 | History  |  34 |  
  2
 1 | 0,35  | 41 |   Cash   |  35 |  
  4
 2 | 0,35,36   | 42 | Receipt  |  36 |  

Re: [Ledger-smb-devel] 1.3: Check printing?

[John Locke]

Hi, Erik,

I use Cash - Vouchers - Payments, create a batch, and then print
checks from the outstanding AP transactions.

Cheers,
John

On 12/29/2011 03:32 PM, Erik Huelsmann wrote:
 Hi,

 This evening, I spent about a few hours looking for how to print
 checks in 1.3... I found how to print Packing lists, work orders, pick
 lists and a few others, but no checks.

 Could someone provide me with a pointer, please?


 Thanks!


 Bye,


 Erik.

 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual 
 desktops for less than the cost of PCs and save 60% on VDI infrastructure 
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4efcf8a477291937411187!



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.3: 1099 reports?

[John Locke]

My turn: I keep seeing svn updates for 1099 reports, but cannot find
those anywhere in the system. How do I generate 1099 reports?

On 12/29/2011 09:14 PM, John Locke wrote:
 Hi, Erik,

 I use Cash - Vouchers - Payments, create a batch, and then print
 checks from the outstanding AP transactions.

 Cheers,
 John

 On 12/29/2011 03:32 PM, Erik Huelsmann wrote:
 Hi,

 This evening, I spent about a few hours looking for how to print
 checks in 1.3... I found how to print Packing lists, work orders, pick
 lists and a few others, but no checks.

 Could someone provide me with a pointer, please?


 Thanks!


 Bye,


 Erik.

 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual 
 desktops for less than the cost of PCs and save 60% on VDI infrastructure 
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4efcf8a477291937411187!



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] 1.3: 1099 reports?

[John Locke]

Not seeing anything here... Maybe I'm dense, but I'm finding the whole
tax form thing really confusing. I do see checkboxes on line items on AP
transactions, but...

What is a Tax Form in LSMB? How does it relate to a tax? How do I get
numbers to show up on a tax form report?

On 12/29/2011 09:27 PM, Chris Travers wrote:
 On Thu, Dec 29, 2011 at 9:18 PM, John Locke m...@freelock.com wrote:
 My turn: I keep seeing svn updates for 1099 reports, but cannot find
 those anywhere in the system. How do I generate 1099 reports?
 Tax Forms/Reports

 Best Wishes,
 Chris Travers

 --
 Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
 infrastructure or vast IT resources to deliver seamless, secure access to
 virtual desktops. With this all-in-one solution, easily deploy virtual 
 desktops for less than the cost of PCs and save 60% on VDI infrastructure 
 costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4efd4bdb77297732316406!



--
Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex
infrastructure or vast IT resources to deliver seamless, secure access to
virtual desktops. With this all-in-one solution, easily deploy virtual 
desktops for less than the cost of PCs and save 60% on VDI infrastructure 
costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] The Great Licensing Discussion

[John Locke]

Personally I prefer GPLv2 over GPLv3. I'm somewhat agnostic about GPL vs
BSD -- I do like GPL v2 a lot, and like its mechanism for protecting end
customers -- but I also work on some BSD-licensed projects and have no
qualms about a license switch.

I would agree with your assessment, Chris, about derivative works -- if
you're extending a class, then yes, that would be derivative and need to
carry the GPL, but just talking to an API doesn't count in my book. And
there's lots of cases of web services sample code being released under
entirely different licenses than the code behind the interfaces they
talk to -- both commercial and proprietary. So I think it's entirely
appropriate to create code samples and release them under the BSD license.

I do think it would be confusing for end users to have to deal with
multiple licenses within the code base, though. I think that having
parts of LSMB under GPL with other parts under BSD and the collection
under GPL -- that's way too confusing to have to explain to anybody.

This makes me think that the only reasonable way forward for the project
as a whole is under the GPL. It's fine to release client API libraries
and samples under BSD, but I don't see how you change the license of
anything in the core project without a huge amount of turmoil.


I would think that if that's a direction you would want to go, I would
suggest setting up a foundation to control the copyright of the code,
and have all contributors sign a contributors licensing agreement that
assigns the right to offer additional/changed licensing terms to the
foundation. This way it would at least be possible, when all the legacy
code is no longer in the project. But it strikes me that one reason to
go BSD is to avoid the need for doing a foundation ;-)

Some of my thoughts on the matter, anyway...

Cheers,
John



On 12/20/2011 01:32 PM, Chris Travers wrote:
 On Tue, Dec 20, 2011 at 9:03 AM, John Hasler jhas...@newsguy.com wrote:
 I'm not a current contributor but as user and potential contributor I'd
 prefer to see the project stay with GPLv2 and away from GPLv3.  BSD is
 ok but I prefer GPLv2 (or LGPL, or GPLv2 with stated exceptions).  IMHO
 GPLv3 is overreaching (it's patent clauses may constitute copyright
 abuse), unduly restrictive, overly complex, and nearly incomprehensible.
 That more or less sums up my view of the GPL v3.  I would also say
 there are a few areas of the GPL v3 I *really* don't like.  These
 include the forced compatibility with the AGPL v3 (section 13).  I
 also dislike Section 7 paragraph 2 (removal of additional permissions
 by non-copyright holders).

 Best Wishes,
 Chris Travers

 --
 Write once. Port to many.
 Get the SDK and tools to simplify cross-platform app development. Create 
 new or port existing apps to sell to consumers worldwide. Explore the 
 Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
 http://p.sf.net/sfu/intel-appdev
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4ef0feeb77291303490587!



--
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Web Services API: URL naming proposal

[John Locke]

 for the added complexity of requiring state handling and cookies.
 Well, yes, it is contrary to REST ideals -- but there's definitely room
 in REST for actions as well as resources. And I was thinking while
 writing this up about what might be an effective way of supporting
 transactions -- complete with begin transaction, commit, and rollback posts.
 I don't see any sane way of handling database transaction controls
 over HTTP.  I think any attempt to do so would significantly reduce
 the robustness of the controls on the server for anyone accessing the
 database.

 However if the same API can be encapsulated over XMPP, then the
 problem goes away entirely and now you can be sure of the state enough
 to expose transaction controls safely.

Yes, I'd just suggest looking at Node.js/Socket.io as an alternative to
XMPP...

 I'm not entirely opposed to putting the company in the URL -- it's
 certainly a viable approach. However, given the complex structure of
 entity/eca/customer objects alone, having the ability to wrap that in a
 transaction might be desirable...
 I dont see how you can possibly have a database transaction safely
 exist across multiple HTTP requests, hence my suggestion to explore
 XMPP for these areas.

Agreed, wasn't thinking this through.

snip
  Yes, I suggest doing both -- returning the whole object as rewritten by
  the server, as well as adding a header to the final URL.

 I like the idea of returning the whole object.

 I am thinking through the security, and I think we'll have to have
 some way of authenticating clients as well as users.  I don't see
 another way around xsrf issues that doesn't break a web services
 model.  Amazon Web Services does this with a preshared key approach.
 I would personally prefer client-side certificates with a configurable
 CN root, and ban use of any of these same certs in the web app.

That's essentially what OAuth is about. It does work at a client
application level, not a client instance level. I don't think it uses
certificates/PKI -- I think it's still a pre-shared key approach -- but
I think that's better in this case, forces the admin to specifically add
approved apps.

By leveraging OAuth, client apps can use existing libraries and
practices and not have to learn something specific to us, or deploy a PKI...

Cheers,
John Locke
http://www.freelock.com

--
All the data continuously generated in your IT infrastructure 
contains a definitive record of customers, application performance, 
security threats, fraudulent activity, and more. Splunk takes this 
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Web Services API: URL naming proposal

[John Locke]

One other thing to clarify:

I am thinking of a rich web application client here, in addition to
whatever other remote applications might get adapted to it. As you say,
Chris, web applications using only HTTP have some serious limitations.
But with the rich Javascript frameworks we have available, and
technologies like Node and XMPP for long-running connections that can
maintain state, it's conceivable to build a much better browser-based
application.

That's definitely something I'm always thinking of, in the back of my
mind, which makes me favor JSON, REST, Node.js, OAuth, and other web
technologies -- these are all things that can be consumed by Javascript
running in a web browser fairly easily.

Trying to access Postgres directly, managing client certificates, doing
SOAP, and even XMPP are quite a bit harder.

By making the current web application an early client of the web
service, it's possible to have that be the degraded version while
allowing multiple, competing, richer web applications to coexist.

Cheers,
John


On 11/21/2011 08:42 AM, John Locke wrote:
 Hi,

 On 11/21/2011 03:03 AM, Chris Travers wrote:
 First some general notes.

 One of the real headaches in web app programming is state handling.
 With a thick client, what you do is you open a connection, perform
 your operations, commit your changes, etc. and then close the
 connection when you log off.  With a web application, a single atomic
 unit of work may span several network connections. As a result a lot
 of things may have to be tracked in this way, and in some of our
 workloads, a large majority of database processing time is actually
 spent managing the application state. A lot of this time could be cut
 out if we didn't have to make sure that this information persisted
 when the database connection was closed and a new one opened.
 Hmm. I'm not thinking we need a huge amount of state here -- mostly we
 are assembling resources that will be posted into the system, or doing
 queries.

 I will give you an example.  One of my customers pays a large number
 of invoices per week.  I would say probably as many as 5000 invoices
 may be paid in a single batch payment workflow.  I have good
 information on the profiling of the web app as to where time is spent.
  The basic selection takes only a couple of seconds (2-3), but once we
 add in the necessity to track that someone has selected these, we end
 up with about 45-50 sec of database time in the actual selection for
 payment.  The XHTML document generation in some cases takes another
 couple of minutes.  We can't use cursors to page through results
 because the cursors can't survive the connection teardown process.
 Consequently there is very limited performance tuning possible at
 present.
 Ah, yes, I wasn't thinking through the transaction handling over
 multiple requests.

 If we skip doing transactions for more than single request actions (like
 using the shipping field to partially ship an order and generate an
 invoice), then I don't think we get into that much trouble.

 Drupal does provide a batch API, which can be used to iterate through
 large result sets while performing some action. For the user interface,
 it puts up a Javascript widget that makes repeated calls, each of which
 processes a configurable number of items (generally 50 or so) and then
 updates its progress bar. For calls from script, you typically process
 the first batch and then leave the rest of the processing to a cron job
 that processes a batch at a time. One approach to bulk operations...
 Now, if this wasn't over HTTP, we could make the application far more
 responsive, and lead to better productivity, but as it is, we are
 fairly limited.  This is one reason why I see the database-level API
 as such a big deal.  It allows one to tune performance by removing the
 limitations of HTTP in this regard.

 If we can do it, I would much prefer to confine these problems to the
 web application than I would to export them to every other application
 that might interface to LedgerSMB.   I would therefore suggest that
 running LedgerSMB over HTTP is a bit kludgy, and that long-term I
 would like to see the web app be secondary to a desktop app directly
 connecting to the database in most environments.
 Have you looked at node.js?
 snip

 One thing to keep in mind is that the db-level interface has taken a
 lot of inspiration from things I think SOAP and friends do well
 (discoverability, etc).  Additionally you can do things which are
 (IMNSHO opinion) insane to try to do over HTTP, like control over
 database transactions.
 Discoverability is the one aspect of SOAP I like...
 That is what I hate most about SOAP -- having to do multiple calls and
 manage state. But to a certain extent, it seems unavoidable.
 Ever looked at SOAP over XMPP?  For that matter although it would no
 longer be RESTful, I don't see any reason why RESTful approaches
 couldn't get encapsulated in XML stanzas and sent over XMPP.  XMPP

Re: [Ledger-smb-devel] Web Services API: URL naming proposal

[John Locke]

Hi,

On 11/20/2011 04:24 PM, Chris Travers wrote:
 I think John's points here raise some important questions I'd like to
 raise here for further discussion:

 On Sun, Nov 20, 2011 at 9:30 AM, John Locke m...@freelock.com wrote:
 On authentication, yes we can use http auth headers, but do we want to
 explicitly require a session token, too? We're starting to delve into
 OAuth -- which adds a layer of complexity but also can take away the
 need for the remote system to collect the password at all. This seems
 like a good option to support.
 A couple questions:
 1)  For an API aimed at other applications, why have a session token?
 What does it buy us?  In the main application we use a session token
 to enforce a full round trip in some cases (XSRF prevention), and to
 handle discretionary locking in long workflows (actually more
 properly, timing out of such locks).  Neither of those general
 requirements apply to a job from an OS Commerce installation which is
 feeding sales orders into LedgerSMB.

Well, think mobile app for a minute, or desktop app. There may well be
many cases where you want round trip, transaction handling, and
anti-XSRF (or at least anti-replay) prevention.

That is what I hate most about SOAP -- having to do multiple calls and
manage state. But to a certain extent, it seems unavoidable.

It's probably not a big deal to make a remote application pass the
company in the URL (instead of in a login session), but slightly easier
I would think to omit (in client implementation), to simply pass in with
authentication.

In many ways, the web application front end is a model for other
applications that might call the web service -- ideally everything in
the web application should be reflected in the web service.

In my experience, most web services still do make use of session
handling, it's not at all an uncommon approach.

 2)  How does OAuth affect our ability to pass through credentials to
 the database?  Or would a web services handle have to do its own
 authentication?
I haven't done this in detail yet, but my understanding is that the
client application must register with the web service, and the user then
authenticates directly with the web application out of band, with the
client application token.

Probably more complex than necessary for most installations. But we
should make it possible to plug in this type of authentication, should
somebody care to implement.

Oh yeah, forgot that we use these credentials directly to access the
database. Yeah, that would probably necessitate the actual credentials
being stored in the session -- not ideal.


 3)  Does the added complexity make sense with general use cases?  I am
 assuming we are primarily interested in a web services API for
 server-server integration since a piece of software used primarily by
 the end user would be more likely to just call the db-level API (which
 would provide greater control over db transactions, and the like than
 one would get from a web services interface)?

Well, server-to-server is certainly the first step. And easiest to adapt
to just about any interface we develop. But today we're doing most web
services for iOS or Android apps. Think about the POS or an inventory
module being available as an app for an Android phone.

The recent thread by a Google engineer praising Amazon for making
everything an API applies here. If you haven't read it:
https://plus.google.com/112678702228711889851/posts/eVeouesvaVX


 2. Since companies are separate databases, where do we put the name of
 the company in the URL? prefix/store.pl/company/etc...?

 What do you think of the above proposal?
 I suggest we include the company in the body of the login, and then it's
 represented in the session cookie. If an external application needs to
 work with multiple companies, it can manage multiple session ids.
 This is contrary to REST ideals, correct?  Not that departures from
 that are necessarily out, but I would prefer to see some justification
 for the added complexity of requiring state handling and cookies.

Well, yes, it is contrary to REST ideals -- but there's definitely room
in REST for actions as well as resources. And I was thinking while
writing this up about what might be an effective way of supporting
transactions -- complete with begin transaction, commit, and rollback posts.

I'm not entirely opposed to putting the company in the URL -- it's
certainly a viable approach. However, given the complex structure of
entity/eca/customer objects alone, having the ability to wrap that in a
transaction might be desirable...

And I think leveraging the current session handling in the app can
reduce opening up new security vulnerabilities. Not suggesting we build
anything new for this, just use what we've already got.

 Also I suspect (though I will defer to others here) that debugging an
 incorrect company name may be easier if that shows up in the url in
 the access logs.

This could easily be printed in a debug log

[Ledger-smb-devel] Proposal: Web Services API

[John Locke]

Hi,

Erik and I were just chatting on IRC about web services. I recently
updated our in-house management system to generate new invoices in LSMB,
and it's a pain in the butt to do -- the current process looks like this:

1. Hit the Login page with username/pw, store session cookie
2. Post some minimal detail to is.pl - customer name/entity_credit_id,
part numbers/qty, action=update
3. Parse the response, scrape all the form fields out and merge their
values with the items we want to post -- and in 1.3 make sure to update
form_id to get past the anti-csrf protection
4. Post the resulting data to is.pl with action=post

... and then if we want to also send an email, essentially repeat the
last couple steps to send the email out to the billing address.

It sounds like adding a good web service api would help this project for
at least a few of us -- but probably help get far more wide-spread
adoption.

At Freelock, we do a substantial amount of web services work, both
creating servers and consuming them as clients. I've come to really
favor REST-based, resource-oriented APIs that use HTTP verbs to mean
something. I'd like to propose building a REST interface that can
interact with the data on the server.

Is this something that Moose will get us without much work?

If not, I'd be happy to contribute code to serve this purpose, if I can
find somebody to sponsor the work. And I'll definitely provide feedback
if anyone wants to take this on themselves.


What I'd like to see is basically an API that has a specific URI for
each resource. For example, an invoice #456 might be referenced at:

http://myledgeraddress.com/store/invoice/456

A simple GET on that address would check for authorized access, and then
retrieve the invoice in a form requested by the client. I generally set
up services to accept a content-type header to specify xml, json, html,
csv, etc -- and allow it to be overridden by a parameter in the query
string.

A PUT on that address with an updated object in the body would update
the object, again based on authorization. (I'm thinking to add payment
to an invoice).

A DELETE on that address would delete (almost certainly dis-allowed on
this type of object).

POST is used to create new objects, or do particular data-changing
actions on an object or in the system.

GET would also accept a variety of parameters, providing a built-in
search to get a collection of objects --

GET http://myledgeraddress.com/store/invoice/?eca_id=334open=any
GET
http://myledgeraddress.com/store/customer/?start_date=2011-01-01start_date_oper=gt


For implementation, this should be pretty easy to provide some sort of
request handler and load up the new objects that Chris has created, do
the appropriate changes, and save. The old code is obviously much harder.

Perhaps we can start with the new entities, customers and vendors that
have already been done, and add more of the accounting objects as they
get rewritten?

Cheers,
John Locke
http://www.freelock.com


--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learning@Cisco Self-Assessment and learn 
about Cisco certifications, training, and career opportunities. 
http://p.sf.net/sfu/cisco-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposed framework changes for 1.4

[John Locke]

Hi,

Sounds like a good direction to me. Couple thoughts -- not being that
active in Perl, don't know if these are realistic or not, but just what
comes to mind, feel free to disregard.

- Are there really no other date or number libraries available that do
what we need, to the point we need to create our own? (or are these
primarily wrappers around something else?)

- Ran across this project recently: http://ledger-cli.org/ - a Perl cli
app that does double-entry accounting in text files. I wonder if they've
worked out some good accounting logic we can use, at a minimum -- or
perhaps incorporate into LSMB? I'm thinking with a little collaboration,
ledger-cli might be extended to use LSMB as back end storage, while LSMB
might potentially leverage the work already done in ledger? Have not
looked at the code, have no idea whether this is practical. But an
easier CLI interface sounds very useful, if it's not too much of a
stretch. And might be a good gateway to new users...

- Regarding extensions, I just had to do some upgrades to some other web
apps where customizations and extension code was scattered across a
bunch of libraries. Basically an MVC organization -- but all extension
code had to be split up, with the M in the M, the V in the V, and the C
in the C directories I just want to express my extreme distaste for
that file organization, from an ongoing maintenance point of view. Using
a framework for development is great, as long as we can set it up in a
way so that if I want to add some sort of custom module to the site, I
can put all the code for it in one directory.

Extending that last point a bit -- might it be possible to re-organize
the core modules this way, to provide good examples? Instead of having a
stub in the root, a file in scripts, the class in LedgerSMB, etc --
might it be possible to have a modules directory with each module in
it's own subdirectory? modules/AR, modules/AP, modules/HR, etc. And then
inside those, if necessary, mirror the rest of the file structure for
MVC -- modules/AR/scripts, modules/AR/LedgerSMB, modules/AR/UI, etc?

And to take it one step further, what Drupal has done brilliantly is
provided an override mechanism -- if you want to override a core module,
you can simply copy it to a place that gets checked first, then hack
away, leaving the original code intact. Then an upgrade won't clobber
your customizations, and you can much more easily do a simple diff to
see what's changed. LSMB doesn't need to have the multiple paths that
Drupal uses (I don't think) but maybe something as simple as a path
that's checked first for a module - local/ comes to mind. You wanna hack
AR? Copy modules/AR to local/AR and go to it.


Cheers,
John

On 10/18/2011 04:49 AM, Chris Travers wrote:
 Hi all;

 INTRODUCTION:
 
 Looking towards 1.4 and trying to improve things significantly from
 where they are on 1.3.  In general, I'd hope that with each new
 version, these changes become more incremental (and smaller) until we
 are ready to start on 2.0.  The goals of these proposals are as
 follows:

 1)  To future-proof the LedgerSMB architecture, trying to standardize
 on something solid, building on what works well with the 1.3 codebase
 and addressing shortcomings that come up in relation to the directions
 we have been going.

 2)  To address specific issues we will run into in the areas we are
 re-engineering in 1.4 and later.

 3)  To better support a variety of architectures, such as mod_perl,
 going forward.

 All changes in this document are backwards compatible, so unless
 otherwise noted we don't have to rewrite code specifically because of
 this document though we will rewrite for other reasons through the 1.x
 process.

 WHAT 1.3 DOES WELL
 ==

 1.3 is a substantial accomplishment.  We've added real security to an
 inherited codebase, and we've added impressive capabilities at the
 same time, and without serious bugs post-1.3.0 release in the core
 functions (those which most users use).  Major reasons for the
 successes include:

 1)  A focus on declarative logic in the database, both for permissions
 and for data constraints
 2)  A clear separation of presentation and data logic.  The database
 procedures handle data logic and the presentation is handled by Perl
 and TT.

 SHORTCOMINGS OF 1.3
 
 The code during the 1.3 development process evolved quite a bit as
 maintainability issues were uncovered and addressed and coding styles
 evolved.  This makes 1.3 a bit of a mishmash of coding paradigms and
 we can expect some maintenance headaches as a result.  Longer-run we
 need more standardization in particular, and coding practices that are
 more conducive to writing great documentation.  This should make it
 easier for people to follow new code and contribute.

 In particular some of the early 1.3 code is relatively unstructured,
 and classes don't have specific properties associated.  This makes the
 code impossible to 

Re: [Ledger-smb-devel] Budget add-on

[John Locke]

Excellent. Where would I find it?

I would think the Reports section might be appropriate... that's where I
go for Income/Expense and Balance Sheet, seems like a similar
strategic/business function...

Cheers,
John

On 10/17/2011 03:42 AM, Chris Travers wrote:
 Hi;

 For those who are wondering, the budget add-on now is minimally
 feature complete.  I'd still like to add notes attachments soon, and I
 haven't set up the menu yet.

 Any idea where the budget menu should go?

 Best Wishes,
 Chris Travers
 !DSPAM:4e9c06d687861139619436!


 --
 All the data continuously generated in your IT infrastructure contains a
 definitive record of customers, application performance, security
 threats, fraudulent activity and more. Splunk takes this data and makes
 sense of it. Business sense. IT sense. Common sense.
 http://p.sf.net/sfu/splunk-d2d-oct

 !DSPAM:4e9c06d687861139619436!


 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


 !DSPAM:4e9c06d687861139619436!

--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2d-oct___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposed financial schema for financial info

[John Locke]

I think the PO should be on the invoice header. In our scenario, we get
a PO for a project, drop it into the Sales order, and have multiple
invoices on that PO.

Having the PO in a specified field makes it easier for our customers to
find on the invoice when they go to pay it, and also for us to show on a
report/search for invoices associated with a PO.

If we have multiple POs, we can always do multiple invoices -- these are
probably associated with different contacts at a customer, anyway.

What Erik describes is the same as our workflow, for our larger customers...

Cheers,
John


On 10/07/2011 01:22 PM, Chris Travers wrote:
 On Fri, Oct 7, 2011 at 1:16 PM, Erik Huelsmann ehu...@gmail.com wrote:
 Hi Chris,

 In the schema you sent, you write that you intend to use one of the
 new links in the invoice table to get the PONumber field as it is
 currently available in the AR table. The links you're referring to are
 the previous document (sales order, sales request, etc) links. Let
 me describe my use-case where I think this linking system won't work
 for me.

 (Note that I'm involved in multiple businesses; the use-case below is
 a use-case from my self-employment. I'm not currently using LSMB to
 create invoices for that business, but I'm using the requirements as a
 showcase.)

 Because I have relatively few contracts (8 or 10 per year) in my
 self-employment business, I'm not creating sales orders for these
 contracts. I'm just creating the invoices directly, using my hours
 registrations and whatever additional requirements my customers have.

 One of my customers requires me to use *their* PO number to be on the
 invoice. They use it to link the digital and physical information
 flows: the physical invoice never actually reaches my contacts -
 instead it's being processed by a central processing office. Without
 that number, they can't link the invoice to the right file. Without
 that number, I won't be paid.
 Ok, so question for everyone:  Should the PO number field be on the
 header or the invoice line item?  I am thinking for now just to add it
 to the header (since that is the way it's done right now) because it
 is easier to go the to the other from here if we need to.

 But that still does bring up the question:  Should client PO's map at
 most 1:1 to invoices? or should we allow an invoice to invoice
 delivery of goods and services off multiple PO's?  If in doubt, I
 think we should keep the current behavior for now while we evaluate,
 but want to get feedback.

 Best Wishes,
 Chris Travers

 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2dcopy2
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4e8f5fb1202861682214271!



--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2dcopy2
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Proposal for database refactoring in 1.4

[John Locke]

Hi,

Initial thoughts: Sounds like a huge improvement, and it mostly makes
sense to me.

The one area I'm not clear on is inventory management, and whether oe
and order_items should get rolled into the same tables as ar/ap/invoice.

I may be totally off-base here, but I'm thinking that invoices are
different from orders. How do items on an order get converted to items
on an order? Is there going to mainly be some sort of type column on
these tables to split it out? Might it be better to keep the order
management separate from the invoicing, if invoices represent legal
documents?

I'm not saying this is the way it should go -- I'm just asking the
question why should these be in the same table? instead of copying
these items to equivalent invoice tables at the time of invoice --
basically keep all the invoice stuff separate from the order stuff.

What you're describing makes sense to me if an order basically IS an
invoice, just at an earlier phase of the lifecycle. But it strikes me
that if you're partially shipping an order and splitting it into
multiple invoices, that might get messier/harder to figure out what
happened than if they're treated as two different things.


Definitely like the idea of combining ar, ap, and gl and doing away with
transactions. I haven't been through the payment schema/workflow enough
to speak to that.

Cheers,
John

On 10/03/2011 10:25 AM, Chris Travers wrote:
 Hi all;

 I would like to go forward with my database refactoring proposal for
 1.4.  This is an outgrowth of two things, Josh Drake's feature request
 that we merge the AR and AP tables and my work on restoring
 referential integrity to the database.  The current problem is that
 acc_trans.trans_id references transactions.id, but transactions as a
 table largely is a proxy for the set of ap.id, ar.id, and gl.id.
 While we have a working solution here, it is more brittle and complex
 than I would like it to be.  So I am working on refactoring the tables
 as follows.  For those who wish to follow the documentation, check out
 the doc/database/ledgersmb.html in your ledgersmb directory.

 The following tables would be replaced:

 acc_trans
 transactions
 payment
 payment_map
 gl
 ar
 ap
 invoice
 oe
 orderitems

 If we can't get to it, we could leave invoice and orderitems out for
 1.4 and address in 1.5

 The new tables would be
 journal_line (replaces acc_trans).  Represents line items.

 journal_type (replaces the table field in transactions).  Gives a
 list of journals for journal entries (sales, purchases, general, etc)

 journal_entry (replaces most of transactions, payment, and gl, as well
 as parts of ar and ap).  Holds basic info about transactions, like
 source number

 payment_map (would work almost the reverse of the current payment_map
 table, mapping the payment journal entry to the appropriate purchase
 entries)

 invoice (replaces ar and ap for customer and invoice-specific info).
 Basically stores due date, customer/vendor links, etc.

 inventory_orders (replaces oe, and also parts of ar and ap as regards
 actual inventory invoices).  This stores container info for
 quotations, orders, and invoices

 inventory_lines.  Replaces invoice and orderitems except for cogs purposes

 inventory_cogs.  Contains info for calculating cogs, so that things
 can be back-tracked to their original transactions.

 This has the impact of:
 1)  Reducing 10 tables into 8
 2)  Allowing enforcement of referential integrity, and reducing the
 number of redundant fields used.
 3)  Better tracking of payments, in particular
 4)  Given that PostgreSQL does allow the creation of constraints on
 subsets, this does not reduce the expressiveness of potential
 constraints.
 5)  Should make for easier reporting.

 Also logically it changes things to the following under the above proposal:
 1)  Every AR and every AP transaction is also a journal entry
 2)  Every payment and every receipt is now a full transaction and journal 
 entry
 3)  COGS calculations can be traced back to see which transactions
 allocated which cogs, allowing for better debugging

 Any feedback before I send a sample database schema?

 Best Wishes,
 Chris Travers

 --
 All the data continuously generated in your IT infrastructure contains a
 definitive record of customers, application performance, security
 threats, fraudulent activity and more. Splunk takes this data and makes
 sense of it. Business sense. IT sense. Common sense.
 http://p.sf.net/sfu/splunk-d2dcopy1
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

 !DSPAM:4e89f01a202861876012615!



--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, 

Re: [Ledger-smb-devel] Proposal for database refactoring in 1.4

[John Locke]

I keep thinking about this, and again, I may be way off base, but I'm
thinking we're missing a historical component here, particularly in orders.

Again, I look to how Drupal addresses this, and for content, this is
done by splitting a node into two tables: node and node_revision. If you
add fields to a content type, these are stored in separate tables with
essentially a fk reference to node_revision.

I'm thinking order and order_revision. Order being a container for
revisions. As items get shipped on an order, you get new revisions, with
a log message, new set of line items, etc.


Invoices may not need this, if they're not supposed to get modified
after creation.



On 10/03/2011 11:22 AM, John Locke wrote:
 Hi,

 Initial thoughts: Sounds like a huge improvement, and it mostly makes
 sense to me.

 The one area I'm not clear on is inventory management, and whether oe
 and order_items should get rolled into the same tables as ar/ap/invoice.

 I may be totally off-base here, but I'm thinking that invoices are
 different from orders. How do items on an order get converted to items
 on an order? Is there going to mainly be some sort of type column on
 these tables to split it out? Might it be better to keep the order
 management separate from the invoicing, if invoices represent legal
 documents?

 I'm not saying this is the way it should go -- I'm just asking the
 question why should these be in the same table? instead of copying
 these items to equivalent invoice tables at the time of invoice --
 basically keep all the invoice stuff separate from the order stuff.

 What you're describing makes sense to me if an order basically IS an
 invoice, just at an earlier phase of the lifecycle. But it strikes me
 that if you're partially shipping an order and splitting it into
 multiple invoices, that might get messier/harder to figure out what
 happened than if they're treated as two different things.


 Definitely like the idea of combining ar, ap, and gl and doing away with
 transactions. I haven't been through the payment schema/workflow enough
 to speak to that.

 Cheers,
 John

 On 10/03/2011 10:25 AM, Chris Travers wrote:
 Hi all;

 I would like to go forward with my database refactoring proposal for
 1.4.  This is an outgrowth of two things, Josh Drake's feature request
 that we merge the AR and AP tables and my work on restoring
 referential integrity to the database.  The current problem is that
 acc_trans.trans_id references transactions.id, but transactions as a
 table largely is a proxy for the set of ap.id, ar.id, and gl.id.
 While we have a working solution here, it is more brittle and complex
 than I would like it to be.  So I am working on refactoring the tables
 as follows.  For those who wish to follow the documentation, check out
 the doc/database/ledgersmb.html in your ledgersmb directory.

 The following tables would be replaced:

 acc_trans
 transactions
 payment
 payment_map
 gl
 ar
 ap
 invoice
 oe
 orderitems

 If we can't get to it, we could leave invoice and orderitems out for
 1.4 and address in 1.5

 The new tables would be
 journal_line (replaces acc_trans).  Represents line items.

 journal_type (replaces the table field in transactions).  Gives a
 list of journals for journal entries (sales, purchases, general, etc)

 journal_entry (replaces most of transactions, payment, and gl, as well
 as parts of ar and ap).  Holds basic info about transactions, like
 source number

 payment_map (would work almost the reverse of the current payment_map
 table, mapping the payment journal entry to the appropriate purchase
 entries)

 invoice (replaces ar and ap for customer and invoice-specific info).
 Basically stores due date, customer/vendor links, etc.

 inventory_orders (replaces oe, and also parts of ar and ap as regards
 actual inventory invoices).  This stores container info for
 quotations, orders, and invoices

 inventory_lines.  Replaces invoice and orderitems except for cogs purposes

 inventory_cogs.  Contains info for calculating cogs, so that things
 can be back-tracked to their original transactions.

 This has the impact of:
 1)  Reducing 10 tables into 8
 2)  Allowing enforcement of referential integrity, and reducing the
 number of redundant fields used.
 3)  Better tracking of payments, in particular
 4)  Given that PostgreSQL does allow the creation of constraints on
 subsets, this does not reduce the expressiveness of potential
 constraints.
 5)  Should make for easier reporting.

 Also logically it changes things to the following under the above proposal:
 1)  Every AR and every AP transaction is also a journal entry
 2)  Every payment and every receipt is now a full transaction and journal 
 entry
 3)  COGS calculations can be traced back to see which transactions
 allocated which cogs, allowing for better debugging

 Any feedback before I send a sample database schema?

 Best Wishes,
 Chris Travers

Re: [Ledger-smb-devel] Database updates

[John Locke]

 want flagged), what would you expect
 such an output to look like that you can't get from a diff on various
 versions of Pg-database?   I mean, what specifically is missing?
 Table names?  Something else?  Or is it a matter of noise from
 comparing dumps?

Looking to solve the following problems with as little pain as possible:

1. Initial database load
2. Update database schema when it's altered
3. Compare installed database schema with the current release/version


#1 works fine now, the upgrade scripts (when they are complete and don't
fail) mostly address #2, but #3 is a pain in the butt. Unless there's
some trick I don't know about?

So I'm proposing that the release contains something like the following,
for managing the database schema:

1. base_schema_list.txt, in a load order that works
2. schema_dump.pl, script that generates #3 from an installed database,
using #1 to specify the dump order
3. base_schema.sql, data schema that can be automatically generated from
#1 and #2
4. base_data.sql, data that only ever gets loaded once, when the company
db is first created
5. modules/loadorder.txt , might as well script the install of functions
while we're at it
6. modules/xxx.sql , individual module stored functions, guaranteed to
be possible to re-run at any time without breaking things, perhaps with
the caveat that roles need to be reloaded
7. modules/dbname_roles.sql , basically what we do now, possibly with
a helper script to assist
8. upgrades/svn-commitlevel-description.sql , manually-built scripts
that alter the database to make running #2 with an updated
release/version generate a file identical to #3 at that commitlevel, as
we're currently doing.


Does that all make sense, or am I missing something/overthinking this?

Cheers,
-- 
John Locke
http://www.freelock.com


--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Database updates

[John Locke]

Hi,


On 07/13/2011 03:15 PM, Chris Travers wrote:
 Ok, two pieces of quick feedback.

 First right now I would highly recommend that if you have to follow
 schema changes you join the ledger-smb-commits list on sourceforge.
 That will help a lot right there.

Well, with git I'm not having any trouble seeing what's changed. What I do:

1. create a tag of my current local branch
2. merge changes from upstream
3. git diff tagname sql/ and get all the schema changes.

Problem is, there have been quite a few! And so I've just been relying
on the upgrade scripts -- but some of these have failed, and I don't
think they're complete.

 Secondly, a tool to compare schemas will be helpful, and I would like
 to create one in the near future.  in the mean time, as a simple
 discussion draft, let me post the following bash code.

 rm ../testdump1.sql ../testdump2.sql
 for line in `grep -i ^create table sql/Pg-database.sql | sed -e
 's/(.*$//' | awk '{ print $3 }'`
 do pg_dump -U postgres -s -t $line database1 | grep -v GRANT |
 grep -v REVOKE  ../testdump1.sql
 done

 for line in `grep -i ^create table sql/Pg-database.sql | sed -e
 's/(.*$//' | awk '{ print $3 }'`
 do pg_dump -U postgres -s -t $line database2 | grep -v GRANT |
 grep -v REVOKE  ../testdump2.sql
 done

 diff ../testdump1.sql ../testdump2.sql

 If this sort of result is found to be acceptable, I could probably
 port the first two parts to Perl pretty easily.  Not sure about diffs
 though.

That sounds like a good start.

I'm thinking, though, that Pg-database.sql is still too big and
monolithic for this -- and the resulting dump file ought to be where you
do the initial schema load, don't you think?

Maybe have a separate file, sort of like an ini file or parsable
loadorder that can identify the type of relation and the name. e.g.

table acc_trans
table account
type _xx_xx
view chart

... etc.

This could then be fed to the dump script, instead of parsing
Pg-database.sql...

Then we can have the tables ordered in a way that will actually load
with foreign keys to tables previously defined, etc.

And as long as that's consistent, then I think diff is fine for now for
seeing what's changed... can just run the dump script, direct the output
to a tmp file, and compare against the one in the code tree.


Cheers,
John Locke
http://www.freelock.com

--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Database updates

[John Locke]

Hi,

Couple issues/thoughts.

1. Errors on upgrade sql
2. Normalize/compare installed schema vs files?



1. Just updating my instance using the upgrade sql files, and got these
errors:


 freelockco=# \i sql/upgrade/3497-schema-changes.sql
 psql:sql/upgrade/3497-schema-changes.sql:1: ERROR:  syntax error at or
 near trans_id
 LINE 1: ALTER TABLE invoice ADD FOREIGN KEY trans_id REFERENCES tran...
 ^
 psql:sql/upgrade/3497-schema-changes.sql:2: ERROR:  syntax error at or
 near parts_id
 LINE 1: ALTER TABLE invoice ADD FOREIGN KEY parts_id REFERENCES part...
 ^
 psql:sql/upgrade/3497-schema-changes.sql:4: ERROR:  syntax error at or
 near chart_id
 LINE 1: ALTER TABLE tax ADD FOREIGN KEY chart_id REFERENCES account(...
 ^
 psql:sql/upgrade/3497-schema-changes.sql:5: ERROR:  syntax error at or
 near ;
 LINE 1: ...IGGER ap_audit_trail AFTER insert or update or delete ON ap;
  ^

... I'm using postgresql 8.3.12, if it makes any difference. I did see
some similar errors a few days ago, when updating trunk from a ~2 week
old version.

Which brings me to part 2:

2. What would be the best way to get a consistent, repeatable, text dump
of the table schema only, along with views, types, and triggers?

I'm thinking back to an earlier discussion about database updates, and
having a shell tool to manage them. I'm thinking we should be able to
dump the structural parts of the database to a single file (e.g.
Pg-database.sql) that we can then easily compare to what's in the code
base. I assume this would mean splitting out the functions and the data
that's currently loaded into Pg-database.sql into separate files -- but
once that's done, it should be trivial to see how close the structure of
your database is to the current release, and what needs to be altered to
get it there. Which would be the first step to auto-generating update
scripts.

Thoughts?

Cheers,
John Locke
http://www.freelock.com



--
AppSumo Presents a FREE Video for the SourceForge Community by Eric 
Ries, the creator of the Lean Startup Methodology on Lean Startup 
Secrets Revealed. This video shows you how to validate your ideas, 
optimize your ideas and identify your business strategy.
http://p.sf.net/sfu/appsumosfdev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Employee search question for 1.3

[John Locke]

On 06/21/2011 04:02 PM, Chris Travers wrote:
 Hi John;

 In terms of the duplication issue can you:

 SELECT p.id as person_id, e.id as entity_id
   FROM person p
   JOIN   entity e ON (e.id = p.entity_id)
  order by p.id;


db= SELECT p.id as person_id, e.id as entity_id
db-   FROM person p
db-   JOIN   entity e ON (e.id = p.entity_id)
db-  order by p.id;
 person_id | entity_id
---+---
 1 | 1
 3 |   653
 4 |   654
 5 |   667
(4 rows)

 This should not contain any personal info but would allow me to look
 at the join issues involved,

 Best Wishes,
 Chris Travers

 --
 EditLive Enterprise is the world's most technically advanced content
 authoring tool. Experience the power of Track Changes, Inline Image
 Editing and ensure content is compliant with Accessibility Checking.
 http://p.sf.net/sfu/ephox-dev2dev
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?

[John Locke]

On 06/22/2011 04:15 PM, Chris Travers wrote:
 At the moment, our customers actually pay via another system
 (Drupal/Ubercart) which already does the right thing for taxes -- it
 does a call to a web service run by the State of Washington which
 returns the appropriate location code and rate.

 Basically what I need from LedgerSMB is a blank line item I can populate
 with this data, that is clearly a tax line, exported for reporting. If
 I can export the tax report detail to ODS, I can then slice it up per
 location code to file the taxes.
 That's a very good stopgap measure.  Specifically what info would be
 stored?  How can we make it generic?

I'm thinking it should be correlated with a regular tax account, so that
you can flag customers/parts for whether it's relevant (and have a mix
of taxable/non-taxable items on it).

Then provide these fields

1. Reference (e.g. location id)
2. Description (text field, optional)
3. Percentage
4. Amount

... that would be one line per invoice that could be filled in.

I'm thinking it would be nice to calculate amount from applying
percentage to taxable items on the invoice, if amount is blank. I also
think for maximum flexibility it should be possible to leave percentage
blank and provide an amount instead.


Then in the tax report for that account, provide a spreadsheet download
with the collected details.

Cheers,
John Locke
http://freelock.com


--
Simplify data backup and recovery for your virtual environment with vRanger.
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today.
http://p.sf.net/sfu/quest-sfdev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?

[John Locke]

On 06/20/2011 03:54 PM, Chris Travers wrote:

 SSTP is a mess.   It's also the reason why a twix bar is not in the
 candy category but a snickers bar is.   I don't know of any solution
 other than per-state tax modules to accommodate this.

In our case, we don't have so many customers that it's a big burden to
just add a new tax for the location of a customer who has a taxable
transaction. So that's what I've been doing -- creating a new tax
whenever we have a customer with a taxable transaction in a new location.

The problem you highlight above is more about marking products as
taxable or not -- that much, while muddy, is at least easily implemented
today.

The bigger problem is having tax rates that vary based on the customer's
address, and a requirement to report a location code for each taxable
transaction.

At the moment, our customers actually pay via another system
(Drupal/Ubercart) which already does the right thing for taxes -- it
does a call to a web service run by the State of Washington which
returns the appropriate location code and rate.

Basically what I need from LedgerSMB is a blank line item I can populate
with this data, that is clearly a tax line, exported for reporting. If
I can export the tax report detail to ODS, I can then slice it up per
location code to file the taxes.

With that generic infrastructure in place, actually writing a module to
populate that tax line as appropriate would be the next step...

Is there a way to programmatically create an invoice today with a custom
tax line?

Cheers,
John Locke
http://freelock.com

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Employee search question for 1.3

[John Locke]

Ok, I was looking at svn #3301. Completely different now.

Out of the available fields, I think I'd show employee number, first
name, last name, role.

My account is showing up 4 times in this list!?!?

... and an account I created a couple weeks ago has no employee id.

Cheers,
-- 
John Locke
http://freelock.com



On 06/20/2011 04:06 PM, Chris Travers wrote:
 On Mon, Jun 20, 2011 at 12:02 PM, John Locke m...@freelock.com wrote:
 Hi, Chris,

 The current defaults look reasonable to me... possibly adding the email
 field. If this can be changed in the database (as it sounds like you've
 set up), that should be fine to start.
 Actually currently there is no email column on the new code.  We could
 add one though but this poses an issue to be discussed.

 One of the huge differences between 1.3 and 1.2 is that an employee,
 customer, or vendor can have any number of email addresses, postal
 addresses for sales/shipping (but only one address for billing), phone
 numbers, etc.  If we want to display this info, how do we choose what
 to display?  I suppose we could just display every email address,
 phone number, etc.
 However, I'm not getting correct data when I do a search... Maybe this
 is an update issue -- I ran the upgrade/3297-employee_changes.sql and
 upgrade/3299-person_functions.sql scripts, but the result of a search is
 a table with Number, Startdate and Role showing up but all the rest of
 the columns blank. And Number is blank on the most recent employee I
 added...
 You are still hitting the old code.  SVN 3302 (iirc) and the
 3302-menu_changes.sql correct that issue.

 Best Wishes,
 Chris Travers

 --
 EditLive Enterprise is the world's most technically advanced content
 authoring tool. Experience the power of Track Changes, Inline Image
 Editing and ensure content is compliant with Accessibility Checking.
 http://p.sf.net/sfu/ephox-dev2dev
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] [Ledger-smb-commits] SF.net SVN: ledger-smb:[3290] trunk

[John Locke]

Hi, Erik,

See below...

On 06/19/2011 12:18 PM, Erik Huelsmann wrote:
 I'm not really used to the system where you extract relevant changes
 into the updates/ directory. Can someone walk me through how that
 would work out fro this commit?


Since I just had to do this to update our production system, I'll walk
through the steps I had to take...


 Thanks in advance!

 Bye,

 Erik.

 On Sun, Jun 19, 2011 at 8:42 PM,  ehuelsm...@users.sourceforge.net wrote:
 Revision: 3290
  http://ledger-smb.svn.sourceforge.net/ledger-smb/?rev=3290view=rev
 Author:   ehuelsmann
 Date: 2011-06-19 18:42:17 + (Sun, 19 Jun 2011)

 Log Message:
 ---
 First step at resolving 3321964: Add a 'tax' boolean to the 'account' table,
 which serves to tell the application the account is tax related.


  * sql/Pg-database.sql
   (account [TABLE]): Add 'tax' bool-typed field.

ALTER TABLE account ADD tax (bool not null default 0); -- not sure if
that's the exact syntax...

   (chart [VIEW]): Add 'tax' field.

Alter did not work -- got error that you cannot change the number of
columns in a view.

So I tried DROP VIEW chart, which did not allow a drop due to
dependent functions/views.

DROP VIEW chart RESTRICT

... reported all of the dependencies, which were all defined in
modules/Account.sql, modules/chart.sql, and modules/payment.sql.

DROP VIEW chart CASCADE

... then dropped the view with all the dependencies.

CREATE VIEW chart AS ... - insert the new definition

\i sql/modules/Account.sql
\i sql/modules/chart.sql
\i sql/modules/payment.sql

... later I got an access denied on relation chart, so I had to re-run
my generated roles.sql as well, which fixed it.
  * sql/modules/Account.sql
   (account_save [FUNCTION]): Add a 'in_tax' parameter,
 to be stored in the 'account.tax' field.
   (chart_i [RULE]): Give 'tax' field same treatment as 'contra'.

These got loaded by doing the above.
  * UI/accounts/edit.html: Add checkbox for 'tax' field, copied from 'contra'.

No database change necessary -- code update is sufficient.
  * LedgerSMB/DBObject/Account.pm
   (save): Set the value for the 'tax' field to 0 (false) if
 the form doesn't specify a value  -- same as 'contra'.

No database change.
  * scripts/account.pl
   (_display_account_screen): Set the value of the Tax checkbox, like 
 'contra'.

No database change.
  * sql/coa/*/chart/*.sql:
   Change account_save() invocations to include the 'tax' parameter (always
false).  At the end, insert a query to set the 'tax' field to true
for those accounts which have tax related links.

coa changes are not relevant for an update of existing data -- aside
from the query to set the tax field to true for appropriate accounts.


... so I am still thinking there are 3 parts to an update, and this is a
good sample to provide:

1. sql statements to alter the table schemas, report dependencies (with
drop xxx xxx restrict) and verify that we're not going to cascade delete
something we don't know about -- in that case we should not drop and
instead exit with an error.

2. perl script to parse the dependencies/make sure all are known, and
build list of sql files to reload. Then reload them.

3. post-update scripts to do any data changes necessary, such as
populate data in new columns with sane defaults.


For permissions-related updates, including any dropped/recreated items,
#2 should regenerate the roles sql file and #3 should execute it.

Cheers,
-- 
John Locke
http://freelock.com

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Employee search question for 1.3

[John Locke]

Hi, Chris,

The current defaults look reasonable to me... possibly adding the email
field. If this can be changed in the database (as it sounds like you've
set up), that should be fine to start.

However, I'm not getting correct data when I do a search... Maybe this
is an update issue -- I ran the upgrade/3297-employee_changes.sql and
upgrade/3299-person_functions.sql scripts, but the result of a search is
a table with Number, Startdate and Role showing up but all the rest of
the columns blank. And Number is blank on the most recent employee I
added...

Cheers,
John Locke
http://www.freelock.com

On 06/20/2011 07:14 AM, Chris Travers wrote:
 I have set up the search function to allow for the menu to specify
 which column including checkboxes are to be checked.

 For those using 1.3, can you take a look and tell me which checkboxes
 you think should be checked by default?

 Best wishes,
 Chris Travers

 --
 EditLive Enterprise is the world's most technically advanced content
 authoring tool. Experience the power of Track Changes, Inline Image
 Editing and ensure content is compliant with Accessibility Checking.
 http://p.sf.net/sfu/ephox-dev2dev
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Tax account creation: how to 'detect' tax accounts?

[John Locke]

Hi,

To summarize what the system currently has available (and how I think
it's supposed to work) the tax stuff is controlled at several levels:

1. COA account -- whether an account contains tax transactions (and
which screens to make it available on)

2. Customer/Vendor account -- whether a particular tax applies to a customer

3. Parts/Services -- whether a particular account applies to a part or
service

... and then if a tax applies to both part and customer, the resulting
calculation is applied to an invoice/order.

I hear people saying (and we need this too) that we want to be able to
change the above for a particular line item, adding

4. Line item is taxable.


In 1.3, there is a new taxform checkbox on invoice lines, but I have
no idea what that's for -- is that to override the default behavior? If
not, I think it would be useful to have something like this -- generally
to exclude tax from an item that would normally include tax. In our
case, for customers who purchase both wholesale and retail -- sales tax
applies to wholesale but not retail. But then we get into the reporting
issue, because revenue from these sales would need to get reported to
the state in a different account. So better might just be to make
wholesale a completely different part, associated with a different account.

But there is one other case -- destination-based sales tax. Currently
our e-commerce system correctly does an address lookup with the state to
get the correct sales tax rate and location code we need to report for
taxable sales. LSMB of course does not. And since Washington currently
has something like ~2000 individual locations, with varying tax rates, I
think the other scenario, until we can build the appropriate tax module,
is to just allow a person to calculate the appropriate tax (or in our
case, post it from the other system that already handles it correctly)
and add it as a separate line item to the invoice so everything matches
up. So I guess I'd like to see some sort of invoice-level setting for
apply tax automatically vs. add tax manually, and with the latter, a
spot to put in the tax and enter an appropriate location code and rate
that can be correlated in the future, in a spreadsheet download if
nothing else.


Cheers,
John

On 06/20/2011 05:55 AM, Chris Travers wrote:
 On Mon, Jun 20, 2011 at 5:24 AM, Michael Richardson m...@sandelman.ca wrote:
 Luke == Luke  account...@lists.tacticus.com writes:
Luke Why?

Luke I mean, I know it would be kind of nonsensical to uncheck that box 
 after
Luke the fact, but if for some reason someone really wanted to, maybe 
 they
Luke should be able to.

Luke So I'll ask the question: is there any conceivable reason why 
 someone
Luke might want to uncheck a tax account?

 Because the tax in question has been abolished or it applicability has
 changed, and new stuff shouldn't have it applied ever.  But, alas, there
 are things that need to be back dated or which a government tells you
 that you should have done it to.

 The only legitimate reason I can see would be if someone checked it by
 accident and wanted to uncheck it before things were really
 configured.  It seems to me the simple answer is to disallow
 unchecking when the account exists in the tax table, i.e. has already
 been configured as a tax account.

 Best Wishes,
 Chris Travers

 --
 EditLive Enterprise is the world's most technically advanced content
 authoring tool. Experience the power of Track Changes, Inline Image
 Editing and ensure content is compliant with Accessibility Checking.
 http://p.sf.net/sfu/ephox-dev2dev
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Updating 1.3 RFC and small bugs

[John Locke]

On 06/18/2011 04:23 PM, Chris Travers wrote:
 On Sat, Jun 18, 2011 at 12:55 PM, Erik Huelsmann ehu...@gmail.com wrote:
 Hi John,

 On Sat, Jun 18, 2011 at 8:10 PM, John Locke m...@freelock.com wrote:
 Hi,

 After a couple weeks away from bookkeeping, doing some catchup now. Just
 pulled down the latest trunk, and merged them in.

 I see the new sql/upgrade directory, which strikes me as a great direction
 to go. I like the naming of sql update scripts with svn id, and I'd like to
 take it one step further: keep a value in the defaults table for the
 latest db updates.

 I just did the following:

 INSERT INTO defaults VALUES ('schema_version', '3273');

 ... since that looks like the largest svn id with a change under sql.

 As the first part of scripting updates, it would be really great to have
 each schema change dropped into an update sql script in sql/upgrade, with
 the svn id in the file name. And part of the script would be updating the
 schema_version in defaults (which should get initially set in
 Pg-database.sql).


 I just spent 2 hours applying schema updates... would be so much easier to
 just import a few sql files. (granted, much of that was fixing underlying
 data issues uncovered by adding unique keys...).
 Very nice idea. I wonder how to take this further: Chris seems to have
 started with that directory, but I have no idea how we should maintain
 it, or if there's anything we could do to make it easy or enforced to
 update the updates/ directory too.
 My thinking is that any time DDL changes unless it is just the
 internals of a function (where the sl file can be reloaded), we should
 have a file to accommodate that change.Every biweekly release can
 also have a psql script which loads changed function definitions since
 last snapshot.  I think the convention should be [svn
 revi]_description.sql

This much sounds good... but there's still the issue of knowing which
sql files need to get reloaded. This is where I think we need a schema
version, and some sort of convention for knowing when an sql file gets
changed (other than timestamps/commit logs).

I can think of two different reasonable approaches:

1. Parseable change log that can be used by an update function.

2. Index file of schema id of the last change to each sql file.

First off, the schema version -- I propose we make it related to svn id,
without requiring it to be exact. Committers will need to be careful
when updating trunk to make sure they increase the number and include
all changes -- which is where commit id makes sense. But in practice, in
update scripts, I think the main thing to care about is whether the
schema version is bigger than the one currently in the database.

For approach 1, I would see writing update functions similar to Drupal,
with the schema id in the name. The function could load any updated sql
files, as well as insert new ones. Some controller function can parse
the file, find all update functions bigger than the current schema file,
and execute them.

For approach 2, I see creating a hash of all the sql files, each with
the most recent schema version containing a change to that file. Then
our update function could just look for sql files with a bigger schema
version and reload them.

Thoughts?


Cheers,
John Locke
http://freelock.com

--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Bug/Patch: email form not populated with emails from account

[John Locke]

When using the Email button to send an invoice to a customer, the
email form does not populate the email/cc/bcc fields from the customer
account.

Here's at least a partial patch to accomplish this (partial because I'm
not sure if I have all of the areas I patched to make this happen -- it
does work correctly on my system.). This patch is against svn #3281, let
me know if I need to re-roll against an updated trunk.

Cheers,
John Locke
http://freelock.com
diff --git LedgerSMB/Form.pm LedgerSMB/Form.pm
index 21a6cac..fec0301 100644
--- LedgerSMB/Form.pm
+++ LedgerSMB/Form.pm
@@ -2432,6 +2431,18 @@ sub create_links {
 $self-{queued} .= $ref-{formname}  . $ref-{spoolfile} 
   if $ref-{spoolfile};
 }
+
+# get email accounts
+$query = qq|
+SELECT * FROM eca__list_contacts(?)|;
+$sth = $dbh-prepare($query);
+$sth-execute( $self-{entity_id} ) || $self-dberror($query);
+
+my $ctype;
+while ( $ref = $sth-fetchrow_hashref('NAME_lc') ) {
+$ctype = lc $ref-{class};
+$self-{$ctype} .= $ref-{contact} ;
+}
 
 $sth-finish;
 for (qw(printed emailed queued)) { $self-{$_} =~ s/ +$//g }
@@ -2802,7 +2813,7 @@ sub update_status {
 
 $sth = $dbh-prepare($query);
 $sth-execute( $self-{id}, $printed, $emailed, $spoolfile,
-$self-{formname} );
+$self-{formname} ) || $self-dberror($query);
 $sth-finish;
 
 }
@@ -2829,7 +2840,7 @@ sub save_status {
 	WHERE trans_id = ?|;
 
 my $sth = $dbh-prepare($query);
-$sth-execute( $self-{id} );
+$sth-execute( $self-{id} ) || $self-dberror($query);
 $sth-finish;
 
 my %queued;
diff --git LedgerSMB/Mailer.pm LedgerSMB/Mailer.pm
index 29c8bd4..f294575 100644
--- LedgerSMB/Mailer.pm
+++ LedgerSMB/Mailer.pm
@@ -160,11 +160,11 @@ sub attach {
 	my %args = @_;
 
 	carp Message not prepared unless ref $self-{_message};
-	if (defined $args{filename}) {
-		if (!$args{filename}){
+	if (defined $args{file}) {
+		if (!$args{file}){
 			carp Invalid filename provided;
-		} elsif (!defined $args{data} and !(-f $args{filename} and -r $args{filename})){
-			carp Cannot access file: $args{filename};
+		} elsif (!defined $args{data} and !(-f $args{file} and -r $args{file})){
+			carp Cannot access file: $args{file};
 		}
 	} else {
 		carp No attachement supplied unless defined $args{data};
diff --git LedgerSMB/Template.pm LedgerSMB/Template.pm
index d368356..03e2182 100755
--- LedgerSMB/Template.pm
+++ LedgerSMB/Template.pm
@@ -270,7 +270,7 @@ sub render {
 	my $post = $format-can('postprocess')-($self);
 	if (!$self-{'noauto'}) {
 		# Clean up
-		$self-output;
+		$self-output(%$vars);
 		if ($self-{rendered}) {
 			unlink($self-{rendered}) or
 throw Error::Simple 'Unable to delete output file';
@@ -361,7 +361,7 @@ sub _email_output {
 	my @mailmime;
 	if (!$self-{rendered} and !$args-{attach}) {
 		$args-{message} .= $self-{output};
-		@mailmime = ('contenttype', $self-{mimeytype});
+		@mailmime = ('contenttype', $self-{mimetype});
 	}
 
 # User default for email from
--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Updating 1.3 RFC and small bugs

[John Locke]

Hi,

After a couple weeks away from bookkeeping, doing some catchup now. Just
pulled down the latest trunk, and merged them in.

I see the new sql/upgrade directory, which strikes me as a great
direction to go. I like the naming of sql update scripts with svn id,
and I'd like to take it one step further: keep a value in the defaults
table for the latest db updates.

I just did the following:

INSERT INTO defaults VALUES ('schema_version', '3273');

... since that looks like the largest svn id with a change under sql.

As the first part of scripting updates, it would be really great to have
each schema change dropped into an update sql script in sql/upgrade,
with the svn id in the file name. And part of the script would be
updating the schema_version in defaults (which should get initially set
in Pg-database.sql).


I just spent 2 hours applying schema updates... would be so much easier
to just import a few sql files. (granted, much of that was fixing
underlying data issues uncovered by adding unique keys...).



Part 2: Issues I'm hitting.

Just trying to jot down the things I'm hitting today:

Issue 1: Permission needed on partstax relation.

Repro: 1. update menu_acl system, regenerate roles file, re-import
roles. Go to Goods and Services - Reports - All Parts, find an
existing part. Attempt to add an existing tax to the part. Result:


Error!

*DELETE FROM partstax WHERE parts_id = ?
ERROR: permission denied for relation partstax*


... Looks like lsmb_dbname__part_create needs to be granted delete on
partstax...


Issue 2: AR - Customers - Search is case-sensitive. Change search
function to use ~ or ILIKE instead of LIKE.


More to come...

Cheers,
John


--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] More 1.3 papercuts - Sales Tax edition

[John Locke]

1. Save Info on AR invoice does not appear to do anything. I expect it
to at least save updates to Internal Notes and also Notes. It does
not save these things on existing invoices.


2. Tax Forms -- I'm seeing add tax form menu item, but no list tax
form, and don't see how the whole tax system is supposed to work.


3. System - Taxes gives me an empty page with a couple table headers,
even though I have at least 4 tax accounts. No way to actually set a tax
rate.


4. AR - Reports - taxable sales shows no results even when reporting
all dates. (I do have taxable sales in the database -- not many, but we
used to sell more parts that were taxable -- these transactions do not
appear.)




--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Bug/Patch: Allow fractional qty

[John Locke]

We use fractional quantities all the time in invoices. In 1.3, the
column is set to type Integer, which truncates all of the fractions.

Patch for invoices attached -- might also need to be fixed in orders...

Cheers,
John Locke
http://freelock.com
diff --git sql/Pg-database.sql sql/Pg-database.sql
index c12657c..4bdb97e 100644
--- sql/Pg-database.sql
+++ sql/Pg-database.sql
@@ -885,7 +885,7 @@ CREATE TABLE invoice (
   trans_id int,
   parts_id int,
   description text,
-  qty integer,
+  qty NUMERIC,
   allocated integer,
   sellprice NUMERIC,
   precision int,--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Bug/Patch - Receipt voucher source start id irrelevant

[John Locke]

When you're receiving checks, you're highly unlikely to have any
sequence of check ids, so picking a source start on the interim step
of voucher receipt is highly annoying.

Attached patch removes this requirement for Cash - Vouchers - Receipts.

Note: Most of the patches I'm sending were done December - January --
might be some missing parts to the patch. If it doesn't fully work, ping
me to see what else I might've changed... (stored functions, most likely..)

Cheers,
John Locke
http://www.freelock.com
diff --git LedgerSMB/DBObject/Payment.pm LedgerSMB/DBObject/Payment.pm
index dba0e9c..230a8f8 100644
--- LedgerSMB/DBObject/Payment.pm
+++ LedgerSMB/DBObject/Payment.pm
@@ -534,7 +534,7 @@ This method sets appropriate project, department, etc. fields.
 sub get_payment_detail_data {
 my ($self) = @_;
 $self-get_metadata();
-if ( !defined $self-{source_start} ){
+if ( $self-{account_class} != 2  !defined $self-{source_start} ){
 $self-error('No source start defined!');
 exit;
 }
@@ -567,8 +567,10 @@ sub get_payment_detail_data {
 }
 		$source =~ s/$source_src(\D*)$/$source_inc$1/;
 		++ $source_inc;
-		$inv-{source} = $source;
-		$self-{source_$inv-{contact_id}} = $source;
+		if ($self-{account_class} == 1) { # skip for AR Receipts 
+		  $inv-{source} = $source;
+		  $self-{source_$inv-{contact_id}} = $source;
+		}
 	} else {
 		# Clear source numbers every time.
 		$inv-{source} = ;--
EditLive Enterprise is the world's most technically advanced content
authoring tool. Experience the power of Track Changes, Inline Image
Editing and ensure content is compliant with Accessibility Checking.
http://p.sf.net/sfu/ephox-dev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Fwd: [PATCH] Save account headers to 'account_header' table (instead of 'account' table)

[John Locke]

Attaching patch for account_get stored function -- the commit in #3187
doesn't load into my version of postgres.

Cheers,
John

On 05/29/2011 09:53 AM, Erik Huelsmann wrote:
 Hi John,

 If you have a moment to check, I'm no longer able to reproduce your
 problems. Since Chris committed fixes in that area, one of them might
 have included the fix to your issue too.

 Could you validate that your problem has been resolved so I can close
 the tracker ticket?


 Thanks in advance!


 Bye,


 Erik.


 -- Forwarded message --
 From: Chris Travers chris.trav...@gmail.com
 Date: Sun, May 29, 2011 at 6:42 PM
 Subject: Re: [PATCH] Save account headers to 'account_header' table
 (instead of 'account' table)
 To: Erik Huelsmann ehu...@gmail.com
 Cc: Development discussion for LedgerSMB
 ledger-smb-devel@lists.sourceforge.net


 Committed

 --
 vRanger cuts backup time in half-while increasing security.
 With the market-leading solution for virtual backup and recovery, 
 you get blazing-fast, flexible, and affordable data protection.
 Download your free trial now. 
 http://p.sf.net/sfu/quest-d2dcopy1
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

diff --git sql/modules/Account.sql sql/modules/Account.sql
index a233e3c..b4e0cad 100644
--- sql/modules/Account.sql
+++ sql/modules/Account.sql
@@ -19,7 +19,7 @@ $$ language sql;
 
 CREATE OR REPLACE FUNCTION account_get (in_id int) RETURNS setof chart AS
 $$
-SELECT * from chart where id = in_id and charttype = 'A';
+SELECT * from chart where id = $1 and charttype = 'A';
 $$ LANGUAGE sql;
 
 
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Issue 3309519: Email fields not populated when sending AR invoice

[John Locke]

Not sure I picked up all the changes that were required to make this
work, but the attached patch populates email/cc/bcc fields from the
customer's record when sending an AR invoice.

I think there was also a problem actually getting the invoice attached
with a relevant filename, which is also included in this patch. We've
been using this for months.

Cheers,
John Locke
http://freelock.com
diff --git UI/io-email.html UI/io-email.html
index decb298..3435891 100644
--- UI/io-email.html
+++ UI/io-email.html
@@ -21,12 +21,8 @@
 tr
   th align=right?lsmb text('Subject') ?/th
   td?lsmb PROCESS input element_data={name = 'subject', size = 30, value = form.subject} ?/td
-?lsmb IF user.role == 'admin' OR user.role == 'manager' ?
   th align=right?lsmb text('Bcc') ?/th
   td?lsmb PROCESS input element_data={name = 'bcc', size = 30, value = form.bcc} ?/td
-?lsmb ELSE ?
-  td colspan=2 /td
-?lsmb END ?
 /tr
   /table
 /td
diff --git bin/io.pl bin/io.pl
index 77d1698..3e35572 100644
--- bin/io.pl
+++ bin/io.pl
@@ -1181,7 +1181,7 @@ sub e_mail {
 
 my %hiddens;
 if ( $myconfig{role} !~ /(admin|manager)/ ) {
-$hiddens{bcc} = $form-{bcc};
+  #  $hiddens{bcc} = $form-{bcc};
 }
 
 if ( $form-{formname} =~ /(pick|packing|bin)_list/ ) {
@@ -1195,7 +1195,7 @@ sub e_mail {
 my $print_options = print_options(\%hiddens);
 
 for (
-qw(email cc bcc subject message sendmode format language_code action nextsub)
+qw(subject message sendmode format language_code action nextsub)
   )
 {
 delete $form-{$_};
@@ -1266,6 +1266,12 @@ sub print_options {
 };
 
 # SC: Option values extracted from other bin/ scripts
+if ($form-{type} eq 'invoice') {
+	push @{$options{formname}{options}}, {
+	text = $locale-text('Invoice'),
+	value = 'invoice',
+	};
+}
 if ($form-{type} eq 'sales_quotation') {
 push @{$options{formname}{options}}, {
 text = $locale-text('Quotation'),
@@ -1720,6 +1726,9 @@ sub print_form {
 	##SC: XXX the from address needs fixing
 $output_options{from} = $myconfig{email};
 $output_options{notify} = 1 if $form-{read_receipt};
+	$output_options{message} = $form-{message};
+	$output_options{filename} = $form-{formname} . '_'. $form-{${inv}number};
+	$output_options{filename} .= '.'. $form-{format}; # assuming pdf or html
 
 if ( %$old_form ) {
 $old_form-{intnotes} = qq|$old_form-{intnotes}\n\n|
@@ -1802,6 +1811,7 @@ sub print_form {
 user = \%myconfig, 
 template = $form-{'formname'},
 format = uc $form-{format},
+no_escape = true,
 method = $form-{media},
 output_options = \%output_options,
 );
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Issue 3309520: Email AR Aging statement patch

[John Locke]

This one I just fixed today -- we've got a lot of accounts aging, and
I'm tired of having to look up email addresses ;-)

Note that AR - Aging calls LedgerSMB::RP-get_customer which looks for
the addresses in the customer view. This view did not even have an
email column and did not contain data for cc and bcc. I had to drop
the view because the number of columns was changing, then load the new
view with the appropriate joins to the eca_to_contact table. Also, in
the customer view, it needed to key off entity_id not id.

Regarding admin/manager access to the bcc field, Chris had indicated
several months ago when I spoke to him about this, that there wasn't an
equivalent in LSMB 1.3 to use, so for this and the previous patch, I
just stripped the check for this access from the template, so it always
shows bcc.

Cheers,
John Locke
http://freelock.com
diff --git LedgerSMB/RP.pm LedgerSMB/RP.pm
index c67b7dc..f1e5b1e 100644
--- LedgerSMB/RP.pm
+++ LedgerSMB/RP.pm
@@ -1872,7 +1872,7 @@ sub get_customer {
 
 my $query = qq|
 		SELECT name, email, cc, bcc FROM $form-{ct} ct
-		 WHERE ct.id = ?|;
+		 WHERE ct.entity_id = ?|;
 $sth = $dbh-prepare($query);
 $sth-execute( $form-{$form-{ct}_id} );
 ( $form-{ $form-{ct} }, $form-{email}, $form-{cc}, $form-{bcc} ) =
diff --git UI/rp-email.html UI/rp-email.html
index 731b388..d990dbf 100644
--- UI/rp-email.html
+++ UI/rp-email.html
@@ -20,11 +20,8 @@
 	tr
 	  th align=right nowrap=nowrap?lsmb text('Subject') ?/th
 	  td?lsmb PROCESS input element_data={name = 'subject', size= '30', value = form.subject} ?/td
-?lsmb IF user.role == 'admin' OR user.role == 'manager' ?
 	  th align=right nowrap=nowrap?lsmb text('Bcc') ?/th
-	  td?lsmb PROCESS input element_data={name = 'bcc', size= '30', value = form.bcc} ?/td?lsmb
-ELSE ?th /thtd /td?lsmb
-END ?
+	  td?lsmb PROCESS input element_data={name = 'bcc', size= '30', value = form.bcc} ?/td
 	/tr
   /table
 /td
diff --git bin/rp.pl bin/rp.pl
index af1f43f..326e7a3 100644
--- bin/rp.pl
+++ bin/rp.pl
@@ -1413,7 +1413,7 @@ sub e_mail {
 
 print_options;
 
-for (qw(email cc bcc subject message type sendmode format action nextsub)) {
+for (qw(subject message type sendmode format action nextsub)) {
 delete $form-{$_};
 }
 
diff --git sql/Pg-database.sql sql/Pg-database.sql
index 06cfd28..cd75561 100644
--- sql/Pg-database.sql
+++ sql/Pg-database.sql
@@ -940,8 +940,9 @@ CREATE VIEW customer AS
 emd.creditlimit,
 emd.terms,
 emd.meta_number as customernumber,
-emd.cc,
-emd.bcc,
+ece.contact as email,
+ecc.contact as cc,
+ecb.contact as bcc,
 emd.business_id,
 emd.language_code,
 emd.pricegroup_id,
@@ -954,6 +955,9 @@ CREATE VIEW customer AS
 FROM entity_credit_account emd 
 LEFT JOIN entity_bank_account eba on emd.entity_id = eba.entity_id
 Left join entity_note ein on ein.ref_key = emd.entity_id
+LEFT JOIN eca_to_contact ece ON emd.id = ece.credit_id AND ece.contact_class_id = 12
+LEFT JOIN eca_to_contact ecc ON emd.id = ecc.credit_id AND ecc.contact_class_id = 13
+LEFT JOIN eca_to_contact ecb ON emd.id = ecb.credit_id AND ecb.contact_class_id = 14
 join company c on c.entity_id = emd.entity_id
 join entity e on c.entity_id = e.id
 where emd.entity_class = 2;
--
Simplify data backup and recovery for your virtual environment with vRanger. 
Installation's a snap, and flexible recovery options mean your data is safe,
secure and there when you need it. Data protection magic?
Nope - It's vRanger. Get your free trial download today. 
http://p.sf.net/sfu/quest-sfdev2dev___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] Fix for customer search not working (trunk)

[John Locke]

Hi,

Did this one get committed? Didn't see the change in the last version
pulled down... Huge relief to have this working, good one.

One more change I'd suggest: s/like/ILIKE/ in the legal name searches,
anyway...

On 05/16/2011 06:06 AM, Erik Huelsmann wrote:
 Hi all,

 This afternoon I found the problem of trunk's customer search not
 working. Mailed the fix to Chris privately, but now I figure others
 may benefit from the fix as much as I do.

 The function 'company__search' needs a fix; fixed version inline below, with
 the changed line marked . The old version tests meta_number for
 nullity, where that should have been 'in_meta_number'.

 Thanks again!

 Regards,


 Erik.



 CREATE OR REPLACE FUNCTION company__search
 (in_account_class int, in_contact text, in_contact_info text[],
in_meta_number text, in_address text, in_city text, in_state text,
in_mail_code text, in_country text, in_date_from date, in_date_to date,
in_business_id int, in_legal_name text, in_control_code text)
 RETURNS SETOF company_search_result AS $$
 DECLARE
out_row company_search_result;
loop_count int;
t_contact_info text[];
 BEGIN
t_contact_info = in_contact_info;


FOR out_row IN
SELECT e.id, e.control_code, c.id, ec.id, ec.meta_number,
ec.description, ec.entity_class,
c.legal_name, c.sic_code, b.description , ec.curr::text
FROM (select * from entity where in_control_code = control_code
  union
  select * from entity where in_control_code is null) e
JOIN (SELECT * FROM company
   WHERE legal_name like  '%' || in_legal_name || '%'
  UNION ALL
  SELECT * FROM company
   WHERE in_legal_name IS NULL) c ON (e.id = c.entity_id)
JOIN (SELECT * FROM entity_credit_account
   WHERE meta_number = in_meta_number
  UNION ALL
  SELECT * from entity_credit_account
    WHERE in_meta_number IS NULL) ec ON
 (ec.entity_id = e.id)
LEFT JOIN business b ON (ec.business_id = b.id)
WHERE ec.entity_class = in_account_class
AND (c.id IN (select company_id FROM company_to_contact
WHERE contact LIKE ALL(t_contact_info))
OR '' LIKE ALL(t_contact_info))

AND (c.legal_name like '%' || in_legal_name || '%'
OR in_legal_name IS NULL)
AND ((in_address IS NULL AND in_city IS NULL
AND in_state IS NULL
AND in_country IS NULL)
OR (c.id IN
(select company_id FROM company_to_location
WHERE location_id IN
(SELECT id FROM location
WHERE line_one
ilike '%' ||
coalesce(in_address, 
 '')
|| '%'
AND city ILIKE
'%' ||
coalesce(in_city, '')
|| '%'
AND state ILIKE
'%' ||
coalesce(in_state, '')
|| '%'
AND mail_code ILIKE
'%' ||
coalesce(in_mail_code,
'')
|| '%'
AND country_id IN
(SELECT id FROM country
WHERE name LIKE '%' ||
in_country 
 ||'%'
OR short_name
ilike
in_country)
AND (ec.business_id =
coalesce(in_business_id, ec.business_id)
OR (ec.business_id IS NULL
  

Re: [Ledger-smb-devel] Reconciliation in 1.3

[John Locke]

Hi, Chris,

I think the best way would be to add a payee column to cr_report_line ,
and modify reconciliation__pending_transactions to load it with either
entity.name (with the joins on eca) or gl.description.

I guess I had already modified the UI to show the payee column. I can
put together a patch if you'd like...


I think my other two issues were related to imported data, not bugs --
it turns out one of the AP transactions was coded to the wrong account...

Cheers,
John


Chris Travers wrote:
 Hi John;

 That might not be a bad idea.  Let me think about this and see what
 the best way to do this would be.

 The original thinking was to keep this as close to the bank format as
 possible.  But maybe an option to display first x characters of payee
 name might be a good thing?

 Best Wishes,
 Chris Travers

 --
 Lotusphere 2011
 Register now for Lotusphere 2011 and learn how
 to connect the dots, take your collaborative environment
 to the next level, and enter the era of Social Business.
 http://p.sf.net/sfu/lotusphere-d2d
 ___
 Ledger-smb-devel mailing list
 Ledger-smb-devel@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel


--
Lotusphere 2011
Register now for Lotusphere 2011 and learn how
to connect the dots, take your collaborative environment
to the next level, and enter the era of Social Business.
http://p.sf.net/sfu/lotusphere-d2d
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Reconciliation in 1.3

[John Locke]

Hi,

My bookkeeper is making headway on reconciling in LSMB 1.3, and we've
hit a couple issues.

1. No payee on reconciliation detail

Direct feedback from my bookkeeper, that it can be quite difficult to
match up transactions to statements when there's no payee listed on the
reconciliation detail.

I think the real fix is to change the schema of the cr_report_line table
to include Payee, and change reconciliation__pending_transactions to
insert payee data into the report.

Since we're actively using this, rather than messing with cascade
deletes/re-inserts, I added a view to do the heavy lifting:

CREATE VIEW recon_payee AS
SELECT n.name AS payee, rr.id, rr.report_id, rr.scn, rr.their_balance, 
   rr.our_balance, rr.errorcode, rr.user, rr.clear_time, rr.insert_time, 
   rr.trans_type, rr.post_date, rr.ledger_id, rr.voucher_id, 
   rr.overlook, rr.cleared 
FROM (((cr_report_line rr 
  LEFT JOIN acc_trans ac ON ((rr.ledger_id = ac.entry_id))) 
  LEFT JOIN gl ON ((ac.trans_id = gl.id))) 
  LEFT JOIN ((SELECT ap.id, e.name 
   FROM ((ap JOIN entity_credit_account eca ON 
((ap.entity_credit_account = eca.id))) 
   JOIN entity e ON ((eca.entity_id = e.id))) 
UNION SELECT ar.id, e.name 
   FROM ((ar JOIN entity_credit_account eca ON 
((ar.entity_credit_account = eca.id)))
   JOIN entity e ON ((eca.entity_id = e.id 
UNION SELECT gl.id, gl.description FROM gl) n ON ((n.id = 
ac.trans_id)));


... then created a reconciliation__pending_transactions_payee that
returned a row of this view instead of cr_report_line, and modified the
Perl code to use this function instead of the original.

Perhaps something along these lines can be integrated into the original
function?


2. Reconciliation of transactions that pay for multiple AP transactions
only show one.

e.g. Bookkeeper enters several AP transactions, with different dates and
different amounts. Then pays them all with one check. Only one of the AP
transactions appears in the reconciliation report.

That's my task for today -- figure out how to get all the appropriate
lines to show up in the reconciliation report. Chris, do you have a
quick fix for this?


oh, and here's one more issue:

3. Reconciliation of one account marks other side of transaction
reconciled. E.g. a payment from a cash account to a credit card account,
after being reconciled in the cash account, no longer shows up in
pending transactions to reconcile on the credit card account. Not sure
if this is an issue with imported data, or if this is a bug in 1.3.

Cheers,


-- 
John Locke
Open Source Solutions for Small Business Problems
published by Charles River Media, June 2004
Follow me on Twitter: http://twitter.com/freelock
http://www.freelock.com


--
Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL,
new data types, scalar functions, improved concurrency, built-in packages, 
OCI, SQL*Plus, data movement tools, best practices and more.
http://p.sf.net/sfu/oracle-sfdev2dev 
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

Re: [Ledger-smb-devel] [Ledger-smb-users] How functional is 1.3?

[John Locke]

For those impatiently awaiting 1.3, I'm now pushing to a git repository
on one of our public servers, at git://git.freelock.com/git/ledgersmb.git.

You can browse it at http://git.freelock.com/?p=ledgersmb.git;a=summary
(note that the recent Firefox update doesn't seem happy with the gitweb
xhtml... try Chrome or something else if you can't view this).

Most of the branches in there are old, but svn/trunk gets updated from
SVN every 6 hours (or when I manually update), and freelock13 contains
patches I'm making as I get things working.

Cheers,
John

John Locke wrote:
 Hi,

 My notes are summarized here:

 http://sourceforge.net/mailarchive/forum.php?thread_name=4CB49532.9000905%40freelock.comforum_name=ledger-smb-devel

 ... since then, I've had to grant privileges on several sequences,
 functions, and tables, and I did have to go through and change the
 account/chart id on all of the individual parts I had imported...

 Also, we had to do some refactoring on our check templates -- it's now
 split into 3 files, and hard-coded to use the templates/demo templates.

 I'm attaching the sql script Chris sent me, with a bunch of edits I did
 as I worked through it...

 We have reached the point where it's mostly usable. At the moment, we're
 issuing invoices, receiving cash, printing checks, running some reports,
 and starting to use the voucher and reconciliation systems. It's
 starting to feel pretty solid. It took a long time getting here, and
 I've been sending a steady stream of patches back to Chris. Next up on
 the list: sending invoices by email. And then I think we're going to
 bolt on a REST interface to facilitate some integration with our other
 systems...

 Cheers,
 John Locke
 http://freelock.com

  Original Message  
 Subject: Re: [Ledger-smb-users] How functional is 1.3?
 From: Philip Rhoades p...@pricom.com.au
 To: John Locke m...@freelock.com
 Cc: John Locke m...@freelock.com
 Date: Sun 24 Oct 2010 03:25:30 AM PST
 John,

 Do you have notes of things you have had to do to get 1.3 going?

 I am finding a number of things too - your notes might help me resolve
 some of these?

 Thanks,

 Phil.


 On 2010-10-15 07:53, John Locke wrote:
   I'm currently in the midst of migrating to 1.3 just this week.

 I'm finding tons of little issues, have been working with Chris T on
 getting my patches back up stream...

 If you're willing to work with some growing pains, and accept a bit of a
 step down in stability, it's probably workable (or will be come hell or
 high water by next week...). We're moving forward primarily because we
 have to fix the reconciliation system -- and this is vastly improved in
 1.3.

 initiate.pl failed for me, didn't install everything necessary. The
 manual process does work, and there's a SQL upgrade script floating
 around if you're looking to import from LSMB 1.2 or SQL-Ledger... not
 really something that's usable if you're not a developer, you will hit
 issues.

 I wrote a post to the Devel list earlier this week about our upgrade
 process so far, if you can't find it in the archives, I can forward to
 this list...

 Today I got reconciliation actually working, fixed a really crazy bug in
 GL that was causing heading accounts to show up as additional lines and
 making transactions out of balance, and am working on getting proper
 shipto, customer, and vendor views that will hopefully fix most of AP
 and AR screens. Reports mostly seem to work ok.


 Cheers,
 John Locke
 http://freelock.com

 Philip Rhoades wrote:
 Turtle,

 I too was about to ask if there was any progress because I hadn't seen
 any posts re progress for a while.  Should I download the latest code
 and try again (64-bit)?

 Thanks,

 Phil.


 On 2010-10-15 02:13, Schmiechen wrote:
 I just checked ledgersmb 1.3 Trunk Revision: 3091.
 Just to see where things are at.
 I installed the few extra dependency's and set it up in Apache on
 my testing
 Laptop.
 How useable is 1.3? are folks here using it for daily use?
 I checked out the initiate.pl in my webbrowser and browsed the code
 a bit.
 I got to initiate.pl not letting me log in as a db user but I did
 not set up
 any lsmb_db first.
 Is initiate.pl supposed to edit ledgersmb.conf and set everything
 up or is it
 like a new admin.pl?
 Anyway looks like allot of progress has been made.

 Cheers
 Turtle

 --

 Beautiful is writing same markup. Internet Explorer 9 supports
 standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2   L3.
 Spend less time writing and  rewriting code and more time creating
 great
 experiences on the web. Be a part of the beta today.
 http://p.sf.net/sfu/beautyoftheweb
 ___
 Ledger-smb-users mailing list
 ledger-smb-us...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/ledger-smb-users

[Ledger-smb-devel] [PATCH] Misc patches for a bunch of little issues with 1.3

[John Locke]

 INTO cr_coa_to_account (chart_id, account) VALUES
(v_chart_id, in_accno||'--'||in_description);
 END IF;
 -- Already found, no need to do anything. =) -- 1.5.4.3



-- 
John Locke
Open Source Solutions for Small Business Problems
published by Charles River Media, June 2004
Follow me on Twitter: http://twitter.com/freelock
http://www.freelock.com

--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

[Ledger-smb-devel] Notes on updating to 1.3 trunk

[John Locke]

 Hi,

I've spent the past couple days trying to migrate to 1.3, and I hit a
ton of issues. Even now, the system is only partially usable -- lots
more bugs to squash. Just thought I'd post my notes so far, maybe with
some others doing this we can get 1.3 out the door.

Many thanks to Chris T for some ongoing assistance with this... I've
learned a ton about Postgres and the data structure of Ledger.

Here we go:

Starting state:
- Server already configured for Apache, CGI, CPAN dependencies, and
aliases set to a working copy that mirrors SVN trunk
- perl Makefile
- make
- resolve most issues, though still lots of failing tests
- tried initiate.pl, got partly there, ended up ditching everything and
starting over with INSTALL.manual steps.

New site install:

1. Install specified contrib templates from
/usr/share/postgresql/8.3/contrib into template1
2. Create database
3. \i sql/Pg-database.sql
4. Import functions from sql/modules/LOADORDER
5. Import other sql/modules files: EndOfYear.sql, Inventory.sql,
security.sql, Settings.sql, Vendor.sql

6. Generate custom roles file from Roles.sql, import.

7. select admin__save_user(null, person__save(null, 3,
'firstname','middle','last', 232), 'mylogin','mypass'); -- 232 is id for
USA in countries table

8. select admin__add_user_to_role('mylogin', rolname) from pg_roles
where rolname like 'lsmb_mydbname%';

9. grant select on account_link_description to
lsmb_mydbname__account_create -- lots more grants needed, may end up
granting all to my login for time being

10. Import old chart (using some other code leveraging another project,
load each chart id and account_save() account_heading_save() each account

11. alter schema public rename to newschema;

12. create schema public;

13. pg_restore -U postgres -d mydbname backup-from-1.2.sqlc

14. alter schema public rename to orig;

15. alter schema newschema rename to public;

16. Work my way through a SQL-Ledger migration script that Chris T
provided (Chris, mind if I post to the list?)

17. insert into parts select * from parts; -- repeat this copy for
assembly, partsgroup, makemodel, pricegroup, warehouse, invoice,
yearend, department

18. drop ar__audit_trail, ap__audit_trail on ar, drop gl_audit_trail on
gl -- couldn't import into ar, ap, gl due to missing grants

19. Import into ar, ap, gl from Chris's script

... that's where I've gotten. Sent a patch to the list earlier with some
other fixes I had to do...

The current result is I've got a partially working upgrade, but I'm
seeing lots of things that need fixing -- it looks like many old tables
have been replaced with views, but the columns don't match what the code
expects, lots of missing permissions, a few broken features (like all
period boxes seem to have no effect, have to enter dates in the fields
instead), reconciliation doesn't show up, etc.

Will post more as we work through it...

Cheers,

-- 
John Locke
Open Source Solutions for Small Business Problems
published by Charles River Media, June 2004
Follow me on Twitter: http://twitter.com/freelock
http://www.freelock.com


--
Beautiful is writing same markup. Internet Explorer 9 supports
standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2  L3.
Spend less time writing and  rewriting code and more time creating great
experiences on the web. Be a part of the beta today.
http://p.sf.net/sfu/beautyoftheweb
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel