date:20160616


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

Pranay Pandey reassigned OFBIZ-7329:


Assignee: Pranay Pandey

> An exception is being thrown when day links are clicked in the Week and Month 
> view of the Calendar widget.
> --
>
> Key: OFBIZ-7329
> URL: https://issues.apache.org/jira/browse/OFBIZ-7329
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 
> Release Branch 15.12
>Reporter: Aditya Patwa
>Assignee: Pranay Pandey
> Attachments: OFBIZ-7329.patch
>
>
> While clicking on the day link (i.e. Sunday, Monday etc.) in Week view or on 
> a particular day of the month in the month view, an exception is thrown due 
> to unparseable date format.
> Exception : 
>  org.ofbiz.base.conversion.ConversionException: java.text.ParseException: 
> Unparseable date: "146566980 00:00:00.000"
>  [java]   at 
> org.ofbiz.base.conversion.DateTimeConverters$StringToTimestamp.convert(DateTimeConverters.java:671)
>  ~[ofbiz-base.jar:?]
>  [java]   at 
> org.ofbiz.base.conversion.DateTimeConverters$StringToTimestamp.convert(DateTimeConverters.java:618)
>  ~[ofbiz-base.jar:?]
>  [java]   at 
> org.ofbiz.base.util.ObjectType.simpleTypeConvert(ObjectType.java:543) 
> [ofbiz-base.jar:?]
>  [java]   at 
> org.ofbiz.service.ModelService.makeValid(ModelService.java:910) 
> [ofbiz-service.jar:?]
>  [java]   at 
> org.ofbiz.service.ModelService.makeValid(ModelService.java:838) 
> [ofbiz-service.jar:?]
>  [java]   at 
> org.ofbiz.service.ModelService.makeValid(ModelService.java:826) 
> [ofbiz-service.jar:?]
>  [java]   at 
> org.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:192) 
> [ofbiz-service.jar:?]
>  [java]   at 
> org.ofbiz.service.DispatchContext.makeValidContext(DispatchContext.java:162) 
> [ofbiz-service.jar:?]
>  [java]   at 
> org.ofbiz.service.DispatchContext$makeValidContext$0.call(Unknown Source) 
> [ofbiz-service.jar:?]
>  [java]   at Days.run(Days.groovy:38) [script:?]



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

[jira] [Commented] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly

2016-06-16 Thread Mridul Pathak (JIRA)


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

Mridul Pathak commented on OFBIZ-6386:
--

Hi [~jacques.le.roux]
That should still work as per the written code through BigDecimal.compareTo() 
implementation of Comparable. compareBigDecimal() method was doing the same but 
with additional unnecessary rounding.

> compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
> compare certain values correctly
> -
>
> Key: OFBIZ-6386
> URL: https://issues.apache.org/jira/browse/OFBIZ-6386
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Mridul Pathak
>Priority: Minor
> Attachments: compareBigDecimals.png, v1.patch, v2.patch
>
>
> Moving the conversation from OFBIZ-6291 to this issue.
> compareBigDecimals scales down and rounds up meaning you lose information and 
> the comparison result is not as expected



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

[jira] [Updated] (OFBIZ-7374) Add capability to Expire or Remove the added content for a party

2016-06-16 Thread Swapnil Shah (JIRA)


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

Swapnil Shah updated OFBIZ-7374:

Attachment: Party_content_1.png

> Add capability to Expire or Remove the added content for a party
> 
>
> Key: OFBIZ-7374
> URL: https://issues.apache.org/jira/browse/OFBIZ-7374
> Project: OFBiz
>  Issue Type: New Feature
>  Components: party
>Affects Versions: Release Branch 14.12, 14.12.01, Release Branch 15.12, 
> 15.12.01
>Reporter: Swapnil Shah
>Assignee: Swapnil Shah
> Attachments: Party_content_1.png
>
>
> Currently when any content is uploaded/added with respect to any party via 
> Party Manager >> Parties >> Party Content tab, there is no option for user to 
> Expire or remove such added content in any form
> We could try adding this feature that could allow user to 
> # Expire any content by setting thru_date to now() on click of "Expire" 
> button against each content row
> # Or option to update the From/Thru date by showing these dates as editable 
> against each content row
> # Remove any added content on click of a "Delete" button 
> (Please refer to attached screenshot for reference)
> We could also try to improvise code such that content associated with any 
> party (PartyContent) are fetched and honored based on thru_date.



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

[jira] [Created] (OFBIZ-7374) Add capability to Expire or Remove the added content for a party

2016-06-16 Thread Swapnil Shah (JIRA)

Swapnil Shah created OFBIZ-7374:
---

 Summary: Add capability to Expire or Remove the added content for 
a party
 Key: OFBIZ-7374
 URL: https://issues.apache.org/jira/browse/OFBIZ-7374
 Project: OFBiz
  Issue Type: New Feature
  Components: party
Affects Versions: Release Branch 15.12, Release Branch 14.12, 14.12.01, 
15.12.01
Reporter: Swapnil Shah
Assignee: Swapnil Shah


Currently when any content is uploaded/added with respect to any party via 
Party Manager >> Parties >> Party Content tab, there is no option for user to 
Expire or remove such added content in any form

We could try adding this feature that could allow user to 
# Expire any content by setting thru_date to now() on click of "Expire" button 
against each content row
# Or option to update the From/Thru date by showing these dates as editable 
against each content row
# Remove any added content on click of a "Delete" button 
(Please refer to attached screenshot for reference)

We could also try to improvise code such that content associated with any party 
(PartyContent) are fetched and honored based on thru_date.





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

[jira] [Commented] (OFBIZ-6986) Simplify getChildHRCategoryTree


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

Jacques Le Roux commented on OFBIZ-6986:


Hi [~kulwantbughipura], any news?

> Simplify getChildHRCategoryTree
> ---
>
> Key: OFBIZ-6986
> URL: https://issues.apache.org/jira/browse/OFBIZ-6986
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS, humanres
>Reporter: Kulwant
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6986.patch, OFBIZ-6986.patch, OFBIZ-6986.patch
>
>
> breaking the single long method to multiple private functions with improved 
> exception handling.



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

[jira] [Created] (OFBIZ-7373) Update Shiro to 12.5 (CVE-2016-4437)

Jacques Le Roux created OFBIZ-7373:
--

 Summary: Update Shiro to 12.5 (CVE-2016-4437)
 Key: OFBIZ-7373
 URL: https://issues.apache.org/jira/browse/OFBIZ-7373
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Release Branch 15.12, Trunk
Reporter: Jacques Le Roux
 Fix For: 15.12.01


Apache Shiro before 1.2.5, when a cipher key has not been configured for the 
"remember me" feature, allows remote attackers to execute arbitrary code or 
bypass intended access restrictions via an unspecified request parameter.

Details at https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2016-4437



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

[jira] [Commented] (OFBIZ-6947) Inventory report throws an error

2016-06-16 Thread Pierre Smits (JIRA)


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

Pierre Smits commented on OFBIZ-6947:
-

No worries.

> Inventory report throws an error
> 
>
> Key: OFBIZ-6947
> URL: https://issues.apache.org/jira/browse/OFBIZ-6947
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: facility, inventory, pdf
> Fix For: 15.12.01
>
> Attachments: OFBIZ-6947_trunk.patch, OFBIZ-6947_trunk_2.patch
>
>
> When executing the print pdf function in 
> https://demo-trunk-ofbiz.apache.org/facility/control/ViewFacilityInventoryByProduct
> the following error is thrown:
> {code}
> The Following Errors Occurred:
> Unable to transform FO file: org.apache.fop.apps.FOPException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115) javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115)
> {code}



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

[jira] [Commented] (OFBIZ-6386) compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not compare certain values correctly


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

Jacques Le Roux commented on OFBIZ-6386:


I tend to agree with all of you, but what will happen to the 161 lines of code 
with
 compareBigDecimals in org.ofbiz.minilang.method.conditional.Compare does not 
> compare certain values correctly
> -
>
> Key: OFBIZ-6386
> URL: https://issues.apache.org/jira/browse/OFBIZ-6386
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Mridul Pathak
>Priority: Minor
> Attachments: compareBigDecimals.png, v1.patch, v2.patch
>
>
> Moving the conversation from OFBIZ-6291 to this issue.
> compareBigDecimals scales down and rounds up meaning you lose information and 
> the comparison result is not as expected



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

Re: We miss a QA team, we face too much regressions

2016-06-16 Thread Ron Wheeler

One of the side benefits of having a small number of committer's is that 
you prevent bad designs and poorly  tested code getting into the trunk.
The disadvantage is that the committers are easily overwhelmed by an 
active contributor community.


You may want to put in some rules about unit tests so that code without 
adequate test coverage can not be updated until the unit tests are 
sufficient for the committer to feel confident about accepting it. This 
may cause people to work on tests for stuff that they did not write but 
are considered key functionality in the modules being updated.
There is no free ride and if you allow people to build up the technical 
debt of the project in order to meet their own deadlines, you will 
eventually have to face a large debt that comes due.


Taher is paying off the debt in the framework which is a great 
contribution.
It may be that others are going to have to take up the challenge in the 
application side.
You may have to have a short moratorium on enhancements until the debt 
is reduced to a manageable level.


There may also be the issue of people modifying too many layers at once 
so changes affect a lot of different services so unpleasant side-effects 
are easier to generate.


Are the regressions caused by a small group of contributors or from 
updates going through a few committers?


It is an open source project so there has to be some sensitivity about 
asking people to do a bit more to clean up old debt but if that is a 
problem and it is not addressed, it can be a big mess.



Ron


On 16/06/2016 3:48 PM, Taher Alkhateeb wrote:

Hi Jacques,

Selenium tests cannot be unit tests in OFBiz because it requires firing up
the server. You can consider them part of the integration tests (existing
functionality). In fact, I would consider selenium tests to be functional
tests (higher than integration) ->
https://en.wikipedia.org/wiki/Functional_testing

So yeah we can add them, but I don't think we can do that to the raw
unit-tests (at least in the context discussed in the other proposal thread)

Taher Alkhateeb

On Thu, Jun 16, 2016 at 10:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

With the considerable HW effort, a lot of things are going on recently,
and it's hard to follow. I though noticed that we experience more and more
regressions (not all related to HW effort, far from it).

Fortunately it's so far mostly minor points and often related with the UI,
OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be
critical)

 From my experience, w/o a QA person or team, it's very hard to detect
those side effects at the UI level when you refactor or fix it. I remember
the (ex) Neogia team (mostly Erwan) tried to maintain a Selenium/Webdriver
set of tests. I don't know if they continue/d.

Since we spoke about Junit and unit tests recently, some prefer TestNG, at
least coupled with Selenium http://testng.org/doc/selenium.html

Does it make sense, do you think it's only an utopia?

Thanks

Jacques





--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102

[jira] [Commented] (OFBIZ-7350) Manage filters in lookup auto completion


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

Jacques Le Roux commented on OFBIZ-7350:


Thanks Charles, could you please give an example of use in a real context? 
Thanks.

> Manage filters in lookup auto completion
> 
>
> Key: OFBIZ-7350
> URL: https://issues.apache.org/jira/browse/OFBIZ-7350
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Release 
> Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Charles STELTZLEN
>Assignee: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-7350.13.07.patch, OFBIZ-7350.patch
>
>
> On form lookup, we can specify target parameters to pass them to the lookup 
> screen and do filtered searches with these parameters. It works fine when you 
> click on lookup button. But when you start to write something in lookup 
> input, these parameters are not passed to the ajax auto-complete system. So, 
> the results are not filtered.



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

Re: We miss a QA team, we face too much regressions

Yes, I agree Selenium does not fit with unit tests and is the higher level of tests as UI is the higher level of code. From my experience running
tests from this level helps also to detect bugs at a lower levels, notably regressions.

I spoke about unit tests only because I wanted to say that some prefer to use TestNG with Selenium, this to see if nobody had an opinion or/and use
Selenium for their own projects. About TestNG, I actually believe you can do the same with JUnit 4.

I must say I never used Selenium with either JUnit or TestNG. Only as a simple user creating tests for myself. That was long ago and it then saved me
a lot of time...

Jacques

Le 16/06/2016 à 21:48, Taher Alkhateeb a écrit :

Hi Jacques,

Selenium tests cannot be unit tests in OFBiz because it requires firing up
the server. You can consider them part of the integration tests (existing
functionality). In fact, I would consider selenium tests to be functional
tests (higher than integration) ->
https://en.wikipedia.org/wiki/Functional_testing

So yeah we can add them, but I don't think we can do that to the raw
unit-tests (at least in the context discussed in the other proposal thread)

Taher Alkhateeb

On Thu, Jun 16, 2016 at 10:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

Hi,

With the considerable HW effort, a lot of things are going on recently,
and it's hard to follow. I though noticed that we experience more and more
regressions (not all related to HW effort, far from it).

Fortunately it's so far mostly minor points and often related with the UI,
OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be
critical)

From my experience, w/o a QA person or team, it's very hard to detect
those side effects at the UI level when you refactor or fix it. I remember
the (ex) Neogia team (mostly Erwan) tried to maintain a Selenium/Webdriver
set of tests. I don't know if they continue/d.

Since we spoke about Junit and unit tests recently, some prefer TestNG, at
least coupled with Selenium http://testng.org/doc/selenium.html

Does it make sense, do you think it's only an utopia?

Thanks

Jacques

[jira] [Updated] (OFBIZ-6947) Inventory report throws an error


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

Jacques Le Roux updated OFBIZ-6947:
---
Fix Version/s: (was: Upcoming Branch)
   15.12.01

> Inventory report throws an error
> 
>
> Key: OFBIZ-6947
> URL: https://issues.apache.org/jira/browse/OFBIZ-6947
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: facility, inventory, pdf
> Fix For: 15.12.01
>
> Attachments: OFBIZ-6947_trunk.patch, OFBIZ-6947_trunk_2.patch
>
>
> When executing the print pdf function in 
> https://demo-trunk-ofbiz.apache.org/facility/control/ViewFacilityInventoryByProduct
> the following error is thrown:
> {code}
> The Following Errors Occurred:
> Unable to transform FO file: org.apache.fop.apps.FOPException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115) javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115)
> {code}



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

Re: We miss a QA team, we face too much regressions

Hi Jacques,

Selenium tests cannot be unit tests in OFBiz because it requires firing up
the server. You can consider them part of the integration tests (existing
functionality). In fact, I would consider selenium tests to be functional
tests (higher than integration) ->
https://en.wikipedia.org/wiki/Functional_testing

So yeah we can add them, but I don't think we can do that to the raw
unit-tests (at least in the context discussed in the other proposal thread)

Taher Alkhateeb

On Thu, Jun 16, 2016 at 10:40 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> With the considerable HW effort, a lot of things are going on recently,
> and it's hard to follow. I though noticed that we experience more and more
> regressions (not all related to HW effort, far from it).
>
> Fortunately it's so far mostly minor points and often related with the UI,
> OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be
> critical)
>
> From my experience, w/o a QA person or team, it's very hard to detect
> those side effects at the UI level when you refactor or fix it. I remember
> the (ex) Neogia team (mostly Erwan) tried to maintain a Selenium/Webdriver
> set of tests. I don't know if they continue/d.
>
> Since we spoke about Junit and unit tests recently, some prefer TestNG, at
> least coupled with Selenium http://testng.org/doc/selenium.html
>
> Does it make sense, do you think it's only an utopia?
>
> Thanks
>
> Jacques
>
>

[jira] [Commented] (OFBIZ-6947) Inventory report throws an error


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

Jacques Le Roux commented on OFBIZ-6947:


After Pierre's comment I noticed that R15.12 was also concerned, fixed at 
r1748772

> Inventory report throws an error
> 
>
> Key: OFBIZ-6947
> URL: https://issues.apache.org/jira/browse/OFBIZ-6947
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: facility, inventory, pdf
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6947_trunk.patch, OFBIZ-6947_trunk_2.patch
>
>
> When executing the print pdf function in 
> https://demo-trunk-ofbiz.apache.org/facility/control/ViewFacilityInventoryByProduct
> the following error is thrown:
> {code}
> The Following Errors Occurred:
> Unable to transform FO file: org.apache.fop.apps.FOPException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115) javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115)
> {code}



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

[jira] [Comment Edited] (OFBIZ-6947) Inventory report throws an error


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

Jacques Le Roux edited comment on OFBIZ-6947 at 6/16/16 7:47 PM:
-

You are right Pierre, OFBIZ-7171 simply disclosed the issue. OFBIZ-6504 
actually broke it. I'll change that.


was (Author: jacques.le.roux):
You are right Pierre, OFBIZ-7171 simply disclosed the issue. OFBIZ-6504 
actually broke it. I'll change that and then wipe the comment (including yours 
;))

> Inventory report throws an error
> 
>
> Key: OFBIZ-6947
> URL: https://issues.apache.org/jira/browse/OFBIZ-6947
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: facility, inventory, pdf
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6947_trunk.patch, OFBIZ-6947_trunk_2.patch
>
>
> When executing the print pdf function in 
> https://demo-trunk-ofbiz.apache.org/facility/control/ViewFacilityInventoryByProduct
> the following error is thrown:
> {code}
> The Following Errors Occurred:
> Unable to transform FO file: org.apache.fop.apps.FOPException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115) javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115)
> {code}



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

We miss a QA team, we face too much regressions


Hi,

With the considerable HW effort, a lot of things are going on recently, and it's hard to follow. I though noticed that we experience more and more 
regressions (not all related to HW effort, far from it).


Fortunately it's so far mostly minor points and often related with the UI, 
OFBIZ-7346 and OFBIZ-7363 being counter examples (OFBIZ-7346 can be critical)

