from:"Martin Becker"


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

Martin Becker updated OFBIZ-6641:
-
Attachment: OFBIZ-6641_SERBIA_and_MONTENEGRO.patch

> Missing CountryCodeData.xml values for countries of the former Yugoslavia
> -
>
> Key: OFBIZ-6641
> URL: https://issues.apache.org/jira/browse/OFBIZ-6641
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6641_SERBIA_and_MONTENEGRO.patch
>
>
> Instead of former YUGOSLAVIA there should be SERBIA.
> Also CountryTeleCode and CountryCapital is missing for MONTENEGRO.



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

[jira] [Updated] (OFBIZ-6640) Eclipse .classpath contains internal Groovy Library classpath container


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

Martin Becker updated OFBIZ-6640:
-
Attachment: OFBIZ-6640_Removed-Groovy-CP-CONs.patch

> Eclipse .classpath contains internal Groovy Library classpath container
> ---
>
> Key: OFBIZ-6640
> URL: https://issues.apache.org/jira/browse/OFBIZ-6640
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6640_Removed-Groovy-CP-CONs.patch
>
>
> There are unnecessarily eclipse internal Groovy Library classpath container 
> referenced in the .classpath file. This may lead to conflicts with the OFBiz 
> "original" groovy libs contained in the framework and produces errors while 
> running OFBiz within eclipse.
> {{}}
> {{}}
> I'll provide a patch for this.



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

[jira] [Updated] (OFBIZ-1032) EntitySaxReader mostly-insert (store after create-error) Fix


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

Martin Becker updated OFBIZ-1032:
-
Attachment: OFBIZ-1032_Remove-fallback-store.patch

I removed the unnecessary call to store after a failing create on 
"mostly-inserts" activated. This call to store can never be successful, because 
the running transaction is already marked rollback only because of the failed 
create attempt. Instead it pollutes the log with additional errors.

The old patch in this issue uses a delegator API that does not exist, maybe 
there had to be additional patches for that.

Conceptual I think, the data load with "mostly inserts" activated should fail 
on a create-failure (what it does indeed already), so I see no need for a 
working solution of a fallback store attempt. Consistently the Feature should 
be renamed in the frontend from "mostly inserts" to "only inserts".

Additional trivial refactoring in the patch: I reduced the full qualified 
classname of org.xml.sax.SAXException in method signatures to the simple name.


> EntitySaxReader mostly-insert (store after create-error) Fix
> 
>
> Key: OFBIZ-1032
> URL: https://issues.apache.org/jira/browse/OFBIZ-1032
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
> Environment: Win XP
>Reporter: Karl Eilebrecht
>Assignee: Adam Heath
>Priority: Minor
> Attachments: OFBIZ-1032_Remove-fallback-store.patch, patch9675.patch
>
>
> This issue is part of Key-Work Ofbiz Contribution Proposal.
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> Based on Release: 540035
> Includes: -
> Required: JIRA-1031, JIRA-1030, JIRA-1029, JIRA-1017, JIRA-1016
> Recommended:  -
> Classes:  EntitySaxReader 
> Description:  Avoids rollback on create error to be able to store the 
>   entity instead (mostly-inserts feature).



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

[jira] [Updated] (OFBIZ-6641) Missing CountryCodeData.xml values for countries of the former Yugoslavia


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

Martin Becker updated OFBIZ-6641:
-
Sprint: Community Day 3 - 2015

> Missing CountryCodeData.xml values for countries of the former Yugoslavia
> -
>
> Key: OFBIZ-6641
> URL: https://issues.apache.org/jira/browse/OFBIZ-6641
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6641_SERBIA_and_MONTENEGRO.patch
>
>
> Instead of former YUGOSLAVIA there should be SERBIA.
> Also CountryTeleCode and CountryCapital is missing for MONTENEGRO.



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

[jira] [Updated] (OFBIZ-1032) EntitySaxReader mostly-insert (store after create-error) Fix


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

Martin Becker updated OFBIZ-1032:
-
Sprint: Bug Crush Event - 21/2/2015, Community Day 3 - 2015  (was: Bug 
Crush Event - 21/2/2015)

> EntitySaxReader mostly-insert (store after create-error) Fix
> 
>
> Key: OFBIZ-1032
> URL: https://issues.apache.org/jira/browse/OFBIZ-1032
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
> Environment: Win XP
>Reporter: Karl Eilebrecht
>Assignee: Adam Heath
>Priority: Minor
> Attachments: patch9675.patch
>
>
> This issue is part of Key-Work Ofbiz Contribution Proposal.
> http://docs.ofbiz.org/display/OFBIZ/Key-Work+Ofbiz+Contribution+Proposal
> Based on Release: 540035
> Includes: -
> Required: JIRA-1031, JIRA-1030, JIRA-1029, JIRA-1017, JIRA-1016
> Recommended:  -
> Classes:  EntitySaxReader 
> Description:  Avoids rollback on create error to be able to store the 
>   entity instead (mostly-inserts feature).



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

[jira] [Updated] (OFBIZ-293) data import - nulling fields impossible


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

Martin Becker updated OFBIZ-293:

Sprint: Bug Crush Event - 21/2/2015, Community Day 3 - 2015  (was: Bug 
Crush Event - 21/2/2015)

> data import - nulling fields impossible
> ---
>
> Key: OFBIZ-293
> URL: https://issues.apache.org/jira/browse/OFBIZ-293
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Marco Risaliti
>Priority: Minor
> Attachments: OFBIZ-293_set-empty-strings-as-null.patch, 
> ofbiz-293-patch.txt, ofbiz-462-patch.txt
>
>
> It's a copy of the old-jira issue 
> http://jira.undersunconsulting.com/browse/OFBIZ-462 Tarlika Elisabeth Schmitz
> =
> I am on rev 5274. 
> data import from .xml file: empty attributes (e.g. description="") are 
> ignored and the field retains its former value. 
>  
>  
>  AllCommentsWork LogChange History   Sort Order:   
> Comment by Chris Juettner [04/Oct/05 01:51 PM] [ Permlink ] 
> This patch comments out the check for null or empty values in the data XML 
> file found by the EntitySaxReader. I also added an additional warning message 
> in case you do not want to persist empty values to the database but still 
> would like to know what happened. 
> Comment by Si Chen [04/Oct/05 01:59 PM] [ Permlink ] 
> Chris- 
> Just a comment: it's very important that a field in the entity engine is set 
> to null ONLY when the XML file specifically has an empty attribute (ie, 
> description=""). Otherwise, there's a lot of seed data that is in separate 
> XML files, and they could overwrite each other. 
> Si 
> Comment by Chris Juettner [10/Oct/05 11:56 AM] [ Permlink ] 
> Si, 
> I'm not sure I understand your comment about seed data in seperate XML files 
> overwriting each other. Shouldn't seed data XML files be entity specific? Why 
> would one seed data XML file overwrite another? 
> Do you have any comment on what a better solution is for seed data values 
> that could be empty? 
> Thanks 
> Chris 



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

[jira] [Updated] (OFBIZ-293) data import - nulling fields impossible


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

Martin Becker updated OFBIZ-293:

Attachment: OFBIZ-293_set-empty-strings-as-null.patch

I've attached an updated version of the patch from 2011.

In my opinion it would be straight forward, if the entity import would treat 
fields that are mentioned in entity XML files as fields that should be updated 
always, as the GenericDAO does. The current logic ignores fields, if there is 
only an empty string as value.

The enhancement brought by the solution of OFBIZ-4949 makes it possible to 
generally configure an entity-engine-xml file to be interpreted as replacement, 
so that all NOT mentioned fields are set to NULL instead of leaving the old 
value while updating the entity.

Nevertheless I think, that the default (update) behavior, the one with fine 
grained control over which fields are touched, should also give the possibility 
to set field values to NULL by including them in the XML.

