[jira] [Closed] (OFBIZ-6019) Adding and improving some Dutch translations to ORDER labels

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-6019.
--
   Resolution: Done
Fix Version/s: Upcoming Branch
 Assignee: Jacques Le Roux

Thanks Pierre,

Your slightly modified patch is in trunk at revision: 1653208  

I have fixed some trivial issues within these changes, 
Wrong change at OFBiz: Gestion commerciale
Removed all Dutch changes which were simply duplicating the English ones

> Adding and improving some Dutch translations to ORDER labels
> 
>
> Key: OFBIZ-6019
> URL: https://issues.apache.org/jira/browse/OFBIZ-6019
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6019-OrderLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (OFBIZ-6020) PartyLabels - adding and improving

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-6020.
--
   Resolution: Done
Fix Version/s: Upcoming Branch
 Assignee: Jacques Le Roux

Thanks Pierre,

Your slightly modified patch is in trunk at revision: 1653208  

I have fixed some trivial issues within these changes, 
Wrong change at OFBiz: Gestion commerciale
Removed all Dutch changes which were simply duplicating the English ones

> PartyLabels - adding and improving
> --
>
> Key: OFBIZ-6020
> URL: https://issues.apache.org/jira/browse/OFBIZ-6020
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6020-PartyEntityLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (OFBIZ-6018) Adding some Dutch translations to Manufacturing Entity labels

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-6018.
--
   Resolution: Done
Fix Version/s: Upcoming Branch
 Assignee: Jacques Le Roux

Thanks Pierre,

Your patch is in trunk at revision: 1653208  


> Adding some Dutch translations to Manufacturing Entity labels
> -
>
> Key: OFBIZ-6018
> URL: https://issues.apache.org/jira/browse/OFBIZ-6018
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6018-ManufacturingEntityLabels.xml.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-6016) Adding som Dutch translations to common labels.

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283533#comment-14283533
 ] 

Pierre Smits commented on OFBIZ-6016:
-

Darn. What a nuisance. I did a cursory check on the CommonUiLabels before I 
generated the patch as I had a number of merge conflicts on pt-BR. So I 
corrected the merge conflicts and the IDE gave the OK. And I submitted the 
patch. Didn't see it coming that there were still other (*)_(*) translations in 
the file, otherwise I would have corrected those too.

I will check [https://issues.apache.org/jira/browse/OFBIZ-6018] and 
[https://issues.apache.org/jira/browse/OFBIZ-6019] again.

> Adding som Dutch translations to common labels.
> ---
>
> Key: OFBIZ-6016
> URL: https://issues.apache.org/jira/browse/OFBIZ-6016
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6016-FrameworkCommonLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OFBIZ-6013) "Return Selected Item(s)" button broken for manually created returns

2015-01-19 Thread Mridul Pathak (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mridul Pathak reassigned OFBIZ-6013:


Assignee: Mridul Pathak

> "Return Selected Item(s)" button broken for manually created returns
> 
>
> Key: OFBIZ-6013
> URL: https://issues.apache.org/jira/browse/OFBIZ-6013
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Mridul Pathak
> Attachments: OFBIZ-6013.patch
>
>
> The "Return Selected Item(s)" button is broken at 
> ordermgr/control/returnItems because the link in returnItemsInc.ftl that 
> tries to submit the form from quickReturn.ftl which doesn't exist for 
> returnItems.ftl which reuses that file.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-3764) Party Relationship Sub-Class

2015-01-19 Thread Mridul Pathak (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-3764?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14283379#comment-14283379
 ] 

Mridul Pathak commented on OFBIZ-3764:
--

I like the second approach better.

> Party Relationship Sub-Class
> 
>
> Key: OFBIZ-3764
> URL: https://issues.apache.org/jira/browse/OFBIZ-3764
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party, product
>Affects Versions: Trunk
>Reporter: Bob Morley
>Assignee: Jacques Le Roux
> Attachments: OFBIZ-3764_SupplierRel.patch
>
>
> Despite how much I typed; this is really a very small patch.  :)
> This patch adds a new entity "SupplierRel" which is a sub-class of 
> "PartyRelationship" (as well as a view-entity for convenience).  It provides 
> a new field "accountNumber" that can be used to store the long-term account 
> number assigned to the relationship between the Company and its Supplier.  
> The life of this account number is longer than any agreement between the two, 
> so it has been put on this informal relationship.  Moreover, it is possible 
> to have an informal relationship between a company and a supplier with out an 
> explicit binding agreement -- this was discussed most recently in this thread:
> http://ofbiz.135035.n4.nabble.com/Storing-supplier-provided-account-number-td2076162.html#a2076162
> ALSO -- this patch fixes two problems that I encountered when attempting to 
> create a party relationship.
> a) It did not look right to have an empty dropdown for status -- I created 
> the standard "Created" status under the PARTY_REL_STATUS type so that we show 
> the only applicable status.  There does not appear to be any specific logic 
> looking for party relationships with a blank status, so creating ones with 
> this status should not cause any issues.
> b) When creating the PartyRelationship the response in the controller was of 
> type "view-last" which was a problem because the last controller request was 
> typically the ajax one to "FindPartyName" which was used as part of the party 
> lookup field in that form.  The net result, was that on success it would 
> render the PartyName instead of replaying the EditPartyRelationships.  
> Changed form "view-last" to "view" to resolve this issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: Is this a way to get the db view or the query behind ModelViewEntity

2015-01-19 Thread Jacques Le Roux

Le 19/01/2015 23:22, Justin Robinson a écrit :

*Thanks to those who helped me with my last question*

I've had a look at the code of ModelViewEntity briefly, that together with
the following abstract:

"A few things about view-entities View-entities are very powerful and allow
you to create join-like queries, even when your database doesn't support
joins." - ofbiz entity cookbook.

Seems to suggest that view entity xml model info is used to piece the view
entity together.

Still I need to write a script to create views on a mysql database that
correspond to all ofbiz 10.04 view entities on a very large system.

Please can I have some advice about how best to go about such a task.

*Looking at the content of this mailing list and the warning to post to be
right list, I wonder if I shouldn't be asking this on users - still I'm not
a user - pls let me know if I should use the other list.*


Yes you should the user list, you are an OFBiz user :)
This is clearly(?) explained at http://ofbiz.apache.org/mailing-lists.html

Jacques


[jira] [Closed] (OFBIZ-6016) Adding som Dutch translations to common labels.

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-6016.
--
   Resolution: Implemented
Fix Version/s: Upcoming Branch
 Assignee: Jacques Le Roux

Thanks Pierre,

Your modified patch is in trunk at r1653143

I had though to fix some issues:
I removed 
3 specific comments



2 duplicates
Gesynchroniseerd
Req. - geannuleerd
For the later I kept the old one which seems more complete

I replaced 2482  by 
Please no longer use "_" but "-" there thanks!

> Adding som Dutch translations to common labels.
> ---
>
> Key: OFBIZ-6016
> URL: https://issues.apache.org/jira/browse/OFBIZ-6016
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6016-FrameworkCommonLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Is this a way to get the db view or the query behind ModelViewEntity

2015-01-19 Thread Justin Robinson
*Thanks to those who helped me with my last question*

I've had a look at the code of ModelViewEntity briefly, that together with
the following abstract:

"A few things about view-entities View-entities are very powerful and allow
you to create join-like queries, even when your database doesn't support
joins." - ofbiz entity cookbook.

Seems to suggest that view entity xml model info is used to piece the view
entity together.

Still I need to write a script to create views on a mysql database that
correspond to all ofbiz 10.04 view entities on a very large system.

Please can I have some advice about how best to go about such a task.

*Looking at the content of this mailing list and the warning to post to be
right list, I wonder if I shouldn't be asking this on users - still I'm not
a user - pls let me know if I should use the other list.*


[jira] [Commented] (OFBIZ-6015) Move Online Help Documentation from Webhelp into Trunk

2015-01-19 Thread Ron Wheeler (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282960#comment-14282960
 ] 

Ron Wheeler commented on OFBIZ-6015:


Topic-based writing seems like a good way to build documentation and encourages 
reuse rather that copy and paste.
Splitting up the documentation into sections based on screens/business 
processes with concepts as separate fragments will make the use of the 
documentation for various purposes (on-line help, program specifications, 
training, manuals, job-aids, etc.) much easier.
It may also encourage developers and business consultants to contribute 
fragments from user requirements, design specifications or even design 
discussions that can be used to construct documents.
The big issue here is naming and tagging fragments so that it is easy to find 
the pieces that you want.
The initial suggestion about using the SCM (SVN) to store them only works if 
the documentation team has write access and can manage the structure of the 
fragments easily. A CMS would be a better choice. If the document production 
steps can support access to fragments in the CMS, that would be ideal.



> Move Online Help Documentation from Webhelp into Trunk
> --
>
> Key: OFBIZ-6015
> URL: https://issues.apache.org/jira/browse/OFBIZ-6015
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Reporter: Sharan Foga
>Assignee: Sharan Foga
>Priority: Minor
>
> This Jira has been created to manage the migration of all the documentation 
> from the Webhelp branch into the current help system so that it will work 
> with what we already have (essentially so that we dont lose it!).  The 
> original issue for the Webhelp is 
> https://issues.apache.org/jira/browse/OFBIZ-4941
> As well as HR, there is also online documentation for Accounting, 
> Manufacturing (English, German and Dutch), Project Manager and Catalog - 
> though not as complete, so I will be consolidating and moving those too.
> The files use the docbook format and are compatible with what we have 
> although he implemented everything into one file whereas we use one file per 
> screen - so I'll need to split it up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282890#comment-14282890
 ] 