From my experience, w/o a QA person or team, it's very hard to detect those side effects at the UI level when you refactor or fix it. I remember the 
(ex) Neogia team (mostly Erwan) tried to maintain a Selenium/Webdriver set of tests. I don't know if they continue/d.


Since we spoke about Junit and unit tests recently, some prefer TestNG, at 
least coupled with Selenium http://testng.org/doc/selenium.html

Does it make sense, do you think it's only an utopia?

Thanks

Jacques

[jira] [Comment Edited] (OFBIZ-6947) Inventory report throws an error


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

Jacques Le Roux edited comment on OFBIZ-6947 at 6/16/16 7:15 PM:
-

You are right Pierre, OFBIZ-7171 simply disclosed the issue. OFBIZ-6504 
actually broke it. I'll change that and then wipe the comment (including yours 
;))


was (Author: jacques.le.roux):
You are right Pierre, it's actually OFBIZ-6504, I'll change that and then wipe 
the comment (including yours ;))

> Inventory report throws an error
> 
>
> Key: OFBIZ-6947
> URL: https://issues.apache.org/jira/browse/OFBIZ-6947
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: facility, inventory, pdf
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6947_trunk.patch, OFBIZ-6947_trunk_2.patch
>
>
> When executing the print pdf function in 
> https://demo-trunk-ofbiz.apache.org/facility/control/ViewFacilityInventoryByProduct
> the following error is thrown:
> {code}
> The Following Errors Occurred:
> Unable to transform FO file: org.apache.fop.apps.FOPException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115) javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115)
> {code}



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

[jira] [Commented] (OFBIZ-6947) Inventory report throws an error


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

Jacques Le Roux commented on OFBIZ-6947:


You are right Pierre, it's actually OFBIZ-6504, I'll change that and then wipe 
the comment (including yours ;))

> Inventory report throws an error
> 
>
> Key: OFBIZ-6947
> URL: https://issues.apache.org/jira/browse/OFBIZ-6947
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Pierre Smits
>Assignee: Jacques Le Roux
>  Labels: facility, inventory, pdf
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6947_trunk.patch, OFBIZ-6947_trunk_2.patch
>
>
> When executing the print pdf function in 
> https://demo-trunk-ofbiz.apache.org/facility/control/ViewFacilityInventoryByProduct
> the following error is thrown:
> {code}
> The Following Errors Occurred:
> Unable to transform FO file: org.apache.fop.apps.FOPException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115) javax.xml.transform.TransformerException: 
> org.apache.fop.fo.ValidationException: null:80:115: "fo:table-cell" is 
> missing child elements. Required content model: marker* (%block;)+ (See 
> position 80:115)
> {code}



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

Re: Proposal to delete stale java files

+1 thank you for your dedication and thinking of this
On Jun 16, 2016 8:55 PM, "Mridul Pathak" 
wrote:

> Hi Taher,
>
> I was just trying to suggest that we will have to create two components in
> specialpurpose, one for payment processor related functionality and one for
> tax related functionality and the reason behind it. Which means we should
> probably drop the idea of introducing a directory named “reference” and
> instead create two separate components.
>
> Our main goal here is to move these files out of core applications and
> most of us are fine with moving it to specialpurpose. I think we can
> conclude our approach as most of us seems fine with having two separate
> components in specialpurpose which was the original suggestion as well.
>
> --
> Thanks & Regards,
> Mridul Pathak
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb 
> wrote:
> >
> > Hi Mridul,
> >
> > Thank you for the detailed and well thought out feedback.
> >
> > I am a little confused however, what is the point you are trying to
> state?
> > The only point from my previous email was to suggest avoiding creating a
> > directory called reference in the top level ofbiz directory and instead
> > keep it in /specialpurpose. If you want to keep it in
> > specialpurpose/reference, fine, if you want to keep it in
> > specialpurpose/your-component-here fine, if you want to do anything in
> > specialpurpose then also fine My point was simply to suggest steering
> away
> > from ofbiz top level directory.
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> > mridul.pat...@hotwaxsystems.com> wrote:
> >
> >> Hi Taher,
> >>
> >> Payment integration files in accounting/thirdparty are not just unused
> >> files and all of it is not dead code. There is the whole functionality
> >> built around those files which is very crucial to production delivery of
> >> order management or ecommerce on top of OFBiz. There are many service
> >> definition files whose implementation is written in these java files.
> Some
> >> examples are,
> >>
> >> accounting/servicedef/services_authorizedotnet.xml
> >> accounting/servicedef/services_clearcommerce.xml
> >> accounting/servicedef/services_cybersource.xml
> >> accounting/servicedef/services_orbital.xml
> >> accounting/servicedef/services_paypal.xml
> >> etc.
> >>
> >> Along with that, many of the configurations needed to use these payment
> >> solutions are maintained in accounting/config/payment.properties file. A
> >> ProductStore in OFBiz as well can be configures to use on of these
> payment
> >> processors.
> >>
> >> Also, these file are intentionally excluded from compile process, but
> can
> >> be included if you want to use/deliver one of these existing payment
> >> solution in OFBiz in production. Following is the code snippet from
> >> accounting/build.xml,
> >>
> >> 
> >> >> value="org/ofbiz/accounting/thirdparty/verisign/**">
> >>
> >>
> >>
> >>
> >>
> >>
> >> >> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> >>
> >>
> >>
> >>
> >> 
> >>
> >> It clearly mentions that if you have required libraries for any of the
> >> third party payment solutions, you could comment out the exclusion.
> >> Usually, when someone needs to use one of the available payment
> processor,
> >> they download the required jar and place it in accounting/lib folder,
> make
> >> the needed changes in build.xml and they are ready to use the respective
> >> payment solution.
> >>
> >> We have used one or the other payment processors in OFBiz many a times
> to
> >> deliver payment solutions as part of the software. I believe there are
> many
> >> application users and service providers who might be using the payment
> >> processor functionality that comes with OFBiz OOTB.
> >>
> >> So, it’s not just about moving some files from core applications to some
> >> other directory because they seems to be unused, the whole functionality
> >> needs to be moved so that current or future users of these
> functionalities
> >> can still use it. And that is the reason if we create a new special
> purpose
> >> component it will help us to keep the functionality intact and usable at
> >> the same time separate it from core applications. That would also
> enable us
> >> to keep such components out of component-load.xml and
> >> specialpurpose/build.xml. A README file would help the user with
> directions
> >> to use it.
> >>
> >> Additionally, I feel that most of these files may need to be upgraded
> and
> >> needs code refactoring probably because they might usually be left out
> as
> >> they do not compile by default with OFBiz.
> >>
> >> --
> >> Thanks & Regards,
> >> Mridul Pathak
> >> HotWax Systems
> >> http://www.hotwaxsystems.com
> >>
> >>> On Jun 16, 2016, at 6:44 PM, Taher

Re: Proposal to delete stale java files

Hi Taher,

I was just trying to suggest that we will have to create two components in 
specialpurpose, one for payment processor related functionality and one for tax 
related functionality and the reason behind it. Which means we should probably 
drop the idea of introducing a directory named “reference” and instead create 
two separate components.

Our main goal here is to move these files out of core applications and most of 
us are fine with moving it to specialpurpose. I think we can conclude our 
approach as most of us seems fine with having two separate components in 
specialpurpose which was the original suggestion as well.

--
Thanks & Regards,
Mridul Pathak
HotWax Systems
http://www.hotwaxsystems.com

> On Jun 16, 2016, at 8:23 PM, Taher Alkhateeb  
> wrote:
> 
> Hi Mridul,
> 
> Thank you for the detailed and well thought out feedback.
> 
> I am a little confused however, what is the point you are trying to state?
> The only point from my previous email was to suggest avoiding creating a
> directory called reference in the top level ofbiz directory and instead
> keep it in /specialpurpose. If you want to keep it in
> specialpurpose/reference, fine, if you want to keep it in
> specialpurpose/your-component-here fine, if you want to do anything in
> specialpurpose then also fine My point was simply to suggest steering away
> from ofbiz top level directory.
> 
> Regards,
> 
> Taher Alkhateeb
> 
> On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
> mridul.pat...@hotwaxsystems.com> wrote:
> 
>> Hi Taher,
>> 
>> Payment integration files in accounting/thirdparty are not just unused
>> files and all of it is not dead code. There is the whole functionality
>> built around those files which is very crucial to production delivery of
>> order management or ecommerce on top of OFBiz. There are many service
>> definition files whose implementation is written in these java files. Some
>> examples are,
>> 
>> accounting/servicedef/services_authorizedotnet.xml
>> accounting/servicedef/services_clearcommerce.xml
>> accounting/servicedef/services_cybersource.xml
>> accounting/servicedef/services_orbital.xml
>> accounting/servicedef/services_paypal.xml
>> etc.
>> 
>> Along with that, many of the configurations needed to use these payment
>> solutions are maintained in accounting/config/payment.properties file. A
>> ProductStore in OFBiz as well can be configures to use on of these payment
>> processors.
>> 
>> Also, these file are intentionally excluded from compile process, but can
>> be included if you want to use/deliver one of these existing payment
>> solution in OFBiz in production. Following is the code snippet from
>> accounting/build.xml,
>> 
>> 
>>> value="org/ofbiz/accounting/thirdparty/verisign/**">
>>
>>
>>
>>
>>
>>
>>> name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
>>
>>
>>
>>
>> 
>> 
>> It clearly mentions that if you have required libraries for any of the
>> third party payment solutions, you could comment out the exclusion.
>> Usually, when someone needs to use one of the available payment processor,
>> they download the required jar and place it in accounting/lib folder, make
>> the needed changes in build.xml and they are ready to use the respective
>> payment solution.
>> 
>> We have used one or the other payment processors in OFBiz many a times to
>> deliver payment solutions as part of the software. I believe there are many
>> application users and service providers who might be using the payment
>> processor functionality that comes with OFBiz OOTB.
>> 
>> So, it’s not just about moving some files from core applications to some
>> other directory because they seems to be unused, the whole functionality
>> needs to be moved so that current or future users of these functionalities
>> can still use it. And that is the reason if we create a new special purpose
>> component it will help us to keep the functionality intact and usable at
>> the same time separate it from core applications. That would also enable us
>> to keep such components out of component-load.xml and
>> specialpurpose/build.xml. A README file would help the user with directions
>> to use it.
>> 
>> Additionally, I feel that most of these files may need to be upgraded and
>> needs code refactoring probably because they might usually be left out as
>> they do not compile by default with OFBiz.
>> 
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> HotWax Systems
>> http://www.hotwaxsystems.com
>> 
>>> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb 
>> wrote:
>>> 
>>> Hey Folks,
>>> 
>>> I would prefer to keep dead code away from the top level OFBiz directory.
>>> If you keep it there then you make it _closer_ to the framework!
>>> 
>>> Anyway, I don't see a problem with keeping it in specialpurpose! You are
>>> not creating a component, you are just creating a folder called

[jira] [Issue Comment Deleted] (OFBIZ-7346) connection pooling not working


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

Jacques Le Roux updated OFBIZ-7346:
---
Comment: was deleted

(was: Thanks Gareth,

I can confirm I see this behaviour (connection pooling not working, ie 
connections not being reused and dissapearing) while using the 
bq. Select * from pg_stat_activity  where usename='ofbiz'
request in Postgres.

With the patch applied I was able to generate 10 used pooled connections using 
OWAS Zap running against ecommerce and catalog, and simultaneously JMeter on 
catalog. After shutting them, the connections stay visible and IDLE, so ready 
to be reused. So the patch clearly fixes this issue which is at least 
reproductible in Postgres (version 9.1 with last driver loaded with Ant+Ivy) 
and easily visible in pdAdmin III (I use 1.18.1)

So far I see no reasons to not commit, but as Gareth is cautious I'll be so and 
check that no issues could creep in.

Ah, I also noticed that contrary what I saw before applying the patch, when I 
run the
bq. Select * from pg_stat_activity  where usename='ofbiz'
query, before running any request against OFBiz, I see 2 connections ready to 
use. Before applying the patch (and after OFBIZ-7344 beind fixed) nothing 
appears and this does not respect the *pool-minsize="2"* parameter of the 
* connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



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

[jira] [Updated] (OFBIZ-7346) connection pooling not working


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

Jacques Le Roux updated OFBIZ-7346:
---
Priority: Critical  (was: Minor)

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Critical
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



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

[jira] [Commented] (OFBIZ-7346) connection pooling not working


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

Jacques Le Roux commented on OFBIZ-7346:


I confirm pooling and report work correctly in R13.07 locally with Derby or 
Postgres .

Also, measured with the fixed Connection Pool Status feature this bug does not 
affect Derby (tested locally on trunk HEAD, with JMeter pushing 100 concurrent 
requests). Maybe the reason it went unnoticed so far.

On the other hand , adding the 2 parameters\[1\] Gareth suggested
{code}
factory.setRollbackOnReturn(false);
factory.setEnableAutoCommitOnReturn(false);
{code}
 does not hurt in a Derby context and fixes the pool-minsize issue in both 
cases (Derby and Postgres). So I believe we should commit the patch because it 
at least fixes the pool-minsize issue and does not hurt in these in both cases.

I'd just ask a question to you [~gareth.carter]: why and how did you pick those 
parameters and only those?

\[1\] 
https://commons.apache.org/proper/commons-dbcp/api-2.1.1/org/apache/commons/dbcp2/BasicDataSource.html
* setRollbackOnReturn "Sets the flag that controls if a connection will be 
rolled back when it is returned to the pool if auto commit is not enabled and 
the connection is not read only."
*  setEnableAutoCommitOnReturn "Sets the value of the flag that controls 
whether or not connections being returned to the pool will be checked and 
configured with Connection.setAutoCommit(true) if the auto commit setting is 
false when the connection is returned. It is true by default."

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



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

[jira] [Commented] (OFBIZ-7258) Duplicate product feature groups associated with a category when duplicating category and selected option to duplicate feature

2016-06-16 Thread Rishi Solanki (JIRA)


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

Rishi Solanki commented on OFBIZ-7258:
--

I would say, when user says to copy features then it should only copy features. 
Adding an additional parameter to UI and based on that take decision. Your 
patch says if two categories shares ProductFeatureCategoryAppl then they will 
also have common ProductFeatureCatGrpAppl, I'm not sure if it is true always.

> Duplicate product feature groups associated with a category when duplicating 
> category and selected option to duplicate feature
> --
>
> Key: OFBIZ-7258
> URL: https://issues.apache.org/jira/browse/OFBIZ-7258
> Project: OFBiz
>  Issue Type: Improvement
>  Components: product
>Affects Versions: Trunk
>Reporter: Ravi Lodhi
>Assignee: Ashish Vijaywargiya
> Attachments: OFBIZ-7258_trunk.patch
>
>
> Problem Area:
> 1) Go to Catalog -> Categories
> 2) Find a category for which feature groups and feature categories are added.
> 3) Duplicate that category and check the option to duplicate feature.
> 4) Right now only features from product feature categories get duplicated not 
> the feature associated with feature group.
> We should duplicate features from feature group as well when duplicating 
> category.



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

[jira] [Commented] (OFBIZ-7339) Replace EntityUtilProperties getPropertyValue method with correct method calls

2016-06-16 Thread Rishi Solanki (JIRA)


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

Rishi Solanki commented on OFBIZ-7339:
--

Thanks for heads up Jacques, reviewed the work committed and nothing to worry 
about it as we are using different methods and no signature changed in Wai's 
work. Also after taking update from trunk, I've tested the work given here by 
[~rahul.kushwah] is working fine.

So these changes have no impact from OFBIZ-7122. And it covers how to use OFBIZ 
api, so we are good. Thanks!

> Replace EntityUtilProperties getPropertyValue method with correct method calls
> --
>
> Key: OFBIZ-7339
> URL: https://issues.apache.org/jira/browse/OFBIZ-7339
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, framework, manufacturing, party, product, 
> securityext, specialpurpose/ecommerce, specialpurpose/lucene, 
> specialpurpose/passport, workeffort
>Affects Versions: Trunk
>Reporter: Rishi Solanki
>Assignee: Arun Patidar
> Attachments: EntityUtilProperties.patch
>
>
> In current OFBiz system at many places many methods implemented but not used 
> as per their purpose. One example is in EntityUtilProperties we have 
> getPropertyAsInteger() and getPropertyAsBigDecimal() and other methods which 
> returns specific type data. But at most places system uses getPropertyValue() 
> which returns string and then do explicit conversions.
> System should use proper methods for which they have been implemented.



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

[jira] [Comment Edited] (OFBIZ-7339) Replace EntityUtilProperties getPropertyValue method with correct method calls

2016-06-16 Thread Rishi Solanki (JIRA)


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

Rishi Solanki edited comment on OFBIZ-7339 at 6/16/16 3:58 PM:
---

Thanks for heads up Jacques, reviewed the work committed and nothing to worry 
about it as we are using different methods and no signature changed in Wai's 
work. Also after taking update from trunk, I've tested the work given here by 
[~rahul.kushwah] is working fine.

So these changes have no impact from OFBIZ-7112. And it covers how to use OFBIZ 
api, so we are good. Thanks!


was (Author: rishisolankii):
Thanks for heads up Jacques, reviewed the work committed and nothing to worry 
about it as we are using different methods and no signature changed in Wai's 
work. Also after taking update from trunk, I've tested the work given here by 
[~rahul.kushwah] is working fine.

So these changes have no impact from OFBIZ-7122. And it covers how to use OFBIZ 
api, so we are good. Thanks!