The solution with the lowest impact on existing XML files and the most natural 
meaning should be to interpret empty string values in the XML as NULL, as it is 
today. The only difference would be, that they are not longer ignored but set 
as NULL values in the database. The only drawback I see is, that you're still 
not able to set "empty string" values as concrete values to the database (no 
loss of function, because you can't do it today, too).

As far as I can see, there should be no conflict with current existing data 
files. There are some where for example a parentTypeId is contained with empty 
string as value. Interpreting it as NULL and setting in database is exactly 
what is meant by such a definition.



> data import - nulling fields impossible
> ---
>
> Key: OFBIZ-293
> URL: https://issues.apache.org/jira/browse/OFBIZ-293
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Marco Risaliti
>Priority: Minor
> Attachments: OFBIZ-293_set-empty-strings-as-null.patch, 
> ofbiz-293-patch.txt, ofbiz-462-patch.txt
>
>
> It's a copy of the old-jira issue 
> http://jira.undersunconsulting.com/browse/OFBIZ-462 Tarlika Elisabeth Schmitz
> =
> I am on rev 5274. 
> data import from .xml file: empty attributes (e.g. description="") are 
> ignored and the field retains its former value. 
>  
>  
>  AllCommentsWork LogChange History   Sort Order:   
> Comment by Chris Juettner [04/Oct/05 01:51 PM] [ Permlink ] 
> This patch comments out the check for null or empty values in the data XML 
> file found by the EntitySaxReader. I also added an additional warning message 
> in case you do not want to persist empty values to the database but still 
> would like to know what happened. 
> Comment by Si Chen [04/Oct/05 01:59 PM] [ Permlink ] 
> Chris- 
> Just a comment: it's very important that a field in the entity engine is set 
> to null ONLY when the XML file specifically has an empty attribute (ie, 
> description=""). Otherwise, there's a lot of seed data that is in separate 
> XML files, and they could overwrite each other. 
> Si 
> Comment by Chris Juettner [10/Oct/05 11:56 AM] [ Permlink ] 
> Si, 
> I'm not sure I understand your comment about seed data in seperate XML files 
> overwriting each other. Shouldn't seed data XML files be entity specific? Why 
> would one seed data XML file overwrite another? 
> Do you have any comment on what a better solution is for seed data values 
> that could be empty? 
> Thanks 
> Chris 



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

[jira] [Created] (OFBIZ-6640) Eclipse .classpath contains internal Groovy Library classpath container

Martin Becker created OFBIZ-6640:


 Summary: Eclipse .classpath contains internal Groovy Library 
classpath container
 Key: OFBIZ-6640
 URL: https://issues.apache.org/jira/browse/OFBIZ-6640
 Project: OFBiz
  Issue Type: Bug
  Components: ALL COMPONENTS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor


There are unnecessarily eclipse internal Groovy Library classpath container 
referenced in the .classpath file. This may lead to conflicts with the OFBiz 
"original" groovy libs contained in the framework and produces errors while 
running OFBiz within eclipse.

{{}}
{{}}

I'll provide a patch for this.



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

[jira] [Created] (OFBIZ-6641) Missing CountryCodeData.xml values for countries of the former Yugoslavia

Martin Becker created OFBIZ-6641:


 Summary: Missing CountryCodeData.xml values for countries of the 
former Yugoslavia
 Key: OFBIZ-6641
 URL: https://issues.apache.org/jira/browse/OFBIZ-6641
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor


Instead of former YUGOSLAVIA there should be SERBIA.
Also CountryTeleCode and CountryCapital is missing for MONTENEGRO.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity


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

Martin Becker commented on OFBIZ-6276:
--

Hi Jacques,
now there have been two more month passed ;-)

> Fix deprecation issues in framework/entity
> --
>
> Key: OFBIZ-6276
> URL: https://issues.apache.org/jira/browse/OFBIZ-6276
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Adam Heath
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-6276-EntityStoreOptions.patch, 
> OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch
>
>
> It appears that the storeAll() variants are being refactor; basically, the 
> useCache parameter is being removed.  However, this has caused the
> entity engine to have deprecation with itself.



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

[jira] [Created] (OFBIZ-6630) Update ShoppingCartItem locale if ShoppingCart locale is changed

Martin Becker created OFBIZ-6630:


 Summary: Update ShoppingCartItem locale if ShoppingCart locale is 
changed
 Key: OFBIZ-6630
 URL: https://issues.apache.org/jira/browse/OFBIZ-6630
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor


If the locale of the cart is changed, for example by choosing the language in 
frontend and setting the locale by CommonEvents.setSessionLocale, the locale 
stored in each cart item isn't updated. A call to item.getName() for example 
uses the wrong locale afterwards.



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

[jira] [Updated] (OFBIZ-6630) Update ShoppingCartItem locale if ShoppingCart locale is changed


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

Martin Becker updated OFBIZ-6630:
-
Attachment: OFBIZ-6630-KeepCartItemLocalInSync.patch

> Update ShoppingCartItem locale if ShoppingCart locale is changed
> 
>
> Key: OFBIZ-6630
> URL: https://issues.apache.org/jira/browse/OFBIZ-6630
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6630-KeepCartItemLocalInSync.patch
>
>
> If the locale of the cart is changed, for example by choosing the language in 
> frontend and setting the locale by CommonEvents.setSessionLocale and updating 
> the cart locale by keepCartUpdated event, the locale stored in each cart item 
> isn't updated. A call to item.getName() for example uses the wrong locale 
> afterwards.



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

[jira] [Created] (OFBIZ-6631) Optimize ShoppingCart.removeCartItem (skip price calc and inventory check)

Martin Becker created OFBIZ-6631:


 Summary: Optimize ShoppingCart.removeCartItem (skip price calc and 
inventory check)
 Key: OFBIZ-6631
 URL: https://issues.apache.org/jira/browse/OFBIZ-6631
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor


Based on the standard parameter completion from the overloaded API of 
ShoppingCartItem.setQuantity, the use of the ShoppingCart.removeCartItem method 
leads to an unnecessary price calculation and inventory check for the item 
being removed.
By using the setQuantity method with full parameter list in this case, this can 
be avoided.



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

[jira] [Updated] (OFBIZ-6631) Optimize ShoppingCart.removeCartItem (skip price calc and inventory check)


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

Martin Becker updated OFBIZ-6631:
-
Attachment: OFBIZ-6631-Optimized-RemoveCartItem.patch

> Optimize ShoppingCart.removeCartItem (skip price calc and inventory check)
> --
>
> Key: OFBIZ-6631
> URL: https://issues.apache.org/jira/browse/OFBIZ-6631
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6631-Optimized-RemoveCartItem.patch
>
>
> Based on the standard parameter completion from the overloaded API of 
> ShoppingCartItem.setQuantity, the use of the ShoppingCart.removeCartItem 
> method leads to an unnecessary price calculation and inventory check for the 
> item being removed.
> By using the setQuantity method with full parameter list in this case, this 
> can be avoided.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity


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

Martin Becker commented on OFBIZ-6276:
--

Hi Jacques, did you have a problem to apply the 
OFBIZ-6276-EntityStoreOptions.patch?
It is in universal diff format and I just tried to apply it within my eclipse 
and it worked fine.

> Fix deprecation issues in framework/entity
> --
>
> Key: OFBIZ-6276
> URL: https://issues.apache.org/jira/browse/OFBIZ-6276
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Adam Heath
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-6276-EntityStoreOptions.patch, 
> OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch
>
>
> It appears that the storeAll() variants are being refactor; basically, the 
> useCache parameter is being removed.  However, this has caused the
> entity engine to have deprecation with itself.



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

[jira] [Updated] (OFBIZ-6629) Duplicate calculation and typo in ShoppingCart.getGrandTotal()


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

Martin Becker updated OFBIZ-6629:
-
Attachment: OFBIZ-6629.patch

I added a type parameter to an Iterator in renamed method 
getOrderGlobalAdjustments(), too

> Duplicate calculation and typo in ShoppingCart.getGrandTotal()
> --
>
> Key: OFBIZ-6629
> URL: https://issues.apache.org/jira/browse/OFBIZ-6629
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
> Attachments: OFBIZ-6629.patch
>
>
> The shopping cart grand total ist calculated twice in getGrandTotal().
> In addition, the Method getOrderGlobalAdjusments() is misspelled.



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

[jira] [Created] (OFBIZ-6635) Old UserLogin from userLoginId-change is not correctly disabled

Martin Becker created OFBIZ-6635:


 Summary: Old UserLogin from userLoginId-change is not correctly 
disabled
 Key: OFBIZ-6635
 URL: https://issues.apache.org/jira/browse/OFBIZ-6635
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Critical


If a userLoginId of an existing user is updated by 
LoginServices.updateUserLoginId, a new UserLogin value is created with the data 
of the old one and the old one is disabled afterwards. In addition to switch 
the enabled flag to "N" the disabledDateTime is set to current date. This is 
wrong because this makes it possible to reenable the old UserLogin by just do a 
login with the old userLoginId (standard mechanism to lock the login for a 
while after subsequent failed login requests).



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

[jira] [Updated] (OFBIZ-6635) Old UserLogin from userLoginId-change is not correctly disabled


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

Martin Becker updated OFBIZ-6635:
-
Attachment: OFBIZ-6635-FixedDisablingOldUserLogin.patch

> Old UserLogin from userLoginId-change is not correctly disabled
> ---
>
> Key: OFBIZ-6635
> URL: https://issues.apache.org/jira/browse/OFBIZ-6635
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Critical
> Attachments: OFBIZ-6635-FixedDisablingOldUserLogin.patch
>
>
> If a userLoginId of an existing user is updated by 
> LoginServices.updateUserLoginId, a new UserLogin value is created with the 
> data of the old one and the old one is disabled afterwards. In addition to 
> switch the enabled flag to "N" the disabledDateTime is set to current date. 
> This is wrong because this makes it possible to reenable the old UserLogin by 
> just do a login with the old userLoginId (standard mechanism to lock the 
> login for a while after subsequent failed login requests).



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

