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

[gilberto d. s. a. <gs...@gm...>]

+1 from me.

--
gilberto dos santos alves
+5511986465049






2017-03-21 20:30 GMT-03:00 Dale Scott <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
>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Web-erp-developers mailing list
> Web...@li...
> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>