> Replace EntityUtilProperties getPropertyValue method with correct method calls
> --
>
> Key: OFBIZ-7339
> URL: https://issues.apache.org/jira/browse/OFBIZ-7339
> Project: OFBiz
>  Issue Type: Bug
>  Components: content, framework, manufacturing, party, product, 
> securityext, specialpurpose/ecommerce, specialpurpose/lucene, 
> specialpurpose/passport, workeffort
>Affects Versions: Trunk
>Reporter: Rishi Solanki
>Assignee: Arun Patidar
> Attachments: EntityUtilProperties.patch
>
>
> In current OFBiz system at many places many methods implemented but not used 
> as per their purpose. One example is in EntityUtilProperties we have 
> getPropertyAsInteger() and getPropertyAsBigDecimal() and other methods which 
> returns specific type data. But at most places system uses getPropertyValue() 
> which returns string and then do explicit conversions.
> System should use proper methods for which they have been implemented.



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

[jira] [Updated] (OFBIZ-7372) Googlebase : Arrange UI Labels in alphabetic order according to best practice.


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

Shivangi Tanwar updated OFBIZ-7372:
---
Assignee: (was: Shivangi Tanwar)

> Googlebase : Arrange UI Labels in alphabetic order according to best practice.
> --
>
> Key: OFBIZ-7372
> URL: https://issues.apache.org/jira/browse/OFBIZ-7372
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/googlebase
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7372_trunk.patch
>
>




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

[jira] [Updated] (OFBIZ-7372) Googlebase : Arrange UI Labels in alphabetic order according to best practice.


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

Shivangi Tanwar updated OFBIZ-7372:
---
Attachment: OFBIZ-7372_trunk.patch

Here is the patch with proper fix and aligned UiLabels alphabetically according 
to best practices.

> Googlebase : Arrange UI Labels in alphabetic order according to best practice.
> --
>
> Key: OFBIZ-7372
> URL: https://issues.apache.org/jira/browse/OFBIZ-7372
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/googlebase
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Assignee: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7372_trunk.patch
>
>




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

[jira] [Created] (OFBIZ-7372) Googlebase : Arrange UI Labels in alphabetic order according to best practice.

Shivangi Tanwar created OFBIZ-7372:
--

 Summary: Googlebase : Arrange UI Labels in alphabetic order 
according to best practice.
 Key: OFBIZ-7372
 URL: https://issues.apache.org/jira/browse/OFBIZ-7372
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/googlebase
Affects Versions: Trunk
Reporter: Shivangi Tanwar
Assignee: Shivangi Tanwar
Priority: Minor
 Fix For: Trunk






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

[jira] [Updated] (OFBIZ-7371) ProjectMgr : Arrange UI Labels in alphabetic order according to best practice.


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

Shivangi Tanwar updated OFBIZ-7371:
---
Assignee: (was: Shivangi Tanwar)

> ProjectMgr :  Arrange UI Labels in alphabetic order according to best 
> practice.
> ---
>
> Key: OFBIZ-7371
> URL: https://issues.apache.org/jira/browse/OFBIZ-7371
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7371_trunk.patch
>
>




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

[jira] [Updated] (OFBIZ-7371) ProjectMgr : Arrange UI Labels in alphabetic order according to best practice.


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

Shivangi Tanwar updated OFBIZ-7371:
---
Attachment: OFBIZ-7371_trunk.patch

"Here is the patch with proper fix and aligned UiLabels alphabetically 
according to best practices.

> ProjectMgr :  Arrange UI Labels in alphabetic order according to best 
> practice.
> ---
>
> Key: OFBIZ-7371
> URL: https://issues.apache.org/jira/browse/OFBIZ-7371
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/projectmgr
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Assignee: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7371_trunk.patch
>
>




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

[jira] [Created] (OFBIZ-7371) ProjectMgr : Arrange UI Labels in alphabetic order according to best practice.

Shivangi Tanwar created OFBIZ-7371:
--

 Summary: ProjectMgr :  Arrange UI Labels in alphabetic order 
according to best practice.
 Key: OFBIZ-7371
 URL: https://issues.apache.org/jira/browse/OFBIZ-7371
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/projectmgr
Affects Versions: Trunk
Reporter: Shivangi Tanwar
Assignee: Shivangi Tanwar
Priority: Minor
 Fix For: Trunk






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

[jira] [Assigned] (OFBIZ-7367) 'From Date' and 'Through Date' is not setting on add of task member


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

Pranay Pandey reassigned OFBIZ-7367:


Assignee: Pranay Pandey  (was: Aditi Patidar)

> 'From Date' and 'Through Date' is not setting on add of task member
> ---
>
> Key: OFBIZ-7367
> URL: https://issues.apache.org/jira/browse/OFBIZ-7367
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/scrum
>Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Aditi Patidar
>Assignee: Pranay Pandey
> Attachments: OFBIZ-7367.patch
>
>
> Steps to regenerate the issue:
> 1. Navigate to 'SCRUM' -> 'Tasks'.
> 2. Press 'New Task' button.
> 3. Create the task.
> 4. Browse the task created.
> 5. Press 'Member' tab.
> 6. Add task member, select 'Project Member', add 'From Date' and 'Thru Date'.
> Expected result:
> Added From and Thru date should display.
> Actual result:
> 'From Date' is showing now timestamp and 'Thru Date' is empty.



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

[jira] [Commented] (OFBIZ-7155) Remove jce-jdk13-154.jar

2016-06-16 Thread Christian Geisert (JIRA)


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

Christian Geisert commented on OFBIZ-7155:
--

Seems like it is needed somehow. After removing and executing run-tests I got 
the following:

{code}
java.lang.NoClassDefFoundError: 
org/bouncycastle/jce/provider/BouncyCastleProvider
at 
org.apache.pdfbox.pdmodel.PDDocument.openProtection(PDDocument.java:1616)
at org.apache.pdfbox.pdmodel.PDDocument.decrypt(PDDocument.java:963)
at org.apache.tika.parser.pdf.PDFParser.parse(PDFParser.java:139)
at 
org.ofbiz.widget.test.WidgetMacroLibraryTests.testFopMacroLibrary(WidgetMacroLibraryTests.java:129)
at org.ofbiz.testtools.TestRunContainer.start(TestRunContainer.java:146)
at 
org.ofbiz.base.container.ContainerLoader.start(ContainerLoader.java:237)
at 
org.ofbiz.base.start.StartupControlPanel.startStartupLoaders(StartupControlPanel.java:274)
at 
org.ofbiz.base.start.StartupControlPanel.start(StartupControlPanel.java:73)
at org.ofbiz.base.start.Start.main(Start.java:84)
Caused by: java.lang.ClassNotFoundException: 
org.bouncycastle.jce.provider.BouncyCastleProvider
at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)

{code}

I'll investigate further.

> Remove jce-jdk13-154.jar
> 
>
> Key: OFBIZ-7155
> URL: https://issues.apache.org/jira/browse/OFBIZ-7155
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Christian Geisert
>Assignee: Christian Geisert
> Fix For: Upcoming Branch, 15.12.01
>
>
> After updating our project to the latest release15.12 branch we got the 
> following error when accessing OFBiz pages:
> {code}
> 2016-06-01 14:37:14,040 |http-nio-8443-exec-2 |NioEndpoint   
> |E|
> java.lang.RuntimeException: Could not generate DH keypair
> at sun.security.ssl.Handshaker.checkThrown(Handshaker.java:1429) 
> ~[?:1.8.0_77]
> ...
> Caused by: java.security.InvalidAlgorithmParameterException: parameter object 
> not a ECParameterSpec
> at 
> org.bouncycastle.jcajce.provider.asymmetric.ec.KeyPairGeneratorSpi$EC.initialize(Unknown
>  Source) ~[jce-jdk13-154.jar:1.54.0]
> ...
> {code}
> It turned out that jce-jdk13-154.jar was the culprit. After removing this Jar 
> everything worked as expected. As this jar is an optional dependency of 
> PDFBox (which is used by Tika) and is only need for Java < 1.7 I propose to 
> remove it from OFBiz.
> I'll wait a few days and if there are no objections I'll remove the jar



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

Re: Proposal to delete stale java files

Hi Mridul,

Thank you for the detailed and well thought out feedback.

I am a little confused however, what is the point you are trying to state?
The only point from my previous email was to suggest avoiding creating a
directory called reference in the top level ofbiz directory and instead
keep it in /specialpurpose. If you want to keep it in
specialpurpose/reference, fine, if you want to keep it in
specialpurpose/your-component-here fine, if you want to do anything in
specialpurpose then also fine My point was simply to suggest steering away
from ofbiz top level directory.

Regards,

Taher Alkhateeb

On Thu, Jun 16, 2016 at 5:34 PM, Mridul Pathak <
mridul.pat...@hotwaxsystems.com> wrote:

> Hi Taher,
>
> Payment integration files in accounting/thirdparty are not just unused
> files and all of it is not dead code. There is the whole functionality
> built around those files which is very crucial to production delivery of
> order management or ecommerce on top of OFBiz. There are many service
> definition files whose implementation is written in these java files. Some
> examples are,
>
> accounting/servicedef/services_authorizedotnet.xml
> accounting/servicedef/services_clearcommerce.xml
> accounting/servicedef/services_cybersource.xml
> accounting/servicedef/services_orbital.xml
> accounting/servicedef/services_paypal.xml
> etc.
>
> Along with that, many of the configurations needed to use these payment
> solutions are maintained in accounting/config/payment.properties file. A
> ProductStore in OFBiz as well can be configures to use on of these payment
> processors.
>
> Also, these file are intentionally excluded from compile process, but can
> be included if you want to use/deliver one of these existing payment
> solution in OFBiz in production. Following is the code snippet from
> accounting/build.xml,
>
> 
>  value="org/ofbiz/accounting/thirdparty/verisign/**">
> 
> 
> 
> 
> 
> 
>  name="org/ofbiz/accounting/thirdparty/paypal/PayPalServices.java"/>
> 
> 
> 
> 
> 
>
> It clearly mentions that if you have required libraries for any of the
> third party payment solutions, you could comment out the exclusion.
> Usually, when someone needs to use one of the available payment processor,
> they download the required jar and place it in accounting/lib folder, make
> the needed changes in build.xml and they are ready to use the respective
> payment solution.
>
> We have used one or the other payment processors in OFBiz many a times to
> deliver payment solutions as part of the software. I believe there are many
> application users and service providers who might be using the payment
> processor functionality that comes with OFBiz OOTB.
>
> So, it’s not just about moving some files from core applications to some
> other directory because they seems to be unused, the whole functionality
> needs to be moved so that current or future users of these functionalities
> can still use it. And that is the reason if we create a new special purpose
> component it will help us to keep the functionality intact and usable at
> the same time separate it from core applications. That would also enable us
> to keep such components out of component-load.xml and
> specialpurpose/build.xml. A README file would help the user with directions
> to use it.
>
> Additionally, I feel that most of these files may need to be upgraded and
> needs code refactoring probably because they might usually be left out as
> they do not compile by default with OFBiz.
>
> --
> Thanks & Regards,
> Mridul Pathak
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb 
> wrote:
> >
> > Hey Folks,
> >
> > I would prefer to keep dead code away from the top level OFBiz directory.
> > If you keep it there then you make it _closer_ to the framework!
> >
> > Anyway, I don't see a problem with keeping it in specialpurpose! You are
> > not creating a component, you are just creating a folder called reference
> > and adding stuff to it, and you are not adding it to component-load.xml?
> > Why is it that you cannot add it there?
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> > mridul.pat...@hotwaxsystems.com> wrote:
> >
> >> Introducing new directory “reference” seems reasonable approach to me as
> >> it is a combined solution to everyone’s views.
> >>
> >> --
> >> Thanks & Regards,
> >> Mridul Pathak
> >> Senior Manager
> >> HotWax Systems
> >> http://www.hotwaxsystems.com
> >>
> >>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>>
> >>> Hi Divesh,
> >>>
> >>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> > 3- In the case of non-compiling / broken / missing dependencies code
>  highlight this issue somewhere visible to the programmer (README,
>  whatever). Why is this important? Because we need to

[jira] [Updated] (OFBIZ-7353) Party : Arrange UI Labels in alphabetic order according to best practice.


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

Shivangi Tanwar updated OFBIZ-7353:
---
Assignee: (was: Shivangi Tanwar)

> Party : Arrange UI Labels in alphabetic order according to best practice.
> -
>
> Key: OFBIZ-7353
> URL: https://issues.apache.org/jira/browse/OFBIZ-7353
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7353_trunk.patch
>
>




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

[jira] [Updated] (OFBIZ-7353) Party : Arrange UI Labels in alphabetic order according to best practice.


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

Shivangi Tanwar updated OFBIZ-7353:
---
Attachment: OFBIZ-7353_trunk.patch

Here is the patch with proper fix and aligned UiLabels alphabetically according 
to best practices.

> Party : Arrange UI Labels in alphabetic order according to best practice.
> -
>
> Key: OFBIZ-7353
> URL: https://issues.apache.org/jira/browse/OFBIZ-7353
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: party
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7353_trunk.patch
>
>




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

[jira] [Updated] (OFBIZ-7370) Scrum : Arrange UI Labels in alphabetic order according to best practice


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

Shivangi Tanwar updated OFBIZ-7370:
---
Assignee: (was: Shivangi Tanwar)

> Scrum : Arrange UI Labels in alphabetic order according to best practice
> 
>
> Key: OFBIZ-7370
> URL: https://issues.apache.org/jira/browse/OFBIZ-7370
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7370_trunk.patch
>
>




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

[jira] [Updated] (OFBIZ-7370) Scrum : Arrange UI Labels in alphabetic order according to best practice


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

Shivangi Tanwar updated OFBIZ-7370:
---
Attachment: OFBIZ-7370_trunk.patch

Here is the patch with proper fix and aligned UiLabels alphabetically according 
to best practices.

> Scrum : Arrange UI Labels in alphabetic order according to best practice
> 
>
> Key: OFBIZ-7370
> URL: https://issues.apache.org/jira/browse/OFBIZ-7370
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: specialpurpose/scrum
>Affects Versions: Trunk
>Reporter: Shivangi Tanwar
>Assignee: Shivangi Tanwar
>Priority: Minor
> Fix For: Trunk
>
> Attachments: OFBIZ-7370_trunk.patch
>
>




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

[jira] [Created] (OFBIZ-7370) Scrum : Arrange UI Labels in alphabetic order according to best practice

Shivangi Tanwar created OFBIZ-7370:
--

 Summary: Scrum : Arrange UI Labels in alphabetic order according 
to best practice
 Key: OFBIZ-7370
 URL: https://issues.apache.org/jira/browse/OFBIZ-7370
 Project: OFBiz
  Issue Type: Sub-task
  Components: specialpurpose/scrum
Affects Versions: Trunk
Reporter: Shivangi Tanwar
Assignee: Shivangi Tanwar
Priority: Minor
 Fix For: Trunk






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

[jira] [Commented] (OFBIZ-7369) Error on deleting Content Type Attribute


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

Amardeep Singh Jhajj commented on OFBIZ-7369:
-

The reason of error was missing default-entity-name in service entity-auto. 
Please find attached patch for Release 15.12 and trunk.

> Error on deleting Content Type Attribute
> 
>
> Key: OFBIZ-7369
> URL: https://issues.apache.org/jira/browse/OFBIZ-7369
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
> Attachments: OFBIZ-7369-Screen-Shot.png, OFBIZ-7369.patch
>
>
> Please find attached screenshot.
> Steps to regenerate:
> 1. Go to https://localhost:8443/content/control/EditContentTypeAttr
> 2. Add ContentTypeAttribute.
> 3. Now try to delete it from list, error occurs.



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

Re: Proposal to delete stale java files

Hi Taher,

Payment integration files in accounting/thirdparty are not just unused files 
and all of it is not dead code. There is the whole functionality built around 
those files which is very crucial to production delivery of order management or 
ecommerce on top of OFBiz. There are many service definition files whose 
implementation is written in these java files. Some examples are,

accounting/servicedef/services_authorizedotnet.xml
accounting/servicedef/services_clearcommerce.xml
accounting/servicedef/services_cybersource.xml
accounting/servicedef/services_orbital.xml
accounting/servicedef/services_paypal.xml
etc.

Along with that, many of the configurations needed to use these payment 
solutions are maintained in accounting/config/payment.properties file. A 
ProductStore in OFBiz as well can be configures to use on of these payment 
processors.

Also, these file are intentionally excluded from compile process, but can be 
included if you want to use/deliver one of these existing payment solution in 
OFBiz in production. Following is the code snippet from accounting/build.xml,

It clearly mentions that if you have required libraries for any of the third 
party payment solutions, you could comment out the exclusion. Usually, when 
someone needs to use one of the available payment processor, they download the 
required jar and place it in accounting/lib folder, make the needed changes in 
build.xml and they are ready to use the respective payment solution.

We have used one or the other payment processors in OFBiz many a times to 
deliver payment solutions as part of the software. I believe there are many 
application users and service providers who might be using the payment 
processor functionality that comes with OFBiz OOTB.

So, it’s not just about moving some files from core applications to some other 
directory because they seems to be unused, the whole functionality needs to be 
moved so that current or future users of these functionalities can still use 
it. And that is the reason if we create a new special purpose component it will 
help us to keep the functionality intact and usable at the same time separate 
it from core applications. That would also enable us to keep such components 
out of component-load.xml and specialpurpose/build.xml. A README file would 
help the user with directions to use it.

Additionally, I feel that most of these files may need to be upgraded and needs 
code refactoring probably because they might usually be left out as they do not 
compile by default with OFBiz.

--
Thanks & Regards,
Mridul Pathak
HotWax Systems
http://www.hotwaxsystems.com