[jira] [Updated] (OFBIZ-6632) Incorrect comparison in TemporalExpressionWorker.java


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

Martin Becker updated OFBIZ-6632:
-
Attachment: OFBIZ-6632-Fixed-exprAssocType-values.patch

Fixed the entitymodel.xml comment and the comparison in 
TemporalExpressionWorker and added constants for the three mentioned values.
Maybe a Java Enum or the use of the OFBiz Enumeration for referential integrity 
in database may be a more complete solution.

> Incorrect comparison in TemporalExpressionWorker.java
> -
>
> Key: OFBIZ-6632
> URL: https://issues.apache.org/jira/browse/OFBIZ-6632
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Vyom Jain
> Attachments: OFBIZ-6632-Fixed-exprAssocType-values.patch
>
>
> Line 128 in TemporalExpressionWorker.java does incorrect comparison
> {code}
> if ("SUBSTITUTION".equals(childExpression.get("exprAssocType"))) {
> {code} should be 
> {code}
> if ("SUBSTITUTE".equals(childExpression.get("exprAssocType"))) {
> {code}
> Also documentation of field exprAssocType in entity definition of 
> TemporalExpressionAssoc needs to be fixed. INCLUDED & EXCLUDED should be 
> INCLUDE & EXCLUDE respectively.



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

[jira] [Created] (OFBIZ-6629) Duplicate calculation and typo in ShoppingCart.getGrandTotal()

Martin Becker created OFBIZ-6629:


 Summary: Duplicate calculation and typo in 
ShoppingCart.getGrandTotal()
 Key: OFBIZ-6629
 URL: https://issues.apache.org/jira/browse/OFBIZ-6629
 Project: OFBiz
  Issue Type: Bug
  Components: order
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor


The shopping cart grand total ist calculated twice in getGrandTotal().
In addition, the Method getOrderGlobalAdjusments() is misspelled.



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

[jira] [Updated] (OFBIZ-6630) Update ShoppingCartItem locale if ShoppingCart locale is changed


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

Martin Becker updated OFBIZ-6630:
-
Description: If the locale of the cart is changed, for example by choosing 
the language in frontend and setting the locale by 
CommonEvents.setSessionLocale and updating the cart locale by keepCartUpdated 
event, the locale stored in each cart item isn't updated. A call to 
item.getName() for example uses the wrong locale afterwards.  (was: If the 
locale of the cart is changed, for example by choosing the language in frontend 
and setting the locale by CommonEvents.setSessionLocale, the locale stored in 
each cart item isn't updated. A call to item.getName() for example uses the 
wrong locale afterwards.)

> Update ShoppingCartItem locale if ShoppingCart locale is changed
> 
>
> Key: OFBIZ-6630
> URL: https://issues.apache.org/jira/browse/OFBIZ-6630
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Minor
>
> If the locale of the cart is changed, for example by choosing the language in 
> frontend and setting the locale by CommonEvents.setSessionLocale and updating 
> the cart locale by keepCartUpdated event, the locale stored in each cart item 
> isn't updated. A call to item.getName() for example uses the wrong locale 
> afterwards.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity


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

Martin Becker commented on OFBIZ-6276:
--

Thanks a lot!

> Fix deprecation issues in framework/entity
> --
>
> Key: OFBIZ-6276
> URL: https://issues.apache.org/jira/browse/OFBIZ-6276
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Reporter: Adam Heath
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-6276-EntityStoreOptions-SVN.patch, 
> OFBIZ-6276-EntityStoreOptions.patch, OFBIZ-6276-variant-1.patch, 
> OFBIZ-6276-variant-2.patch
>
>
> It appears that the storeAll() variants are being refactor; basically, the 
> useCache parameter is being removed.  However, this has caused the
> entity engine to have deprecation with itself.



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

[jira] [Updated] (OFBIZ-6635) Old UserLogin from userLoginId-change is not correctly disabled


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

Martin Becker updated OFBIZ-6635:
-
Sprint: Community Day 3 - 2015

> Old UserLogin from userLoginId-change is not correctly disabled
> ---
>
> Key: OFBIZ-6635
> URL: https://issues.apache.org/jira/browse/OFBIZ-6635
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Upcoming Branch
>    Reporter: Martin Becker
>Priority: Critical
>
> If a userLoginId of an existing user is updated by 
> LoginServices.updateUserLoginId, a new UserLogin value is created with the 
> data of the old one and the old one is disabled afterwards. In addition to 
> switch the enabled flag to "N" the disabledDateTime is set to current date. 
> This is wrong because this makes it possible to reenable the old UserLogin by 
> just do a login with the old userLoginId (standard mechanism to lock the 
> login for a while after subsequent failed login requests).



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

[jira] [Updated] (OFBIZ-6632) Incorrect comparison in TemporalExpressionWorker.java


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

Martin Becker updated OFBIZ-6632:
-
Sprint: Community Day 3 - 2015

> Incorrect comparison in TemporalExpressionWorker.java
> -
>
> Key: OFBIZ-6632
> URL: https://issues.apache.org/jira/browse/OFBIZ-6632
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk
>Reporter: Vyom Jain
> Attachments: OFBIZ-6632-Fixed-exprAssocType-values.patch
>
>
> Line 128 in TemporalExpressionWorker.java does incorrect comparison
> {code}
> if ("SUBSTITUTION".equals(childExpression.get("exprAssocType"))) {
> {code} should be 
> {code}
> if ("SUBSTITUTE".equals(childExpression.get("exprAssocType"))) {
> {code}
> Also documentation of field exprAssocType in entity definition of 
> TemporalExpressionAssoc needs to be fixed. INCLUDED & EXCLUDED should be 
> INCLUDE & EXCLUDE respectively.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-06-21 Thread Martin Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595084#comment-14595084
 ] 

Martin Becker commented on OFBIZ-6276:
--

I forgot to mention: The standard tests were all green...

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Jacques Le Roux
Priority: Minor
 Attachments: OFBIZ-6276-EntityStoreOptions.patch, 
 OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Updated] (OFBIZ-6522) Potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers

2015-06-21 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6522:
-
Attachment: OFBIZ-6522.patch

Added patch with fixed potential IndexOutOfBoundsException in 
CategoryServices.getProductCategoryAndLimitedMembers.
BTW also ensured that the EntityListIterator gets closed if an error occurs and 
corrected some minor code laxness.

 Potential IndexOutOfBoundsException in 
 CategoryServices.getProductCategoryAndLimitedMembers
 ---

 Key: OFBIZ-6522
 URL: https://issues.apache.org/jira/browse/OFBIZ-6522
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor
 Attachments: OFBIZ-6522.patch


 If view indexes as input parameters of service 
 getProductCategoryAndLimitedMembers get manipulated (e.g. by manipulating URL 
 params or bookmarking an URL with those params an come back later), it can 
 lead to an IndexOutOfBoundsException because of a lowIndex greater list size. 
 The highIndex is checked for that, the lowIndex is not.



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

[jira] [Commented] (OFBIZ-6458) Upgrade OFBiz to Java JDK 8

2015-06-21 Thread Martin Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14595018#comment-14595018
 ] 

Martin Becker commented on OFBIZ-6458:
--

Hi Taher,
what i meant was, I provided a fix for that with title Compiler-Error with JDK 
1.8 and source compatibility 1.8 already 8 weeks ago, when the Java 8 
compatibility was a headline once before, but it wasn't recognized or 
forgotten...

 Upgrade OFBiz to Java JDK 8
 ---

 Key: OFBIZ-6458
 URL: https://issues.apache.org/jira/browse/OFBIZ-6458
 Project: OFBiz
  Issue Type: Improvement
Affects Versions: Upcoming Branch
Reporter: Taher Alkhateeb
Assignee: Jacques Le Roux
Priority: Critical
  Labels: java, jdk, jdk8, upgrade
 Fix For: Upcoming Branch

 Attachments: OFBIZ-6458-01-fix-test-errors.patch, 
 OFBIZ-6458-02-fix-eclipse-compiler.patch, OFBIZ-6458-03-update-to-jdk8.patch, 
 OFBIZ-6458-04-update-README.patch


 The following will be tracked through this JIRA:
 - upgrade the framework to JDK 8 and fix any errors
 - make sure that ./ant clean-all load-demo run-tests will run after the 
 upgrade
 - upgrade the infrastructure and demo server to accommodate the new change



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

[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file


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

Martin Becker updated OFBIZ-6317:
-
Attachment: OFBIZ-6317_14-12.patch

Added patch for Branch 14.12 which fixes the current missing/obsolete 
.classpath entries including birt libs and framework/base/config as stated 
above and removes in addition the following obsolete entries:
* framework/webapp/lib/json-lib-2.2.3-jdk15.jar
* framework/bi/src
* framework/sql/src

So that a fresh checkout is runnable within eclipse without changing the 
classpath within the run-/debug-configuration.

 Missing BIRT libs in eclipse .classpath file
 

 Key: OFBIZ-6317
 URL: https://issues.apache.org/jira/browse/OFBIZ-6317
 Project: OFBiz
  Issue Type: Bug
  Components: framework, specialpurpose/birt
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch

 Attachments: OFBIZ-6317.patch, OFBIZ-6317_14-12.patch, 
 OFBIZ-6317_trunk_framework-base-config.patch


 Because of missing JARs from the specialpurpose component birt in the eclipse 
 .classpath file OFBiz could not be startet within eclipse without errors 
 (NoClassDefFoundError while starting birt component).
 With starting within eclipse I mean the configuration with hot code 
 replacement like this: 
 https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses
 I will provide a patch for the .classpath file with 4 added libs from the 
 specialpurpose/birt/lib folder.
 It would be beneficial, at least for simple contribution of jira issue fixes, 
 if the default configuration of OFBiz from trunk is runnable as is (in a 
 common development scenario like the above), without the need to modify 
 config files which are under version control (.classpath for example). The 
 alternative could be to not put files under version control, that are related 
 to individual development environments.
 By the way, it would also be nice to have the framework/base/config folder as 
 src in the .classpath file as described in the wiki article above, so that 
 the configuration of an eclipse debug/run target for starting OFBiz in 
 eclipse is done by only selecting the project + start-class and giving some 
 JVM args.



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

[jira] [Reopened] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file


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

Martin Becker reopened OFBIZ-6317:
--

Reopened to provide patch for 14.12

 Missing BIRT libs in eclipse .classpath file
 

 Key: OFBIZ-6317
 URL: https://issues.apache.org/jira/browse/OFBIZ-6317
 Project: OFBiz
  Issue Type: Bug
  Components: framework, specialpurpose/birt
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch

 Attachments: OFBIZ-6317.patch


 Because of missing JARs from the specialpurpose component birt in the eclipse 
 .classpath file OFBiz could not be startet within eclipse without errors 
 (NoClassDefFoundError while starting birt component).
 With starting within eclipse I mean the configuration with hot code 
 replacement like this: 
 https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses
 I will provide a patch for the .classpath file with 4 added libs from the 
 specialpurpose/birt/lib folder.
 It would be beneficial, at least for simple contribution of jira issue fixes, 
 if the default configuration of OFBiz from trunk is runnable as is (in a 
 common development scenario like the above), without the need to modify 
 config files which are under version control (.classpath for example). The 
 alternative could be to not put files under version control, that are related 
 to individual development environments.
 By the way, it would also be nice to have the framework/base/config folder as 
 src in the .classpath file as described in the wiki article above, so that 
 the configuration of an eclipse debug/run target for starting OFBiz in 
 eclipse is done by only selecting the project + start-class and giving some 
 JVM args.



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

[jira] [Commented] (OFBIZ-6458) Upgrade OFBiz to Java JDK 8


[ 
https://issues.apache.org/jira/browse/OFBIZ-6458?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14594519#comment-14594519
 ] 

Martin Becker commented on OFBIZ-6458:
--

The second patch (OFBIZ-6458-02-fix-eclipse-compiler.patch related to 
EntityFieldMap) compromises type security. I provided a patch for that within 
OFBIZ-6300 already in April.

 Upgrade OFBiz to Java JDK 8
 ---

 Key: OFBIZ-6458
 URL: https://issues.apache.org/jira/browse/OFBIZ-6458
 Project: OFBiz
  Issue Type: Improvement
Affects Versions: Upcoming Branch
Reporter: Taher Alkhateeb
Assignee: Jacques Le Roux
Priority: Critical
  Labels: java, jdk, jdk8, upgrade
 Fix For: Upcoming Branch

 Attachments: OFBIZ-6458-01-fix-test-errors.patch, 
 OFBIZ-6458-02-fix-eclipse-compiler.patch, OFBIZ-6458-03-update-to-jdk8.patch, 
 OFBIZ-6458-04-update-README.patch


 The following will be tracked through this JIRA:
 - upgrade the framework to JDK 8 and fix any errors
 - make sure that ./ant clean-all load-demo run-tests will run after the 
 upgrade
 - upgrade the infrastructure and demo server to accommodate the new change



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

[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file


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

Martin Becker updated OFBIZ-6317:
-
Attachment: OFBIZ-6317_trunk_framework-base-config.patch

Added patch for adding framework/base/config dir as described above to the 
.classpath file in trunk

 Missing BIRT libs in eclipse .classpath file
 

 Key: OFBIZ-6317
 URL: https://issues.apache.org/jira/browse/OFBIZ-6317
 Project: OFBiz
  Issue Type: Bug
  Components: framework, specialpurpose/birt
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch

 Attachments: OFBIZ-6317.patch, 
 OFBIZ-6317_trunk_framework-base-config.patch


 Because of missing JARs from the specialpurpose component birt in the eclipse 
 .classpath file OFBiz could not be startet within eclipse without errors 
 (NoClassDefFoundError while starting birt component).
 With starting within eclipse I mean the configuration with hot code 
 replacement like this: 
 https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses
 I will provide a patch for the .classpath file with 4 added libs from the 
 specialpurpose/birt/lib folder.
 It would be beneficial, at least for simple contribution of jira issue fixes, 
 if the default configuration of OFBiz from trunk is runnable as is (in a 
 common development scenario like the above), without the need to modify 
 config files which are under version control (.classpath for example). The 
 alternative could be to not put files under version control, that are related 
 to individual development environments.
 By the way, it would also be nice to have the framework/base/config folder as 
 src in the .classpath file as described in the wiki article above, so that 
 the configuration of an eclipse debug/run target for starting OFBiz in 
 eclipse is done by only selecting the project + start-class and giving some 
 JVM args.



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

[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file


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

Martin Becker updated OFBIZ-6317:
-
Affects Version/s: Release Branch 14.12

 Missing BIRT libs in eclipse .classpath file
 

 Key: OFBIZ-6317
 URL: https://issues.apache.org/jira/browse/OFBIZ-6317
 Project: OFBiz
  Issue Type: Bug
  Components: framework, specialpurpose/birt
Affects Versions: Release Branch 14.12, Trunk
Reporter: Martin Becker
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch

 Attachments: OFBIZ-6317.patch, OFBIZ-6317_14-12.patch, 
 OFBIZ-6317_trunk_framework-base-config.patch


 Because of missing JARs from the specialpurpose component birt in the eclipse 
 .classpath file OFBiz could not be startet within eclipse without errors 
 (NoClassDefFoundError while starting birt component).
 With starting within eclipse I mean the configuration with hot code 
 replacement like this: 
 https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses
 I will provide a patch for the .classpath file with 4 added libs from the 
 specialpurpose/birt/lib folder.
 It would be beneficial, at least for simple contribution of jira issue fixes, 
 if the default configuration of OFBiz from trunk is runnable as is (in a 
 common development scenario like the above), without the need to modify 
 config files which are under version control (.classpath for example). The 
 alternative could be to not put files under version control, that are related 
 to individual development environments.
 By the way, it would also be nice to have the framework/base/config folder as 
 src in the .classpath file as described in the wiki article above, so that 
 the configuration of an eclipse debug/run target for starting OFBiz in 
 eclipse is done by only selecting the project + start-class and giving some 
 JVM args.



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

[jira] [Updated] (OFBIZ-6276) Fix deprecation issues in framework/entity


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

Martin Becker updated OFBIZ-6276:
-
Attachment: OFBIZ-6276-EntityStoreOptions.patch

Added new patch which removes the use of deprecated API and the deprecated API 
itself from Delegator and GenericDelegator.

Introduced the EntityStoreOptions class as mentioned in a comment before to 
substitute the createDummyFks parameter of storeAll method to avoid ambiguous 
API after removing the deprecated doCacheClear parameter.

The decryptFieldValue method, just defined deprecated by Jacopo is left there 
as deprecated. Only the old deprecated methods where removed.


 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Jacques Le Roux
Priority: Minor
 Attachments: OFBIZ-6276-EntityStoreOptions.patch, 
 OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Created] (OFBIZ-6522) Potential IndexOutOfBoundsException in CategoryServices.getProductCategoryAndLimitedMembers

Martin Becker created OFBIZ-6522:


 Summary: Potential IndexOutOfBoundsException in 
CategoryServices.getProductCategoryAndLimitedMembers
 Key: OFBIZ-6522
 URL: https://issues.apache.org/jira/browse/OFBIZ-6522
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Priority: Minor


If view indexes as input parameters of service 
getProductCategoryAndLimitedMembers get manipulated (e.g. by manipulating URL 
params or bookmarking an URL with those params an come back later), it can lead 
to an IndexOutOfBoundsException because of a lowIndex greater list size. The 
highIndex is checked for that, the lowIndex is not.



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

[jira] [Updated] (OFBIZ-6305) German translations for various applications

2015-05-29 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6305:
-
Attachment: OFBIZ-6305-PartyComponent.patch

Sorry, I selected the wrong file for upload, now a correct patch for 
PartyComponent is availiable

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Assignee: Christian Geisert
 Attachments: OFBIZ-6305-PartyComponent.patch, 
 OFBIZ-6305-PartyComponent.patch.html, OFBIZ-6305-ProductEntityLabels.patch, 
 OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Updated] (OFBIZ-6305) German translations for various applications

2015-05-29 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6305:
-
Attachment: (was: OFBIZ-6305-PartyComponent.patch.html)

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Assignee: Christian Geisert
 Attachments: OFBIZ-6305-PartyComponent.patch, 
 OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, 
 OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-05-20 Thread Martin Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14552078#comment-14552078
 ] 

Martin Becker commented on OFBIZ-6276:
--

Good point, I would call it EntityStoreOptions according to the existing 
EntityFindOptions.

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Jacques Le Roux
Priority: Minor
 Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-05-19 Thread Martin Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550171#comment-14550171
 ] 

