Re: Proposed change of priorities for 1.4

[Chris Travers <..hidden..>]

Hi Erik;

Thank you for your reply.

On Sun, Dec 11, 2011 at 3:33 AM, Erik Huelsmann <..hidden..> wrote:
> Hi Chris,
>
>> Due to the length of time it took to get 1.3 out I haven't had the
>> time necessary to get 1.4 development going strong.
>
> Although I do understand that you're doing the most of the development
> at this time (and have done so for quite some time), I believe we both
> agree that that's not the desired long-term situation. I'm saying this
> so that people reading this conversation feel invited to join the
> effort: it's not intentionally solely yours, is it?
>
> As I've said in private conversations over the past months as well:
> I'd like to contribute more as well, however, I'm unable to make
> commitments to specific efforts as far as commitments to specific
> release dates go.

Right.  Nor do I think it proper to expect the same from any contributors.
>
>> Replacing the financial logic is going to be a big job.
>
> Agreed. Could we start working out a document which describes what
> should happen? That way, it would be easier for other people to join
> our effort: they'd simply have to read the document stating what we're
> doing and how far along the effort we've gone so far.

I think for GL stuff we are pretty close in the way things currently
work.  For AR/AP I think we need two things:

1)  Discussions on -users asking the question "anything you think we
need to change?" in affected areas.  Also we need to go through
feature requests a few times in these areas too.

2)  After this, I think we can discuss workflows on -devel, as well as
other stuff.  Take proposals back to -users after we have something
generally discussed.
>
>>  What I don't want to see is another 4 year release cycle.
>
> Absolutely agreed!
>
>> So I am going to suggest we shift our priorities and
>> don't tackle the financial logic yet.
>
> Thinking about this some more, I agree with you if you mean "don't
> start coding" by "don't tackle". However, I'm thinking we could start
> drawing up the impact assessment and plan-of-attack, the outline of
> the DB stored procs, triggers and what-not. If we create a good
> outline document with the mentioned components, I'm thinking it'll be
> easier for others to join the effort. And I think we want to make that
> as easy as possible: it'll be good for the community if/when that
> happens.

Technically by "tackle" I mean "don't make disruptive changes to the
codebase in trunk."  Coding might be fine, but not for 1.4.

>
>> 1.4 should include as part of core
>> 1)  New recurring transactions logic based on the template transaction
>> addon in 1.3
>
> As we  discussed in our chat, this changes the way recurring
> transactions are being posted; instead of copying a posted document,
> the process will copy a valid (but not posted) accounting/invoice
> document. The effect is that users will be able to schedule invoices
> without being required to actually post one first. Even more, it
> allows one to change all future invoices - which isn't currently
> possible.
>
>> 2)  New trial balance module based on the enhanced_tb addon (currently
>> under testing for 1.3)
>
> You tell me this module is much faster and more flexible, such as
> allowing subsets of accounts to be selected. If we integrate the
> change you mention under (3) - allowing account totals to be split by
> the various classifications (departments, funds, etc) - that would
> absolutely rock!
>
>> 3)  Generalizing projects, departments, funds, etc. out for reporting
>> purposes.  Making these hierarchical
>
> Having hierarchical classifications as well as flexible
> classifications sounds really good; can we take into account that
> people may want to define multiple hierarchies for one specific class?
> (i.e. two or three department hierarchies. Sounds ridiculous, but it
> works great in practice.)
>
>> 4)  Refactoring contact logic, making it more flexible, ensuring that
>> customers and vendors can be tracked as individuals instead of just
>> companies.
>
> Personally, I'd assign a higher priority to developing (web)services
> APIs than prioritizing this item. I'm not against this and definitely
> see the value added as well. We do have use for this, but we're just
> creating people as companies and setting them up as their own
> contacts. It works well enough for now.

yeah, but web service API's will be cleaner for this area if we do it.
 I'd like to revive Jason's REST work regarding the old codebase too
and add invoices, orders, etc. to those.  Reading the code there, that
shouldn't be too hard.
>
>> Some of the work I have done on number/date formatting for 1.4 will be
>> included and this will allow a wider range of number/date formats to
>> be supported.
>
>> The goal would be to have something we could target for release in
>> summer/fall, and get our release schedule back on track, as well as
>> providing a basic springboard for further development into the
>> financial logic of the software.
>
> As I have expressed in earlier conversations (possibly private only?)
> I  think that's a great idea: having a dependable release cycle where
> the functionalities which are done get released to the public. That
> way, the part of the community which benefits from those changes
> doesn't have to wait for some huge project to complete.
>
> My idea for approaching the financial logic refactoring would be to
> determine in the assessment which bits can be done on trunk as part of
> any release. That'll help paving the way for 'the big change'. When
> we're done refactoring the smaller bits, we move the main refactoring
> to a branch where we work on it at our own pace. There, the work isn't
> blocking releases of other functionality or fixes. Working on a branch
> until we're ready to integrate means we won't be forced to have
> another 4-year release cycle.
>
>> If I have time I would be open to putting some time towards an appointment
>> module, I would like to do that but at this point, there are no guarantees.
>> What do people think?
>
> Well, if you get funding for the appointment module, I'm the last one
> to tell you to earn money :-) However, if I look at the current
> structure of the application, I'm not sure where it fits in. I mean,
> other CRM software integrates with e-mail clients and agendas these
> days. Is an appointment module good enough?

It's good enough for some use cases.  Those use cases can bring
additional projects later.


Also want to integrate the work I have been doing on payroll.

best Wishes,
Chris Travers