> On Jun 16, 2016, at 6:44 PM, Taher Alkhateeb  
> wrote:
> 
> Hey Folks,
> 
> I would prefer to keep dead code away from the top level OFBiz directory.
> If you keep it there then you make it _closer_ to the framework!
> 
> Anyway, I don't see a problem with keeping it in specialpurpose! You are
> not creating a component, you are just creating a folder called reference
> and adding stuff to it, and you are not adding it to component-load.xml?
> Why is it that you cannot add it there?
> 
> Regards,
> 
> Taher Alkhateeb
> 
> On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
> mridul.pat...@hotwaxsystems.com> wrote:
> 
>> Introducing new directory “reference” seems reasonable approach to me as
>> it is a combined solution to everyone’s views.
>> 
>> --
>> Thanks & Regards,
>> Mridul Pathak
>> Senior Manager
>> HotWax Systems
>> http://www.hotwaxsystems.com
>> 
>>> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>> 
>>> Hi Divesh,
>>> 
>>> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> 3- In the case of non-compiling / broken / missing dependencies code
 highlight this issue somewhere visible to the programmer (README,
 whatever). Why is this important? Because we need to tell our build
 scripts
 and our classpath settings to ignore these files.

 The reason why I suggested to keep all of them in
 /reference/each-component-name-here is to tell the build system to
>> ignore
 all Java files found in /specialpurpose/reference. If you instead
>> break it
 up into multiple components, then I need to ignore the files in each
 component by hand which makes the build script more complex and
>> more prone
 to human error and it would add to the confusion.

>> I agree and I think your initial proposition ("How about
>> reference/paymentext and reference/whatever-else-you-want?") was not
>> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>> 
 Actually Jacques,  we cannot create component like
 specialpurpose/reference/paymentext . Other way can be we introduce new
 directory "reference" in parallel to specialpurpose, applications ,

[jira] [Updated] (OFBIZ-7369) Error on deleting Content Type Attribute


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

Amardeep Singh Jhajj updated OFBIZ-7369:

Attachment: OFBIZ-7369.patch
OFBIZ-7369-Screen-Shot.png

> Error on deleting Content Type Attribute
> 
>
> Key: OFBIZ-7369
> URL: https://issues.apache.org/jira/browse/OFBIZ-7369
> Project: OFBiz
>  Issue Type: Bug
>  Components: content
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Amardeep Singh Jhajj
>Assignee: Amardeep Singh Jhajj
> Attachments: OFBIZ-7369-Screen-Shot.png, OFBIZ-7369.patch
>
>
> Please find attached screenshot.
> Steps to regenerate:
> 1. Go to https://localhost:8443/content/control/EditContentTypeAttr
> 2. Add ContentTypeAttribute.
> 3. Now try to delete it from list, error occurs.



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

[jira] [Created] (OFBIZ-7369) Error on deleting Content Type Attribute

Amardeep Singh Jhajj created OFBIZ-7369:
---

 Summary: Error on deleting Content Type Attribute
 Key: OFBIZ-7369
 URL: https://issues.apache.org/jira/browse/OFBIZ-7369
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Release Branch 15.12, Trunk
Reporter: Amardeep Singh Jhajj
Assignee: Amardeep Singh Jhajj


Please find attached screenshot.

Steps to regenerate:

1. Go to https://localhost:8443/content/control/EditContentTypeAttr
2. Add ContentTypeAttribute.
3. Now try to delete it from list, error occurs.



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

[jira] [Updated] (OFBIZ-7368) Mime Type Id field on Content Lookup displayed Html Encoded String for special character


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

Ravi Lodhi updated OFBIZ-7368:
--
Attachment: OFBIZ-7368_trunk.patch

> Mime Type Id field on Content Lookup displayed Html Encoded String for 
> special character
> 
>
> Key: OFBIZ-7368
> URL: https://issues.apache.org/jira/browse/OFBIZ-7368
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Ravi Lodhi
>Assignee: Ravi Lodhi
>Priority: Minor
> Attachments: OFBIZ-7368_trunk.patch
>
>




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

[jira] [Created] (OFBIZ-7368) Mime Type Id field on Content Lookup displayed Html Encoded String for special character

Ravi Lodhi created OFBIZ-7368:
-

 Summary: Mime Type Id field on Content Lookup displayed Html 
Encoded String for special character
 Key: OFBIZ-7368
 URL: https://issues.apache.org/jira/browse/OFBIZ-7368
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Ravi Lodhi
Assignee: Ravi Lodhi
Priority: Minor






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

[jira] [Updated] (OFBIZ-6293) If a party is both a contact and a lead, then SFA profile renders screens for both


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

Ravi Lodhi updated OFBIZ-6293:
--
Attachment: OFBIZ-6293_trunk.patch

I looked around this issue and made changes to display respective section on 
Lead Profile and Contact Profile page. 

> If a party is both a contact and a lead, then SFA profile renders screens for 
> both
> --
>
> Key: OFBIZ-6293
> URL: https://issues.apache.org/jira/browse/OFBIZ-6293
> Project: OFBiz
>  Issue Type: Bug
>  Components: marketing
>Affects Versions: Trunk
>Reporter: Pierre Smits
> Attachments: OFBIZ-6293_trunk.patch
>
>
> When a party is assigned both roles Contact and Lead, then the contact 
> profile shows all screens for the Lead profile too. And the lead profile 
> shows the screens for the contact too.
> In both cases this results in multiple screens shown twice.



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

[jira] [Commented] (OFBIZ-7330) Error with Agreement Item Supplier product Pdf


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

Ravi Lodhi commented on OFBIZ-7330:
---

Hi [~pfm.smits]

This issue is a generic issue, which exists in all other places where list form 
is used for generating pdf.
Some of the places are -
1) Approved Product Requirements Pdf 
(ordermgr/control/ApprovedProductRequirements)
2) Facility Inventory By Product Pdf 
(facility/control/ViewFacilityInventoryByProduct)

> Error with Agreement Item Supplier product Pdf 
> ---
>
> Key: OFBIZ-7330
> URL: https://issues.apache.org/jira/browse/OFBIZ-7330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Ravi Lodhi
>Assignee: Ravi Lodhi
> Attachments: OFBIZ-7330_trunk.patch
>
>
> Steps to regenerate:
> 1) Go to Accounting -> Agreements
> 2) Find  a purchase agreement and go to the List Agreement Items page.
> 3) Go to edit any agreement item and  then products page.
> 4) Error with pdf generation when there are no products associated.



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

[jira] [Commented] (OFBIZ-7330) Error with Agreement Item Supplier product Pdf


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

Ravi Lodhi commented on OFBIZ-7330:
---

Hi [~pfm.smits]

This issue is a generic issue, which exists in all other places where list form 
is used for generating pdf.
Some of the places are -
1) Approved Product Requirements Pdf 
(ordermgr/control/ApprovedProductRequirements)
2) Facility Inventory By Product Pdf 
(facility/control/ViewFacilityInventoryByProduct)

> Error with Agreement Item Supplier product Pdf 
> ---
>
> Key: OFBIZ-7330
> URL: https://issues.apache.org/jira/browse/OFBIZ-7330
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Ravi Lodhi
>Assignee: Ravi Lodhi
> Attachments: OFBIZ-7330_trunk.patch
>
>
> Steps to regenerate:
> 1) Go to Accounting -> Agreements
> 2) Find  a purchase agreement and go to the List Agreement Items page.
> 3) Go to edit any agreement item and  then products page.
> 4) Error with pdf generation when there are no products associated.



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

[jira] [Updated] (OFBIZ-7367) 'From Date' and 'Through Date' is not setting on add of task member

2016-06-16 Thread Aditi Patidar (JIRA)


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

Aditi Patidar updated OFBIZ-7367:
-
Attachment: OFBIZ-7367.patch

'fromDate' and 'thruDate' was not set in the map passed to service. Here is the 
patch to fix the issue.

> 'From Date' and 'Through Date' is not setting on add of task member
> ---
>
> Key: OFBIZ-7367
> URL: https://issues.apache.org/jira/browse/OFBIZ-7367
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/scrum
>Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Aditi Patidar
>Assignee: Aditi Patidar
> Attachments: OFBIZ-7367.patch
>
>
> Steps to regenerate the issue:
> 1. Navigate to 'SCRUM' -> 'Tasks'.
> 2. Press 'New Task' button.
> 3. Create the task.
> 4. Browse the task created.
> 5. Press 'Member' tab.
> 6. Add task member, select 'Project Member', add 'From Date' and 'Thru Date'.
> Expected result:
> Added From and Thru date should display.
> Actual result:
> 'From Date' is showing now timestamp and 'Thru Date' is empty.



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

buildbot success in on ofbiz-trunk

The Buildbot has detected a restored build on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/855

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: forced: by IRC user  (privmsg): forces manual build 
after weird failures
Build Source Stamp: HEAD
Blamelist: 

Build succeeded!

Sincerely,
 -The Buildbot

[jira] [Created] (OFBIZ-7367) 'From Date' and 'Through Date' is not setting on add of task member

2016-06-16 Thread Aditi Patidar (JIRA)

Aditi Patidar created OFBIZ-7367:


 Summary: 'From Date' and 'Through Date' is not setting on add of 
task member
 Key: OFBIZ-7367
 URL: https://issues.apache.org/jira/browse/OFBIZ-7367
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/scrum
Affects Versions: Release Branch 15.12, Trunk, Release Branch 14.12
Reporter: Aditi Patidar
Assignee: Aditi Patidar


Steps to regenerate the issue:
1. Navigate to 'SCRUM' -> 'Tasks'.
2. Press 'New Task' button.
3. Create the task.
4. Browse the task created.
5. Press 'Member' tab.
6. Add task member, select 'Project Member', add 'From Date' and 'Thru Date'.

Expected result:
Added From and Thru date should display.

Actual result:
'From Date' is showing now timestamp and 'Thru Date' is empty.



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

[jira] [Commented] (OFBIZ-7346) connection pooling not working


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

Jacques Le Roux commented on OFBIZ-7346:


After noticing the Connection Pool Status feature in webtools was broken in 
trunk (also in R15.12 and R14.12) I checked the connection pooling in our 
stable release (R13.07 where the Connection Pool Status feature still works) 
and there it seems the connection pooling is still working correctly. I say it 
seems because I only checked with *Derby* locally and on the demo. 

On stable demo we have currently 4 connections in the pool with 2 idle. Of 
course this varies, but I checked at several moments and the pool does not tend 
to 0 as in trunk with postgres when the patch is not applied.

Now the weird thing, if the Connection Pool Status feature reports correctly, 
then you can now also see that the pooling seems to work on trunk demo (after 
committing for OFBIZ-7363, I also restarted the trunk demo, wich is currently 
quite slow BTW). I need to revisit the whole thing...

> connection pooling not working
> --
>
> Key: OFBIZ-7346
> URL: https://issues.apache.org/jira/browse/OFBIZ-7346
> Project: OFBiz
>  Issue Type: Bug
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Gareth Carter
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: DBCPConnectionFactory.patch
>
>
> Connection pooling does not seem to work. Connections are created fine but as 
> the close() method is called (outside of transaction) or the transaction is 
> committed the connections are closed to the db server and not returned to the 
> pool.
> I believe the issue is with 
> org.apache.commons.dbcp2.PoolableConnectionFactory passivateObject method. 
> This will call rollback() when rollbackOnReturn is set to true even if the 
> transaction is committed. This is because any connection wrappers extending 
> org.apache.commons.dbcp2.DelegatingConnection cache autoCommit status. At 
> some point, this cached autoCommit is different from the underlying 
> connection autoCommit. The rollback() method will throw an exception and the 
> connection is destroyed rather than put back to the pool
> Environment this has been tested on:
> ofbiz: rev 1725574 and latest trunk (as of 2016-06-14)
> db: postgresql 9.1
> jdbc driver: postgresql-9.3-1101.jdbc4
> os: linux and windows
> I have asked dev ml for others to check this with other dbs. Jacques has test 
> with postgres but could not see this behaviour



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

[jira] [Updated] (OFBIZ-7143) Error on cancelling agreement

2016-06-16 Thread Montalbano Florian (JIRA)


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

Montalbano Florian updated OFBIZ-7143:
--
Attachment: OFBIZ-7143.patch

I just encountered this problem once again. I found this solution while 
searching for this issue.

It seems simpler than the one you already proposed [~lodhiravi].
I'll try to update the status of this JIRA for helping with the resolution of 
this issue.

> Error on cancelling agreement
> -
>
> Key: OFBIZ-7143
> URL: https://issues.apache.org/jira/browse/OFBIZ-7143
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Ravi Lodhi
>Assignee: Ravi Lodhi
>Priority: Minor
> Attachments: OFBIZ-7143.patch, OFBIZ-7143_1412.patch, 
> OFBIZ-7143_1512.patch, OFBIZ-7143_trunk.patch
>
>
> Step to regenerate:
> 1) Go to Agreements screen under Accounting 
> component.(https://localhost:8443/accounting/control/FindAgreement)
> 2) Cancel an agreement from the list.
> 3) See the error on Search Results section.



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

Re: Proposal to delete stale java files

Hey Folks,

I would prefer to keep dead code away from the top level OFBiz directory.
If you keep it there then you make it _closer_ to the framework!

Anyway, I don't see a problem with keeping it in specialpurpose! You are
not creating a component, you are just creating a folder called reference
and adding stuff to it, and you are not adding it to component-load.xml?
Why is it that you cannot add it there?

Regards,

Taher Alkhateeb

On Thu, Jun 16, 2016 at 3:55 PM, Mridul Pathak <
mridul.pat...@hotwaxsystems.com> wrote:

> Introducing new directory “reference” seems reasonable approach to me as
> it is a combined solution to everyone’s views.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 5:56 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
> >
> > Hi Divesh,
> >
> > Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
> >>> 3- In the case of non-compiling / broken / missing dependencies code
>  >>highlight this issue somewhere visible to the programmer (README,
>  >>whatever). Why is this important? Because we need to tell our build
>  >>scripts
>  >>and our classpath settings to ignore these files.
>  >>
>  >>The reason why I suggested to keep all of them in
>  >>/reference/each-component-name-here is to tell the build system to
> ignore
>  >>all Java files found in /specialpurpose/reference. If you instead
> break it
>  >>up into multiple components, then I need to ignore the files in each
>  >>component by hand which makes the build script more complex and
> more prone
>  >>to human error and it would add to the confusion.
>  >>
> >>> >I agree and I think your initial proposition ("How about
> >>> >reference/paymentext and reference/whatever-else-you-want?") was not
> >>> >clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
> >>> >
> >> Actually Jacques,  we cannot create component like
> >> specialpurpose/reference/paymentext . Other way can be we introduce new
> >> directory "reference" in parallel to specialpurpose, applications ,
> >> framework . Do you mean to do that ?
> >
> > You are right, and following Taher's idea I missed this point, it seems
> to me that your proposition of < parallel to specialpurpose, applications ,framework>> is the best one so
> far.
> > It could be also that Taher anticipated on the work (I know) he will do
> on refactoring the build system and this possibility will be open "soon",
> Taher?
> >
> >>
> >> Also as Mridul put it, and you agreed, the "shipping integration/s"
> which
> >>> >"doesn’t have the compilation or library reference issues" would be
> in its
> >>> >own independent component/s (ie not under /reference), same for other
> stuff
> >>> >with the same status, if exist.
> >> In this case, shipping integration can be under special purpose. So
> >> specialpurpose/shippingIntegratio.
> >
> > Clearly, nobrainer :)
> >
> > Jacques
> >>
> >>
> >> Thanks
> >> --
> >> Divesh Dutta.
> >>
> >>
> >>
> >
>
>

[jira] [Assigned] (OFBIZ-7365) fonts.pdf Throw error on terminal


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

Pranay Pandey reassigned OFBIZ-7365:


Assignee: Vaibhav Jain  (was: Pranay Pandey)

Hi [~vaibhav.jain],

Please don't assign any issue directly to me, I will definitely pick it up as I 
get some bandwidth but in the mean time any of the committer can jump in can 
help you for committing the fix.

Thanks.

> fonts.pdf Throw error on terminal
> -
>
> Key: OFBIZ-7365
> URL: https://issues.apache.org/jira/browse/OFBIZ-7365
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/example
>Reporter: Vaibhav Jain
>Assignee: Vaibhav Jain
>
> Steps to regenerate the issue:
> 1. Go to "EXAMPLE"  component.
> 2. Click on sub-menu "FOP fonts in a PDF"
> _
> Direct link
> https://localhost:8443/example/control/fonts.pdf
> _
> {code}
>   [java] 2016-06-13 19:25:34,639 |ttp-nio-8443-exec-10 |ScreenFopViewHandler  
> |E| Unable to write to OutputStream: 
> org.apache.catalina.connector.ClientAbortException: java.io.IOException: 
> Broken pipe; Screen XSL:FO text was:
> [java] 
> [java] 2016-06-13 19:25:35,084 |ttp-nio-8443-exec-10 |ScreenFopViewHandler
>   |E| Multiple errors rendering FOP
> [java] 2016-06-13 19:25:35,085 |ttp-nio-8443-exec-10 |ControlServlet  
>   |E| Error in request handler: 
> [java] java.lang.IllegalStateException: getOutputStream() has already 
> been called for this response
> [java] at 
> org.apache.catalina.connector.Response.getWriter(Response.java:564) 
> ~[tomcat-8.0.33-catalina.jar:8.0.33]
> [java] at 
> org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:212)
>  ~[tomcat-8.0.33-catalina.jar:8.0.33]
> [java] at 
> org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.renderError(ScreenFopViewHandler.java:191)
>  ~[ofbiz-widget.jar:?]
> [java] at 
> org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.render(ScreenFopViewHandler.java:174)
>  ~[ofbiz-widget.jar:?]
> [java] at 
> org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:1001) 
> ~[ofbiz-webapp.jar:?]
> [java] at 
> org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:653) 
> ~[ofbiz-webapp.jar:?]
> [java] at 
> org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
> [ofbiz-webapp.jar:?]
> [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) 
> [servlet-api-3.1.jar:?]
> [java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) 
> [servlet-api-3.1.jar:?]
> 
> {code}



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