Martin Becker commented on OFBIZ-6276:
--

Hi Jacques,

what do you mean with we already used the same?
This issue is open and unassigned and I wanted to take a step forward to be 
able to work on OFBIZ-6273.

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor
 Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-05-19 Thread Martin Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550445#comment-14550445
 ] 

Martin Becker commented on OFBIZ-6276:
--

Mmmh, 1st way was my 1st idea, but I was not happy with introducing a new 
method name like storeAllWithDummyFks while the strategy is more like adding 
boolean parameters for such features (e.g. useCache parameter instead of 
methods like findByAnd and findByAndCache).
This combined with the small relevance of the createDummyFks Feature (my 
opinion) led me to the simpler API without a different method name but switched 
parameter order for a method that may not be used very often.

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Jacques Le Roux
Priority: Minor
 Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Commented] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-05-19 Thread Martin Becker (JIRA)


[ 
https://issues.apache.org/jira/browse/OFBIZ-6276?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14550341#comment-14550341
 ] 

Martin Becker commented on OFBIZ-6276:
--

Aaah, check!
Not really nice but effective ;-)

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Assignee: Jacques Le Roux
Priority: Minor
 Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Updated] (OFBIZ-6305) German translations for various applications

2015-05-16 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6305:
-
Attachment: OFBIZ-6305-PartyComponent.patch.html

