[WebERP-developers] release 4.13.1 zip archive missing xml files in companies/weberp/FormDesigns

[Dale S. <dal...@sh...>]

The webERP_4.13.1.zip archive downloaded from Sourceforge is missing a number of xml files from the companies/weberp/FormDesigns directory. This prevented at least the correct generation of work order PDF "Paperwork" and "Labels" files. 

root@whizzer:/usr/local/www/weberp-4.13.1 # ll companies/weberp/FormDesigns 
total 32 
-rw-r--r-- 1 www www 5264 Feb 21 13:26 GoodsReceived.xml 
-rw-r--r-- 1 www www 3901 Feb 21 13:26 Journal.xml 
-rw-r--r-- 1 www www 8903 Feb 21 13:26 PickingList.xml 
-rw-r--r-- 1 www www 7650 Feb 21 13:26 PurchaseOrder.xml 

root@whizzer:/usr/local/www/weberp-4.13.1 # ll companies/weberpdemo/FormDesigns 
total 48 
-rw-r--r-- 1 www www 1702 Mar 21 15:42 FGLabel.xml 
-rw-r--r-- 1 www www 5264 Mar 21 15:42 GoodsReceived.xml 
-rw-r--r-- 1 www www 3901 Mar 21 15:42 Journal.xml 
-rw-r--r-- 1 www www 8903 Mar 21 15:42 PickingList.xml 
-rw-r--r-- 1 www www 7650 Mar 21 15:42 PurchaseOrder.xml 
-rw-r--r-- 1 www www 1204 Mar 21 15:42 QALabel.xml 
-rw-r--r-- 1 www www 7967 Mar 21 15:42 WOPaperwork.xml 

I diff'd the files in common and they were identical. Then I copied over the files missing in weberp/ from weberpdemo/ and correct work order PDFs appear to be generated. Thanks to Tim Schofield for his help figuring this out. 

How is the zip release file created? I checked the trunk branch on Sourceforge and did not see a companies/weberp directory . 

For what it's worth, I would have taken the effort to enter this into a project bug tracker (even if in hindsight it turns out to be my fault and not a bug at all). I read archived mail threads proposing a project bug tracker, and understand the rationale that a quick email from a user and equally quick fix from a developer is less work than what a bug tracker will impose (e.g. enter bug, fix code, commit code, link bug to commit, close bug). However, not having a bug tracker also means there is no common or public place to store issues for fixing later (e.g. when the fix isn't quick, or isn't a high priority), and searching through mail archives for old bug reports, and then figuring if a report has already been fixed or not, becomes much more work and much less reliable than a bug tracker would have been. 

I've experimented using the Sourceforge Tickers system on one of my own projects and although not perfect, it seems convenient and good enough for the basics. Bug reports could still be welcomed from casual community members through email or forum posts, but active members could take it upon themselves to create a ticket when they felt it was justified. 

A side benefit to a bug tracker is the confidence it gives to the general community, showing bugs are treated seriously, reports are triaged, and resolved appropriately. There may be arguments about _how_ a bug was triaged or resolved (in particular, the ones classified as "won't fix"), but the visibility means that a bug report can't be overlooked or forgotten. 


Cheers, 
Dale