[jira] [Assigned] (OFBIZ-7366) FTL formatting in the whole application


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

Pranay Pandey reassigned OFBIZ-7366:


Assignee: Vaibhav Jain  (was: Pranay Pandey)

Hi [~vaibhav.jain],

Please don't assign any issue directly to me, I will definitely pick it up as I 
get some bandwidth but in the mean time any of the committer can jump in can 
help you for committing the fix.

Thanks.

> FTL formatting in the whole application
> ---
>
> Key: OFBIZ-7366
> URL: https://issues.apache.org/jira/browse/OFBIZ-7366
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL APPLICATIONS
>Reporter: Vaibhav Jain
>Assignee: Vaibhav Jain
>
> There is a formatting issue in the most of FTL files in OFBiz.
> We need to format the code as per best practice to make it more readable.



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

buildbot failure in on ofbiz-trunk

The Buildbot has detected a new failure on builder ofbiz-trunk while building . 
Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/854

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1748703
Blamelist: jleroux

BUILD FAILED: failed compile_1

Sincerely,
 -The Buildbot

Re: Proposal to delete stale java files

Introducing new directory “reference” seems reasonable approach to me as it is 
a combined solution to everyone’s views.

--
Thanks & Regards,
Mridul Pathak
Senior Manager
HotWax Systems
http://www.hotwaxsystems.com

> On Jun 16, 2016, at 5:56 PM, Jacques Le Roux  
> wrote:
> 
> Hi Divesh,
> 
> Le 16/06/2016 à 13:38, Divesh Dutta a écrit :
>>> 3- In the case of non-compiling / broken / missing dependencies code
 >>highlight this issue somewhere visible to the programmer (README,
 >>whatever). Why is this important? Because we need to tell our build
 >>scripts
 >>and our classpath settings to ignore these files.
 >>
 >>The reason why I suggested to keep all of them in
 >>/reference/each-component-name-here is to tell the build system to ignore
 >>all Java files found in /specialpurpose/reference. If you instead break 
 >>it
 >>up into multiple components, then I need to ignore the files in each
 >>component by hand which makes the build script more complex and more 
 >>prone
 >>to human error and it would add to the confusion.
 >>
>>> >I agree and I think your initial proposition ("How about
>>> >reference/paymentext and reference/whatever-else-you-want?") was not
>>> >clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>>> >
>> Actually Jacques,  we cannot create component like
>> specialpurpose/reference/paymentext . Other way can be we introduce new
>> directory "reference" in parallel to specialpurpose, applications ,
>> framework . Do you mean to do that ?
> 
> You are right, and following Taher's idea I missed this point, it seems to me 
> that your proposition of < parallel to specialpurpose, applications ,framework>> is the best one so far.
> It could be also that Taher anticipated on the work (I know) he will do on 
> refactoring the build system and this possibility will be open "soon", Taher?
> 
>> 
>> Also as Mridul put it, and you agreed, the "shipping integration/s" which
>>> >"doesn’t have the compilation or library reference issues" would be in its
>>> >own independent component/s (ie not under /reference), same for other stuff
>>> >with the same status, if exist.
>> In this case, shipping integration can be under special purpose. So
>> specialpurpose/shippingIntegratio.
> 
> Clearly, nobrainer :)
> 
> Jacques
>> 
>> 
>> Thanks
>> --
>> Divesh Dutta.
>> 
>> 
>> 
>

buildbot success in on ofbiz-trunk

The Buildbot has detected a restored build on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/853

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1748693
Blamelist: jleroux

Build succeeded!

Sincerely,
 -The Buildbot

[jira] [Commented] (OFBIZ-7364) Failed to open BIRT charts on Product Statistics page.

2016-06-16 Thread Jacopo Cappellato (JIRA)


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

Jacopo Cappellato commented on OFBIZ-7364:
--

I have noticed that this typo has been introduced with rev. 1672752 by 
[~soledad]: since that commit changed several other files, it would be great to 
check if the same typo is elsewhere.

> Failed to open BIRT charts on Product Statistics page.
> --
>
> Key: OFBIZ-7364
> URL: https://issues.apache.org/jira/browse/OFBIZ-7364
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/birt, specialpurpose/scrum
>Reporter: Rohit Koushal
>Assignee: Rohit Koushal
> Attachments: OFBIZ-7364.patch
>
>
> Ofbiz failed to open 3 BIRT charts on Product Statistics page.
> 1. Project and Sprint
> 2. Task by Type
> 3. Task by status
> Steps to  regenerate the issue.
> 1. Go to screen  [Product 
> Statistics|https://ofbiz-vm.apache.org:8443//scrum/control/ProductStatistics]
> 2. Select Product Name and Click on Submit button.
> 3. Screen rendered with 3 empty sections.



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

[jira] [Created] (OFBIZ-7366) FTL formatting in the whole application

2016-06-16 Thread Vaibhav Jain (JIRA)

Vaibhav Jain created OFBIZ-7366:
---

 Summary: FTL formatting in the whole application
 Key: OFBIZ-7366
 URL: https://issues.apache.org/jira/browse/OFBIZ-7366
 Project: OFBiz
  Issue Type: Improvement
  Components: ALL APPLICATIONS
Reporter: Vaibhav Jain
Assignee: Pranay Pandey


There is a formatting issue in the most of FTL files in OFBiz.
We need to format the code as per best practice to make it more readable.



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

[jira] [Updated] (OFBIZ-7365) fonts.pdf Throw error on terminal

2016-06-16 Thread Vaibhav Jain (JIRA)


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

Vaibhav Jain updated OFBIZ-7365:

Description: 
Steps to regenerate the issue:
1. Go to "EXAMPLE"  component.
2. Click on sub-menu "FOP fonts in a PDF"

_
Direct link
https://localhost:8443/example/control/fonts.pdf
_

{code}
  [java] 2016-06-13 19:25:34,639 |ttp-nio-8443-exec-10 |ScreenFopViewHandler
  |E| Unable to write to OutputStream: 
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken 
pipe; Screen XSL:FO text was:
[java] 

[java] 2016-06-13 19:25:35,084 |ttp-nio-8443-exec-10 |ScreenFopViewHandler  
|E| Multiple errors rendering FOP
[java] 2016-06-13 19:25:35,085 |ttp-nio-8443-exec-10 |ControlServlet
|E| Error in request handler: 
[java] java.lang.IllegalStateException: getOutputStream() has already been 
called for this response
[java] at 
org.apache.catalina.connector.Response.getWriter(Response.java:564) 
~[tomcat-8.0.33-catalina.jar:8.0.33]
[java] at 
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:212) 
~[tomcat-8.0.33-catalina.jar:8.0.33]
[java] at 
org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.renderError(ScreenFopViewHandler.java:191)
 ~[ofbiz-widget.jar:?]
[java] at 
org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.render(ScreenFopViewHandler.java:174)
 ~[ofbiz-widget.jar:?]
[java] at 
org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:1001) 
~[ofbiz-webapp.jar:?]
[java] at 
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:653) 
~[ofbiz-webapp.jar:?]
[java] at 
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
[ofbiz-webapp.jar:?]
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) 
[servlet-api-3.1.jar:?]
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) 
[servlet-api-3.1.jar:?]


{code}

  was:
Steps to regenerate the issue:
1. Go to "EXAMPLE"  component.
2. Click on sub-menu "FOP fonts in a PDF"

_
Direct link
https://ofbiz-trunk.hotwaxsystems.com/example/control/fonts.pdf
_

{code}
  [java] 2016-06-13 19:25:34,639 |ttp-nio-8443-exec-10 |ScreenFopViewHandler
  |E| Unable to write to OutputStream: 
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken 
pipe; Screen XSL:FO text was:
[java] 

[java] 2016-06-13 19:25:35,084 |ttp-nio-8443-exec-10 |ScreenFopViewHandler  
|E| Multiple errors rendering FOP
[java] 2016-06-13 19:25:35,085 |ttp-nio-8443-exec-10 |ControlServlet
|E| Error in request handler: 
[java] java.lang.IllegalStateException: getOutputStream() has already been 
called for this response
[java] at 
org.apache.catalina.connector.Response.getWriter(Response.java:564) 
~[tomcat-8.0.33-catalina.jar:8.0.33]
[java] at 
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:212) 
~[tomcat-8.0.33-catalina.jar:8.0.33]
[java] at 
org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.renderError(ScreenFopViewHandler.java:191)
 ~[ofbiz-widget.jar:?]
[java] at 
org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.render(ScreenFopViewHandler.java:174)
 ~[ofbiz-widget.jar:?]
[java] at 
org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:1001) 
~[ofbiz-webapp.jar:?]
[java] at 
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:653) 
~[ofbiz-webapp.jar:?]
[java] at 
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
[ofbiz-webapp.jar:?]
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) 
[servlet-api-3.1.jar:?]
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) 
[servlet-api-3.1.jar:?]


{code}


> fonts.pdf Throw error on terminal
> -
>
> Key: OFBIZ-7365
> URL: https://issues.apache.org/jira/browse/OFBIZ-7365
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/example
>Reporter: Vaibhav Jain
>Assignee: Pranay Pandey
>
> Steps to regenerate the issue:
> 1. Go to "EXAMPLE"  component.
> 2. Click on sub-menu "FOP fonts in a PDF"
> _
> Direct link
> https://localhost:8443/example/control/fonts.pdf
> _
> {code}
>   [java] 2016-06-13 19:25:34,639 |ttp-nio-8443-exec-10 |ScreenFopViewHandler  
> |E| Unable to write to OutputStream: 
> org.apache.catalina.connector.ClientAbortException: java.io.IOException: 
> Broken pipe; Screen XSL:FO text

[jira] [Created] (OFBIZ-7365) fonts.pdf Throw error on terminal

2016-06-16 Thread Vaibhav Jain (JIRA)

Vaibhav Jain created OFBIZ-7365:
---

 Summary: fonts.pdf Throw error on terminal
 Key: OFBIZ-7365
 URL: https://issues.apache.org/jira/browse/OFBIZ-7365
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/example
Reporter: Vaibhav Jain
Assignee: Pranay Pandey


Steps to regenerate the issue:
1. Go to "EXAMPLE"  component.
2. Click on sub-menu "FOP fonts in a PDF"

_
Direct link
https://ofbiz-trunk.hotwaxsystems.com/example/control/fonts.pdf
_

{code}
  [java] 2016-06-13 19:25:34,639 |ttp-nio-8443-exec-10 |ScreenFopViewHandler
  |E| Unable to write to OutputStream: 
org.apache.catalina.connector.ClientAbortException: java.io.IOException: Broken 
pipe; Screen XSL:FO text was:
[java] 

[java] 2016-06-13 19:25:35,084 |ttp-nio-8443-exec-10 |ScreenFopViewHandler  
|E| Multiple errors rendering FOP
[java] 2016-06-13 19:25:35,085 |ttp-nio-8443-exec-10 |ControlServlet
|E| Error in request handler: 
[java] java.lang.IllegalStateException: getOutputStream() has already been 
called for this response
[java] at 
org.apache.catalina.connector.Response.getWriter(Response.java:564) 
~[tomcat-8.0.33-catalina.jar:8.0.33]
[java] at 
org.apache.catalina.connector.ResponseFacade.getWriter(ResponseFacade.java:212) 
~[tomcat-8.0.33-catalina.jar:8.0.33]
[java] at 
org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.renderError(ScreenFopViewHandler.java:191)
 ~[ofbiz-widget.jar:?]
[java] at 
org.ofbiz.widget.renderer.fo.ScreenFopViewHandler.render(ScreenFopViewHandler.java:174)
 ~[ofbiz-widget.jar:?]
[java] at 
org.ofbiz.webapp.control.RequestHandler.renderView(RequestHandler.java:1001) 
~[ofbiz-webapp.jar:?]
[java] at 
org.ofbiz.webapp.control.RequestHandler.doRequest(RequestHandler.java:653) 
~[ofbiz-webapp.jar:?]
[java] at 
org.ofbiz.webapp.control.ControlServlet.doGet(ControlServlet.java:213) 
[ofbiz-webapp.jar:?]
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:622) 
[servlet-api-3.1.jar:?]
[java] at javax.servlet.http.HttpServlet.service(HttpServlet.java:729) 
[servlet-api-3.1.jar:?]


{code}



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

[jira] [Updated] (OFBIZ-7364) Failed to open BIRT charts on Product Statistics page.

2016-06-16 Thread Rohit Koushal (JIRA)


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

Rohit Koushal updated OFBIZ-7364:
-
Attachment: OFBIZ-7364.patch

There is a typo in the charts, "LinkedList" class is written as "LinkedkList"

> Failed to open BIRT charts on Product Statistics page.
> --
>
> Key: OFBIZ-7364
> URL: https://issues.apache.org/jira/browse/OFBIZ-7364
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/birt, specialpurpose/scrum
>Reporter: Rohit Koushal
>Assignee: Rohit Koushal
> Attachments: OFBIZ-7364.patch
>
>
> Ofbiz failed to open 3 BIRT charts on Product Statistics page.
> 1. Project and Sprint
> 2. Task by Type
> 3. Task by status
> Steps to  regenerate the issue.
> 1. Go to screen  [Product 
> Statistics|https://ofbiz-vm.apache.org:8443//scrum/control/ProductStatistics]
> 2. Select Product Name and Click on Submit button.
> 3. Screen rendered with 3 empty sections.



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

[jira] [Created] (OFBIZ-7364) Failed to open BIRT charts on Product Statistics page.

2016-06-16 Thread Rohit Koushal (JIRA)

Rohit Koushal created OFBIZ-7364:


 Summary: Failed to open BIRT charts on Product Statistics page.
 Key: OFBIZ-7364
 URL: https://issues.apache.org/jira/browse/OFBIZ-7364
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/birt, specialpurpose/scrum
Reporter: Rohit Koushal
Assignee: Rohit Koushal


Ofbiz failed to open 3 BIRT charts on Product Statistics page.
1. Project and Sprint
2. Task by Type
3. Task by status

Steps to  regenerate the issue.
1. Go to screen  [Product 
Statistics|https://ofbiz-vm.apache.org:8443//scrum/control/ProductStatistics]
2. Select Product Name and Click on Submit button.
3. Screen rendered with 3 empty sections.




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

Re: Proposal to delete stale java files


Hi Divesh,

Le 16/06/2016 à 13:38, Divesh Dutta a écrit :

3- In the case of non-compiling / broken / missing dependencies code

>>highlight this issue somewhere visible to the programmer (README,
>>whatever). Why is this important? Because we need to tell our build
>>scripts
>>and our classpath settings to ignore these files.
>>
>>The reason why I suggested to keep all of them in
>>/reference/each-component-name-here is to tell the build system to ignore
>>all Java files found in /specialpurpose/reference. If you instead break it
>>up into multiple components, then I need to ignore the files in each
>>component by hand which makes the build script more complex and more prone
>>to human error and it would add to the confusion.
>>

>I agree and I think your initial proposition ("How about
>reference/paymentext and reference/whatever-else-you-want?") was not
>clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>

Actually Jacques,  we cannot create component like
specialpurpose/reference/paymentext . Other way can be we introduce new
directory "reference" in parallel to specialpurpose, applications ,
framework . Do you mean to do that ?


You are right, and following Taher's idea I missed this point, it seems to me that your proposition of > is the best one so far.

It could be also that Taher anticipated on the work (I know) he will do on refactoring 
the build system and this possibility will be open "soon", Taher?



Also as Mridul put it, and you agreed, the "shipping integration/s" which

>"doesn’t have the compilation or library reference issues" would be in its
>own independent component/s (ie not under /reference), same for other stuff
>with the same status, if exist.

In this case, shipping integration can be under special purpose. So
specialpurpose/shippingIntegratio.


Clearly, nobrainer :)

Jacques



Thanks
--
Divesh Dutta.

[jira] [Closed] (OFBIZ-7363) The Connection Pool Status feature in webtools is broken


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

Jacques Le Roux closed OFBIZ-7363.
--
Resolution: Fixed

Fixed in
trunk r1748689+1748693
R15.12 r1748695+1748697
R14.12 r1748696+1748698

I fixed it by using directly the DebugManagedDataSource. It's not an issue as 
long as you don't set the logging level to verbose which is anyway not 
something you would do in production. In case you do so and don't want to be 
disturbed in the log (focusing on something else), it's still easy to comment 
out the line from DebugManagedDataSource. I also fixed some type warnings while 
at it.

I also removed this old comment
// Hmm... then how do we close the JDBC connections?
Because "we" don't close JDBC connections, DBPC takes care of that (or at least 
should, I did not check).

> The Connection Pool Status feature in webtools is broken
> 
>
> Key: OFBIZ-7363
> URL: https://issues.apache.org/jira/browse/OFBIZ-7363
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework/webtools
>Affects Versions: Release Branch 14.12, Trunk, Release Branch 15.12
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: 14.12.01, 15.12.01
>
>
> This was introduced by OFBIZ-4864 hence 1st in R13.07 where it still work 
> well (see demo), as the connection pooling. But has been broken since, with 
> the pooling.
> Fortunately, it's easy to fix and has no implications has long has you don't 
> enable verbose logging (the DebugManagedDataSource only extends 
> ManagedDataSource for verbose logging and to generate the info needed for the 
> Connection Pool Status feature).



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

buildbot exception in on ofbiz-trunk

The Buildbot has detected a build exception on builder ofbiz-trunk while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-trunk/builds/852

Buildbot URL: https://ci.apache.org/

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/trunk] 1748689
Blamelist: jleroux

BUILD FAILED: exception upload_2

Sincerely,
 -The Buildbot

Re: Proposal to delete stale java files

2016-06-16 Thread Divesh Dutta