Next translations, now for Party component...

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Assignee: Christian Geisert
 Attachments: OFBIZ-6305-PartyComponent.patch.html, 
 OFBIZ-6305-ProductEntityLabels.patch, OFBIZ-6305-ProductErrorUiLabels.patch, 
 OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Updated] (OFBIZ-6276) Fix deprecation issues in framework/entity

2015-05-16 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6276:
-
Attachment: OFBIZ-6276-variant-2.patch
OFBIZ-6276-variant-1.patch

It has to be ensured, that with the future removal of the doCacheClear 
parameter from the method signature:

from
{{storeAll(ListGenericValue values, boolean doCacheClear, boolean 
createDummyFks)}}
to
{{storeAll(ListGenericValue values, boolean createDummyFks)}}

the signature afterwards does not match the old signature with different 
meaning:  

{{storeAll(ListGenericValue values, boolean doCacheClear)}}

where legacy code would get no compiler error and may miss the changed meaning.


I implemented two variants of a solution for this:

With the first I renamed the method with the concrete implementation from 
storeAll to storeAllInternal and changed the visibility to private, so there is 
no collision with the other signature with {{ListGenericValue, boolean}} 
params. The createDummyFks function is made public available with a new method 
{{storeAllWithDummyFks}}.

The second variant is simpler and without the need of changed method names, it 
just switches the order of the parameters in the signature, which is not so 
nice in reading the signature but avoids special method name for the 
createDummyFks feature.


The next step for me would be to remove the deprecated code from the Delegator 
implementation in the context of OFBIZ-6273.

 Fix deprecation issues in framework/entity
 --

 Key: OFBIZ-6276
 URL: https://issues.apache.org/jira/browse/OFBIZ-6276
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Reporter: Adam Heath
Priority: Minor
 Attachments: OFBIZ-6276-variant-1.patch, OFBIZ-6276-variant-2.patch


 It appears that the storeAll() variants are being refactor; basically, the 
 useCache parameter is being removed.  However, this has caused the
 entity engine to have deprecation with itself.



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

[jira] [Updated] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText

2015-05-06 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6329:
-
Attachment: OFBIZ-6329_Non-Template-Caching-DiffOnly.patch
OFBIZ-6329_FTL-Caching-DiffOnly.patch

Patches *-DiffOnly.patch with simple diff format attached

 Malfunction of configurable FTL-Template caching in 
 DataResourceWorker.renderDataResourceAsText
 ---

 Key: OFBIZ-6329
 URL: https://issues.apache.org/jira/browse/OFBIZ-6329
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Trunk
Reporter: Martin Becker
 Attachments: OFBIZ-6329_FTL-Caching-DiffOnly.patch, 
 OFBIZ-6329_FTL-Caching.patch, OFBIZ-6329_Non-Template-Caching-DiffOnly.patch, 
 OFBIZ-6329_Non-Template-Caching.patch


 There are several problems with the current caching logic in 
 DataResourceWorker.renderDataResourceAsText(...). 
 Enabling the caching of rendered FTL-Templates from DataResources with the 
 property disable.ftl.template.cache in content.properties enables a 
 non-functioning block of code that handles the rendering of the cached 
 template. And if it is deactivated (default), the FTL-Templates are still 
 cached by the FreeMarkerWorker.
 However the correct logic for caching and using the rendered FTL-Template is 
 already implemented in the FreeMarkerWorker and controlled by an optional 
 useCache parameter.
 In addition there is an API call to DataResourceWorker.writeDataResourceText 
 for non template content with a static true for useCache instead of using 
 the given cache parameter value of the renderDataResourceAsText method 
 itself, so even if the caller do not want to use caching at all, the non 
 template text data is cached an FTL-Templates are cached also.
 I will provide a patch for those two issues in the mentioned method.



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

[jira] [Updated] (OFBIZ-6305) German translations for various applications

2015-05-06 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6305:
-
Attachment: OFBIZ-6305-ProductEntityLabels.patch

Patch for ProductEntityLabels...

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Assignee: Christian Geisert
 Attachments: OFBIZ-6305-ProductEntityLabels.patch, 
 OFBIZ-6305-ProductErrorUiLabels.patch, OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Commented] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText

2015-05-05 Thread Martin Becker (JIRA)

[
https://issues.apache.org/jira/browse/OFBIZ-6329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14528284#comment-14528284
]

Martin Becker commented on OFBIZ-6329:
--

Sorry for that, Adrian. I'm using git locally and created the patch files with
git format-patch as Michael stated. Therefore there are some header
informations additional to the standard diff in the patch file. There should be
no need for a committer to modify a patch file to get it working, so we will
create the patch files with git diff, that should be fine.

I will provide corrected patch files here soon and Adrian may check if they are
usable for him (and thus for all others).

Malfunction of configurable FTL-Template caching in
DataResourceWorker.renderDataResourceAsText
---

Key: OFBIZ-6329
URL: https://issues.apache.org/jira/browse/OFBIZ-6329
Project: OFBiz
Issue Type: Bug
Components: content
Affects Versions: Trunk
Reporter: Martin Becker
Attachments: OFBIZ-6329_FTL-Caching.patch,
OFBIZ-6329_Non-Template-Caching.patch

There are several problems with the current caching logic in
DataResourceWorker.renderDataResourceAsText(...).
Enabling the caching of rendered FTL-Templates from DataResources with the
property disable.ftl.template.cache in content.properties enables a
non-functioning block of code that handles the rendering of the cached
template. And if it is deactivated (default), the FTL-Templates are still
cached by the FreeMarkerWorker.
However the correct logic for caching and using the rendered FTL-Template is
already implemented in the FreeMarkerWorker and controlled by an optional
useCache parameter.
In addition there is an API call to DataResourceWorker.writeDataResourceText
for non template content with a static true for useCache instead of using
the given cache parameter value of the renderDataResourceAsText method
itself, so even if the caller do not want to use caching at all, the non
template text data is cached an FTL-Templates are cached also.
I will provide a patch for those two issues in the mentioned method.

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

Re: Vote: move to git.

2015-05-05 Thread Martin Becker



smime.p7m
Description: S/MIME encrypted message

Re: Vote: move to git.

2015-05-05 Thread Martin Becker

Full ack for Adams remarks.

There should be a +0.5 like „I like this idea, but the realization has to be 
well planned for a point in the future where the all over organization fits the 
needs for a different contribution process ;-)

So, +0.5 from me.