Jacques Le Roux commented on OFBIZ-5959:


GCR stands for?

> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282886#comment-14282886
 ] 

Jacques Le Roux commented on OFBIZ-5959:


Ha indeed, somehow I missed the "type" word. Thanks for the information about 
David Hay's XxxConstraint entities. I had no ideas about that, interesting 
point!

> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-3464) Added check if the creditcard number string is numeric in validation method isCreditcard in UtilValidate

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-3464:
---
Fix Version/s: Upcoming Branch
   13.07.02
   12.04.06
   14.12.01

> Added check if the creditcard number string is numeric in validation method 
> isCreditcard in UtilValidate
> 
>
> Key: OFBIZ-3464
> URL: https://issues.apache.org/jira/browse/OFBIZ-3464
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Reporter: Nils Pförtner
>Assignee: Ashish Vijaywargiya
> Fix For: 14.12.01, 12.04.06, 13.07.02, Upcoming Branch
>
> Attachments: OFBIZ-3464_UtilValidate.patch
>
>
> Added check if the creditcard number string is numeric in validation method 
> isCreditcard in UtilValidate



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Closed] (OFBIZ-3464) Added check if the creditcard number string is numeric in validation method isCreditcard in UtilValidate

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-3464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux closed OFBIZ-3464.
--

Backported in
R14.12 r1653065
R13.07 r1653066
R12.04 r1653067


> Added check if the creditcard number string is numeric in validation method 
> isCreditcard in UtilValidate
> 
>
> Key: OFBIZ-3464
> URL: https://issues.apache.org/jira/browse/OFBIZ-3464
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Reporter: Nils Pförtner
>Assignee: Ashish Vijaywargiya
> Fix For: 14.12.01, 12.04.06, 13.07.02, Upcoming Branch
>
> Attachments: OFBIZ-3464_UtilValidate.patch
>
>
> Added check if the creditcard number string is numeric in validation method 
> isCreditcard in UtilValidate



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5364) Incorrect quantityNotAvailable for OrderItemShipGrpInvRes when issuing items to shipments

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282722#comment-14282722
 ] 

Jacques Le Roux commented on OFBIZ-5364:


I have temporary removed (commented out) the testMultipleInventoryItemIssuance 
test after r1649408 and r1650455 in trunk at r1653056

> Incorrect quantityNotAvailable for OrderItemShipGrpInvRes when issuing items 
> to shipments
> -
>
> Key: OFBIZ-5364
> URL: https://issues.apache.org/jira/browse/OFBIZ-5364
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 12.04
>Reporter: Christian Carlow
>Assignee: Ashish Vijaywargiya
> Attachments: OFBIZ-5364.patch
>
>
> The quantityNotAvailable field of OrderItemShipGrpRes seems to reflect 
> incorrect numbers after shipment issuances occur.
> To reproduct:
> 1.  Create an order for DemoCustCompany for a quantity of 100 of a product 
> having no inventory quantity 
> 2.  Create a second ship group on the Shipping page
> 3.  Assign half of the order item quantity (50) to the second ship group 
> created and then finish creating the order
> 4.  Click the "New Shipment for Ship Group" button for the first ship group 
> and navigate to the "Order Items" page
> 5.  On the "Order Items" page, notice the issue quantity field is blank 
> because no inventory exist yet to be issued to the shipment.  
> 6.  Navigate to the WebstoreWarehouse Receive Inventory page and receive a 
> quantity of 1 for the order item product to increase the inventory by 1
> 7.  Refresh the Shipment Order Items page and you'll see the issue quantity 
> change to 1 because the inventoryItemId created in the last step was assigned 
> to the orderItemShipGrpInvRes for this item.
> 8.  Now change from ship group 1 to ship group 2 and notice the issue 
> quantity is blank
> 9.  Assign a quantity of 1 to the second ship group and click the "Issue All" 
> button
> 10.  Change the ship group back to 1 and notice the quantity in the issue 
> text box is still 1
> It seems like the issue text box in step 10 should be 0 instead of 1 since 
> the inventory item quantity was used for ship group 2.  
> Does anyone disagree?  Could I be misinterpreting the way the 
> OrderItemShipGrpInvRes is supposed to work?



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Adrian Crum (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282619#comment-14282619
 ] 

Adrian Crum commented on OFBIZ-5959:


I believe my comment on the mailing list has been misunderstood. The point I 
was making is this: In the PartyRelationship entity, the 
partyRelationshipTypeId field is optional - because the "from" and "to" party 
roles are enough to describe the party relationship. That conversation has 
nothing to do with this issue.

I am not opposed to this issue, and my comments in it were merely meant to warn 
everyone that this will be a big change.

I agree that the original intent of the PartyRole entity (as expressed in the 
DMRB) has been lost, and currently the entity is being used in another way. The 
current use of the entity is more like David Hay's XxxConstraint entities 
(Enterprise Model Patterns) - where the fk relationships to PartyRole are used 
to constrain how a party is related to various things. In practice, this fk 
relationship becomes cumbersome, and I have suggested in the past that we 
remove those fk relationships.


> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OFBIZ-5712) New Delegator Container and GLOBAL_BATCH thread pool

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282610#comment-14282610
 ] 

Jacques Le Roux edited comment on OFBIZ-5712 at 1/19/15 3:42 PM:
-

Hi Adam, any chances here? http://markmail.org/message/veeuoiozoacbxnay


was (Author: jacques.le.roux):
Hi Adam, any chances here?

> New Delegator Container and GLOBAL_BATCH thread pool
> 
>
> Key: OFBIZ-5712
> URL: https://issues.apache.org/jira/browse/OFBIZ-5712
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Adam Heath
>Assignee: Adam Heath
> Fix For: 14.12.01
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5712) New Delegator Container and GLOBAL_BATCH thread pool

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5712?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282610#comment-14282610
 ] 

Jacques Le Roux commented on OFBIZ-5712:


Hi Adam, any chances here?

> New Delegator Container and GLOBAL_BATCH thread pool
> 
>
> Key: OFBIZ-5712
> URL: https://issues.apache.org/jira/browse/OFBIZ-5712
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Adam Heath
>Assignee: Adam Heath
> Fix For: 14.12.01
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Ron Wheeler (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282598#comment-14282598
 ] 

Ron Wheeler commented on OFBIZ-4941:


Separate the documentation into a sub-project and let the documentation team 
that are not software writers commit to the docs.

Of course, the software committers would all be committers on the doc project.

This would also allow the documentation to be tagged, branched and released 
separately.
It is likely to be released more frequently than the software project which 
would be helpful.

I would suggest that we consider including the demo data in the documentation 
project so that the demos could be improved and coordinated with the 
documentation so that the OOTB demo matches the documentation and the demo data 
can be used in examples and figures.

If people are using the demo data as test data, we would have be careful with 
branching and tagging to support changes in the code that affects the entity 
model but at least the load of maintaining demo/test data would be more widely 
shared.


> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