On Thu, Jun 16, 2016 at 4:45 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Le 16/06/2016 à 12:41, Taher Alkhateeb a écrit :
>
>> Hi Divesh and everyone,
>>
>> Nicely summarized, thank you for your input.
>>
>> I don't have any strong opinion on how to structure things. The important
>> thing for me whatever you decide to do is the following:
>>
>> 1- Keep dead / irrelevant code away from the framework and core
>> applications
>>
> +1
>
>> 2- Keep peripheral or non-core functionality away from framework and core
>> applications.
>>
> +1


+1 for above points.

>
> 3- In the case of non-compiling / broken / missing dependencies code
>> highlight this issue somewhere visible to the programmer (README,
>> whatever). Why is this important? Because we need to tell our build
>> scripts
>> and our classpath settings to ignore these files.
>>
>> The reason why I suggested to keep all of them in
>> /reference/each-component-name-here is to tell the build system to ignore
>> all Java files found in /specialpurpose/reference. If you instead break it
>> up into multiple components, then I need to ignore the files in each
>> component by hand which makes the build script more complex and more prone
>> to human error and it would add to the confusion.
>>
> I agree and I think your initial proposition ("How about
> reference/paymentext and reference/whatever-else-you-want?") was not
> clearly understood by Pierre and maybe not Divesh. Pierre, Divesh?
>

Actually Jacques,  we cannot create component like
specialpurpose/reference/paymentext . Other way can be we introduce new
directory "reference" in parallel to specialpurpose, applications ,
framework . Do you mean to do that ?

Also as Mridul put it, and you agreed, the "shipping integration/s" which
> "doesn’t have the compilation or library reference issues" would be in its
> own independent component/s (ie not under /reference), same for other stuff
> with the same status, if exist.


In this case, shipping integration can be under special purpose. So
specialpurpose/shippingIntegratio.


Thanks
--
Divesh Dutta.



>
>
> Jacques
>
> So, although I still prefer to have one place for all non-compiling code,
>> if you can satisfy the above mentioned items, then at least we have a
>> middle ground even though the build scripts and classpath settings will be
>> more complex.
>>
>> Regards,
>>
>> Taher Alkhateeb
>>
>> On Thu, Jun 16, 2016 at 1:24 PM, Divesh Dutta <
>> divesh.du...@hotwaxsystems.com> wrote:
>>
>> Thanks Pierre and Jacques for your views. I agree with Jacques that we
>>> should not create new repos and I agree with Pierre that code can be
>>> logically grouped based on business functionality.
>>>
>>> So there are two views going on:
>>>
>>> 1) Initially Taher was suggesting to remove all the codes and then when
>>> we
>>> discussed that there are lots of users who are using those codes, he
>>> suggested to create specialpurpose/reference component for non-compiling
>>> code and rest in their own components.
>>>
>>>
>>> 2)  Create components in special purpose for each logical business
>>> functionality. So for eg: Payment integration specific codes can be in
>>> new
>>> component. Shipment integration code can be in its own component. This
>>> way
>>> we will logically group the business purpose specific codes  and they can
>>> be further used as addons in future.
>>>
>>>
>>> So it seems that most of the code which are non-compilable are candidate
>>> of
>>> new components (for eg: tax integration, payment integration etc. ). And
>>> there are less java files which are non-compilable. Some code (java
>>> files)
>>> which are compilable can also be new component for eg: shipping
>>> integration. And all these can be separate addons in future when we have
>>> the architecture support for it. There is no such code which is
>>> non-compilable and not a candidate new component and that code will have
>>> to
>>> sit inside OFBiz (either in framework of applications.)
>>>
>>> So I think we can go with #2 where we can also add details in read me
>>> file
>>> of these components that which files of the components are dependent on
>>> which jars etc.
>>>
>>>
>>> Thanks
>>> --
>>> Divesh Dutta.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
>>> jacques.le.r...@les7arts.com> wrote:
>>>
>>> As Ashish and some others mentioned, those are still needed by some of

>>> our
>>>
 users.
 Of course we need to maintain them (logically more those who are
 interested) but we can't neglect our users based on code
 cleaning/refactoring.
 And if we mix all in a ball of mud it, the cost of maintaining it will
 be
 increased. So agree with you on this part Pierre, and we need 1st to
 separate things surgically and then decide about the parts.

 But, I don't like the idea of having them in "repos" (I guess you  svn
 branches or GitHub repo/branches?) because they would be disconnected.

[jira] [Created] (OFBIZ-7363) The Connection Pool Status feature in webtools is broken

Jacques Le Roux created OFBIZ-7363:
--

 Summary: The Connection Pool Status feature in webtools is broken
 Key: OFBIZ-7363
 URL: https://issues.apache.org/jira/browse/OFBIZ-7363
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework/webtools
Affects Versions: Release Branch 15.12, Trunk, Release Branch 14.12
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
 Fix For: 14.12.01, 15.12.01


This was introduced by OFBIZ-4864 hence 1st in R13.07 where it still work well 
(see demo), as the connection pooling. But has been broken since, with the 
pooling.
Fortunately, it's easy to fix and has no implications has long has you don't 
enable verbose logging (the DebugManagedDataSource only extends 
ManagedDataSource for verbose logging and to generate the info needed for the 
Connection Pool Status feature).



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

[FYI] Adrian's picture in PMC wiki page


Hi,

I noticed that Adrian's picture in PMC wiki page was a link to his site namely 
http://www.sandglass-software.com/img/ac-head.png

I fear that this site will disappear, so I copied the picture as an attachment 
to the PMC wiki page, in any case...

Jacques

Re: Proposal to delete stale java files

Le 16/06/2016 à 12:41, Taher Alkhateeb a écrit :

Hi Divesh and everyone,

Nicely summarized, thank you for your input.

I don't have any strong opinion on how to structure things. The important
thing for me whatever you decide to do is the following:

1- Keep dead / irrelevant code away from the framework and core applications

2- Keep peripheral or non-core functionality away from framework and core
applications.

3- In the case of non-compiling / broken / missing dependencies code
highlight this issue somewhere visible to the programmer (README,
whatever). Why is this important? Because we need to tell our build scripts
and our classpath settings to ignore these files.

The reason why I suggested to keep all of them in
/reference/each-component-name-here is to tell the build system to ignore
all Java files found in /specialpurpose/reference. If you instead break it
up into multiple components, then I need to ignore the files in each
component by hand which makes the build script more complex and more prone
to human error and it would add to the confusion.
I agree and I think your initial proposition ("How about reference/paymentext and reference/whatever-else-you-want?") was not clearly understood by
Pierre and maybe not Divesh. Pierre, Divesh?
Also as Mridul put it, and you agreed, the "shipping integration/s" which "doesn’t have the compilation or library reference issues" would be in its
own independent component/s (ie not under /reference), same for other stuff with the same status, if exist.

Jacques

So, although I still prefer to have one place for all non-compiling code,
if you can satisfy the above mentioned items, then at least we have a
middle ground even though the build scripts and classpath settings will be
more complex.

Regards,

Taher Alkhateeb

On Thu, Jun 16, 2016 at 1:24 PM, Divesh Dutta <
divesh.du...@hotwaxsystems.com> wrote:

Thanks Pierre and Jacques for your views. I agree with Jacques that we
should not create new repos and I agree with Pierre that code can be
logically grouped based on business functionality.

So there are two views going on:

1) Initially Taher was suggesting to remove all the codes and then when we
discussed that there are lots of users who are using those codes, he
suggested to create specialpurpose/reference component for non-compiling
code and rest in their own components.

2) Create components in special purpose for each logical business
functionality. So for eg: Payment integration specific codes can be in new
component. Shipment integration code can be in its own component. This way
we will logically group the business purpose specific codes and they can
be further used as addons in future.

So it seems that most of the code which are non-compilable are candidate of
new components (for eg: tax integration, payment integration etc. ). And
there are less java files which are non-compilable. Some code (java files)
which are compilable can also be new component for eg: shipping
integration. And all these can be separate addons in future when we have
the architecture support for it. There is no such code which is
non-compilable and not a candidate new component and that code will have to
sit inside OFBiz (either in framework of applications.)

So I think we can go with #2 where we can also add details in read me file
of these components that which files of the components are dependent on
which jars etc.

Thanks
--
Divesh Dutta.

On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

As Ashish and some others mentioned, those are still needed by some of

our

users.
Of course we need to maintain them (logically more those who are
interested) but we can't neglect our users based on code
cleaning/refactoring.
And if we mix all in a ball of mud it, the cost of maintaining it will be
increased. So agree with you on this part Pierre, and we need 1st to
separate things surgically and then decide about the parts.

But, I don't like the idea of having them in "repos" (I guess you svn
branches or GitHub repo/branches?) because they would be disconnected.
I still can remember the effect of dropping the specialpurpose component,
but ecommerce, in R13.07 (OK they were still in svn, see?)
I mean once things are disconnected, and as long as we don't have a
good/fast/reliable technical way to connect them, they tend to be

forgotten

(see what we initially discuss here), not maintained and finally garbage.

On the other hand, as soon as we will have a solid way to support addons,
those will be perfect addons.
And no, I'm not speaking out of thin air, we (PMC) are currently
discussing about deep modifications in the project which should help
support, creation and adoption of addons (hint: look at Moqui, though we
don't want to incorporate Moqui framework)
Of course it's not for tomorrow, but we need to take time to decide on
crucial choices.

As I said already dropping the bathwater with the baby is not a solution

Re: Error on pagination at some screens when we do any operation (like update, delete) from list

2016-06-16 Thread Amardeep Singh Jhajj

Thanks everyone for your thoughts.

I have created ticket for this issue -
https://issues.apache.org/jira/browse/OFBIZ-7362

Regards,
--
Amardeep Singh Jhajj
http://www.hotwaxsystems.com/

On Wed, Jun 15, 2016 at 12:28 PM, Pranay Pandey <
pranay.pan...@hotwaxsystems.com> wrote:

> Hi Amardeep,
>
> What you have recommended is looking good to me i.e. pagination target URL
> should be independent of page URL and it should be added on form using
> paginate-target attribute of form widget.
>
> The approach you are planning to take is also looking good to me i.e. to
> create on parent ticket and add a child ticket for each of component to
> check and fix.
>
> Best regards,
>
> Pranay Pandey
> HotWax Systems
> http://www.hotwaxsystems.com/
>
> On Tue, Jun 14, 2016 at 9:43 PM, Amardeep Singh Jhajj <
> amardeep.jh...@hotwaxsystems.com> wrote:
>
> > Hi Everyone,
> >
> > I found issue in pagination on some screens when we do any operation
> (like
> > update, delete) on list item.
> >
> > For example: I have updated the content type from list in Content Setup
> > Menu in Content application and then clicked on next link of pagination,
> I
> > got the following error:
> >
> > The Following Errors Occurred:
> >
> > Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found
> > URL
> > parameter [contentTypeId] passed to secure (https) request-map with uri
> > [updateContentType] with an event that calls service [updateContentType];
> > this is not allowed for security reasons!
> >
> > The above error is unexpected as I just tried to see next list records of
> > ContentType. The reason of error is pagination URL which is same as URL
> of
> > page i.e. updateContentType. This URL is the update operation URL and it
> is
> > not redirected to appropriate page after operation.
> >
> > IMO, pagination target URL should be independent of page URL and it
> should
> > be added on form using paginate-target attribute of form widget.
> >
> > This issue can be possible in all components. I am planning to create one
> > parent ticket and will add their child tickets wherever needed for each
> > component for adding "paginate-target" to the forms.
> >
> > Please let us know your thoughts.
> >
> > Thanks and Regards
> > --
> > Amardeep Singh Jhajj
> > http://www.hotwaxsystems.com/
> >
>

[jira] [Created] (OFBIZ-7362) Add paginate target to list forms to fix the pagination error

Amardeep Singh Jhajj created OFBIZ-7362:
---

 Summary: Add paginate target to list forms to fix the pagination 
error
 Key: OFBIZ-7362
 URL: https://issues.apache.org/jira/browse/OFBIZ-7362
 Project: OFBiz
  Issue Type: Bug
  Components: content
Affects Versions: Trunk
Reporter: Amardeep Singh Jhajj
Assignee: Amardeep Singh Jhajj


I found issue in pagination on some screens when we do any operation (like 
update, delete) on list item.

For example: I have updated the content type from list in Content Setup Menu in 
Content application and then clicked on next link of pagination, I got the 
following error:
{code}
The Following Errors Occurred:
Error calling event: org.ofbiz.webapp.event.EventHandlerException: Found URL 
parameter [contentTypeId] passed to secure (https) request-map with uri 
[updateContentType] with an event that calls service [updateContentType]; this 
is not allowed for security reasons!
{code}
The above error is unexpected as I just tried to see next list records of 
ContentType. The reason of error is pagination URL which is same as URL of page 
i.e. updateContentType. This URL is the update operation URL and it is not 
redirected to appropriate page after operation.

Pagination target URL should be independent of page URL and it should be added 
on form using paginate-target attribute of form widget.

This is a parent ticket and child tickets will be added in it for components.



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

[jira] [Created] (OFBIZ-7361) Catalog : Product Store Group from Product Store Group List item is not being open.

2016-06-16 Thread Rahul bhammarker (JIRA)

Rahul bhammarker created OFBIZ-7361:
---

 Summary: Catalog : Product Store Group from Product Store Group 
List item is not being open.
 Key: OFBIZ-7361
 URL: https://issues.apache.org/jira/browse/OFBIZ-7361
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Trunk
Reporter: Rahul bhammarker
Assignee: Aman Agrawal
Priority: Minor


Steps to generate:
Click on Catalog -> Product Store Groups -> click on any item from the list



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

Re: Proposal to delete stale java files

Hi Divesh and everyone,

Nicely summarized, thank you for your input.

I don't have any strong opinion on how to structure things. The important
thing for me whatever you decide to do is the following:

1- Keep dead / irrelevant code away from the framework and core applications
2- Keep peripheral or non-core functionality away from framework and core
applications.
3- In the case of non-compiling / broken / missing dependencies code
highlight this issue somewhere visible to the programmer (README,
whatever). Why is this important? Because we need to tell our build scripts
and our classpath settings to ignore these files.

The reason why I suggested to keep all of them in
/reference/each-component-name-here is to tell the build system to ignore
all Java files found in /specialpurpose/reference. If you instead break it
up into multiple components, then I need to ignore the files in each
component by hand which makes the build script more complex and more prone
to human error and it would add to the confusion.

So, although I still prefer to have one place for all non-compiling code,
if you can satisfy the above mentioned items, then at least we have a
middle ground even though the build scripts and classpath settings will be
more complex.

Regards,

Taher Alkhateeb

On Thu, Jun 16, 2016 at 1:24 PM, Divesh Dutta <
divesh.du...@hotwaxsystems.com> wrote:

> Thanks Pierre and Jacques for your views. I agree with Jacques that we
> should not create new repos and I agree with Pierre that code can be
> logically grouped based on business functionality.
>
> So there are two views going on:
>
> 1) Initially Taher was suggesting to remove all the codes and then when we
> discussed that there are lots of users who are using those codes, he
> suggested to create specialpurpose/reference component for non-compiling
> code and rest in their own components.
>
>
> 2)  Create components in special purpose for each logical business
> functionality. So for eg: Payment integration specific codes can be in new
> component. Shipment integration code can be in its own component. This way
> we will logically group the business purpose specific codes  and they can
> be further used as addons in future.
>
>
> So it seems that most of the code which are non-compilable are candidate of
> new components (for eg: tax integration, payment integration etc. ). And
> there are less java files which are non-compilable. Some code (java files)
> which are compilable can also be new component for eg: shipping
> integration. And all these can be separate addons in future when we have
> the architecture support for it. There is no such code which is
> non-compilable and not a candidate new component and that code will have to
> sit inside OFBiz (either in framework of applications.)
>
> So I think we can go with #2 where we can also add details in read me file
> of these components that which files of the components are dependent on
> which jars etc.
>
>
> Thanks
> --
> Divesh Dutta.
>
>
>
>
>
>
>
> On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > As Ashish and some others mentioned, those are still needed by some of
> our
> > users.
> > Of course we need to maintain them (logically more those who are
> > interested) but we can't neglect our users based on code
> > cleaning/refactoring.
> > And if we mix all in a ball of mud it, the cost of maintaining it will be
> > increased. So agree with you on this part Pierre, and we need 1st to
> > separate things surgically and then decide about the parts.
> >
> > But, I don't like the idea of having them in "repos" (I guess you  svn
> > branches or GitHub repo/branches?) because they would be disconnected.
> > I still can remember the effect of dropping the specialpurpose component,
> > but ecommerce, in R13.07 (OK they were still in svn, see?)
> > I mean once things are disconnected, and as long as we don't have a
> > good/fast/reliable technical way to connect them, they tend to be
> forgotten
> > (see what we initially discuss here), not maintained and finally garbage.
> >
> > On the other hand, as soon as we will have a solid way to support addons,
> > those will be perfect addons.
> > And no, I'm not speaking out of thin air, we (PMC) are currently
> > discussing about deep modifications in the project which should help
> > support, creation and adoption of addons (hint: look at Moqui, though we
> > don't want to incorporate Moqui framework)
> > Of course it's not for tomorrow, but we need to take time to decide on
> > crucial choices.
> >
> > As I said already dropping the bathwater with the baby is not a solution
> :)
> >
> > Jacques
> >
> >
> >
> > Le 16/06/2016 à 10:56, Pierre Smits a écrit :
> >
> >> I suggest that we do not put code in a new catch all component
> (reference)
> >> for just the mere purpose of preserving it. All code elements are
> related
> >> to a set specific business functionality. I'd rather see that each has
> its
> >> own

Re: Proposal to delete stale java files

2016-06-16 Thread Divesh Dutta