Martin Becker
ecomify GmbH
www.ecomify.de



 Am 05.05.2015 um 06:25 schrieb Adam Heath doo...@brainfood.com:
 
 This may be the nail in the coffin, at least for now, but +0, needs more 
 discussion/planning.  I've been using git-svn for longer than most with 
 ofbiz, and would really love it if we were already using git, but it's just 
 too soon.
 
 Just because git is decentralized, doesn't mean that there is no longer a 
 center. *Someone* has to be pulling/merging all the branches, and who would 
 step up to that plate?  Who would want to take on the mantel?  I don't think 
 we as a community are ready to require that of someone.
 
 Of course, we need to start planning for this eventuality, imho, but we are 
 still a long ways off.
 
 ps: I, and others, will continue to use git in our upstream svn interactions, 
 as that seems to work well enough
 
 pps: as per Adrian's vote call, there is nothing actionable here.
 
 On 05/04/2015 10:01 PM, Hans Bakker wrote:
 As the discussions seem to end, can i propose a vote?
 
 The question : should we convert the master SVN repository of Apache OFBIz 
 to a GIT version?
 The possible answers are according the apache voting guidelines at: 
 https://www.apache.org/foundation/voting.html
 
 *
 
   +1: 'Yes lets do it'
 
 * +0: 'I don't feel strongly about it, but I'm okay with this.'
 *
 
   -0.5: 'I don't like this idea, but I can't find any rational
   justification for my feelings.'
 
 *
 
   ++1: 'Wow! I like this! Let's /do/ it!'
 
 *
 
   -0.9: 'I /really/ don't like this, but I'm not going to stand in the
   way if everyone else wants to go ahead with it.'
 
 *
 
   +0.9: 'This is a cool idea and i like it, but I don't have time/the
   skills necessary to help out.'
 
 * -1 'I do not want this.'
 
 
 Votes will be possible for one week from today.
 
 Regards,
 Hans
 
 On 20/04/15 11:38, Hans Bakker wrote:
 As discussed at apachecon in Austin, i propose to switch from svn to git 
 for the ofbiz repository. The main reason being that all major contributors 
 are using git and contributions are cumbersome, further, git allows for 
 better branching and merging.
 
 Regards,
 Hans

[jira] [Updated] (OFBIZ-6305) German translations for various applications

2015-05-04 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6305:
-
Attachment: OFBIZ-6305-ProductErrorUiLabels.patch

Next patch for the ProductErrorUiLabels...

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
Assignee: Christian Geisert
 Attachments: OFBIZ-6305-ProductErrorUiLabels.patch, 
 OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Created] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText

2015-05-04 Thread Martin Becker (JIRA)

Martin Becker created OFBIZ-6329:


 Summary: Malfunction of configurable FTL-Template caching in 
DataResourceWorker.renderDataResourceAsText
 Key: OFBIZ-6329
 URL: https://issues.apache.org/jira/browse/OFBIZ-6329
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Trunk
Reporter: Martin Becker


There are several problems with the current caching logic in 
DataResourceWorker.renderDataResourceAsText(...). 

Enabling the caching of rendered FTL-Templates from DataResources with the 
property disable.ftl.template.cache in content.properties enables a 
non-functioning block of code that handles the rendering of the cached 
template. And if it is deactivated (default), the FTL-Templates are still 
cached by the FreeMarkerWorker.

However the correct logic for caching and using the rendered FTL-Template is 
already implemented in the FreeMarkerWorker and controlled by an optional 
useCache parameter.

In addition there is an API call to DataResourceWorker.writeDataResourceText 
for non template content with a static true for useCache instead of using the 
given cache parameter value of the renderDataResourceAsText method itself, so 
even if the caller do not want to use caching at all, the non template text 
data is cached an FTL-Templates are cached also.

I will provide a patch for those two issues in the mentioned method.



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

[jira] [Updated] (OFBIZ-6329) Malfunction of configurable FTL-Template caching in DataResourceWorker.renderDataResourceAsText

2015-05-04 Thread Martin Becker (JIRA)


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

Martin Becker updated OFBIZ-6329:
-
Attachment: OFBIZ-6329_Non-Template-Caching.patch
OFBIZ-6329_FTL-Caching.patch

 Malfunction of configurable FTL-Template caching in 
 DataResourceWorker.renderDataResourceAsText
 ---

 Key: OFBIZ-6329
 URL: https://issues.apache.org/jira/browse/OFBIZ-6329
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Trunk
Reporter: Martin Becker
 Attachments: OFBIZ-6329_FTL-Caching.patch, 
 OFBIZ-6329_Non-Template-Caching.patch


 There are several problems with the current caching logic in 
 DataResourceWorker.renderDataResourceAsText(...). 
 Enabling the caching of rendered FTL-Templates from DataResources with the 
 property disable.ftl.template.cache in content.properties enables a 
 non-functioning block of code that handles the rendering of the cached 
 template. And if it is deactivated (default), the FTL-Templates are still 
 cached by the FreeMarkerWorker.
 However the correct logic for caching and using the rendered FTL-Template is 
 already implemented in the FreeMarkerWorker and controlled by an optional 
 useCache parameter.
 In addition there is an API call to DataResourceWorker.writeDataResourceText 
 for non template content with a static true for useCache instead of using 
 the given cache parameter value of the renderDataResourceAsText method 
 itself, so even if the caller do not want to use caching at all, the non 
 template text data is cached an FTL-Templates are cached also.
 I will provide a patch for those two issues in the mentioned method.



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

[jira] [Updated] (OFBIZ-6317) Missing BIRT libs in eclipse .classpath file


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

Martin Becker updated OFBIZ-6317:
-
Attachment: OFBIZ-6317.patch

 Missing BIRT libs in eclipse .classpath file
 

 Key: OFBIZ-6317
 URL: https://issues.apache.org/jira/browse/OFBIZ-6317
 Project: OFBiz
  Issue Type: Bug
  Components: framework, specialpurpose/birt
Affects Versions: Trunk
Reporter: Martin Becker
Priority: Minor
 Attachments: OFBIZ-6317.patch


 Because of missing JARs from the specialpurpose component birt in the eclipse 
 .classpath file OFBiz could not be startet within eclipse without errors 
 (NoClassDefFoundError while starting birt component).
 With starting within eclipse I mean the configuration with hot code 
 replacement like this: 
 https://cwiki.apache.org/confluence/display/OFBIZ/Running+and+Debugging+OFBiz+in+Eclipse#RunningandDebuggingOFBizinEclipse-debuggingInEclipseHotClasses
 I will provide a patch for the .classpath file with 4 added libs from the 
 specialpurpose/birt/lib folder.
 It would be beneficial, at least for simple contribution of jira issue fixes, 
 if the default configuration of OFBiz from trunk is runnable as is (in a 
 common development scenario like the above), without the need to modify 
 config files which are under version control (.classpath for example). The 
 alternative could be to not put files under version control, that are related 
 to individual development environments.
 By the way, it would also be nice to have the framework/base/config folder as 
 src in the .classpath file as described in the wiki article above, so that 
 the configuration of an eclipse debug/run target for starting OFBiz in 
 eclipse is done by only selecting the project + start-class and giving some 
 JVM args.



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

[jira] [Updated] (OFBIZ-6305) German translations for various applications


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

Martin Becker updated OFBIZ-6305:
-
Attachment: OFBIZ-6305-ProductUiLabels.patch

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
 Attachments: OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Commented] (OFBIZ-6305) German translations for various applications


[ 
https://issues.apache.org/jira/browse/OFBIZ-6305?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14521698#comment-14521698
 ] 

Martin Becker commented on OFBIZ-6305:
--

OFBIZ-6305-ProductUiLabels.patch is the first patch for this issue, it contains 
about 900 changes in ProductUILabels.xml. Mainly missing german translations 
added but also some corrections in other entries.

 German translations for various applications
 

 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker
 Attachments: OFBIZ-6305-ProductUiLabels.patch


 We would like to contribute missing german translations for the OFBiz 
 applications based on the current trunk. There will arrive patches for this 
 per application within this ticket.



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

[jira] [Created] (OFBIZ-6319) Add missing entries to .gitignore to ignore typical Idea/eclipse folders/files

Martin Becker created OFBIZ-6319:


 Summary: Add missing entries to .gitignore to ignore typical 
Idea/eclipse folders/files
 Key: OFBIZ-6319
 URL: https://issues.apache.org/jira/browse/OFBIZ-6319
 Project: OFBiz
  Issue Type: Improvement
Affects Versions: Trunk
Reporter: Martin Becker
Priority: Trivial


Some folder/filenames that are configured for SVN to be ignored are missing in 
the current .gitignore file. Especially the internal config folders created by 
eclipse in the project root (.settings and .groovy) are missing for me, so that 
they get displayed as modification while using git.



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

[jira] [Created] (OFBIZ-6305) German translations for various applications

2015-04-28 Thread Martin Becker (JIRA)

