Evidence Supporting my Statement of Facts Around My Dispute with Tim Schofield
The Fixed Assets Module Correspondence
I have pasted below some of the correspondence around the fixed assets which caused the initial rift. The discussion was off list because I was trying to protect Tim's reputation... we are long past that.
From - Mon Oct 18 21:59:36 2010 X-Mozilla-Status: 0003 X-Mozilla-Status2: 00800000 X-Mozilla-Keys: Message-ID: <4CBC1A88.8040804@logicworks.co.nz> Date: Mon, 18 Oct 2010 21:59:36 +1200 From: Phil Daintree <phil@logicworks.co.nz> Reply-To: phil@logicworks.co.nz Organization: Logic Works Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Tim Schofield <tim@weberpafrica.com> Subject: Fixed Assets Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tim, I have not really experimented before with the Fixed Asset code and just had a look at the FixedAssetItem.php script - it seems as though it is not doing anything with the asset tables it is trying to add to stockmaster - I am wondering if this is a rogue script that is not where it should be. Does fixed assets work at all? Phil
From - Sun Nov 14 18:32:50 2010 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 X-Mozilla-Keys: Message-ID: <4CDF828F.4050908@logicworks.co.nz> Date: Sun, 14 Nov 2010 18:32:47 +1200 From: Phil Daintree <phil@logicworks.co.nz> Reply-To: phil@logicworks.co.nz Organization: Logic Works Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: For the general discussion of webERP project <web-erp-users@lists.sourceforge.net> Subject: Fixed Asset Module - Warning Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I recently released a new version 4.0RC1 - including a new fixed asset module. Unfortunately, I have to advise that the fixed asset module has some problems and I would warn those considering using it not to. I am working on fixing the fixed assets module for a future release. Apologies to those who have been inconvenienced. Phil
From - Sun Nov 14 20:23:42 2010 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 X-Mozilla-Keys: Message-ID: <4CDF9C8B.5010407@logicworks.co.nz> Date: Sun, 14 Nov 2010 20:23:39 +1200 From: Phil Daintree <phil@logicworks.co.nz> Reply-To: phil@logicworks.co.nz Organization: Logic Works Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Tim Schofield <tim@weberpafrica.com> Subject: Fixed Assets Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tim, I hope the resetting of the ankle is going to plan and the recuperation of being once again confined to a chair/crutches/cast not driving you too mad. In relation to this Fixed Asset stuff I would like to have a chat when you are up to it Tim. I think I found your Skype address tim.schofield3 ??? Phil
From - Sun Nov 21 22:18:17 2010 X-Mozilla-Status: 0001 X-Mozilla-Status2: 00800000 X-Mozilla-Keys: Message-ID: <4CE8F1E7.2010000@logicworks.co.nz> Date: Sun, 21 Nov 2010 22:18:15 +1200 From: Phil Daintree <phil@logicworks.co.nz> Reply-To: phil@logicworks.co.nz Organization: Logic Works Ltd User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Tim Schofield <tim@weberpafrica.com> Subject: Re: [WebERP-developers] Hacks should not be in webERP trunk - theFixed Assets Module! References: <4CDF54C3.4000104@logicworks.co.nz> <AANLkTinJYZNKii_RN6RyLua5vp9E7h8_=-+_JESjnCmz@mail.gmail.com> <4CE0EC06.50705@logicworks.co.nz> <AANLkTi=UKKeYOaRfSG-LNm7FCgxmz0XMF_V41RFvk2v0@mail.gmail.com> <1099472191-1289934288-cardhu_decombobulator_blackberry.rim.net-1825057942-@b12.c1.bise3.blackberry> <AANLkTikqUvOBrhCkBoxvDXTwdAkuue=cKXwZAYnaE54z@mail.gmail.com> In-Reply-To: <AANLkTikqUvOBrhCkBoxvDXTwdAkuue=cKXwZAYnaE54z@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Tim, Just reworking some of the scripts for style as I work through the fixed asset changes. Is it right to have a $UOM property of the PurchOrder Class and a $uom property?? Forgive the silly questions, I've not really understood the code used in all the purchasing changes. I notice quite a bit of lower case variable naming which is confusing for me as I have used CamelCase everywhere else for variable names. What are the variables nw? and gw? Sorry to re-litigate this fixed asset stuff but have been thinking about how you could be offended by the word "hack"? I used this thinking it meant scripts that was cobbled together from existing scripts and the variable names not changed and still including large chunks of redundant code relevant to the original script but not relevant to the new functionality... Not sure why you think that was an unfair description? I am still some way away from completing the fixed asset stuff - although I have put quite a few hours in this weekend. No doubt it will be next weekend before I can give it another nudge. I do hope you understand about the standards I am insisting upon. I had previously thought that you concurred with these and that is why I was surprised (and upset) by that this code was in the trunk. Phil On 18/11/10 19:14, Tim Schofield wrote: > Hi Phil, > > Ok, I think the stockmaster table long ago started to have non stock > items in it, so I figured it would not be a problem to include fixed > assets. However as I have said before I am happy for you to have the > final say on webERP policy. > > I was a bit upset at the comment in the change log which I am not sure > is the correct forum for personal opinions on other peoples code. It > sets an unfortunate precedent and I feel it would be best if the > change log was just a description of the change. As Exsson said the > only bug was the typo with extra " which I think came in when I was > doing that mass change for the form id, and I corrected as soon as you > informed me, the other problem I couldn't replicate. Also I felt the > tone and content of the emails to the list was a bit insulting to the > people who wrote the code, which worked, even though you consider it > to be a "hack". > > Most worryingly for me though is that trunk which was working is now > completely broken. For instance I am told (but can't verify at the > moment) that the db upgrade script is now broken and wont even run. > There is more apparently than just the bug that you reintroduced the > other day and I emailed you about. Even without the bugs though trunk > now doesn't work as your changes are not complete. My fear is that if > you run into the same problems that we did with this approach, then > backing out will be very hard. We kept the work in a separate branch > until we were happy it worked, would not it have been better to keep > your changes in a new branch until it worked? > > As you say this is the first time we have disagreed about webERP > policy and code, and I would like to keep it as that, just as a > discussion about policy and not personal which I felt it had become > with your previous comments. > > Thanks > Tim > > > On 16 November 2010 22:05, Phil Daintree<phil@logicworks.co.nz> wrote: >> Hi Tim >> >> Thanks for explaining the rationale for using the stockmaster to store fixed assets. >> >> Following my initial comments privately and in the change log when I started to realise the problems with this code, I have studied the logic before starting with the major changes yesterday. I fully realise the large changes required to make the new structure work. I do also understand the rationale and some areas of common logic which made you choose to merge fixed assets with stock. >> >> However I feel the separation between fixed assets is both important and logical - the code will be simpler, be more readable and maintainable. But yes it is very largely a rewrite. >> >> I am proposing to have a function from stock adjustments that allows stock to be transferred to a fixed asset. This handles internally manufactured items neatly. Purchase ordered items will go through as nominal items and the supplier invoice will have a new script to capture fixed assets like grns shipment charges or contract charges. I put all this up on the wiki for comment. I should be able to remove any additional complexity from goods received and stock scripts. >> >> Unfortunately, after a few weeks consideration and after communicating my concerns, I still felt that the fixed assets merged with stock was ill-conceived. >> >> I too have concerns as Exson expressed so eloquently. I know it is very difficult, boring and time consuming testing adnauseum. But we must now dig in and knock over a few bugs. Probably not all that many but enough to frustrate and undermine our reputation for reliable code. >> >> It is time to take a breath as you say Tim. >> >> Perhaps with some communication of development intentions prior we could have side stepped this difficult situation we are now in. >> >> I do hate to be on the other side of the fence from you Tim this is the first time it has happened and I really would prefer to be talking to you about this. Please rest assured I have not taken this action on a whim. >> >> Phil >> Phil Daintree >> Logic Works Ltd - 0275 567890 >> >> -----Original Message----- >> From: Tim Schofield<tim@weberpafrica.com> >> Date: Tue, 16 Nov 2010 12:50:17 >> To:<phil@logicworks.co.nz>; webERP Developers<web-erp-developers@lists.sourceforge.net> >> Subject: Re: [WebERP-developers] Hacks should not be in webERP trunk - the >> Fixed Assets Module! >> >> Hi Phil, >> >> I think you have been hasty to judge, and to change this module >> because it didn't at first work for you. >> >> The decision to use the stockmaster and related tables was not taken >> on a whim. By separating out the fixed asset items into a new table as >> you have now done means many changes to many scripts, and changes to >> other tables. For instance the goods received script now needs >> considerable reworking to make it work with your changes, whereas >> before it just worked fine. The purchase ordering scripts also now >> need changing as the fixed asset items will no longer appear. The >> whole serial items code (which in my opinion needs reworking) also >> will have to be changed to fit in with this. >> >> I feel from the tone of your emails to the list, and from the tone of >> your comments in the change log that you decided the code was bad and >> jumped in to change it without properly understanding the decisions >> that went behind the code. I appreciate this is my fault as I was >> unable to reply to your email asking for clarification, but I do >> wonder whether a pause for breath is not required here before the code >> gets very messy. >> >> Thanks >> Tim >> >> >> On 15 November 2010 11:15, Phil Daintree<phil@logicworks.co.nz> wrote: >>> Yeah I guess I was a bit upset about seeing this code - the more I look >>> the more grizzly I get! It will pass. Is this your work Tim? >>> >>> I hope you won't mind me reworking it some and knocking it into shape. >>> >>> I am keen to understand this more. Next time you are on Skype early >>> morning would be nice to chat. >>> >>> Phil >>> >>> On 15/11/10 18:41, Tim Schofield wrote: >>>> Hi Phil, >>>> >>>> I am a bit surprised at this email as we have several people using >>>> this functionality. >>>> >>>> You wrote me an email a couple of weeks ago that I haven't had a >>>> chance to respond to as things have been a bit difficult here. Some of >>>> the queries that you brought up I did some alterations on, but others >>>> I could not replicate, is your database correct? >>>> >>>> Yes we used some of the stock scripts, as the functionality there was >>>> very similar, and maybe they could do with more tidying up, but I am >>>> very surprised you couldn't get it to work. >>>> >>>> "Hack" is an emotive and subjective word, and I do not agree with its use here. >>>> >>>> Tim >>>> >>>> >>>> On 14 November 2010 03:17, Phil Dainrtree<phil@logicworks.co.nz> wrote: >>>>> Guys, >>>>> >>>>> Is anyone using the fixed asset code that was committed to SVN some time >>>>> ago? I would be most surprised to hear any positive responses .... >>>>> >>>>> I fear on looking into it and doing a little testing myself that this >>>>> code is absolutely woeful. >>>>> >>>>> It is a poor hack of the stock items scripts and quite badly broken in >>>>> my view. Just a warning for anyone intending to use this - don't! >>>>> >>>>> I put a huge amount of work into webERP and it is very upsetting for me >>>>> to see this sort of code getting into the trunk. >>>>> >>>>> I opened up development to others and I have made it plain that future >>>>> webERP work must follow strict guidelines and hacks are absolutely to be >>>>> avoided. Only carefully crafted scripts in a style that I took the >>>>> trouble to describe at length. I trusted that those with SVN access >>>>> would follow this formula. I simply don't have the time to review all >>>>> the code these days as I have to earn a living and most of my webERP >>>>> work is voluntary. >>>>> >>>>> I will be working this code over to try to get something functional - it >>>>> will take some time. >>>>> >>>>> I am aware of one business who was depending on this functionality and >>>>> has come away disappointed - this does very bad things for webERP's >>>>> reputation. >>>>> >>>>> A reminder then that code that goes into the trunk must: >>>>> >>>>> a) Be tested - a couple of minor bugs ok ... but is should basically >>>>> work. It may not work so well when first committed but it should be >>>>> polished up before it is left. >>>>> b) Be written according to the detailed style guide at >>>>> http://www.weberp.org/ContributingtowebERP - please re-read this if you >>>>> had any involvement in this code. >>>>> c) Must not have large tracts of redundant code in it >>>>> >>>>> This may seem ungrateful as someone has clearly had a go at trying to >>>>> put together a fixed assets module and it is an interesting concept to >>>>> recycle the stock logic but the scripts in there present form have no >>>>> place in the trunk let alone version 4.0RC1 - there has been very little >>>>> communication on the list about this development and it needs a warning >>>>> out there to folks who may see it advertised (as I have done) that it >>>>> plain doesn't work. >>>>> >>>>> -- >>>>> Phil >>>>> >>>>>
Although I did try I was unable to have a skype conversation about this with Tim - I even thought he may have been actively avoiding me - although I had requested a discussion at least twice.
Date Permissions Modified Changing Tim From web-erp Admin to Developer
Screen shot of sourceforge web-erp project admin logTim's permissions were updated from webERP Admin to developer on 13th November 2010. This log also shows the dates when Tim was removed completely due to him over-writing my work Dec 27 2010 - and then reinstated Jan 21st 2011 - he has been removed again finally in April 2013.
Links to Code Over-writing my Commits
I committed the start of my purchasing code review on 14 Dec 2010
https://sourceforge.net/p/web-erp/code/4183/
The commits to svn over-writing my purchase ordering work were on 22 December 2010
https://sourceforge.net/p/web-erp/code/4438/
and a couple of minor changes too around this time.
There was a heap of review work subsequent starting on
https://sourceforge.net/p/web-erp/code/4458/
There was also a dispute around the upgrade methodology. Tim could not accept my decision to go with a single SQL file for each version upgrade rather than the pseudo SQL language he developed. Which he proceeded with anyway so I was left with little alternative but to remove him temporarily while I got on with the job.
Final Removal from the Project
Tim's commit:http://sourceforge.net/p/web-erp/code/5834
contained references to his Kwamoja fork and also used css classes we don't use in webERP.
I asked him to review and fix it... he refused.
Access now removed as a result.
Date: Sat, 6 Apr 2013 02:05:56 +0100 Subject: Re: [Web-erp-svn] SF.net SVN: web-erp:[5834] trunk From: Tim Schofield <tim@weberpafrica.com> To: phil@logicworks.co.nz Content-Type: text/plain; charset=ISO-8859-1 Give me a clue? On 06/04/2013, Phil Daintree <phil@logicworks.co.nz> wrote: > If you can't see the issues with this then you must be incompetent. > > Phil > > Phil Daintree > Logic Works Ltd - +64 (0)275 567890 > http://www.logicworks.co.nz > skype:daintree > > > On 06/04/13 13:16, Tim Schofield wrote: >> Reviewed >> >> On 05/04/2013, Phil Daintree<phil@logicworks.co.nz> wrote: >>> Please could you review this diff. >>> >>> Thanks >>> Phil
My advice to Tim:
Date: Sun, 07 Apr 2013 13:00:13 +1200 From: Phil Daintree <phil@logicworks.co.nz> To: Tim Schofield <tim@weberpafrica.com> Subject: We're done Tim, I spent a little time trying to re-moderate your postings advertising your hate blog but in the end I thought "stuff it" and deleted the lot using the prune option. You are now banned from the forums and your alter-egos. You are still only moderated on the mailing lists. Of course silly posts will not come through to the list. No doubt you will continue to infect people as they write to the list. You write access to svn has also been removed - since I just can't trust you and your latest commit is full of css errors. For a long time I though you were a good guy genuinely trying to help me with webERP... increasingly I have found I am wasting so much good time on you it is hampering webERP rather than helping. It is unhealthy for you to be harbouring such a grudge and I have no time for you any more sorry TIm. Let us move on now please. It would be much better for you to focus on something positive in your life.
Purchase Orders Conversion Units:
From - Sun Nov 28 08:41:30 2010
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00800000
X-Mozilla-Keys:
Message-ID: <4CF16CF8.1030509@logicworks.co.nz>
Date: Sun, 28 Nov 2010 08:41:28 +1200
From: Phil Daintree <phil@logicworks.co.nz>
Reply-To: phil@logicworks.co.nz
Organization: Logic Works Ltd
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1
MIME-Version: 1.0
To: Tim Schofield <tim@weberpafrica.com>
Subject: Re: [WebERP-developers] State of trunk
References: <AANLkTi=usYYbWE723Xa7C=SmoK-=iXYpynmuOQOJudzS@mail.gmail.com> <4CEF8601.6000302@logicworks.co.nz> <AANLkTimunC-kVmMAA1aSvEFKQqvZ-SdMgqj-zjs8NST6@mail.gmail.com> <4CF01E75.9010906@logicworks.co.nz> <AANLkTikpe=hwmMDwb6+ZwXJo00sC46pEEpCF40oSM59g@mail.gmail.com>
In-Reply-To: <AANLkTikpe=hwmMDwb6+ZwXJo00sC46pEEpCF40oSM59g@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Hi Tim,
Sorry 'bout that. I understand your frustration - although it surprises
me also that you would be using the trunk to demonstrate - given that I
have advertised what I am doing.
ALTER TABLE purchorderdetails ADD COLUMN assetid int NOT NULL DEFAULT 0;
I really don't think a new branch is necessary for this - again we
disagree. Only a few more scripts to go - with fixed assets. I got
side-tracked, have had quite a go at the purchasing scripts -
CamelCasing variable names etc I noticed that there are look ups for
ConversionFactor all over. This needs to be thought through a bit and a
proper solution developed. I have removed these in the short term. I
think it best to have only our (the business's) units stored in the
database, the only time I think we need conversions are :
- when the purchase order is placed and printed for the supplier
- when the purchase order is received.
It will need more rework... next job after fixed assets.
Phil
Note the dates - long before Tim's commit
In fact I have asked repeatedly to be spared the continual barrage of hate email from TIm on several occassions.
See my Thunderbird Tim Schofield spam inbox - his own folder - showing emails just for April - after I have asked to be removed from his emails.
and the email I have sent to Tim since December 2012
Tim is NOT an English Chartered Accountant
Finally, knowing the code of ethics to which I signed up to when I became a member of the ICAEW (Insititute of Chartered Accountants of England and Wales) and the strict ethical rules that apply to members I reported Tim to the Institute so they could investigate our dispute and discipline one or both of us as they saw fit. Of course, the truth is a great ally in such investigations. Only members of this institute are allowed to call themselves Chartered Accountants in the UK.However, it transpires that this is yet another of Tim's deceptions. He is NOT actually a member of the ICAEW! I had believed this since 2007 and webERP had been promoted as being led by two English Chartered Accountants for a number of years prior to 2010. I am sorry to have been a party to this deception and I have been as misled as everyone else.