Re: recurring transactions / templates in 1.4?

> > As I understand,
> > templates don't currently work (throw errors),
> We've recently found the same. Chris has been working to fix this
> situation, but that turned out to take longer than expected. The fix is
> planned to be included in one of the upcoming releases.

I saw that issue on github. What's the normal workflow on bug fixing -- ie., if
someone other than Chris wanted to help with it? It doesn't seem that
the github is a focal point for details of errors thrown, suggestions for
code blocks to work on, etc. -- would that be more on irc? (And maybe
this is more of a -devel list topic...)

This one in particular is tricky, because Chris wrote the original add-on and merged it. However, since it was merged, the database model changed, making it hard to glue together the pieces of the puzzle.

In general, the workflow for bugfixing would be that you see an issue you want to work on in the tracker, or you have your own (not registered in the tracker). If you want to know if your approach to resolving it is acceptable, it's a good idea to post your proposed solution on the developers mailing list. I read it multiple times per day and respond whenever I have time. If you'd rather work by example, that's fine too.

So, either with a solution discussed beforehand or not, you would then fork the GitHub LedgerSMB repository. Create a branch (as explained by David), implement your fix there, test it, push it back to GitHub from your local repository and create a Pull Request. There's some "Getting Started (developing)" documentation on the ledgersmb website (http://ledgersmb.org/community-guide/community-guide/development/getting-started-developing). If you find it's lacking, you can create an account on that site and add your enhancements, or you can simply post about it here and we can work together on the enhancements.

If you want to contribute, but have no idea where to start (e.g. you don't have any bugs of your own to work on), you could search the issue tracker for bugs with the label "bite-sized". Those are not too big and beginning contributors should be able to solve those with coaching from one of the more seasoned devs or even completely on their own.

> > and I'm not sure about
> > the status of recurring transactions. In my upgraded install, existing
> > recurring transactions disappear from the list when I edit them, and new
> > ones (by "Schedule"ing an AR entry, say) don't show up at all.
> >
> That's definitely a bug.

[snip]

> Does it happen to
> transactions in a newly created database/company? (I'm assuming so and will
> test myself as well.)

Ok. I tested this yesterday and have found a number of issues that I'll be slowly working through resolving. I'll create a branch in my repository so you can see my progress and contribute/review or even check it out for your own testing.

What are you getting? FWIW, here's some more details (but should I put
them here on in github issue tracker?)--

Yes. It's best to put them in the tracker so when someone starts working on it, all the information is complete. However, adding a link in the tracker linking to a mail in the archives which lists a repro-recipe is fine too, if copy/pasting from the mail is too much work. The archives are hosted at http://archive.ledgersmb.org/.

1) On an AR transaction, click schedule.
2) Keep date the same, and enter "every 1 month 3 times"
3) Goes back to Ar with "saved schedule" message, but nothing shows on
recurring transactions.
4) If I change the date, or use some other parameters, I get one of the
following errors (not sure exactly what causes which, etc.)

Ok. I ran into the same error(s) yesterday night when I started testing this. The error reported ("Transaction aborted") means that there's a query which fails, but the result isn't checked and reported. Then, the program continues and a later query fails with "transaction aborted" because the earlier query already failed. The result of *that* query *is* checked, established as a fail and reported, but the report is rather useless, because it's not the cause of the problem.

I have found which query causes the actual error by adding more error checks in LedgerSMB/Form.pm. I'll commit and push that and send you the name of the branch the fixes live on, so you can see what I'm doing to get it fixed.

The main problem as I found it is that the columns "repeat" and "unit" have been replaced with "recurrence_interval". The latter allows date-calculations to happen within PostgreSQL, but changing a column requires depending code to be adapted too, of course :-)

[ snip error messages ]

> > FWIW, I'm thinking about getting more involved in LedgerSMB as a project,
> That would be great! The irc://chat.freenode.net/#ledgersmb channel is
> pretty active these days. If you need help/ want to discuss your questions
> in real time, it might be an option to pop in and see if we can help.

I'll do that soonish, esp. when I get a full chunk of time to work on it.

Great! Thanks!

> > possibly moving into some customizing (I've done a bunch of BIRT reports
> > for the 1.2 version) and possibly coding, etc.
> We highly appreciate any and all contributions: bug reports,
> customizations, coding, testing, UI improvements, documentation, you name
> it. Let us know what you need to be able to contribute and we'll see what
> we can do to provide for it.

Great! I think getting some input on folks' development environments
would be helpful, and more of a layout of the current codebase, best
practices, etc. Sounds like perhaps using IRC to get specific
suggestions on particular bugs and building up from there might be the
way to go based on current practice, so I'll try that.

To provide you some input: my own development environment is a Linux VM (Debian, both Wheezy and Jessie), with all the prerequisites installed. The VM runs in VirtualBox on Windows, because for my contracts I usually need to be able to process data on Windows for my contracting work. We use GitHub (as you already know) to share our VC state. We use Travis CI to validate the quality of the software, with SauceLabs as the Selenium grid (browser testing). We need loads more tests to be defined, though.

Talk to you on IRC soon!

Bye,

Erik.

http://efficito.com -- Hosted accounting and ERP.

Robust and Flexible. No vendor lock-in.