Thanks Pierre and Jacques for your views. I agree with Jacques that we
should not create new repos and I agree with Pierre that code can be
logically grouped based on business functionality.

So there are two views going on:

1) Initially Taher was suggesting to remove all the codes and then when we
discussed that there are lots of users who are using those codes, he
suggested to create specialpurpose/reference component for non-compiling
code and rest in their own components.

2)  Create components in special purpose for each logical business
functionality. So for eg: Payment integration specific codes can be in new
component. Shipment integration code can be in its own component. This way
we will logically group the business purpose specific codes  and they can
be further used as addons in future.

So it seems that most of the code which are non-compilable are candidate of
new components (for eg: tax integration, payment integration etc. ). And
there are less java files which are non-compilable. Some code (java files)
which are compilable can also be new component for eg: shipping
integration. And all these can be separate addons in future when we have
the architecture support for it. There is no such code which is
non-compilable and not a candidate new component and that code will have to
sit inside OFBiz (either in framework of applications.)

So I think we can go with #2 where we can also add details in read me file
of these components that which files of the components are dependent on
which jars etc.

Thanks
--
Divesh Dutta.

On Thu, Jun 16, 2016 at 2:48 PM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> As Ashish and some others mentioned, those are still needed by some of our
> users.
> Of course we need to maintain them (logically more those who are
> interested) but we can't neglect our users based on code
> cleaning/refactoring.
> And if we mix all in a ball of mud it, the cost of maintaining it will be
> increased. So agree with you on this part Pierre, and we need 1st to
> separate things surgically and then decide about the parts.
>
> But, I don't like the idea of having them in "repos" (I guess you  svn
> branches or GitHub repo/branches?) because they would be disconnected.
> I still can remember the effect of dropping the specialpurpose component,
> but ecommerce, in R13.07 (OK they were still in svn, see?)
> I mean once things are disconnected, and as long as we don't have a
> good/fast/reliable technical way to connect them, they tend to be forgotten
> (see what we initially discuss here), not maintained and finally garbage.
>
> On the other hand, as soon as we will have a solid way to support addons,
> those will be perfect addons.
> And no, I'm not speaking out of thin air, we (PMC) are currently
> discussing about deep modifications in the project which should help
> support, creation and adoption of addons (hint: look at Moqui, though we
> don't want to incorporate Moqui framework)
> Of course it's not for tomorrow, but we need to take time to decide on
> crucial choices.
>
> As I said already dropping the bathwater with the baby is not a solution :)
>
> Jacques
>
>
>
> Le 16/06/2016 à 10:56, Pierre Smits a écrit :
>
>> I suggest that we do not put code in a new catch all component (reference)
>> for just the mere purpose of preserving it. All code elements are related
>> to a set specific business functionality. I'd rather see that each has its
>> own component.
>>
>> Also, rather than putting these in the special purpose folder and from
>> there pushing them into releases (where adopters would need to delete them
>> from when they don't want those), I would prefer to see them in separate
>> repos so that the can be developed from there and if need can be
>> integrated
>> in a deployed OFBiz instance at will. That way we create more flexibility
>> for our adopters and enhance the appeal.
>>
>> Best regards,
>>
>> Pierre Smits
>>
>> ORRTIZ.COM 
>> OFBiz based solutions & services
>>
>> OFBiz Extensions Marketplace
>> http://oem.ofbizci.net/oci-2/
>>
>> On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb <
>> slidingfilame...@gmail.com
>>
>>> wrote:
>>> Hi Mridul,
>>>
>>> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
>>> regardless of origin in specialpurpose/reference and the rest in their
>>> own
>>> components.
>>>
>>> Regards,
>>>
>>> -Original Message-
>>> From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com]
>>> Sent: 15 June 2016 14:19
>>> To: dev@ofbiz.apache.org
>>> Cc: Mridul Pathak
>>> Subject: Re: Proposal to delete stale java files
>>>
>>> Hi Taher,
>>>
>>> I would like to make sure that I am understanding your proposal
>>> correctly.
>>>
>>> Are you proposing to create a specialpurpose component named “reference”
>>> which would have all the code that can be referenced but not compiled, no
>>> matter what domain it is?
>>>
>>> If that is the case, we have discussed about moving shipping

[jira] [Assigned] (OFBIZ-7358) In Facility find shipment button doesn't work on first click

2016-06-16 Thread Ashish Vijaywargiya (JIRA)


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

Ashish Vijaywargiya reassigned OFBIZ-7358:
--

Assignee: Ashish Vijaywargiya  (was: Rahul bhammarker)

> In Facility find shipment button doesn't work on first click
> 
>
> Key: OFBIZ-7358
> URL: https://issues.apache.org/jira/browse/OFBIZ-7358
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Aman Agrawal
>Assignee: Ashish Vijaywargiya
>Priority: Minor
> Attachments: OFBIZ-7358.patch
>
>
> Steps to generate:
> Click on Facility --> Shipments --> find button doesn't works on single click.



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

[jira] [Updated] (OFBIZ-7358) In Facility find shipment button doesn't work on first click

2016-06-16 Thread Rahul bhammarker (JIRA)


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

Rahul bhammarker updated OFBIZ-7358:

Attachment: OFBIZ-7358.patch

Fixed issue and patch provided for FindShipment.ftl

> In Facility find shipment button doesn't work on first click
> 
>
> Key: OFBIZ-7358
> URL: https://issues.apache.org/jira/browse/OFBIZ-7358
> Project: OFBiz
>  Issue Type: Bug
>  Components: product
>Affects Versions: Trunk
>Reporter: Aman Agrawal
>Assignee: Rahul bhammarker
>Priority: Minor
> Attachments: OFBIZ-7358.patch
>
>
> Steps to generate:
> Click on Facility --> Shipments --> find button doesn't works on single click.



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

[jira] [Assigned] (OFBIZ-7311) Formatting and renaming of the CSS files as per best practices


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

Pranay Pandey reassigned OFBIZ-7311:


Assignee: Pranay Pandey  (was: Swapnil M Mane)

> Formatting and renaming of the CSS files as per best practices
> --
>
> Key: OFBIZ-7311
> URL: https://issues.apache.org/jira/browse/OFBIZ-7311
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Swapnil M Mane
>Assignee: Pranay Pandey
>Priority: Minor
> Attachments: OFBIZ-7311-bizznesstime.patch, 
> OFBIZ-7311-bluelight.patch, OFBIZ-7311-droppingcrumbs.patch, 
> OFBIZ-7311-flatgrey.patch, OFBIZ-7311-multiflex.patch, 
> OFBIZ-7311-rainbowstone.patch, OFBIZ-7311-renamed-maincss-to-style.patch, 
> OFBIZ-7311-tomahawk.patch
>
>
> In CSS files, we are having various inconsistency in the formatting of the 
> code for e.g. we have following types of code formatting
> // No space
> {code}
> ul#preferences-menu a:hover {
> text-decoration: none;
> }
> {code}
> // Space of 2
> {code}
> div.autocomplete ul {
>   list-style-type:none;
>   margin:0;
>   padding:0;
> }
> {code}
> // Space of 4
> {code}
> .control-area a {
> font-size: 1.1em;
> color: #5CA3D7;
> }
> {code}
> For better readability we should format the existing files with space of 4.
> Also for some theme, we named CSS files as *maincss.css* and for some, we 
> named it as *style.css*. We can rename these file as per best practices for 
> consistency.



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

[jira] [Updated] (OFBIZ-7311) Formatting and renaming of the CSS files as per best practices

2016-06-16 Thread Swapnil M Mane (JIRA)


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

Swapnil M Mane updated OFBIZ-7311:
--
Attachment: OFBIZ-7311-renamed-maincss-to-style.patch

To maintain the consistency, renamed the *maincss.css* to *style.css* (also 
*mainrtl.css* to *stylertl.css*)

This patch is to update the references of files after renaming.
After applying this patch, kindly run the following commands from OFBiz home

svn mv themes/flatgrey/webapp/flatgrey/maincss.css 
themes/flatgrey/webapp/flatgrey/style.css
svn mv themes/flatgrey/webapp/flatgrey/mainrtl.css 
themes/flatgrey/webapp/flatgrey/stylertl.css

svn mv themes/rainbowstone/webapp/rainbowstone/maincss.css 
themes/rainbowstone/webapp/rainbowstone/style.css
svn mv themes/rainbowstone/webapp/rainbowstone/mainrtl.css 
themes/rainbowstone/webapp/rainbowstone/stylertl.css 

> Formatting and renaming of the CSS files as per best practices
> --
>
> Key: OFBIZ-7311
> URL: https://issues.apache.org/jira/browse/OFBIZ-7311
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Swapnil M Mane
>Assignee: Swapnil M Mane
>Priority: Minor
> Attachments: OFBIZ-7311-bizznesstime.patch, 
> OFBIZ-7311-bluelight.patch, OFBIZ-7311-droppingcrumbs.patch, 
> OFBIZ-7311-flatgrey.patch, OFBIZ-7311-multiflex.patch, 
> OFBIZ-7311-rainbowstone.patch, OFBIZ-7311-renamed-maincss-to-style.patch, 
> OFBIZ-7311-tomahawk.patch
>
>
> In CSS files, we are having various inconsistency in the formatting of the 
> code for e.g. we have following types of code formatting
> // No space
> {code}
> ul#preferences-menu a:hover {
> text-decoration: none;
> }
> {code}
> // Space of 2
> {code}
> div.autocomplete ul {
>   list-style-type:none;
>   margin:0;
>   padding:0;
> }
> {code}
> // Space of 4
> {code}
> .control-area a {
> font-size: 1.1em;
> color: #5CA3D7;
> }
> {code}
> For better readability we should format the existing files with space of 4.
> Also for some theme, we named CSS files as *maincss.css* and for some, we 
> named it as *style.css*. We can rename these file as per best practices for 
> consistency.



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

Re: Proposal to delete stale java files


As Ashish and some others mentioned, those are still needed by some of our 
users.
Of course we need to maintain them (logically more those who are interested) 
but we can't neglect our users based on code cleaning/refactoring.
And if we mix all in a ball of mud it, the cost of maintaining it will be increased. So agree with you on this part Pierre, and we need 1st to 
separate things surgically and then decide about the parts.


But, I don't like the idea of having them in "repos" (I guess you  svn branches 
or GitHub repo/branches?) because they would be disconnected.
I still can remember the effect of dropping the specialpurpose component, but 
ecommerce, in R13.07 (OK they were still in svn, see?)
I mean once things are disconnected, and as long as we don't have a good/fast/reliable technical way to connect them, they tend to be forgotten (see 
what we initially discuss here), not maintained and finally garbage.


On the other hand, as soon as we will have a solid way to support addons, those 
will be perfect addons.
And no, I'm not speaking out of thin air, we (PMC) are currently discussing about deep modifications in the project which should help support, 
creation and adoption of addons (hint: look at Moqui, though we don't want to incorporate Moqui framework)

Of course it's not for tomorrow, but we need to take time to decide on crucial 
choices.

As I said already dropping the bathwater with the baby is not a solution :)

Jacques


Le 16/06/2016 à 10:56, Pierre Smits a écrit :

I suggest that we do not put code in a new catch all component (reference)
for just the mere purpose of preserving it. All code elements are related
to a set specific business functionality. I'd rather see that each has its
own component.

Also, rather than putting these in the special purpose folder and from
there pushing them into releases (where adopters would need to delete them
from when they don't want those), I would prefer to see them in separate
repos so that the can be developed from there and if need can be integrated
in a deployed OFBiz instance at will. That way we create more flexibility
for our adopters and enhance the appeal.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb 

wrote:

Hi Mridul,

How about reference/paymentext and reference/whatever-else-you-want?
So the top level directory is called reference to indicate to people
that this is just for reference and will not compile. Also, this way
we keep all reference material under one directory to avoid polluting
the directory tree. My 2 cents.

Regards,

Taher Alkhateeb

On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
mridul.pat...@hotwaxsystems.com >

wrote:

Hi Taher,

Sure, I’ll take care of deleting rest of the files as well.

Also, we could name these specialpurpose component(s) as paymentext,

etc.

and mention in README file that these are extensions to OFBiz and
does not compile directly.

--
Thanks & Regards,
Mridul Pathak
HotWax Systems
http://www.hotwaxsystems.com


On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb


wrote:

Hi Mridul and everyone,

Thank you all for your inputs. May I also ask you Mridul while you
are

at it to delete the rest of the files so the whole task resides with
you to avoid crossing any wires.

Also, I suggest to name that component into something like archives
or

reference and put a README file that says this component does not
compile and it holds this stuff. This way it is easy to isolate that
component from the build system.

Thank you all again for your contributions.

Taher Alkhateeb

-Original Message-
From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com 
mridul.pat...@hotwaxsystems.com>

[jira] [Updated] (OFBIZ-7311) Formatting and renaming of the CSS files as per best practices

2016-06-16 Thread Swapnil M Mane (JIRA)


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

Swapnil M Mane updated OFBIZ-7311:
--
Attachment: OFBIZ-7311-tomahawk.patch
OFBIZ-7311-rainbowstone.patch
OFBIZ-7311-multiflex.patch
OFBIZ-7311-flatgrey.patch
OFBIZ-7311-droppingcrumbs.patch
OFBIZ-7311-bluelight.patch
OFBIZ-7311-bizznesstime.patch

Attaching the patches with respect to each theme for the formatted code.

> Formatting and renaming of the CSS files as per best practices
> --
>
> Key: OFBIZ-7311
> URL: https://issues.apache.org/jira/browse/OFBIZ-7311
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Swapnil M Mane
>Assignee: Swapnil M Mane
>Priority: Minor
> Attachments: OFBIZ-7311-bizznesstime.patch, 
> OFBIZ-7311-bluelight.patch, OFBIZ-7311-droppingcrumbs.patch, 
> OFBIZ-7311-flatgrey.patch, OFBIZ-7311-multiflex.patch, 
> OFBIZ-7311-rainbowstone.patch, OFBIZ-7311-tomahawk.patch
>
>
> In CSS files, we are having various inconsistency in the formatting of the 
> code for e.g. we have following types of code formatting
> // No space
> {code}
> ul#preferences-menu a:hover {
> text-decoration: none;
> }
> {code}
> // Space of 2
> {code}
> div.autocomplete ul {
>   list-style-type:none;
>   margin:0;
>   padding:0;
> }
> {code}
> // Space of 4
> {code}
> .control-area a {
> font-size: 1.1em;
> color: #5CA3D7;
> }
> {code}
> For better readability we should format the existing files with space of 4.
> Also for some theme, we named CSS files as *maincss.css* and for some, we 
> named it as *style.css*. We can rename these file as per best practices for 
> consistency.



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

[jira] [Updated] (OFBIZ-7360) Add functionality to remove CustRequestItem from ordermanager

2016-06-16 Thread Chandan Khandelwal (JIRA)


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

Chandan Khandelwal updated OFBIZ-7360:
--
Attachment: OFBIZ-7360.patch

Patch to add remove functionality for CustRequestItem.

> Add functionality to remove CustRequestItem from ordermanager
> -
>
> Key: OFBIZ-7360
> URL: https://issues.apache.org/jira/browse/OFBIZ-7360
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Chandan Khandelwal
>Assignee: Chandan Khandelwal
> Attachments: OFBIZ-7360.patch, screenshot-1.png
>
>
> # Go to Order  > Requests
> # Create New Request
> # Add Request Item
> There should be a remove link to delete the cust request item (e.g. 
> QuoteItems)



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

[jira] [Commented] (OFBIZ-7327) Sales Invoice PDF doesn't show associated logoImage

2016-06-16 Thread Ankush Upadhyay (JIRA)


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

Ankush Upadhyay commented on OFBIZ-7327:


This issue also exists on other PDF's like return pdf as this is also using 
same CompanyHeader.groovy and companyHeader.fo.ftl.

Steps to reproduce this issue:
1. Set party content with  Logo Image URL content type for Company party.
2. Now try to print invoice, return. logo image does not show.

As per my research, this issue only occurs if  logo image setup from party 
content. According to CompanyHeader.groovy logic, system gives first preference 
to ParyContent logo image and if not found then only use 
partyGroup.logoImageUrl to render over PDF.

I also checked that this functionality working fine over 13.07.

> Sales Invoice PDF doesn't show associated logoImage
> ---
>
> Key: OFBIZ-7327
> URL: https://issues.apache.org/jira/browse/OFBIZ-7327
> Project: OFBiz
>  Issue Type: Bug
>  Components: accounting
>Affects Versions: Trunk
>Reporter: Pierre Smits
>
> When a logo is associated with an internal company and a sales invoice 
> exists, then the logo should be visible in the invoice PDF.



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

[jira] [Updated] (OFBIZ-7360) Add functionality to remove CustRequestItem from ordermanager

2016-06-16 Thread Chandan Khandelwal (JIRA)


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

Chandan Khandelwal updated OFBIZ-7360:
--
Attachment: screenshot-1.png

> Add functionality to remove CustRequestItem from ordermanager
> -
>
> Key: OFBIZ-7360
> URL: https://issues.apache.org/jira/browse/OFBIZ-7360
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Chandan Khandelwal
>Assignee: Chandan Khandelwal
> Attachments: screenshot-1.png
>
>
> # Go to Order  > Requests
> # Create New Request
> # Add Request Item
> There should be a remove link to delete the cust request item (e.g. 
> QuoteItems)



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

[jira] [Created] (OFBIZ-7360) Add functionality to remove CustRequestItem from ordermanager

2016-06-16 Thread Chandan Khandelwal (JIRA)

Chandan Khandelwal created OFBIZ-7360:
-

 Summary: Add functionality to remove CustRequestItem from 
ordermanager
 Key: OFBIZ-7360
 URL: https://issues.apache.org/jira/browse/OFBIZ-7360
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Trunk
Reporter: Chandan Khandelwal
Assignee: Chandan Khandelwal