Martin Becker created OFBIZ-6305:


 Summary: German translations for various applications
 Key: OFBIZ-6305
 URL: https://issues.apache.org/jira/browse/OFBIZ-6305
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Affects Versions: Upcoming Branch
Reporter: Martin Becker


We would like to contribute missing german translations for the OFBiz 
applications based on the current trunk. There will arrive patches for this per 
application within this ticket.



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

Re: VOTE: Begin Replacing OFBiz Framework With Moqui

2015-04-27 Thread Martin Becker

Generally I see three ways if I think of an combination of OFBiz and Moqui as 
already mentioned in the discussion so far:

1) „Replace“ the OFBiz Framework with Moqui

2) Replace parts of the OFBiz Framework with Moqui parts respectively update 
the OFBiz Framework in a Moqui manner

3) Migrate OFBiz applications and functionality, so that they be part of Mantle 
or standalone apps on base of Moqui

Numbers 1 and 3 could lead to the same result, maybe the steps between are 
different or the approach or just the headline is another. 
Number 2 is more like thinking of optimization of the current framework, maybe 
by looking at Moqui, but there would be no Moqui integration in the end, only 
an updated OFBiz Framework.


My vote for 1) is -1, because I don’t think it is a realistic project in terms 
of effort vs. benefit an with respect to the „customers“ of an „application 
framework OFBiz, this change could be an upgrade killer.

For 2) there is generally a +1 where optimizations are reasonable, but this 
might be much less than a Moqui framework switch

For 3) I say +1, also this would more be an parallel next OFBiz“ thing


Martin Becker
ecomify GmbH



 Am 27.04.2015 um 03:20 schrieb Adam Heath doo...@brainfood.com:
 
 Begin replacing ... is not an actional item.
 
 How can we vote on something that is ill-defined?  Just saying.
 
 On 04/26/2015 08:09 PM, Ron Wheeler wrote:
 +1 for being too early.
 -1 for going ahead as a project
 +1 for a PoC and impact analysis
 
 Ron
 
 On 26/04/2015 6:46 PM, Pierre Smits wrote:
 First of all, a big thanks to Adrian for taking this step, this RtV
 (Request to Vote) to get clarity from the community. A lot has been said
 over the last week regarding adopting a new architecture for a future
 release.
 
 When discussions, like fire, die down it is good to find out where the
 community stands. And it seems that a saturation point was reached, as the
 last posting before Adam started to test the water of consensus was already
 6 days ago.
 
 It seems that we are facing a chicken-and-egg situation here, as we can't
 vote on the new direction without knowing the impact of such path. And we
 can't establish insights about the impact without having tested the water
 and report about it.
 
 A PoC is a means to gain the insights. Based on the output of such an
 action, the community can reach a well-founded decision. But a PoC is not
 the only means to establish the insight. An in-dept comparative study  of
 the two solutions (architecture, et all) might lead to such insights too.
 And a PoC can be done everywhere, even outside the OFBiz repository.
 
 The result of the impact analysis (whether from PoC or comparative study)
 could be recorded as JIRA issues. And all the registered JIRA issues
 together will be the starting point of a dev branch when the community
 votes for the adoption of a new architecture or not (based on those issues
 and other information).
 
 On the basis of current (high level) information regarding the impact, I
 say it is to early to vote for a migration.
 
 Best regards,
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Sun, Apr 26, 2015 at 10:56 PM, Michael Brohl michael.br...@ecomify.de
 wrote:
 
 Thank you for the clarification.
 I'll stick to my vote and my arguments then.
 
 Michael Brohl
 ecomify GmbH
 www.ecomify.de
 
 Am 26.04.15 um 22:33 schrieb Adrian Crum:
 
  No, it is not a vote for a POC. If the community agrees we need to make a
 change, then we can create a Jira issue, branch, POC, etc.
 
 No one is going to go to all that work if in the end the community says
 Nope, don't want it.
 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com

[jira] [Commented] (OFBIZ-5169) Removing Javolution from framework components


[ 
https://issues.apache.org/jira/browse/OFBIZ-5169?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511170#comment-14511170
 ] 

Martin Becker commented on OFBIZ-5169:
--

Well, my intention is to overall switch the now used LinkedList to ArrayList, 
as it is the more proper default with a light performance drawback in rare 
cases, if at all, and to be in line with the types used in groovy scripts. No 
functional drawback compared to FastList is to be expected (in contrast to 
HashMap/HashSet, if preserving the insert-order for iteration is a requirement).

That would be a good starting point for detailed analysis and changes in the 
scope of [OFBIZ-6298], to optimize the use of collection types, also this will 
be a very exhausting activity over thousands of code places with very small 
expectable benefits in real world performance.


 Removing Javolution from framework components
 -

 Key: OFBIZ-5169
 URL: https://issues.apache.org/jira/browse/OFBIZ-5169
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Varun Bhansaly
Priority: Minor
 Attachments: framework-FastList-removed.patch


 a. Remove static instances of Javolution objects.
 b. Remove other uses of Javolution objects.



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

[jira] [Commented] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8


[ 
https://issues.apache.org/jira/browse/OFBIZ-6300?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14511232#comment-14511232
 ] 

Martin Becker commented on OFBIZ-6300:
--

1.8 compile target top-level issue sounds good, currently (after applying my 
patch) there should only be warnings. The patched issue in EntityFieldMap was 
the only error I got.

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath
 Attachments: OFBIZ-6300-EntityFieldMap.patch


 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

[jira] [Updated] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8


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

Martin Becker updated OFBIZ-6300:
-
Attachment: OFBIZ-6300-EntityFieldMap.patch

 Compiler-Error with JDK 1.8 and source compatibility 1.8
 

 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Adam Heath
 Attachments: OFBIZ-6300-EntityFieldMap.patch


 I just found another error compiling the code with JDK 1.8 with source code 
 compatibility switched to 1.8 in my eclipse workspace. The external ant build 
 is working because there is java version 1.7 defined as target in the 
 macros.xml.
 The error is an issue regarding generics in EntityFieldMap.java.
 I will provide a patch her soon.
 The code is the same in the release branches.



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

[jira] [Created] (OFBIZ-6300) Compiler-Error with JDK 1.8 and source compatibility 1.8

Martin Becker created OFBIZ-6300:


 Summary: Compiler-Error with JDK 1.8 and source compatibility 1.8
 Key: OFBIZ-6300
 URL: https://issues.apache.org/jira/browse/OFBIZ-6300
 Project: OFBiz
  Issue Type: Bug
  Components: framework
Affects Versions: Trunk
Reporter: Martin Becker


I just found another error compiling the code with JDK 1.8 with source code 
compatibility switched to 1.8 in my eclipse workspace. The external ant build 
is working because there is java version 1.7 defined as target in the 
macros.xml.

The error is an issue regarding generics in EntityFieldMap.java.

I will provide a patch her soon.

The code is the same in the release branches.



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

Re: move to git.

2015-04-23 Thread Martin Becker

 Strange occurrences stopped happening for me after a couple of months and
 generally stopped once all developers either stopped using git client UIs
 that used settings they didn't understand or they started using the command
 line…


That’s my experience, too, and therefore one of my reasons to not love git so 
far. I’m a command line guy, but for daily „commit work i miss the overview an 
the usability of a UI that I can rely on. But this is a mainly „layer 8“ 
problem…

In my opinion, the main aspect is the decision for a different workflow for 
contributing and managing this project with its opportunities and drawbacks, as 
stated widely in this thread. Maybe it’s necessary to think about which 
processes and workflows maybe the ones that are expected by the current and 
especially future audience/clients/contributors from a state of the art, living 
and ongoing open source project.