Re: [jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Pierre Smits
I meant to say 'in the issue'.

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Jan 19, 2015 at 4:13 PM, Pierre Smits 
wrote:

> Ron,
>
> Please put your insights and suggestions as comment to the issue.
>
> Best regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
> On Mon, Jan 19, 2015 at 4:06 PM, Ron Wheeler <
> rwhee...@artifact-software.com> wrote:
>
>> Separate the documentation into a sub-project and let the documentation
>> team that are not software writers commit to the docs.
>>
>> Of course, the software committers would all be committers on the doc
>> project.
>>
>> This would also allow the documentation to be tagged, branched and
>> released separately.
>> It is likely to be released more frequently than the software project
>> which would be helpful.
>>
>> I would suggest that we consider including the demo data in the
>> documentation project so that the demos could be improved and coordinated
>> with the documentation so that the OOTB demo matches the documentation and
>> the demo data can be used in examples and figures.
>>
>>
>> Ron
>>
>>
>> On 19/01/2015 8:35 AM, Jacques Le Roux (JIRA) wrote:
>>
>>>  [ https://issues.apache.org/jira/browse/OFBIZ-4941?page=
>>> com.atlassian.jira.plugin.system.issuetabpanels:comment-
>>> tabpanel&focusedCommentId=14282494#comment-14282494 ]
>>>
>>> Jacques Le Roux commented on OFBIZ-4941:
>>> 
>>>
>>> I proposed to use AsciiDoc instead of Docbook because despite having
>>> [Oxygen in Eclipse|http://www.oxygenxml.com/xml_editor/eclipse_plugin.
>>> html#s2_docbook_documents_support] I found that it's not that easy to
>>> create documentation with Docbook, even with a specialised tool, so think
>>> about people with only XML.  I believe AsciiDoc opens more possibilities,
>>> like for instance as you said, supports of in-line GraphViz.
>>>
>>> The idea is to use only AsciiDoc (everywhere) because , it seems to me,
>>> it has won the game among Lightweight markup formats.
>>>
>>> Following is a bit unrelated, but you will see where I going with this
>>> 
>>> *I HATE CONFLUENCE* since they removed the possibility to use their own
>>> markup format. Actually I was already *HATING IT BEFORE*. Their rendering
>>> has always been erratic, to say the least.
>>>
>>> Currently, despite ourt efforts, what we have in Confluence is a big
>>> ball of mud.
>>>
>>> * Try for instance to replace a string in all a worskspace (not even
>>> speaking about several ones).  For instance, our complete domain name
>>> (actually a sub-domain name) is now _cwiki.apache.org/confluence_ when
>>> it was historically _docs.ofbiz.org_ before we moved from Contegix to the
>>> ASF Confluence instance. Of course this is impossible, can you believe it?
>>> So you have to do it *PAGE BY PAGE*, good luch with that! Just look at this
>>> link to have an idea.
>>> https://cwiki.apache.org/confluence/dosearchsite.
>>> action?queryString=&where=conf_favorites&type=&
>>> lastModified=&contributor=&contributorUsername=&
>>> queryString=docs.ofbiz.org
>>> * Moreover when it's only about a string it's somewhat doable, but just
>>> try to do it for URLs, yes it's a nightmare!
>>> * Not only that but, as the ASF confluence instance is shared between a
>>> lot of projects, it's *SLOW*. Even barely reliable sometimes for long pages
>>> like the FAQ or the Minilang reference.
>>> * The information given for a page is not able to distinguish wrong links
>>> * There are a lot of obsolete, incomplete and confusing information in
>>> the wiki worskspace, and a lot of obsolete comments
>>> * Try to remove obsolete comments, it's not only *SLOW* but you have to
>>> remove them *ONE BY ONE*.
>>>
>>> I could go on and on. The only advantage Confluence had was how it
>>> handled access permissions. But with the last infra change due to spam,
>>> this is not even interesting now. We have to handle every contributors
>>> access ourselves. And sorry to say but from our current experience there is
>>> not a good ROI. People want to be contributors, but few contribute. We
>>> could handle that better using svn and AsciiDoc ourselves (committers).
>>> People really wanting to contribute would give us their contributions,
>>> through Jira for instance.
>>>
>>> OK, it's just an idea for now, but I really would like to go this way.
>>> Using https://marketplace.atlassian.com/plugins/com.k15t.scroll.
>>> scroll-docbook (would need to ask infra to install it for us) we could
>>> begin in DocBook format, before moving all in AsciiDoc.  Then we could use
>>> Buildbot to generate the documentation automatically using Pandoc. Where to
>>> post it is secondary, at the ASF of course! Using the demo VM seems the
>>> right p

Re: [jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Pierre Smits
Ron,

Please put your insights and suggestions as comment to the issue.

Best regards,

Pierre Smits

*ORRTIZ.COM *
Services & Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail & Trade
http://www.orrtiz.com

On Mon, Jan 19, 2015 at 4:06 PM, Ron Wheeler  wrote:

> Separate the documentation into a sub-project and let the documentation
> team that are not software writers commit to the docs.
>
> Of course, the software committers would all be committers on the doc
> project.
>
> This would also allow the documentation to be tagged, branched and
> released separately.
> It is likely to be released more frequently than the software project
> which would be helpful.
>
> I would suggest that we consider including the demo data in the
> documentation project so that the demos could be improved and coordinated
> with the documentation so that the OOTB demo matches the documentation and
> the demo data can be used in examples and figures.
>
>
> Ron
>
>
> On 19/01/2015 8:35 AM, Jacques Le Roux (JIRA) wrote:
>
>>  [ https://issues.apache.org/jira/browse/OFBIZ-4941?page=
>> com.atlassian.jira.plugin.system.issuetabpanels:comment-
>> tabpanel&focusedCommentId=14282494#comment-14282494 ]
>>
>> Jacques Le Roux commented on OFBIZ-4941:
>> 
>>
>> I proposed to use AsciiDoc instead of Docbook because despite having
>> [Oxygen in Eclipse|http://www.oxygenxml.com/xml_editor/eclipse_plugin.
>> html#s2_docbook_documents_support] I found that it's not that easy to
>> create documentation with Docbook, even with a specialised tool, so think
>> about people with only XML.  I believe AsciiDoc opens more possibilities,
>> like for instance as you said, supports of in-line GraphViz.
>>
>> The idea is to use only AsciiDoc (everywhere) because , it seems to me,
>> it has won the game among Lightweight markup formats.
>>
>> Following is a bit unrelated, but you will see where I going with this
>> 
>> *I HATE CONFLUENCE* since they removed the possibility to use their own
>> markup format. Actually I was already *HATING IT BEFORE*. Their rendering
>> has always been erratic, to say the least.
>>
>> Currently, despite ourt efforts, what we have in Confluence is a big ball
>> of mud.
>>
>> * Try for instance to replace a string in all a worskspace (not even
>> speaking about several ones).  For instance, our complete domain name
>> (actually a sub-domain name) is now _cwiki.apache.org/confluence_ when
>> it was historically _docs.ofbiz.org_ before we moved from Contegix to the
>> ASF Confluence instance. Of course this is impossible, can you believe it?
>> So you have to do it *PAGE BY PAGE*, good luch with that! Just look at this
>> link to have an idea.
>> https://cwiki.apache.org/confluence/dosearchsite.
>> action?queryString=&where=conf_favorites&type=&
>> lastModified=&contributor=&contributorUsername=&
>> queryString=docs.ofbiz.org
>> * Moreover when it's only about a string it's somewhat doable, but just
>> try to do it for URLs, yes it's a nightmare!
>> * Not only that but, as the ASF confluence instance is shared between a
>> lot of projects, it's *SLOW*. Even barely reliable sometimes for long pages
>> like the FAQ or the Minilang reference.
>> * The information given for a page is not able to distinguish wrong links
>> * There are a lot of obsolete, incomplete and confusing information in
>> the wiki worskspace, and a lot of obsolete comments
>> * Try to remove obsolete comments, it's not only *SLOW* but you have to
>> remove them *ONE BY ONE*.
>>
>> I could go on and on. The only advantage Confluence had was how it
>> handled access permissions. But with the last infra change due to spam,
>> this is not even interesting now. We have to handle every contributors
>> access ourselves. And sorry to say but from our current experience there is
>> not a good ROI. People want to be contributors, but few contribute. We
>> could handle that better using svn and AsciiDoc ourselves (committers).
>> People really wanting to contribute would give us their contributions,
>> through Jira for instance.
>>
>> OK, it's just an idea for now, but I really would like to go this way.
>> Using https://marketplace.atlassian.com/plugins/com.k15t.scroll.
>> scroll-docbook (would need to ask infra to install it for us) we could
>> begin in DocBook format, before moving all in AsciiDoc.  Then we could use
>> Buildbot to generate the documentation automatically using Pandoc. Where to
>> post it is secondary, at the ASF of course! Using the demo VM seems the
>> right place, we have already HTTPS serving the large videos there.
>> Of course this is not for tomorrow, but I believe it's the way to go if
>> we want a really reliable, as complete as possible documentation. Without
>> it OFBiz will never get the attention it deserves... :(
>>
>>  Proposal for a new help system
>>> --
>>>
>>>  Key: OFBIZ-4941
>>>  

Re: [jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Ron Wheeler
Separate the documentation into a sub-project and let the documentation 
team that are not software writers commit to the docs.


Of course, the software committers would all be committers on the doc 
project.


This would also allow the documentation to be tagged, branched and 
released separately.
It is likely to be released more frequently than the software project 
which would be helpful.


I would suggest that we consider including the demo data in the 
documentation project so that the demos could be improved and 
coordinated with the documentation so that the OOTB demo matches the 
documentation and the demo data can be used in examples and figures.



Ron

On 19/01/2015 8:35 AM, Jacques Le Roux (JIRA) wrote:

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282494#comment-14282494
 ]

Jacques Le Roux commented on OFBIZ-4941:


I proposed to use AsciiDoc instead of Docbook because despite having [Oxygen in 
Eclipse|http://www.oxygenxml.com/xml_editor/eclipse_plugin.html#s2_docbook_documents_support]
 I found that it's not that easy to create documentation with Docbook, even 
with a specialised tool, so think about people with only XML.  I believe 
AsciiDoc opens more possibilities, like for instance as you said, supports of 
in-line GraphViz.

The idea is to use only AsciiDoc (everywhere) because , it seems to me, it has 
won the game among Lightweight markup formats.

Following is a bit unrelated, but you will see where I going with this

*I HATE CONFLUENCE* since they removed the possibility to use their own markup 
format. Actually I was already *HATING IT BEFORE*. Their rendering has always 
been erratic, to say the least.

Currently, despite ourt efforts, what we have in Confluence is a big ball of 
mud.

* Try for instance to replace a string in all a worskspace (not even speaking 
about several ones).  For instance, our complete domain name (actually a 
sub-domain name) is now _cwiki.apache.org/confluence_ when it was historically 
_docs.ofbiz.org_ before we moved from Contegix to the ASF Confluence instance. 
Of course this is impossible, can you believe it? So you have to do it *PAGE BY 
PAGE*, good luch with that! Just look at this link to have an idea.
https://cwiki.apache.org/confluence/dosearchsite.action?queryString=&where=conf_favorites&type=&lastModified=&contributor=&contributorUsername=&queryString=docs.ofbiz.org
* Moreover when it's only about a string it's somewhat doable, but just try to 
do it for URLs, yes it's a nightmare!
* Not only that but, as the ASF confluence instance is shared between a lot of 
projects, it's *SLOW*. Even barely reliable sometimes for long pages like the 
FAQ or the Minilang reference.
* The information given for a page is not able to distinguish wrong links
* There are a lot of obsolete, incomplete and confusing information in the wiki 
worskspace, and a lot of obsolete comments
* Try to remove obsolete comments, it's not only *SLOW* but you have to remove 
them *ONE BY ONE*.

I could go on and on. The only advantage Confluence had was how it handled 
access permissions. But with the last infra change due to spam, this is not 
even interesting now. We have to handle every contributors access ourselves. 
And sorry to say but from our current experience there is not a good ROI. 
People want to be contributors, but few contribute. We could handle that better 
using svn and AsciiDoc ourselves (committers). People really wanting to 
contribute would give us their contributions, through Jira for instance.

OK, it's just an idea for now, but I really would like to go this way. Using 
https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-docbook (would 
need to ask infra to install it for us) we could begin in DocBook format, 
before moving all in AsciiDoc.  Then we could use Buildbot to generate the 
documentation automatically using Pandoc. Where to post it is secondary, at the 
ASF of course! Using the demo VM seems the right place, we have already HTTPS 
serving the large videos there.
Of course this is not for tomorrow, but I believe it's the way to go if we want 
a really reliable, as complete as possible documentation. Without it OFBiz will 
never get the attention it deserves... :(


Proposal for a new help system
--

 Key: OFBIZ-4941
 URL: https://issues.apache.org/jira/browse/OFBIZ-4941
 Project: OFBiz
  Issue Type: Wish
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Paul Foxworthy
Priority: Minor
 Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
OFBIZ-4941.patch, OFBIZ-

[jira] [Issue Comment Deleted] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-5959:

Comment: was deleted

(was: An equally quick analogy:

{quote}
For every road to Rome there is an alternative. Some prefer to travel on one 
road at some times, and on the other roads at other times. Some are required to 
use the one, others are obliged to travel the other.
{quote}
)

> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282578#comment-14282578
 ] 

Pierre Smits commented on OFBIZ-5959:
-

An equally quick analogy:

{quote}
For every road to Rome there is an alternative. Some prefer to travel on one 
road at some times, and on the other roads at other times. Some are required to 
use the one, others are obliged to travel the other.
{quote}


> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Gil Portenseigne (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282564#comment-14282564
 ] 

Gil Portenseigne commented on OFBIZ-5959:
-

Quick answer to illustrate my way to deal with the given scenarii, then i'll 
read the doc you link about the UDM

The fact that makes me have this opinion is that, for such kind of screens, i 
use to customize the screen to show only the roles that should be usable in the 
customer process, not the global list. Then the customized screen let us choose 
any party without ensuring that he possess the good role, and behind that, the 
creation of *Entity*Role record, will create the PartyRole if needed.

The way you describe the first scenario imply that we have to manage each party 
role independantly before associating the party to the Agreement (PartyRel or 
so). I do not find that convenient, and i'd appreciate to have more testimony 
about this matter.

For the second scenario, i'm not sure that automation is the good way to do. 
It's like adding the option to terminate all EntityRole records of the party 
and given role. It might be useful in specific cases. But i think that to know 
if the role is active or not, it's better to check *Entity*Role, than 
PartyRole...



> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282548#comment-14282548
 ] 

Jacques Le Roux commented on OFBIZ-4941:


No needs to put that in releases as long it's available online, like we have 
the demos

> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282545#comment-14282545
 ] 

Pierre Smits commented on OFBIZ-4941:
-

I can relate to the arguments, both the complaints about the products and the 
drive to onboard more and diverse contributors and committers.

But we have to consider that if we were to move all kinds of documents into 
OFBiz and make it available as part of a release we will increase the size of 
our product considerably. We have to take into the equation, that the users are 
not waiting to get loads of development documentation etc. They prefer to have 
that in the hands of the system integrators.


> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282534#comment-14282534
 ] 

Pierre Smits edited comment on OFBIZ-5959 at 1/19/15 2:15 PM:
--

I can follow the reasoning and would be inclined to share your viewpoint, if we 
would not follow the 'Universal Data Model' as the guiding aspect regarding 
entity models. And guess what: it is in the UDM. 

See following articles (and incorporated diagrams):
* 
[http://www.universaldatamodels.com/Portals/9/udm_Publication_Articles_11_05_Models_Patterns.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_5_02_Healthcare.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_7_02_Financial_Serv.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_3_02_Relationship_Dev.pdf]

To name but a few. 

And the reason why it is in the UDM is simple. It all has to do with the aspect 
of being able to track and trace changes (as part of GCR). Not having the 
fromDate and thruDate fields in that entity makes it harder to track changes. 

Apart from the aspect above, it has additional benefits, as it ensures that 
only those persons are shown in drop down fields and other selection mechanism 
in derivative functions. Not the persons who had the role in the past and are 
not in that role anymore, and potentially not those persons who have the role 
in the future and not now (although the latter is debatable - depending on 
requirements). Having the right set of people, based on the attribute 
filter-by-date, available for selection reduces data traffic and improves user 
experience.

Let me outline briefly two scenarios of what might happen without PartyRoles 
and the assignment to persons as prerequisite for dependent functionalities 
(forgoing the aspect that current functionality throughout the entire feature 
set doesn't factor in PartyRelationship in any person selection, see issue 
[https://issues.apache.org/jira/browse/OFBIZ-5827] or Employment with respect 
to internal persons, see issue 
[https://issues.apache.org/jira/browse/OFBIZ-5832]).

Scenario
{quote}
Have a look at the following screen: 
[http://demo-trunk-ofbiz.apache.org/accounting/control/EditAgreementRoles?agreementId=8000]
In current feature set of OFBiz the search for the right person can be long, 
type ahead only delivers a specific number of hits and then you have to go 
through the list of all the roles available to find the right one. Our current 
demo data set is limited, but imagine how that will be experienced in a real 
life scenario, when multiple parties need to be added to a specific agreement 
and over and over again for each new agreement. Not very user friendly, I would 
say.

Now imagine the following, in the screen above you find the person and the drop 
down field were to show only the roles he has. You would instantly know whether 
that person has the right role (as intended with issue: 
[https://issues.apache.org/jira/browse/OFBIZ-5990]. Or another potential 
improvement inclusion: you type the role and you get the appropriate persons. 
{quote}

Another scenario
{quote}
Suppose that all agreements registered in a real life scenario and all 
agreements have parties been assigned to various roles. Suppose also that a 
internal person has left the company and all agreements needs to be revisited 
to evaluate whether the assignment needs to be adjusted.
Evaluation and maintainability of the validity of the records regarding the 
other Role entities is much more cumbersome without automation (again 
not user friendly) and/or more complex to achieve with automation. Or there is 
no uniformity.
{quote}

For sure, if we were to question the people considering OFBiz the majority is 
either investigating it for a small setup (the person in the small 
organisation) or considering it as a  setup for small users (the system 
integrator). 
But we always have to keep in mind that OFBiz is not just for the smaller 
organisation (where shortcuts are applied visavis compexity), but also the 
larger/more complex organisations. These larger organisations have a lot more 
data to manage and/or complex organisational setups to delegate authority (to 
central back offices, or a multitude of persons in middle mgt). Think of 
Stannah (see this testimonial: 
[http://ofbiz.markmail.org/message/phwl43o5vzwvfwmc?q=stannah]) as such an 
OFBiz user. 

OFbiz is a suite of generic solutions intended for all kinds of organisational 
setups and this kind of refactoring (improvement) of business functionality not 
only ensures that it stays in the top bracket functionality wise. It also keeps 
us in the position to promote it with the slogan 'Yes, it works for you too' 
and drive adoption. Not only of users, but also with respect to a diversity in 
contributors.




was (Author: pfm.smits):
I can follow th

[jira] [Comment Edited] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282534#comment-14282534
 ] 

Pierre Smits edited comment on OFBIZ-5959 at 1/19/15 2:14 PM:
--

I can follow the reasoning and would be inclined to share your viewpoint, if we 
would not follow the 'Universal Data Model' as the guiding aspect regarding 
entity models. And guess what: it is in the UDM. 

See following articles (and incorporated diagrams):
* 
[http://www.universaldatamodels.com/Portals/9/udm_Publication_Articles_11_05_Models_Patterns.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_5_02_Healthcare.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_7_02_Financial_Serv.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_3_02_Relationship_Dev.pdf]

To name but a few. 

And the reason why it is in the UDM is simple. It all has to do with the aspect 
of being able to track and trace changes (as part of GCR). Not having the 
fromDate and thruDate fields in that entity makes it harder to track changes. 

Apart from the aspect above, it has additional benefits, as it ensures that 
only those persons are shown in drop down fields and other selection mechanism 
in derivative functions. Not the persons who had the role in the past and are 
not in that role anymore, and potentially not those persons who have the role 
in the future and not now (although the latter is debatable - depending on 
requirements). Having the right set of people, based on the attribute 
filter-by-date, available for selection reduces data traffic and improves user 
experience.

Let me outline briefly two scenarios of what might happen without PartyRoles 
and the assignment to persons as prerequisite for dependent functionalities 
(forgoing the aspect that current functionality throughout the entire feature 
set doesn't factor in PartyRelationship in any person selection, see issue 
[https://issues.apache.org/jira/browse/OFBIZ-5827] or Employment with respect 
to internal persons, see issue 
[https://issues.apache.org/jira/browse/OFBIZ-5832]).

Scenario
{quote}
Have a look at the following screen: 
[http://demo-trunk-ofbiz.apache.org/accounting/control/EditAgreementRoles?agreementId=8000]
In current feature set of OFBiz the search for the right person can be long, 
type ahead only delivers a specific number of hits and then you have to go 
through the list of all the roles available to find the right one. Our current 
demo data set is limited, but imagine how that will be experienced in a real 
life scenario, when multiple parties need to be added to a specific agreement 
and over and over again for each new agreement. Not very user friendly, I would 
say.

Now imagine the following, in the screen above you find the person and the drop 
down field were to show only the roles he has. You would instantly know whether 
that person has the right role (as intended with issue: 
[https://issues.apache.org/jira/browse/OFBIZ-5990]. Or another potential 
improvement inclusion: you type the role and you get the appropriate persons. 
{quote}

Another scenario
{quote}
Suppose that all agreements registered in a real life scenario and all 
agreements have parties been assigned to various roles. Suppose also that a 
internal person has left the company and all agreements needs to be revisited 
to evaluate whether the assignment needs to be adjusted.
Evaluation and maintainability of the validity of the records regarding the 
other Role entities is much more cumbersome without automation (again 
not user friendly) and/or more complex to achieve with automation. Or there is 
no uniformity.
{quote}

For sure, if we were to question the people considering OFBiz these the 
majority is either investigating it for a small setup (the person in the small 
organisation)or considering it as a  setup for small users (the system 
integrator). But always have to keep in mind that OFBiz is not just for the 
smaller organisation (where shortcuts are applied visavis compexity), but also 
the larger/more complex organisations. These larger organisations have a lot 
more data to manage and/or complex organisational setups to delegate authority 
(to central back offices, or a multitude of persons in middle mgt). Think of 
Stannah (see this testimonial: 
[http://ofbiz.markmail.org/message/phwl43o5vzwvfwmc?q=stannah]) as such an 
OFBiz user. 

OFbiz is a suite of generic solutions intended for all kinds of organisational 
setups and this kind of refactoring (improvement) of business functionality not 
only ensures that it stays in the top bracket functionality wise. It also keeps 
us in the position to promote it with the slogan 'Yes, it works for you too' 
and drive adoption. Not only of users, but also with respect to a diversity in 
contributors.




was (Author: pfm.smits):
I can follow t

[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282534#comment-14282534
 ] 

Pierre Smits commented on OFBIZ-5959:
-

I can follow the reasoning and would be inclined to share your viewpoint, if we 
would not follow the 'Universal Data Model' as the guiding aspect regarding 
entity models. And guess what: it is in the UDM. 

See following articles (and incorporated diagrams):
* 
[http://www.universaldatamodels.com/Portals/9/udm_Publication_Articles_11_05_Models_Patterns.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_5_02_Healthcare.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_7_02_Financial_Serv.pdf]
* 
[http://www.universaldatamodels.com/Portals/9/Publication_Articles_3_02_Relationship_Dev.pdf]

To name but a few. 

And the reason why it is in the UDM is simple. It all has to do with the aspect 
of being able to track and trace changes (as part of GCR). Not having the 
fromDate and thruDate fields in that entity makes it harder to track changes. 

Apart from the aspect above, it has additional benefits, as it ensures that 
only those persons are shown in drop down fields and other selection mechanism 
in derivative functions. Not the persons who had the role in the past and are 
not in that role anymore, and potentially not those persons who have the role 
in the future and not now (although the latter is debatable - depending on 
requirements). Having the right set of people, based on the attribute 
filter-by-date, available for selection reduces data traffic and improves user 
experience.

Let me outline briefly two scenarios of what might happen without PartyRoles 
and the assignment to persons as prerequisite for dependent functionalities 
(forgoing the aspect that current functionality throughout the entire feature 
set doesn't factor in PartyRelationship in any person selection, see issue 
[https://issues.apache.org/jira/browse/OFBIZ-5827] or Employment with respect 
to internal persons, see issue 
[https://issues.apache.org/jira/browse/OFBIZ-5832]).

Scenario
{quote}
Have a look at the following screen: 
[http://demo-trunk-ofbiz.apache.org/accounting/control/EditAgreementRoles?agreementId=8000]
In current feature set of OFBiz the search for the right person can be long, 
type ahead only delivers a specific number of hits and then you have to go 
through the list of all the roles available to find the right one. Our current 
demo data set is limited, but imagine how that will be experienced in a real 
life scenario, when multiple parties need to be added to a specific agreement 
and over and over again for each new agreement. Not very user friendly, I would 
say.

Now imagine the following, in the screen above you find the person and the drop 
down field were to show only the roles he has. You would instantly know whether 
that person has the right role (as intended with issue: 
[https://issues.apache.org/jira/browse/OFBIZ-5990]. Or another potential 
improvement inclusion: you type the role and you get the appropriate persons. 
{quote}

{quote}
Scenario two:
Suppose that all agreements registered in a real life scenario and all 
agreements have parties been assigned to various roles. Suppose also that a 
internal person has left the company and all agreements needs to be revisited 
to evaluate whether the assignment needs to be adjusted.
Evaluation and maintainability of the validity of the records regarding the 
other Role entities is much more cumbersome without automation (again 
not user friendly) and/or more complex to achieve with automation. Or there is 
no uniformity.
{quote}

For sure, if we were to question the people considering OFBiz these the 
majority is either investigating it for a small setup (the person in the small 
organisation)or considering it as a  setup for small users (the system 
integrator). But always have to keep in mind that OFBiz is not just for the 
smaller organisation (where shortcuts are applied visavis compexity), but also 
the larger/more complex organisations. These larger organisations have a lot 
more data to manage and/or complex organisational setups to delegate authority 
(to central back offices, or a multitude of persons in middle mgt). Think of 
Stannah (see this testimonial: 
[http://ofbiz.markmail.org/message/phwl43o5vzwvfwmc?q=stannah]) as such an 
OFBiz user. 

OFbiz is a suite of generic solutions intended for all kinds of organisational 
setups and this kind of refactoring (improvement) of business functionality not 
only ensures that it stays in the top bracket functionality wise. It also keeps 
us in the position to promote it with the slogan 'Yes, it works for you too' 
and drive adoption. Not only of users, but also with respect to a diversity in 
contributors.



> Add lifespan fields to PartyRole
> 
>
> Ke

[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282503#comment-14282503
 ] 

Jacques Le Roux commented on OFBIZ-5959:


Scott,

{quote}
I can't really even think of a reason why PartyRole exists as all.
{quote}

I'd be interested by Adrian's view on PartyRole vs PartyRelationship, see 
http://markmail.org/message/3viepadtxyxm4mzx
{quote}
The party relationship type is optional, typically the party roles are enough 
to describe the relationship.
{quote}


> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Comment Edited] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282494#comment-14282494
 ] 

Jacques Le Roux edited comment on OFBIZ-4941 at 1/19/15 1:37 PM:
-

I proposed to use AsciiDoc instead of Docbook because despite having [Oxygen in 
Eclipse|http://www.oxygenxml.com/xml_editor/eclipse_plugin.html#s2_docbook_documents_support]
 I found that it's not that easy to create documentation with Docbook, even 
with a specialised tool, so think about people with only XML.  I believe 
AsciiDoc opens more possibilities, like for instance as you said, supports of 
in-line GraphViz.

The idea is to use only AsciiDoc (everywhere) because , it seems to me, it has 
won the game among Lightweight markup formats.

Following is a bit unrelated, but you will see where I going with this

*I HATE CONFLUENCE* since they removed the possibility to use their own markup 
format. Actually I was already *HATING IT BEFORE*. Their rendering has always 
been erratic, to say the least.

Currently, despite ourt efforts, what we have in Confluence is a big ball of 
mud.

* Try for instance to replace a string in all a worskspace (not even speaking 
about several ones).  For instance, our complete domain name (actually a 
sub-domain name) is now _cwiki.apache.org/confluence_ when it was historically 
_docs.ofbiz.org_ before we moved from Contegix to the ASF Confluence instance. 
Of course this is impossible, can you believe it? So you have to do it *PAGE BY 
PAGE*, good luch with that! Just look at this link to have an idea.
https://cwiki.apache.org/confluence/dosearchsite.action?queryString=&where=conf_favorites&type=&lastModified=&contributor=&contributorUsername=&queryString=docs.ofbiz.org
* Moreover when it's only about a string it's somewhat doable, but just try to 
do it for URLs, yes it's a nightmare!
* Not only that but, as the ASF confluence instance is shared between a lot of 
projects, it's *SLOW*. Even barely reliable sometimes for long pages like the 
FAQ or the Minilang reference.
* The information given for a page is not able to distinguish wrong links
* There are a lot of obsolete, incomplete and confusing information in the wiki 
worskspace, and a lot of obsolete comments
* Try to remove obsolete comments, it's not only *SLOW* but you have to remove 
them *ONE BY ONE*.

I could go on and on. The only advantage Confluence had was how it handled 
access permissions. But with the last infra change due to spam, this is not 
even interesting now. We have to handle every contributors access ourselves. 
And sorry to say but from our current experience there is not a good ROI. 
People want to be contributors, but few contribute. We could handle that better 
using svn and AsciiDoc ourselves (committers). People really wanting to 
contribute would give us their contributions, through Jira for instance.

OK, it's just an idea for now, but I really would like to go this way. Using 
https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-docbook (would 
need to ask infra to install it for us) we could begin in DocBook format, 
before moving all in AsciiDoc.  Then we could use Buildbot to generate the 
documentation automatically using Pandoc. Where to post it is secondary, at the 
ASF of course! Using the demo VM seems the right place, we have already HTTPD 
serving the large videos there.

Of course this is not for tomorrow, but I believe it's the way to go if we want 
a really reliable, as complete as possible documentation. Without it OFBiz will 
never get the attention it deserves... :(


was (Author: jacques.le.roux):
I proposed to use AsciiDoc instead of Docbook because despite having [Oxygen in 
Eclipse|http://www.oxygenxml.com/xml_editor/eclipse_plugin.html#s2_docbook_documents_support]
 I found that it's not that easy to create documentation with Docbook, even 
with a specialised tool, so think about people with only XML.  I believe 
AsciiDoc opens more possibilities, like for instance as you said, supports of 
in-line GraphViz.

The idea is to use only AsciiDoc (everywhere) because , it seems to me, it has 
won the game among Lightweight markup formats.

Following is a bit unrelated, but you will see where I going with this

*I HATE CONFLUENCE* since they removed the possibility to use their own markup 
format. Actually I was already *HATING IT BEFORE*. Their rendering has always 
been erratic, to say the least.

Currently, despite ourt efforts, what we have in Confluence is a big ball of 
mud.

* Try for instance to replace a string in all a worskspace (not even speaking 
about several ones).  For instance, our complete domain name (actually a 
sub-domain name) is now _cwiki.apache.org/confluence_ when it was historically 
_docs.ofbiz.org_ before we moved from Contegix to the ASF Confluence instance. 
Of course this is impossible, can you believe it? So you h

[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282494#comment-14282494
 ] 

Jacques Le Roux commented on OFBIZ-4941:


I proposed to use AsciiDoc instead of Docbook because despite having [Oxygen in 
Eclipse|http://www.oxygenxml.com/xml_editor/eclipse_plugin.html#s2_docbook_documents_support]
 I found that it's not that easy to create documentation with Docbook, even 
with a specialised tool, so think about people with only XML.  I believe 
AsciiDoc opens more possibilities, like for instance as you said, supports of 
in-line GraphViz.

The idea is to use only AsciiDoc (everywhere) because , it seems to me, it has 
won the game among Lightweight markup formats.

Following is a bit unrelated, but you will see where I going with this

*I HATE CONFLUENCE* since they removed the possibility to use their own markup 
format. Actually I was already *HATING IT BEFORE*. Their rendering has always 
been erratic, to say the least.

Currently, despite ourt efforts, what we have in Confluence is a big ball of 
mud.

* Try for instance to replace a string in all a worskspace (not even speaking 
about several ones).  For instance, our complete domain name (actually a 
sub-domain name) is now _cwiki.apache.org/confluence_ when it was historically 
_docs.ofbiz.org_ before we moved from Contegix to the ASF Confluence instance. 
Of course this is impossible, can you believe it? So you have to do it *PAGE BY 
PAGE*, good luch with that! Just look at this link to have an idea.
https://cwiki.apache.org/confluence/dosearchsite.action?queryString=&where=conf_favorites&type=&lastModified=&contributor=&contributorUsername=&queryString=docs.ofbiz.org
* Moreover when it's only about a string it's somewhat doable, but just try to 
do it for URLs, yes it's a nightmare!
* Not only that but, as the ASF confluence instance is shared between a lot of 
projects, it's *SLOW*. Even barely reliable sometimes for long pages like the 
FAQ or the Minilang reference.
* The information given for a page is not able to distinguish wrong links
* There are a lot of obsolete, incomplete and confusing information in the wiki 
worskspace, and a lot of obsolete comments
* Try to remove obsolete comments, it's not only *SLOW* but you have to remove 
them *ONE BY ONE*.

I could go on and on. The only advantage Confluence had was how it handled 
access permissions. But with the last infra change due to spam, this is not 
even interesting now. We have to handle every contributors access ourselves. 
And sorry to say but from our current experience there is not a good ROI. 
People want to be contributors, but few contribute. We could handle that better 
using svn and AsciiDoc ourselves (committers). People really wanting to 
contribute would give us their contributions, through Jira for instance.

OK, it's just an idea for now, but I really would like to go this way. Using 
https://marketplace.atlassian.com/plugins/com.k15t.scroll.scroll-docbook (would 
need to ask infra to install it for us) we could begin in DocBook format, 
before moving all in AsciiDoc.  Then we could use Buildbot to generate the 
documentation automatically using Pandoc. Where to post it is secondary, at the 
ASF of course! Using the demo VM seems the right place, we have already HTTPS 
serving the large videos there.
Of course this is not for tomorrow, but I believe it's the way to go if we want 
a really reliable, as complete as possible documentation. Without it OFBiz will 
never get the attention it deserves... :(

> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> Doc

[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Gil Portenseigne (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282450#comment-14282450
 ] 

Gil Portenseigne commented on OFBIZ-5959:
-

Hi Pierre, here is my point of vue and I tend to agree with Scott.

Imho, a role need a context to be. I try to get your point but i didn't find a 
good example of a global role, i.e. a role that won't be link to another Entity 
which give the context. Sure there are examples, but the context is implicit, 
and in our datamodel, my opinion is that implicit should be avoided. 

I did met that issue with a customer, who tried to understand the use of 
partyRole data (without context). I had to rethink over it to be able to answer 
him.
Indeed, i used to have some partyRole positionned directly on the party, to 
make it appear in specific lookup, but I think that is a bad conception... 

I like to see PartyRole as the entity of the roles that a party have or used to 
have. But to know and filter active roles, i must go on Role entities.

> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-6020) PartyLabels - adding and improving

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-6020:

Attachment: OFBIZ-6020-PartyEntityLabels.patch

This patch addresses the issue.

> PartyLabels - adding and improving
> --
>
> Key: OFBIZ-6020
> URL: https://issues.apache.org/jira/browse/OFBIZ-6020
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-6020-PartyEntityLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-6020) PartyLabels - adding and improving

2015-01-19 Thread Pierre Smits (JIRA)
Pierre Smits created OFBIZ-6020:
---

 Summary: PartyLabels - adding and improving
 Key: OFBIZ-6020
 URL: https://issues.apache.org/jira/browse/OFBIZ-6020
 Project: OFBiz
  Issue Type: Improvement
  Components: party
Affects Versions: Trunk
Reporter: Pierre Smits
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282433#comment-14282433
 ] 

Jacques Le Roux commented on OFBIZ-4941:


Thanks Paul,

Wooo, pandoc is amazing!

> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Jacques Le Roux (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282432#comment-14282432
 ] 

Jacques Le Roux commented on OFBIZ-4941:


Thanks Paul,

Wooo, pandoc is amazing!

> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-6019) Adding and improving some Dutch translations to ORDER labels

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-6019:

Attachment: OFBIZ-6019-OrderLabels.patch

This patch addresses the issue.

> Adding and improving some Dutch translations to ORDER labels
> 
>
> Key: OFBIZ-6019
> URL: https://issues.apache.org/jira/browse/OFBIZ-6019
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-6019-OrderLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-6019) Adding and improving some Dutch translations to ORDER labels

2015-01-19 Thread Pierre Smits (JIRA)
Pierre Smits created OFBIZ-6019:
---

 Summary: Adding and improving some Dutch translations to ORDER 
labels
 Key: OFBIZ-6019
 URL: https://issues.apache.org/jira/browse/OFBIZ-6019
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Trunk
Reporter: Pierre Smits
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-6018) Adding some Dutch translations to Manufacturing Entity labels

2015-01-19 Thread Pierre Smits (JIRA)
Pierre Smits created OFBIZ-6018:
---

 Summary: Adding some Dutch translations to Manufacturing Entity 
labels
 Key: OFBIZ-6018
 URL: https://issues.apache.org/jira/browse/OFBIZ-6018
 Project: OFBiz
  Issue Type: Improvement
  Components: manufacturing
Affects Versions: Trunk
Reporter: Pierre Smits
Priority: Minor
 Attachments: OFBIZ-6018-ManufacturingEntityLabels.xml.patch





--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-6018) Adding some Dutch translations to Manufacturing Entity labels

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-6018:

Attachment: OFBIZ-6018-ManufacturingEntityLabels.xml.patch

This patch addresses the issue.

> Adding some Dutch translations to Manufacturing Entity labels
> -
>
> Key: OFBIZ-6018
> URL: https://issues.apache.org/jira/browse/OFBIZ-6018
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-6018-ManufacturingEntityLabels.xml.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-6015) Move Online Help Documentation from Webhelp into Trunk

2015-01-19 Thread Sharan Foga (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sharan Foga updated OFBIZ-6015:
---
Description: 
This Jira has been created to manage the migration of all the documentation 
from the Webhelp branch into the current help system so that it will work with 
what we already have (essentially so that we dont lose it!).  The original 
issue for the Webhelp is https://issues.apache.org/jira/browse/OFBIZ-4941

As well as HR, there is also online documentation for Accounting, Manufacturing 
(English, German and Dutch), Project Manager and Catalog - though not as 
complete, so I will be consolidating and moving those too.

The files use the docbook format and are compatible with what we have although 
he implemented everything into one file whereas we use one file per screen - so 
I'll need to split it up.

  was:
This Jira has been created to manage the migration of all the documentation 
from the Webhelp branch into the current help system so that it will work with 
what we already have (essentially so that we dont lose it!).  
https://issues.apache.org/jira/browse/OFBIZ-4941

As well as HR, there is also online documentation for Accounting, Manufacturing 
(English, German and Dutch), Project Manager and Catalog - though not as 
complete, so I will be consolidating and moving those too.

The files use the docbook format and are compatible with what we have although 
he implemented everything into one file whereas we use one file per screen - so 
I'll need to split it up.


> Move Online Help Documentation from Webhelp into Trunk
> --
>
> Key: OFBIZ-6015
> URL: https://issues.apache.org/jira/browse/OFBIZ-6015
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Reporter: Sharan Foga
>Assignee: Sharan Foga
>Priority: Minor
>
> This Jira has been created to manage the migration of all the documentation 
> from the Webhelp branch into the current help system so that it will work 
> with what we already have (essentially so that we dont lose it!).  The 
> original issue for the Webhelp is 
> https://issues.apache.org/jira/browse/OFBIZ-4941
> As well as HR, there is also online documentation for Accounting, 
> Manufacturing (English, German and Dutch), Project Manager and Catalog - 
> though not as complete, so I will be consolidating and moving those too.
> The files use the docbook format and are compatible with what we have 
> although he implemented everything into one file whereas we use one file per 
> screen - so I'll need to split it up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-6015) Move Online Help Documentation from Webhelp into Trunk

2015-01-19 Thread Sharan Foga (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6015?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sharan Foga updated OFBIZ-6015:
---
Description: 
This Jira has been created to manage the migration of all the documentation 
from the Webhelp branch into the current help system so that it will work with 
what we already have (essentially so that we dont lose it!).  
https://issues.apache.org/jira/browse/OFBIZ-4941

As well as HR, there is also online documentation for Accounting, Manufacturing 
(English, German and Dutch), Project Manager and Catalog - though not as 
complete, so I will be consolidating and moving those too.

The files use the docbook format and are compatible with what we have although 
he implemented everything into one file whereas we use one file per screen - so 
I'll need to split it up.

  was:
This Jira has been created to manage the migration of all the documentation 
from the Webhelp branch into the current help system so that it will work with 
what we already have (essentially so that we dont lose it!). 

As well as HR, there is also online documentation for Accounting, Manufacturing 
(English, German and Dutch), Project Manager and Catalog - though not as 
complete, so I will be consolidating and moving those too.

The files use the docbook format and are compatible with what we have although 
he implemented everything into one file whereas we use one file per screen - so 
I'll need to split it up.


> Move Online Help Documentation from Webhelp into Trunk
> --
>
> Key: OFBIZ-6015
> URL: https://issues.apache.org/jira/browse/OFBIZ-6015
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Reporter: Sharan Foga
>Assignee: Sharan Foga
>Priority: Minor
>
> This Jira has been created to manage the migration of all the documentation 
> from the Webhelp branch into the current help system so that it will work 
> with what we already have (essentially so that we dont lose it!).  
> https://issues.apache.org/jira/browse/OFBIZ-4941
> As well as HR, there is also online documentation for Accounting, 
> Manufacturing (English, German and Dutch), Project Manager and Catalog - 
> though not as complete, so I will be consolidating and moving those too.
> The files use the docbook format and are compatible with what we have 
> although he implemented everything into one file whereas we use one file per 
> screen - so I'll need to split it up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5347) Shipping costs not recalculated after changing sales order shipment method

2015-01-19 Thread Mridul Pathak (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282395#comment-14282395
 ] 

Mridul Pathak commented on OFBIZ-5347:
--

Divesh,
Thank you for the patch. I'll review/test it and commit if all seems fine.

> Shipping costs not recalculated after changing sales order shipment method
> --
>
> Key: OFBIZ-5347
> URL: https://issues.apache.org/jira/browse/OFBIZ-5347
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Mridul Pathak
> Attachments: OFBIZ-5347.patch
>
>
> Sales order shipping costs are not recalculated when ship group shipment 
> methods are changed.  Its required that the order items be updated before the 
> new shipment method costs are calculated and applied to the order.
> The same logic that calculates the new shipment method costs when order items 
> are updated should be applied when the shipment method is updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OFBIZ-5347) Shipping costs not recalculated after changing sales order shipment method

2015-01-19 Thread Mridul Pathak (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mridul Pathak reassigned OFBIZ-5347:


Assignee: Mridul Pathak

> Shipping costs not recalculated after changing sales order shipment method
> --
>
> Key: OFBIZ-5347
> URL: https://issues.apache.org/jira/browse/OFBIZ-5347
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Assignee: Mridul Pathak
> Attachments: OFBIZ-5347.patch
>
>
> Sales order shipping costs are not recalculated when ship group shipment 
> methods are changed.  Its required that the order items be updated before the 
> new shipment method costs are calculated and applied to the order.
> The same logic that calculates the new shipment method costs when order items 
> are updated should be applied when the shipment method is updated.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-6017) Return shipmentRouteSegment FTL error

2015-01-19 Thread Christian Carlow (JIRA)
Christian Carlow created OFBIZ-6017:
---

 Summary: Return shipmentRouteSegment FTL error
 Key: OFBIZ-6017
 URL: https://issues.apache.org/jira/browse/OFBIZ-6017
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Trunk
Reporter: Christian Carlow


This error is displayed at order/control/mainReturn when status is changed to 
accepted:
FreeMarker template error: The following has evaluated to null or missing: ==> 
Static["org.ofbiz.entity.util.EntityUtil"].getFirst(delegator.findByAnd("ShipmentRouteSegment",
 {"shipmentId" : shipGroupShipment.shipmentId}, null, false)) [in template 
"component://order/webapp/ordermgr/return/returnLinks.ftl" at line 55, column 
49]



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-6016) Adding som Dutch translations to common labels.

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-6016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-6016:

Attachment: OFBIZ-6016-FrameworkCommonLabels.patch

This patch addresses the issue.

> Adding som Dutch translations to common labels.
> ---
>
> Key: OFBIZ-6016
> URL: https://issues.apache.org/jira/browse/OFBIZ-6016
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Priority: Minor
> Attachments: OFBIZ-6016-FrameworkCommonLabels.patch
>
>




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-6016) Adding som Dutch translations to common labels.

2015-01-19 Thread Pierre Smits (JIRA)
Pierre Smits created OFBIZ-6016:
---

 Summary: Adding som Dutch translations to common labels.
 Key: OFBIZ-6016
 URL: https://issues.apache.org/jira/browse/OFBIZ-6016
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Pierre Smits
Priority: Minor






--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Created] (OFBIZ-6015) Move Online Help Documentation from Webhelp into Trunk

2015-01-19 Thread Sharan Foga (JIRA)
Sharan Foga created OFBIZ-6015:
--

 Summary: Move Online Help Documentation from Webhelp into Trunk
 Key: OFBIZ-6015
 URL: https://issues.apache.org/jira/browse/OFBIZ-6015
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Reporter: Sharan Foga
Assignee: Sharan Foga
Priority: Minor


This Jira has been created to manage the migration of all the documentation 
from the Webhelp branch into the current help system so that it will work with 
what we already have (essentially so that we dont lose it!). 

As well as HR, there is also online documentation for Accounting, Manufacturing 
(English, German and Dutch), Project Manager and Catalog - though not as 
complete, so I will be consolidating and moving those too.

The files use the docbook format and are compatible with what we have although 
he implemented everything into one file whereas we use one file per screen - so 
I'll need to split it up.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Paul Foxworthy (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282377#comment-14282377
 ] 

Paul Foxworthy commented on OFBIZ-4941:
---

Hi,

I very much support using AsciiDoc. We have used it for creating several 
courses recently and were very pleased with the results.

Check out the amazing PanDoc: http://johnmacfarlane.net/pandoc/ which can 
convert between many different structured formats, including from docbook to 
AsciiDoc.

Cheers

Paul Foxworthy

> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Assigned] (OFBIZ-4941) Proposal for a new help system

2015-01-19 Thread Paul Foxworthy (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-4941?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Paul Foxworthy reassigned OFBIZ-4941:
-

Assignee: Paul Foxworthy  (was: Jacques Le Roux)

> Proposal for a new help system
> --
>
> Key: OFBIZ-4941
> URL: https://issues.apache.org/jira/browse/OFBIZ-4941
> Project: OFBiz
>  Issue Type: Wish
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Paul Foxworthy
>Priority: Minor
> Attachments: HelpAccounting.jpg, HelpPerformanceReview1.jpg, 
> HelpPerformanceReview2.jpg, HelpRoadmap.jpg, LICENSE.html, LicenseFiles.zip, 
> OFBIZ-4941 POC HR Help.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, OFBIZ-4941.patch, 
> WebhelpFiles.zip, WebhelpFiles.zip, WebhelpHRAppDocbook.zip, 
> WebhelpHRAppDocbook.zip, content.7z, docbook diff.patch, 
> docbook-xsl-1.77.1.zip, help_content.jpg, help_ofbizhelp.jpg, 
> help_webhlep.jpg, helppdf.zip, jh.jar, ofbiz-common.xsl, webhelp.jpg
>
>
> Quoting Tom Burns at OFBIZ-4869
> {quote}
> This is a status update just to let anyone who is interested know that this 
> item is being worked on.
> I started out using the OFBiz structure for help docs but after a while I 
> needed/wanted something more expressive.
> Here is what I wound up using for development:
> Java Help System http://java.net/projects/javahelp/content
> DocBook 5: The Definitive Guide
> http://www.docbook.org/tdg5/en/html/docbook.html
> http://www.docbook.org/xml/5.0/
> DocBook XSL: The Complete Guide
> http://www.sagehill.net/docbookxsl/index.html
> 
> http://sourceforge.net/projects/docbook/files/docbook-xsl/1.77.1/docbook-xsl-1.77.1.zip
> Help Master - FE for managing java help files. Best feature drag and drop 
> TOC creates TOC matching file folder structure. Convenient launcher for 
> viewing & testing. http://www.halogenware.com/software/helpmaster.html
> XML Mind XML Editor - Free Personal Edition is far better then editing in 
> Eclipse. download from http://www.xmlmind.com/xmleditor/download.shtml
> Tutorial - DocBook editing with XML Mind XML Editor. Worth going through 
> http://www.xmlmind.com/xmleditor/tutorial.html
> Read Me First style guide from Sun (cost from Amazon 1 cent + shipping)
> Attached are some screen shots of the results.
> Every screen is/will be documented in a similar structure. This is as much 
> for defining requirements and testing as for help. More work but worth it.
> The screenshots show a Java Help format generated using DocBook XSL. This 
> will likely not be the final presentation format.
> Note the Performance Review screen shots do not match the trunk. There is a 
> bug in update screen and I did some clean up of labels and drop-down list. 
> There are issues like this all through the application so I did not want to 
> get bogged down with patches at this time.
> {quote}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Reopened] (OFBIZ-5914) Gift card reload service not working OOTB

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux reopened OFBIZ-5914:


> Gift card reload service not working OOTB
> -
>
> Key: OFBIZ-5914
> URL: https://issues.apache.org/jira/browse/OFBIZ-5914
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk, 
> 14.12.01
>Reporter: Prateek
>Assignee: Jacques Le Roux
>
> The product GC-002 misses inventory value for the amount field to show at 
> ecommerce at ecommerce/gift-card-reload-GC-002-p



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-5914) Gift card reload service not working OOTB

2015-01-19 Thread Jacques Le Roux (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Jacques Le Roux updated OFBIZ-5914:
---
 Priority: Major  (was: Trivial)
Affects Version/s: 14.12.01
   Release Branch 12.04
   Release Branch 13.07
Fix Version/s: (was: Upcoming Branch)
   Issue Type: Bug  (was: Improvement)

Yes I agree, and it's finally kind of bug

> Gift card reload service not working OOTB
> -
>
> Key: OFBIZ-5914
> URL: https://issues.apache.org/jira/browse/OFBIZ-5914
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk, 
> 14.12.01
>Reporter: Prateek
>Assignee: Jacques Le Roux
>
> The product GC-002 misses inventory value for the amount field to show at 
> ecommerce at ecommerce/gift-card-reload-GC-002-p



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-4457) Checkout layout: in screens before payment screen: the fields are below the last div in right column.

2015-01-19 Thread Mridul Pathak (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-4457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282352#comment-14282352
 ] 

Mridul Pathak commented on OFBIZ-4457:
--

Thanks for the pointer Jacques, I'll keep that in mind. Will read the document 
a few more times as well. :-)

> Checkout layout: in screens before payment screen: the fields are below the 
> last div in right column.
> -
>
> Key: OFBIZ-4457
> URL: https://issues.apache.org/jira/browse/OFBIZ-4457
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 09.04, Release Branch 10.04, Release 
> Branch 11.04, Trunk
>Reporter: Jacques Le Roux
>Assignee: Mridul Pathak
>Priority: Minor
> Fix For: 14.12.01, 12.04.06, 13.07.02, Upcoming Branch
>
> Attachments: OFBIZ-4457.patch
>
>
> In checkout layout, in screens before payment screen: the fields are below 
> the last div in right column. The payment screen was fixed recently it was a 
> layout issue related to missing or supernumerary div(s), IIRW..



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282300#comment-14282300
 ] 

Pierre Smits commented on OFBIZ-5959:
-

This is what Len Silverston had to say regarding the universal data model (UDM) 
and PARTY ROLE:

{quote}
The PARTY ROLE entity maintains information associated with each role that a 
PERSON or ORGANIZATION
plays, thus providing a more complete profile of each party by identifyingall 
the roles played by each
party. 
{quote}

And regarding the distinction between PARTY ROLE and PARTY RELATIONSHIP:
{quote}
In order to provide meaningful relationship information, it is essential to 
distinguish which information should be stored with the PARTY, which 
information is associated withthe PARTY ROLE and which information is 
associated with the PARTY RELATIONSHIP.
{quote}

> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-5817) Remove Portal Management code from Framework/WebTools.

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5817?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-5817:

Attachment: OFBIZ-5817-PortalMenus.xml.patch
OFBIZ-5817-PortalScreenForms.patch
OFBIZ-5817-PortalLabels.patch
OFBIZ-5817-PortalData.patch
OFBIZ-5817-PortalController.patch

These patches remove the code etc. from Framework/Webtools.

> Remove Portal Management code from Framework/WebTools.
> --
>
> Key: OFBIZ-5817
> URL: https://issues.apache.org/jira/browse/OFBIZ-5817
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: MyPortal
> Attachments: OFBIZ-5817-PortalController.patch, 
> OFBIZ-5817-PortalData.patch, OFBIZ-5817-PortalLabels.patch, 
> OFBIZ-5817-PortalMenus.xml.patch, OFBIZ-5817-PortalScreenForms.patch
>
>
> Remove code related to Portal Management functionality from WebTools after 
> equivalent code in MyPortal has been committed. 



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Updated] (OFBIZ-5812) Move Portal Mgt functions in MyPortal

2015-01-19 Thread Pierre Smits (JIRA)

 [ 
https://issues.apache.org/jira/browse/OFBIZ-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pierre Smits updated OFBIZ-5812:

Attachment: OFBIZ-5812MyPortalUiLabels.patch
OFBIZ-5812-MyPortalMenus.xml.patch

As the original patch is somewhat out of date regarding trunk of today, it 
produces issues with the labels file. 
OFBIZ-5812-MyPortalMenus.xml.patch corrects that issue.

OFBIZ-5812MyPortalUiLabels.patch corrects a menu item to work with the new 
labels patch. Plus a little correction regarding admin permission.

> Move Portal Mgt functions in MyPortal
> -
>
> Key: OFBIZ-5812
> URL: https://issues.apache.org/jira/browse/OFBIZ-5812
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework, specialpurpose/myportal
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: admin, portalPage
> Attachments: OFBIZ-5812-MyPortalAdmin.patch, 
> OFBIZ-5812-MyPortalMenus.xml.patch, OFBIZ-5812MyPortalUiLabels.patch
>
>
> Portal page admin functionalities are included in WebTools, but should be 
> also in MyPortal for those users that don't have access to WebTools.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5959) Add lifespan fields to PartyRole

2015-01-19 Thread Scott Gray (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282260#comment-14282260
 ] 

Scott Gray commented on OFBIZ-5959:
---

Yeah maybe have a discussion before creating a huge number of tickets.

PartyRelationship is intended for the type of use case you're looking at here. 
PartyRole very rarely makes sense to use for just about anything because it 
provides no context for the role.  It's already been overused in OFBiz as a 
lazy way of saying the Party has a given role in relation to the company using 
OFBiz (i.e. an implied role).  It is much better IMO to use context specific 
entities for defining roles such as PartyRelationship, OrderRole, 
AgreementRole, etc.

I can't really even think of a reason why PartyRole exists as all.

> Add lifespan fields to PartyRole
> 
>
> Key: OFBIZ-5959
> URL: https://issues.apache.org/jira/browse/OFBIZ-5959
> Project: OFBiz
>  Issue Type: Improvement
>  Components: party
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: role, roles
>
> Currently the assignments of roles to parties are boolean (there or not 
> there).
> However, these role assignments also have a lifespan. This can be achieved by 
> adding fromDate and thruDate fields.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)


[jira] [Commented] (OFBIZ-5812) Move Portal Mgt functions in MyPortal

2015-01-19 Thread Pierre Smits (JIRA)

[ 
https://issues.apache.org/jira/browse/OFBIZ-5812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14282248#comment-14282248
 ] 

Pierre Smits commented on OFBIZ-5812:
-

Darn. The UiLabels in the patch need to be redone. Applying the patch generates 
issues in that respect.

> Move Portal Mgt functions in MyPortal
> -
>
> Key: OFBIZ-5812
> URL: https://issues.apache.org/jira/browse/OFBIZ-5812
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework, specialpurpose/myportal
>Affects Versions: Trunk
>Reporter: Pierre Smits
>  Labels: admin, portalPage
> Attachments: OFBIZ-5812-MyPortalAdmin.patch
>
>
> Portal page admin functionalities are included in WebTools, but should be 
> also in MyPortal for those users that don't have access to WebTools.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)