# Go to Order  > Requests
# Create New Request
# Add Request Item
There should be a remove link to delete the cust request item (e.g. QuoteItems)



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

Re: Proposal to delete stale java files

2016-06-16 Thread Pierre Smits

I suggest that we do not put code in a new catch all component (reference)
for just the mere purpose of preserving it. All code elements are related
to a set specific business functionality. I'd rather see that each has its
own component.

Also, rather than putting these in the special purpose folder and from
there pushing them into releases (where adopters would need to delete them
from when they don't want those), I would prefer to see them in separate
repos so that the can be developed from there and if need can be integrated
in a deployed OFBiz instance at will. That way we create more flexibility
for our adopters and enhance the appeal.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Wed, Jun 15, 2016 at 1:23 PM, Taher Alkhateeb  wrote:

> Hi Mridul,
>
> Ahh I see that makes sense. Yeah sure we put non-compiling stuff
> regardless of origin in specialpurpose/reference and the rest in their own
> components.
>
> Regards,
>
> -Original Message-
> From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com]
> Sent: 15 June 2016 14:19
> To: dev@ofbiz.apache.org
> Cc: Mridul Pathak
> Subject: Re: Proposal to delete stale java files
>
> Hi Taher,
>
> I would like to make sure that I am understanding your proposal correctly.
>
> Are you proposing to create a specialpurpose component named “reference”
> which would have all the code that can be referenced but not compiled, no
> matter what domain it is?
>
> If that is the case, we have discussed about moving shipping integrations
> to specialpurpose component as well, and that code doesn’t have the
> compilation or library reference issues as listed in this thread, so I
> think that should go in it's own component.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 15, 2016, at 3:01 PM, Taher Alkhateeb 
> wrote:
> >
> > Hi Mridul,
> >
> > How about reference/paymentext and reference/whatever-else-you-want?
> > So the top level directory is called reference to indicate to people
> > that this is just for reference and will not compile. Also, this way
> > we keep all reference material under one directory to avoid polluting
> > the directory tree. My 2 cents.
> >
> > Regards,
> >
> > Taher Alkhateeb
> >
> > On Wed, Jun 15, 2016 at 12:27 PM, Mridul Pathak <
> > mridul.pat...@hotwaxsystems.com >
> wrote:
> >
> >> Hi Taher,
> >>
> >> Sure, I’ll take care of deleting rest of the files as well.
> >>
> >> Also, we could name these specialpurpose component(s) as paymentext,
> etc.
> >> and mention in README file that these are extensions to OFBiz and
> >> does not compile directly.
> >>
> >> --
> >> Thanks & Regards,
> >> Mridul Pathak
> >> HotWax Systems
> >> http://www.hotwaxsystems.com
> >>
> >>> On Jun 15, 2016, at 2:37 PM, Taher Alkhateeb
> >>> 
> >> wrote:
> >>>
> >>> Hi Mridul and everyone,
> >>>
> >>> Thank you all for your inputs. May I also ask you Mridul while you
> >>> are
> >> at it to delete the rest of the files so the whole task resides with
> >> you to avoid crossing any wires.
> >>>
> >>> Also, I suggest to name that component into something like archives
> >>> or
> >> reference and put a README file that says this component does not
> >> compile and it holds this stuff. This way it is easy to isolate that
> >> component from the build system.
> >>>
> >>> Thank you all again for your contributions.
> >>>
> >>> Taher Alkhateeb
> >>>
> >>> -Original Message-
> >>> From: Mridul Pathak [mailto:mridul.pat...@hotwaxsystems.com  mridul.pat...@hotwaxsystems.com>  >> mridul.pat...@hotwaxsystems.com
> >> >]
> >>> Sent: 15 June 2016 11:09
> >>> To: dev@ofbiz.apache.org 
> >>> >
> >>> Cc: Mridul Pathak
> >>> Subject: Re: Proposal to delete stale java files
> >>>
> >>> I would like to volunteer for this change (moving payment, shipping
> >>> and
> >> tax integrations to specialpurpose).
> >>>
> >>> --
> >>> Mridul Pathak
> >>>
> >>> On Wednesday 15 June 2016, Jacopo Cappellato <
> >> jacopo.cappell...@hotwaxsystems.com  jacopo.cappell...@hotwaxsystems.com>> wrote:
> >>>
>  Based on the new comments it seems like that we could isolate the
>  shipment, payment and tax integration classes (and artifacts that
>  use
>  them) into their own specialpurpose components (waiting for a
>  better pluggable components architecture); they will not be
>  compiled by default but each component will have its own readme
>  file containing instructions about how to deploy and use them.
>  As regards the JasperReports*, JRE* and openoffice ones I think
>  they can go to Attic since they are old and

Re: Product base promotion calculation

2016-06-16 Thread Arvind singh tomar

Link for the issue: https://issues.apache.org/jira/browse/OFBIZ-7359

On 16 June 2016 at 14:03, Arvind singh tomar 
wrote:

> Thanks for your approval Mridul and Pranay. Also thank you, Jacques for
> your image upload related suggestion :) .
>
> Added a JIRA task and Here is the link for the same.
>
> On 16 June 2016 at 13:51, Pranay Pandey 
> wrote:
>
>> +1 Mridul.
>>
>> Best regards,
>>
>> Pranay Pandey
>> HotWax Systems
>> http://www.hotwaxsystems.com/
>>
>> On Thu, Jun 16, 2016 at 1:32 PM, Mridul Pathak <
>> mridul.pat...@hotwaxsystems.com> wrote:
>>
>> > Hi Arvind,
>> >
>> > While I agree that current behavior can be improved as per your
>> suggestion
>> > but at the same time considering different behaviors of the range of
>> > promotions we have, implementing a proper fix would be tricky. I think a
>> > JIRA ticket can be logged and solution can be discussed over there. If
>> you
>> > have patch available please provide it on the ticket you create.
>> >
>> > --
>> > Thanks & Regards,
>> > Mridul Pathak
>> > Senior Manager
>> > HotWax Systems
>> > http://www.hotwaxsystems.com
>> >
>> > > On Jun 16, 2016, at 12:21 PM, Pranay Pandey <
>> > pranay.pan...@hotwaxsystems.com> wrote:
>> > >
>> > > Hi Arvind,
>> > >
>> > > Yes I agree, If it's the promotion for one product than
>> orderAdjustment
>> > > should also be one. Also please create a JIRA issue and attach your
>> > > screenshots there.
>> > >
>> > >
>> > > Best regards,
>> > >
>> > > Pranay Pandey
>> > > HotWax Systems
>> > > http://www.hotwaxsystems.com/
>> > >
>> > > On Wed, Jun 15, 2016 at 7:16 PM, Arvind singh tomar <
>> > > arvindtomar1...@gmail.com> wrote:
>> > >
>> > >> Hi Everyone,
>> > >>
>> > >> I found the behavior of product base promotion calculation a bit
>> > strange.
>> > >> Need your advice on whether it is correct behaviour or need some
>> > >> improvement in promotion calculation.
>> > >>
>> > >> The promotion which I used was to give 30% discount for the item
>> (i.e.
>> > >> RAM1GB_BRAND). I created a sales order with 10 quantity of the
>> product.
>> > >> During the promotion calculation, OFBiz created 10 OrderAdjustments,
>> one
>> > >> for each quantity for the same promotion type.
>> > >>
>> > >> I was expecting that in the case if same Promotion is applicable for
>> > more
>> > >> than one quantity of a product then a single OrderAdjustment should
>> be
>> > >> created instead of creating one for each quantity. It is also
>> messing up
>> > >> the UI.
>> > >>
>> > >> Attached the screenshots for the same.
>> > >>
>> > >>
>> > >> Thanks and Regards
>> > >> --
>> > >> Arvind Singh Tomar
>> > >>
>> >
>> >
>>
>
>

Re: Product base promotion calculation

2016-06-16 Thread Arvind singh tomar

Thanks for your approval Mridul and Pranay. Also thank you, Jacques for
your image upload related suggestion :) .

Added a JIRA task and Here  is the link for the
same.

On 16 June 2016 at 13:51, Pranay Pandey 
wrote:

> +1 Mridul.
>
> Best regards,
>
> Pranay Pandey
> HotWax Systems
> http://www.hotwaxsystems.com/
>
> On Thu, Jun 16, 2016 at 1:32 PM, Mridul Pathak <
> mridul.pat...@hotwaxsystems.com> wrote:
>
> > Hi Arvind,
> >
> > While I agree that current behavior can be improved as per your
> suggestion
> > but at the same time considering different behaviors of the range of
> > promotions we have, implementing a proper fix would be tricky. I think a
> > JIRA ticket can be logged and solution can be discussed over there. If
> you
> > have patch available please provide it on the ticket you create.
> >
> > --
> > Thanks & Regards,
> > Mridul Pathak
> > Senior Manager
> > HotWax Systems
> > http://www.hotwaxsystems.com
> >
> > > On Jun 16, 2016, at 12:21 PM, Pranay Pandey <
> > pranay.pan...@hotwaxsystems.com> wrote:
> > >
> > > Hi Arvind,
> > >
> > > Yes I agree, If it's the promotion for one product than orderAdjustment
> > > should also be one. Also please create a JIRA issue and attach your
> > > screenshots there.
> > >
> > >
> > > Best regards,
> > >
> > > Pranay Pandey
> > > HotWax Systems
> > > http://www.hotwaxsystems.com/
> > >
> > > On Wed, Jun 15, 2016 at 7:16 PM, Arvind singh tomar <
> > > arvindtomar1...@gmail.com> wrote:
> > >
> > >> Hi Everyone,
> > >>
> > >> I found the behavior of product base promotion calculation a bit
> > strange.
> > >> Need your advice on whether it is correct behaviour or need some
> > >> improvement in promotion calculation.
> > >>
> > >> The promotion which I used was to give 30% discount for the item (i.e.
> > >> RAM1GB_BRAND). I created a sales order with 10 quantity of the
> product.
> > >> During the promotion calculation, OFBiz created 10 OrderAdjustments,
> one
> > >> for each quantity for the same promotion type.
> > >>
> > >> I was expecting that in the case if same Promotion is applicable for
> > more
> > >> than one quantity of a product then a single OrderAdjustment should be
> > >> created instead of creating one for each quantity. It is also messing
> up
> > >> the UI.
> > >>
> > >> Attached the screenshots for the same.
> > >>
> > >>
> > >> Thanks and Regards
> > >> --
> > >> Arvind Singh Tomar
> > >>
> >
> >
>

[jira] [Assigned] (OFBIZ-5636) Add WorkEffort Timesheet to Invoice or to New Invoice does not work

2016-06-16 Thread Avnindra Sharma (JIRA)


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

Avnindra Sharma reassigned OFBIZ-5636:
--

Assignee: Avnindra Sharma

> Add WorkEffort Timesheet to Invoice or to New Invoice does not work
> ---
>
> Key: OFBIZ-5636
> URL: https://issues.apache.org/jira/browse/OFBIZ-5636
> Project: OFBiz
>  Issue Type: Bug
>  Components: workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
> Environment: Windows
>Reporter: Ahmad Ludin
>Assignee: Avnindra Sharma
>Priority: Minor
>  Labels: WorkEffort, timesheet
>
> In work effort menu, My time, create a time sheet with time entries, then to 
> add the time entries to an existing Invoice or a New invoice throws the 
> following error.  Note: Time entries to invoice from scrum and projectmgr 
> application works.
> Error running the simple-method: Entity value not found with name: workEffort 
> Method = createTimeEntryInvoiceItemsInline, File = 
> file:/applications/workeffort/script/org/ofbiz/workeffort/timesheet/TimesheetServices.xml,
>  Element = , Line 160null



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

[jira] [Updated] (OFBIZ-7359) Product base promotion calculation

2016-06-16 Thread Arvind Singh Tomar (JIRA)


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

Arvind Singh Tomar updated OFBIZ-7359:
--
Attachment: Promotion1.png
Promotion2.png

> Product base promotion calculation
> --
>
> Key: OFBIZ-7359
> URL: https://issues.apache.org/jira/browse/OFBIZ-7359
> Project: OFBiz
>  Issue Type: Improvement
>  Components: order
>Affects Versions: Trunk
>Reporter: Arvind Singh Tomar
>Priority: Minor
> Attachments: Promotion1.png, Promotion2.png
>
>
> I found the behavior of product base promotion calculation a bit strange. Any 
> further insights into the issue would be very helpful.
> The promotion which I used was to give 30% discount for the item (i.e. 
> RAM1GB_BRAND). I created a sales order with 10 quantity of the product. 
> During the promotion calculation, OFBiz created 10 OrderAdjustments, one for 
> each quantity for the same promotion type.
> I was expecting that in the case if same Promotion is applicable for more 
> than one quantity of a product then a single OrderAdjustment should be 
> created instead of creating one for each quantity. It is also messing up the 
> UI.



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

[jira] [Created] (OFBIZ-7359) Product base promotion calculation

2016-06-16 Thread Arvind Singh Tomar (JIRA)

Arvind Singh Tomar created OFBIZ-7359:
-

 Summary: Product base promotion calculation
 Key: OFBIZ-7359
 URL: https://issues.apache.org/jira/browse/OFBIZ-7359
 Project: OFBiz
  Issue Type: Improvement
  Components: order
Affects Versions: Trunk
Reporter: Arvind Singh Tomar
Priority: Minor


I found the behavior of product base promotion calculation a bit strange. Any 
further insights into the issue would be very helpful.

The promotion which I used was to give 30% discount for the item (i.e. 
RAM1GB_BRAND). I created a sales order with 10 quantity of the product. During 
the promotion calculation, OFBiz created 10 OrderAdjustments, one for each 
quantity for the same promotion type.

I was expecting that in the case if same Promotion is applicable for more than 
one quantity of a product then a single OrderAdjustment should be created 
instead of creating one for each quantity. It is also messing up the UI.



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

Re: Product base promotion calculation

2016-06-16 Thread Pranay Pandey

+1 Mridul.

Best regards,

Pranay Pandey
HotWax Systems
http://www.hotwaxsystems.com/

On Thu, Jun 16, 2016 at 1:32 PM, Mridul Pathak <
mridul.pat...@hotwaxsystems.com> wrote:

> Hi Arvind,
>
> While I agree that current behavior can be improved as per your suggestion
> but at the same time considering different behaviors of the range of
> promotions we have, implementing a proper fix would be tricky. I think a
> JIRA ticket can be logged and solution can be discussed over there. If you
> have patch available please provide it on the ticket you create.
>
> --
> Thanks & Regards,
> Mridul Pathak
> Senior Manager
> HotWax Systems
> http://www.hotwaxsystems.com
>
> > On Jun 16, 2016, at 12:21 PM, Pranay Pandey <
> pranay.pan...@hotwaxsystems.com> wrote:
> >
> > Hi Arvind,
> >
> > Yes I agree, If it's the promotion for one product than orderAdjustment
> > should also be one. Also please create a JIRA issue and attach your
> > screenshots there.
> >
> >
> > Best regards,
> >
> > Pranay Pandey
> > HotWax Systems
> > http://www.hotwaxsystems.com/
> >
> > On Wed, Jun 15, 2016 at 7:16 PM, Arvind singh tomar <
> > arvindtomar1...@gmail.com> wrote:
> >
> >> Hi Everyone,
> >>
> >> I found the behavior of product base promotion calculation a bit
> strange.
> >> Need your advice on whether it is correct behaviour or need some
> >> improvement in promotion calculation.
> >>
> >> The promotion which I used was to give 30% discount for the item (i.e.
> >> RAM1GB_BRAND). I created a sales order with 10 quantity of the product.
> >> During the promotion calculation, OFBiz created 10 OrderAdjustments, one
> >> for each quantity for the same promotion type.
> >>
> >> I was expecting that in the case if same Promotion is applicable for
> more
> >> than one quantity of a product then a single OrderAdjustment should be
> >> created instead of creating one for each quantity. It is also messing up
> >> the UI.
> >>
> >> Attached the screenshots for the same.
> >>
> >>
> >> Thanks and Regards
> >> --
> >> Arvind Singh Tomar
> >>
>
>

[jira] [Updated] (OFBIZ-7324) From facility location should be product based in stock move form.

2016-06-16 Thread Montalbano Florian (JIRA)


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

Montalbano Florian updated OFBIZ-7324:
--
Attachment: OFBIZ-7324_tryV2.patch

Hi [~deepak.dixit],
sorry for the duplicate work but given that I'm new to OFBiz, I think it's a 
good experience for me to try to provide some patch while following your work.

I used the work proposed in OFBIZ-7350 to provide the filtering on the 
auto-completion of the product location based on the product id given.

There are some changes that I'm unsure of :
- The auto-completion calls the service 
StockMoveServices#findProductInventorylocations , so I modified it to do a 
"like" operator check on the field 'locationSeqId'. I feel that modifying this 
service may have not been appropriated. What is the good way ?

- The screen LookupScreens.xml#LookupProductInventoryLocation now support call 
with an undefined 'parameters.productId', answering with a more user-friendly 
error message. In this same screen, I used the field 'conditionFields' to 
filter the auto-completion but I didn't find this way of doing thing in another 
part of OFBiz, so I'm wondering if it is ok.

Please give me your thought about this patch. I tried to apply it on a clean 
trunk and it works (for the Move stock problem only (for now)). But it still 
doesn't work on other form that could benefit from it (LookupQuoteItem).

> From facility location should be product based in stock move form.
> --
>
> Key: OFBIZ-7324
> URL: https://issues.apache.org/jira/browse/OFBIZ-7324
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Attachments: OFBIZ-7324_try.patch, OFBIZ-7324_tryV2.patch
>
>
> From facility location should be product based in stock move form.



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

Re: Product base promotion calculation