Martin Becker
ecomify GmbH




 Am 23.04.2015 um 10:28 schrieb Scott Gray scott.g...@hotwaxsystems.com:
 
 I am thoroughly familiar with Git.
 Git always screws things up.
 
 These two statements are complete contradictions.  Outcomes in git only
 appear strange while you're still unfamiliar with it.
 
 I've been using the git-svn bridge to commit to OFBiz for about 4 years and
 using a git repo on my current project for the last 18 months or so.
 Strange occurrences stopped happening for me after a couple of months and
 generally stopped once all developers either stopped using git client UIs
 that used settings they didn't understand or they started using the command
 line (which is exceedingly simple for basic workflows).
 
 The value of feature branches and pull requests over patches cannot be
 overstated IMO.  The ability to easily multi-task on features, review pull
 requests, keep a real commit history for contributed features, to
 collaborate outside of the main repo puts git miles ahead of svn for
 collaborative incremental software development.
 
 Regards
 Scott
 
 
 On 20 April 2015 at 22:19, Adrian Crum adrian.c...@sandglass-software.com
 wrote:
 
 I am thoroughly familiar with Git. I've used it on on three projects, and
 that is why I don't like it.
 
 I have a far easier time merging branches with Subversion. Git always
 screws things up.
 
 I don't need to be convinced of anything. I have my experience and my
 opinion. But still, I'm not opposed to switching to Git.
 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com
 
 On 4/20/2015 11:08 AM, Taher Alkhateeb wrote:
 
 One of the most difficult and challenging issue with branches is _merging_
 them. Git is a tool that is far more advanced in its feature set in that
 area.
 
 It seems some of the opinions expressed against git are due to
 unfamiliarity. The only way to be convinced is to try it on an advanced
 level as i don't think an email thread would be enough for convincing
 anyone of the merits.
 
 My 2 cents
 
 Taher Alkhateeb
 On Apr 20, 2015 12:54 PM, Pierre Smits pierre.sm...@gmail.com wrote:
 
 If we only want GIT for multiple local development branches, then we are
 doing for the wrong reasons. SVN doesn't hinder you in doing that today.
 
 Best regards,
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Mon, Apr 20, 2015 at 11:12 AM, Jacques Le Roux 
 jacques.le.r...@les7arts.com wrote:
 
 Like Adrian and mostly for the same reasons, I don't believe we need
 Git.
 
 But there is one other major reason which has already been discussed in
 the other common ASF MLs.  As Taher exulted, it's possible to create
 
 local
 
 branches. So people are able to do a lot of work alone without
 exchanging
 before committing or submitting. It will certainly not help to have this
 possibility. Remember our recent discussion on the lack or core commits
 reviews. With Git you end with commits bursts or big patches and it's
 
 then
 
 hard to review and too late to share ideas.
 
 So unlike Adrian, I'm even strongly against it. I will not hesitate to
 
 use
 
 a -1 if necessary!
 
 Jacques
 
 
 Le 20/04/2015 09:53, Adrian Crum a écrit :
 
 I don't agree that all major contributors are using git.
 
 Personally, I find Git to be an overly complicated solution to a simple
 problem. It frequently does bizarre things that no one understands, and
 
 you
 
 are left with things being mysteriously reverted for unknown reasons.
 
 This isn't a -1 vote though. I'm just making it clear that I will be
 dragged kicking and screaming into using it.
 
 Adrian Crum
 Sandglass Software
 www.sandglass-software.com
 
 On 4/20/2015 5:38 AM, Hans Bakker wrote:
 
 As discussed at apachecon in Austin, i propose to switch from svn to
 
 git
 
 for the ofbiz repository. The main reason being that all major
 contributors are using git and contributions are cumbersome, further,
 git allows for better branching and merging.
 
 Regards,
 Hans

[jira] [Commented] (OFBIZ-6238) Give the order notification email attachment the orderId as filename


[ 
https://issues.apache.org/jira/browse/OFBIZ-6238?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507275#comment-14507275
 ] 

Martin Becker commented on OFBIZ-6238:
--

What (F)partyId do you mean for your setting, from the order point of view, 
respectively which orderRole to get a party from the current oder? As there a 
different roles for sales and purchase orders, this has to be differentiated at 
least.

My thought was a simple and robust way to give the attachment a unique name, 
which the orderId itself does, or isn't it?

 Give the order notification email attachment the orderId as filename
 

 Key: OFBIZ-6238
 URL: https://issues.apache.org/jira/browse/OFBIZ-6238
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Trunk
Reporter: Martin Becker
Assignee: Jacopo Cappellato
Priority: Trivial
 Attachments: OrderServices.patch


 According to customer needs I've made a change to 
 OrderServices.sendOrderNotificationScreen to fill the attachmentName 
 parameter of the sendMailFromScreen context with the orderId to override the 
 default in sendMailFromScreen, so that the PDF attachments in standard order 
 notifications have a name like WS10001.pdf instead of Details.pdf



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

Re: Renaming OFBiz artefacts

2015-04-22 Thread Martin Becker

That’s a good point!

(especially for a bunch of build tool alternative branches ;-))

Martin Becker
ecomify GmbH



 Am 22.04.2015 um 17:13 schrieb Adam Heath doo...@brainfood.com:
 
 -1, but not permanently.
 
 If we start renaming things, then it'll become hard to port changes back and 
 forth between release branches and trunk.  We need to reduce the number of 
 outstanding branches first, before this can even be started.
 
 On 04/22/2015 10:09 AM, Ron Wheeler wrote:
 I was thinking of something like an 8 hour sprint where several people 
 divide up the task and do it  and test it quickly.
 divide up by application, code/XML, seed data, documentation, testing and 
 what ever makes sense to get the change done in a few hours.
 
 Ron
 On 22/04/2015 5:01 AM, Pierre Smits wrote:
 Ron,
 
 Notwithstanding the appropriateness of the elements in your response,
 everything done in the OFBiz project IS a community project (endeavour for
 a better word).
 
 Thank you for reiterating the invite for more collaboration. I
 wholeheartedly agree and support.
 
 Best regards,
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 On Wed, Apr 22, 2015 at 10:47 AM, Ron Wheeler 
 rwhee...@artifact-software.com wrote:
 
 Definitely a good idea.
 Should it be done as a community project over a short period of time?
 It would seem to be easier to do as a sort of global search and replace
 followed by testing rather than modifying a piece and looking for all of
 the references to that code and changing them and testing and then picking
 the next piece.
 
 Adding a JIRA sounds like the best start.
 
 Ron
 
 On 22/04/2015 4:36 AM, Pierre Smits wrote:
 
 Hi all,
 
 In this posting http://ofbiz.markmail.org/message/mjlm5dvimcjngr6k Adrian
 proposed to rename our OFBiz artefacts from org.ofbiz to
 org.apache.ofbiz to bring it more inline to conventions used by other
 Apache projects/products.
 
 Does this proposal need any further discussion? Or can we move forward by
 creating a JIRA and work from there?
 
 Best regards,
 
 
 Pierre Smits
 
 *ORRTIZ.COM http://www.orrtiz.com*
 Services  Solutions for Cloud-
 Based Manufacturing, Professional
 Services and Retail  Trade
 http://www.orrtiz.com
 
 
 -- 
 Ron Wheeler
 President
 Artifact Software Inc
 email: rwhee...@artifact-software.com
 skype: ronaldmwheeler
 phone: 866-970-2435, ext 102

[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014


[ 
https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507425#comment-14507425
 ] 

Martin Becker commented on OFBIZ-6273:
--

There are about 375 findings of Deprecated keyword in java code in the trunk, 
some are duplicated, because of the deprecated keyword in javaDoc and as 
annotation for the same method.

What about to link this issue with [OFBIZ-6275] OFBiz code seems make use of 
other deprecated OFBiz features from Adam for which a branch already exists, 
since the use of some deprecated API by OFBiz has to be changed first before we 
can get rid of the deprecated API itself?

I would vote for first fixing the findings from Adam and then removing the 
deprecated API, either in the branch Adam just created or in another branch in 
sequence.

Another question is: What about deprecated fields/entities and corresponding 
upgrade services?

 Remove from trunk the deprecated code if deprecated before December 2014
 

 Key: OFBIZ-6273
 URL: https://issues.apache.org/jira/browse/OFBIZ-6273
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Jacopo Cappellato

 The code that has been deprecated before December 2014 will be released in 
 the releases of the 14.12 branch: in this way users will be notified about 
 deprecated methods/code.
 For this reason we can proceed and remove all the deprecated code from trunk, 
 deprecated before December 2014.



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

[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014


[ 
https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14507496#comment-14507496
 ] 

Martin Becker commented on OFBIZ-6273:
--

Thats my opinion, too (entities/fields).

I will monitor [OFBIZ-6275] and perhaps deliver some patches for the issues 
there and come back to this task if afterwards.

 Remove from trunk the deprecated code if deprecated before December 2014
 

 Key: OFBIZ-6273
 URL: https://issues.apache.org/jira/browse/OFBIZ-6273
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Jacopo Cappellato

 The code that has been deprecated before December 2014 will be released in 
 the releases of the 14.12 branch: in this way users will be notified about 
 deprecated methods/code.
 For this reason we can proceed and remove all the deprecated code from trunk, 
 deprecated before December 2014.



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

[jira] [Commented] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014


[ 
https://issues.apache.org/jira/browse/OFBIZ-6273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14506749#comment-14506749
 ] 

Martin Becker commented on OFBIZ-6273:
--

I would like to do this for the community.

 Remove from trunk the deprecated code if deprecated before December 2014
 

 Key: OFBIZ-6273
 URL: https://issues.apache.org/jira/browse/OFBIZ-6273
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL COMPONENTS
Affects Versions: Trunk
Reporter: Jacopo Cappellato

 The code that has been deprecated before December 2014 will be released in 
 the releases of the 14.12 branch: in this way users will be notified about 
 deprecated methods/code.
 For this reason we can proceed and remove all the deprecated code from trunk, 
 deprecated before December 2014.



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

[jira] [Comment Edited] (OFBIZ-6273) Remove from trunk the deprecated code if deprecated before December 2014