date:20141023


On 23/10/2014 11:33 AM, Jacques Le Roux wrote:


Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 wrote:


I agree about the idea, but this applies only to releases or 
checked out code. Because there are no ways for users to 
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand the 
meaning of it.


Your idea of disabling some specialpurpose component can't be 
applied in R13.07 demo until we decide which component should be 
disabled in trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.


Actually the specialpurpose components are in the R13.07 demos because 
they can be there. But they are not maintained in the R13.07 branch 
(but ecommerce) only in trunk.


As you can guess, I am troubled about the relation between releases 
and the trunk and demos in OFBiz.


Would you prefer to not have the specialpurpose components in R13.07 
demo?


If they are not in the 13.07.01 release it creates a bit of a mismatch 
between the demo and what you actually get.

Otherwise I would have no problem.

Ron



It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download 
and carries whatever warranty that the project offers in terms of 
testing and rapidity of bug fixes and the trunk is usually called 
something that includes"nightly build" and "unstable" in the name and 
comes with no warranty and a warning about using it at your own risk.


Demos should be of the latest release and should be stable and have a 
fixed functionality that can be documented in the wiki and marketing 
pages.


They are, just that they use the branch instead of the packaged 
releases.  For R13.07 (current stable) there is an exception, because 
I thought it was better to have the specialpurpose components 
available. This is what Jacopo contests


It could be maintained by the documentation team once it is set up 
since it should not require any technical skills to keep working and 
fed with demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as 
they require and can support  to be sure that the trunk still works 
but this should not be the public demo or even be called a "demo".


It's also, there are no official mention of the trunk demo, it's only 
a developers thing.




Of course, this only works if a release is actually a Release and the 
team stands behind it and uses it when establishing new customers.


We have no customers, only users

Jacques



Does anyone have an opinion about the gap between 13.07.01 and what 
the main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it 
would be possible to use the official Release as the actual release?




I hope it's more clear

Jacques



Thanks,

Jacopo











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

Re: Theme bootstrap

2014-10-23 Thread Florient


Hi Julien, Adrian, Community,

Le 23/10/2014 08:46, Adrian Crum a écrit :

On 10/23/2014 7:12 AM, Julien NICOLAS wrote:

For this point I suggest to work on this way : Create tool to delegate
HTML widget structure (and other structure) into theme framework.
To be clear, I suggest to not integrate bootstrap only but modify the
framework to allow any other HTML/CSS frameworks integration without
modifying the OFBiz framework.
But we'll do it for bootstrap first.



You don't need to modify the framework. The screen widgets allow you 
to substitute alternate macros for the rendering engine. See 
widget.properties.



Adrian Crum


correct me if I'm wrong,
but if we use widget's properties, we will not be able to provide a 
hot-swap between them, except by creating new output type.
It sounds like duplicate each actual view-map definition using 'screen' 
type to the new one, as the CSV rendering.
or am I missing the way that widget allow us to substitute macros 
rendering ?


Regards,
Florient.

Re: specialpurpose in R13.07 demo


On 23/10/2014 3:32 PM, Jacques Le Roux wrote:

Le 23/10/2014 19:52, Ron Wheeler a écrit :
I don't think that I was implying that in the point that I was trying 
to make.


It is my theory that the way that this project deals with the 
releases and the trunk is directly related to the fact that most of 
the people involved have customers for whom they fork the OFBiz 
system and deliver a forked version to which they apply patches and 
improvements when they get applied to the trunk rather than using the 
official release as a base for their deliverables.


Actually I believe more and more OFBiz service providers rely on one 
of the release branches, less and less the trunk HEAD.


One would think that this would generate a lot of support for backporting.




But yes, there are also maybe few OFBiz service providers who start 
with a static packaged releases for a client custom project.
Thought it's far easier to svn update a release branch where bug fixes 
are "routinely" backported by committers than to muck around with 
patches to apply on a static packaged releases or anything else static 
(static meaning here with no connection with the OFBiz svn repo).


This is actually even true for anybody working from OFBiz.

Jacques



This may appear to work but I think that it hurts the project and 
probably has a negative effect on the overall profitability of the 
OFBiz market served by these companies.


Ron


On 23/10/2014 12:33 PM, Pierre @GMail wrote:
The others participating in this project ( with and without 
customers are of no importance?


Regards,

Pierre

Sent from my iPhone

On 23 okt. 2014, at 18:04, Ron Wheeler 
 wrote:



On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 wrote:


I agree about the idea, but this applies only to releases or 
checked out code. Because there are no ways for users to 
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand 
the meaning of it.
Your idea of disabling some specialpurpose component can't be 
applied in R13.07 demo until we decide which component should be 
disabled in trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available 
in R13.07 demo)

If they are in the demo they should be in the release.
Actually the specialpurpose components are in the R13.07 demos 
because they can be there. But they are not maintained in the 
R13.07 branch (but ecommerce) only in trunk.


As you can guess, I am troubled about the relation between 
releases and the trunk and demos in OFBiz.
Would you prefer to not have the specialpurpose components in 
R13.07 demo?


It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended 
download and carries whatever warranty that the project offers in 
terms of testing and rapidity of bug fixes and the trunk is 
usually called something that includes"nightly build" and 
"unstable" in the name and comes with no warranty and a warning 
about using it at your own risk.


Demos should be of the latest release and should be stable and 
have a fixed functionality that can be documented in the wiki and 
marketing pages.
They are, just that they use the branch instead of the packaged 
releases.  For R13.07 (current stable) there is an exception, 
because I thought it was better to have the specialpurpose 
components available. This is what Jacopo contests


It could be maintained by the documentation team once it is set 
up since it should not require any technical skills to keep 
working and fed with demo data.



If the developers need a test site based on the nightly build, 
they should be free to set up as many combinations of 
configurations as they require and can support  to be sure that 
the trunk still works but this should not be the public demo or 
even be called a "demo".
It's also, there are no official mention of the trunk demo, it's 
only a developers thing.


Of course, this only works if a release is actually a Release and 
the team stands behind it and uses it when establishing new 
customers.

We have no customers, only users

The PMC members have the customers to whom I was referring.


Jacques

Does anyone have an opinion about the gap between 13.07.01 and 
what the main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where 
it would be possible to use the official Release as the actual 
release?



I hope it's more clear

Jacques


Thanks,

Jacopo


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









--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.c

Re: svn commit: r1632760 - in /ofbiz/branches/release13.07/applications: order/webapp/ordermgr/WEB-INF/actions/entry/catalog/ order/webapp/ordermgr/entry/catalog/ product/servicedef/ product/src/org/o

2014-10-23 Thread Ashish Vijaywargiya

Hello Gil, 

I will get back to this conversation in next week. Thanks!

--
Ashish

- gil portenseigne  wrote:
| I ashish,
| 
| Is there a reason to introduce these imports in : CategoryServices.java, 
| these might be remains of devel
| 
|   import java.io.Writer;
| +import java.math.BigDecimal;
|   import java.sql.Timestamp;
| +import java.util.ArrayList;
|   import java.util.List;
| 
| [...]
| 
|   import org.ofbiz.entity.util.EntityListIterator;
| +import org.ofbiz.entity.util.EntityTypeUtil;
|   import org.ofbiz.entity.util.EntityUtil;
| [...]
| +import org.ofbiz.service.GenericServiceException;
| 
| My eclipse tell me they are no use here :).
| 
| Not so important i guess, but to have less import is better.
| 
| Other thing is formatting where you remove an empty line for spaces :
| 
| @@ -237,7 +245,7 @@ public class CategoryServices {
|   }
|   
|   Timestamp nowTimestamp = UtilDateTime.nowTimestamp();
| -
| +
|   int viewIndex = 0;
|   try {
| 
| 
| Best Regards
| 
| Gil
| 
| Le 18/10/2014 13:23, ash...@apache.org a écrit :
| > Author: ashish
| > Date: Sat Oct 18 11:23:45 2014
| > New Revision: 1632760
| >
| > URL: http://svn.apache.org/r1632760
| > Log:
| > Applied bug fix from trunk r1632750.
| > ===
| > Applied patch from jira issue - OFBIZ-4528 - Out of stock products screw up 
the pagination during category browsing.
| > ===
| > Pagination is handled in getProductCategoryAndLimitedMembers
| > Then the out of stock filtering is done in CategoryDetail.groovy.
| > Hence the pagination is screwed up. Certain pages might show less records 
or no records based upon data condition.
| > ===
| > Thanks Arun for the contribution and Thanks Kiran for creating the issue.
| >
| > Modified:
| >  
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
| >  
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl
| >  
ofbiz/branches/release13.07/applications/product/servicedef/services_view.xml
| >  
ofbiz/branches/release13.07/applications/product/src/org/ofbiz/product/category/CategoryServices.java
| >  
ofbiz/branches/release13.07/applications/product/src/org/ofbiz/product/product/ProductWorker.java
| >
| > Modified: 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
| > URL: 
http://svn.apache.org/viewvc/ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy?rev=1632760&r1=1632759&r2=1632760&view=diff
| > 
==
| > --- 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
 (original)
| > +++ 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
 Sat Oct 18 11:23:45 2014
| > @@ -54,52 +54,20 @@ andMap = [productCategoryId : productCat
| >   limitView : limitView];
| >   andMap.put("prodCatalogId", currentCatalogId);
| >   andMap.put("checkViewAllow", true);
| > +// Prevents out of stock product to be displayed on site
| > +productStore = ProductStoreWorker.getProductStore(request);
| > +if (productStore) {
| > +andMap.put("productStoreId", productStore.productStoreId);
| > +}
| >   if (context.orderByFields) {
| >   andMap.put("orderByFields", context.orderByFields);
| >   } else {
| >   andMap.put("orderByFields", ["sequenceNum", "productId"]);
| >   }
| >   catResult = dispatcher.runSync("getProductCategoryAndLimitedMembers", 
andMap);
| > -
| >   productCategory = catResult.productCategory;
| >   productCategoryMembers = catResult.productCategoryMembers;
| > -
| > -// Prevents out of stock product to be displayed on site
| > -productStore = ProductStoreWorker.getProductStore(request);
| > -if(productStore) {
| > -if("N".equals(productStore.showOutOfStockProducts)) {
| > -productsInStock = [];
| > -productCategoryMembers.each { productCategoryMember ->
| > -product = delegator.findOne("Product", [productId : 
productCategoryMember.productId], true);
| > -boolean isMarketingPackage = 
EntityTypeUtil.hasParentType(delegator, "ProductType", "productTypeId", 
product.productTypeId, "parentTypeId", "MARKETING_PKG");
| > -context.isMarketingPackage = (isMarketingPackage? "true": 
"false");
| > -if (isMarketingPackage) {
| > -resultOutput = 
dispatcher.runSync("getMktgPackagesAvailable", [productId : 
productCategoryMember.productId]);
| > -availableInventory = resultOutput.availableToPromiseTotal;
| > -if(availableInventory > 0) {
| > -

Re: specialpurpose in R13.07 demo


Le 23/10/2014 19:52, Ron Wheeler a écrit :

I don't think that I was implying that in the point that I was trying to make.

It is my theory that the way that this project deals with the releases and the trunk is directly related to the fact that most of the people 
involved have customers for whom they fork the OFBiz system and deliver a forked version to which they apply patches and improvements when they get 
applied to the trunk rather than using the official release as a base for their deliverables.


Actually I believe more and more OFBiz service providers rely on one of the 
release branches, less and less the trunk HEAD.

But yes, there are also maybe few OFBiz service providers who start with a 
static packaged releases for a client custom project.
Thought it's far easier to svn update a release branch where bug fixes are "routinely" backported by committers than to muck around with patches to 
apply on a static packaged releases or anything else static (static meaning here with no connection with the OFBiz svn repo).


This is actually even true for anybody working from OFBiz.

Jacques



This may appear to work but I think that it hurts the project and probably has a negative effect on the overall profitability of the OFBiz market 
served by these companies.


Ron


On 23/10/2014 12:33 PM, Pierre @GMail wrote:

The others participating in this project ( with and without customers are of no 
importance?

Regards,

Pierre

Sent from my iPhone


On 23 okt. 2014, at 18:04, Ron Wheeler  wrote:


On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux  
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a 
component in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of 
it.

Your idea of disabling some specialpurpose component can't be applied in R13.07 
demo until we decide which component should be disabled in trunk.
In the meantime we should keep the current state (ie all specialpurpose 
components present in trunk should be available in R13.07 demo)

If they are in the demo they should be in the release.
Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but 
ecommerce) only in trunk.



As you can guess, I am troubled about the relation between releases and the 
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries 
whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that 
includes"nightly build" and "unstable" in the name and comes with no warranty and a warning about using it at your own risk.


Demos should be of the latest release and should be stable and have a fixed 
functionality that can be documented in the wiki and marketing pages.
They are, just that they use the branch instead of the packaged releases.  For R13.07 (current stable) there is an exception, because I thought 
it was better to have the specialpurpose components available. This is what Jacopo contests


It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with 
demo data.



If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they 
require and can support  to be sure that the trunk still works but this should not be the public demo or even be called a "demo".

It's also, there are no official mention of the trunk demo, it's only a 
developers thing.


Of course, this only works if a release is actually a Release and the team 
stands behind it and uses it when establishing new customers.

We have no customers, only users

The PMC members have the customers to whom I was referring.


Jacques


Does anyone have an opinion about the gap between 13.07.01 and what the main SI 
companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it would be 
possible to use the official Release as the actual release?


I hope it's more clear

Jacques


Thanks,

Jacopo


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

Re: svn commit: r1632793 - in /ofbiz/trunk/framework: common/widget/HelpScreens.xml resources/templates/CommonScreens.xml

2014-10-23 Thread Ashish Vijaywargiya

Thanks Jacques. :-)

Happy Diwali...!!!

--
Ashish

- Jacques Le Roux  wrote:
| Yes sure Ashish, I understand, have a good Diwali :)
| 
| Thanks to care
| 
| Jacques
| 
| Le 23/10/2014 20:27, Ashish Vijaywargiya a écrit :
| > Please give us some time. We will get back to this conversation in next 
week. Thanks!
| >
| > --
| > Ashish
| >
| >
| > - Jacques Le Roux  wrote:
| > | Is somebody taking care of that? Is it a real issue?
| > |
| > | Jacques
| > |
| > | Le 18/10/2014 16:32, Adrian Crum a écrit :
| > | > I don't think we need to change the component templates. This is a 
regression - components created with the ant target will not function properly.
| > | >
| > | > Adrian Crum
| > | > Sandglass Software
| > | > www.sandglass-software.com
| > | >
| > | > On 10/18/2014 3:11 PM, apa...@apache.org wrote:
| > | >> Author: apatel
| > | >> Date: Sat Oct 18 14:11:50 2014
| > | >> New Revision: 1632793
| > | >>
| > | >> URL: http://svn.apache.org/r1632793
| > | >> Log:
| > | >> [OFBIZ-3329] Removing framework code on resources in commonext.
| > | >> Thanks Divesh and Mridul for helping with resuluation.
| > | >> Thanks Adrian for reporting it.
| > | >> Thanks Chris Snow for reporting the issue
| > | >>
| > | >> Modified:
| > | >>  ofbiz/trunk/framework/common/widget/HelpScreens.xml
| > | >>  ofbiz/trunk/framework/resources/templates/CommonScreens.xml
| > | >>
| > | >> Modified: ofbiz/trunk/framework/common/widget/HelpScreens.xml
| > | >> URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/HelpScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
| > | >> 
==
| > | >> --- ofbiz/trunk/framework/common/widget/HelpScreens.xml (original)
| > | >> +++ ofbiz/trunk/framework/common/widget/HelpScreens.xml Sat Oct 18 
14:11:50 2014
| > | >> @@ -25,7 +25,6 @@ under the License.
| > | >>   
| > | >>   
| > | >>   
| > | >> -
| > | >>   
| > | >>   
| > | >>   
| > | >>
| > | >> Modified: ofbiz/trunk/framework/resources/templates/CommonScreens.xml
| > | >> URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/resources/templates/CommonScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
| > | >> 
==
| > | >> --- ofbiz/trunk/framework/resources/templates/CommonScreens.xml 
(original)
| > | >> +++ ofbiz/trunk/framework/resources/templates/CommonScreens.xml Sat 
Oct 18 14:11:50 2014
| > | >> @@ -17,7 +17,7 @@
| > | >>   
| > | >>   
| > | >>   
| > | >> -
| > | >> +
| > | >>   
| > | >>   
| > | >>   
| > | >>
| > | >>
| > | >
| >
| >
| >

Re: svn commit: r1632793 - in /ofbiz/trunk/framework: common/widget/HelpScreens.xml resources/templates/CommonScreens.xml


Yes sure Ashish, I understand, have a good Diwali :)

Thanks to care

Jacques

Le 23/10/2014 20:27, Ashish Vijaywargiya a écrit :

Please give us some time. We will get back to this conversation in next week. 
Thanks!

--
Ashish


- Jacques Le Roux  wrote:
| Is somebody taking care of that? Is it a real issue?
|
| Jacques
|
| Le 18/10/2014 16:32, Adrian Crum a écrit :
| > I don't think we need to change the component templates. This is a 
regression - components created with the ant target will not function properly.
| >
| > Adrian Crum
| > Sandglass Software
| > www.sandglass-software.com
| >
| > On 10/18/2014 3:11 PM, apa...@apache.org wrote:
| >> Author: apatel
| >> Date: Sat Oct 18 14:11:50 2014
| >> New Revision: 1632793
| >>
| >> URL: http://svn.apache.org/r1632793
| >> Log:
| >> [OFBIZ-3329] Removing framework code on resources in commonext.
| >> Thanks Divesh and Mridul for helping with resuluation.
| >> Thanks Adrian for reporting it.
| >> Thanks Chris Snow for reporting the issue
| >>
| >> Modified:
| >>  ofbiz/trunk/framework/common/widget/HelpScreens.xml
| >>  ofbiz/trunk/framework/resources/templates/CommonScreens.xml
| >>
| >> Modified: ofbiz/trunk/framework/common/widget/HelpScreens.xml
| >> URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/HelpScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
| >> 
==
| >> --- ofbiz/trunk/framework/common/widget/HelpScreens.xml (original)
| >> +++ ofbiz/trunk/framework/common/widget/HelpScreens.xml Sat Oct 18 
14:11:50 2014
| >> @@ -25,7 +25,6 @@ under the License.
| >>   
| >>   
| >>   
| >> -
| >>   
| >>   
| >>   
| >>
| >> Modified: ofbiz/trunk/framework/resources/templates/CommonScreens.xml
| >> URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/resources/templates/CommonScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
| >> 
==
| >> --- ofbiz/trunk/framework/resources/templates/CommonScreens.xml (original)
| >> +++ ofbiz/trunk/framework/resources/templates/CommonScreens.xml Sat Oct 18 
14:11:50 2014
| >> @@ -17,7 +17,7 @@
| >>   
| >>   
| >>   
| >> -
| >> +
| >>   
| >>   
| >>   
| >>
| >>
| >

Re: svn commit: r1632793 - in /ofbiz/trunk/framework: common/widget/HelpScreens.xml resources/templates/CommonScreens.xml

2014-10-23 Thread Ashish Vijaywargiya

Please give us some time. We will get back to this conversation in next week. 
Thanks!

--
Ashish


- Jacques Le Roux  wrote:
| Is somebody taking care of that? Is it a real issue?
| 
| Jacques
| 
| Le 18/10/2014 16:32, Adrian Crum a écrit :
| > I don't think we need to change the component templates. This is a 
regression - components created with the ant target will not function properly.
| >
| > Adrian Crum
| > Sandglass Software
| > www.sandglass-software.com
| >
| > On 10/18/2014 3:11 PM, apa...@apache.org wrote:
| >> Author: apatel
| >> Date: Sat Oct 18 14:11:50 2014
| >> New Revision: 1632793
| >>
| >> URL: http://svn.apache.org/r1632793
| >> Log:
| >> [OFBIZ-3329] Removing framework code on resources in commonext.
| >> Thanks Divesh and Mridul for helping with resuluation.
| >> Thanks Adrian for reporting it.
| >> Thanks Chris Snow for reporting the issue
| >>
| >> Modified:
| >>  ofbiz/trunk/framework/common/widget/HelpScreens.xml
| >>  ofbiz/trunk/framework/resources/templates/CommonScreens.xml
| >>
| >> Modified: ofbiz/trunk/framework/common/widget/HelpScreens.xml
| >> URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/HelpScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
| >> 
==
| >> --- ofbiz/trunk/framework/common/widget/HelpScreens.xml (original)
| >> +++ ofbiz/trunk/framework/common/widget/HelpScreens.xml Sat Oct 18 
14:11:50 2014
| >> @@ -25,7 +25,6 @@ under the License.
| >>   
| >>   
| >>   
| >> -
| >>   
| >>   
| >>   
| >>
| >> Modified: ofbiz/trunk/framework/resources/templates/CommonScreens.xml
| >> URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/resources/templates/CommonScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
| >> 
==
| >> --- ofbiz/trunk/framework/resources/templates/CommonScreens.xml (original)
| >> +++ ofbiz/trunk/framework/resources/templates/CommonScreens.xml Sat Oct 18 
14:11:50 2014
| >> @@ -17,7 +17,7 @@
| >>   
| >>   
| >>   
| >> -
| >> +
| >>   
| >>   
| >>   
| >>
| >>
| >

Re: specialpurpose in R13.07 demo


On 23/10/2014 1:00 PM, Jacques Le Roux wrote:

Le 23/10/2014 18:04, Ron Wheeler a écrit :

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:


Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 wrote:


I agree about the idea, but this applies only to releases or 
checked out code. Because there are no ways for users to 
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand 
the meaning of it.


Your idea of disabling some specialpurpose component can't be 
applied in R13.07 demo until we decide which component should be 
disabled in trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.


Actually the specialpurpose components are in the R13.07 demos 
because they can be there. But they are not maintained in the R13.07 
branch (but ecommerce) only in trunk.


As you can guess, I am troubled about the relation between releases 
and the trunk and demos in OFBiz.


Would you prefer to not have the specialpurpose components in R13.07 
demo?


It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download 
and carries whatever warranty that the project offers in terms of 
testing and rapidity of bug fixes and the trunk is usually called 
something that includes"nightly build" and "unstable" in the name 
and comes with no warranty and a warning about using it at your own 
risk.


Demos should be of the latest release and should be stable and have 
a fixed functionality that can be documented in the wiki and 
marketing pages.


They are, just that they use the branch instead of the packaged 
releases.  For R13.07 (current stable) there is an exception, 
because I thought it was better to have the specialpurpose 
components available. This is what Jacopo contests


It could be maintained by the documentation team once it is set up 
since it should not require any technical skills to keep working 
and fed with demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as 
they require and can support  to be sure that the trunk still works 
but this should not be the public demo or even be called a "demo".


It's also, there are no official mention of the trunk demo, it's 
only a developers thing.




Of course, this only works if a release is actually a Release and 
the team stands behind it and uses it when establishing new customers.


We have no customers, only users


The PMC members have the customers to whom I was referring.


Please don't mix things. With "We" above I spoke on behalf of the 
OFBiz dev team (ie the committers).
To state it clearly the >

You owe something to a customer, it's your client.
The Apache OFBiz project does not owe anything to its users. You can 
speak around that, but it's a fact, only volunteers work is donated to 
this project. Nobody is paid directly by the ASF or the OFBiz project.


I thought this was quite obvious for everyone (including Pierre which 
is questioning in 2 other emails)


Now as you said indeed PMC members have customers. But that's another 
totally unrelated thing to me.


Sorry that I was not clear when I talked about "team" having customers.
I was referring to those on the PMC that make their living selling 
forked versions of OFBiz to others.

It may not be true for all committers.

Ron



Jacques





Jacques



Does anyone have an opinion about the gap between 13.07.01 and what 
the main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it 
would be possible to use the official Release as the actual release?




I hope it's more clear

Jacques



Thanks,

Jacopo
















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

Re: specialpurpose in R13.07 demo

I don't think that I was implying that in the point that I was trying to
make.

It is my theory that the way that this project deals with the releases
and the trunk is directly related to the fact that most of the people
involved have customers for whom they fork the OFBiz system and deliver
a forked version to which they apply patches and improvements when they
get applied to the trunk rather than using the official release as a
base for their deliverables.

This may appear to work but I think that it hurts the project and
probably has a negative effect on the overall profitability of the OFBiz
market served by these companies.

Ron

On 23/10/2014 12:33 PM, Pierre @GMail wrote:

The others participating in this project ( with and without customers are of no
importance?

Regards,

Pierre

Sent from my iPhone

On 23 okt. 2014, at 18:04, Ron Wheeler wrote:

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux
wrote:

I agree about the idea, but this applies only to releases or checked out code.
Because there are no ways for users to enable/disable a component in demos,
moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

Your idea of disabling some specialpurpose component can't be applied in R13.07
demo until we decide which component should be disabled in trunk.
In the meantime we should keep the current state (ie all specialpurpose
components present in trunk should be available in R13.07 demo)

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can
be there. But they are not maintained in the R13.07 branch (but ecommerce) only
in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

It is a bit odd and certainly goes against most product release strategies wherein the current
release is the recommended download and carries whatever warranty that the project offers in terms
of testing and rapidity of bug fixes and the trunk is usually called something that
includes"nightly build" and "unstable" in the name and comes with no warranty
and a warning about using it at your own risk.

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

They are, just that they use the branch instead of the packaged releases. For
R13.07 (current stable) there is an exception, because I thought it was better
to have the specialpurpose components available. This is what Jacopo contests

It could be maintained by the documentation team once it is set up since it
should not require any technical skills to keep working and fed with demo data.

If the developers need a test site based on the nightly build, they should be free to set
up as many combinations of configurations as they require and can support to be sure
that the trunk still works but this should not be the public demo or even be called a
"demo".

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

The PMC members have the customers to whom I was referring.

Jacques

Does anyone have an opinion about the gap between 13.07.01 and what the main SI
companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it would be
possible to use the official Release as the actual release?

I hope it's more clear

Jacques

Thanks,

Jacopo

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

Re: specialpurpose in R13.07 demo

I was referring to "real" customers that are paying OFBiz contributors
like you, real money to get them set up using OFBiz.

On 23/10/2014 12:30 PM, Pierre @GMail wrote:

Is it a good thing to not regard the ofbiz user as a customer?

Regards,

Pierre

Sent from my iPhone

On 23 okt. 2014, at 17:33, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux
wrote:

I agree about the idea, but this applies only to releases or checked out code.
Because there are no ways for users to enable/disable a component in demos,
moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can
be there. But they are not maintained in the R13.07 branch (but ecommerce) only
in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

It could be maintained by the documentation team once it is set up since it
should not require any technical skills to keep working and fed with demo data.

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

Jacques

I hope it's more clear

Jacques

Thanks,

Jacopo

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

[jira] [Commented] (OFBIZ-5790) Json string parameters as a service input are not recognized by OFBiz ServiceEventHandler.

2014-10-23 Thread Anil K Patel (JIRA)


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

Anil K Patel commented on OFBIZ-5790:
-

Jacopo,
Amardeep is trying to do JSON-RPC.

> Json string parameters as a service input are not recognized by OFBiz 
> ServiceEventHandler.
> --
>
> Key: OFBIZ-5790
> URL: https://issues.apache.org/jira/browse/OFBIZ-5790
> Project: OFBiz
>  Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Amardeep Singh Jhajj
>Priority: Minor
> Attachments: CommonEvents.java.patch, OFBIZ-5790.patch, 
> jackson-annotations-2.4.0.jar, jackson-core-2.4.2.jar, 
> jackson-databind-2.4.2.jar
>
>
> I was trying to pass the Json string as a input to a service, but is not 
> recognized by ServiceEventHandler.
> Example Json String- {"faciltyId": "WebStoreWarehouse"}
> I worked on this issue and attached a patch here. Here I have used Jackson 
> Json library for parsing.



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

Re: specialpurpose in R13.07 demo

Le 23/10/2014 18:04, Ron Wheeler a écrit :

On 23/10/2014 11:33 AM, Jacques Le Roux wrote:

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a
component in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
ecommerce) only in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries
whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that
includes"nightly build" and "unstable" in the name and comes with no warranty and a warning about using it at your own risk.

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

They are, just that they use the branch instead of the packaged releases. For R13.07 (current stable) there is an exception, because I thought it
was better to have the specialpurpose components available. This is what Jacopo contests

It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with
demo data.

If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they
require and can support to be sure that the trunk still works but this should not be the public demo or even be called a "demo".

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

The PMC members have the customers to whom I was referring.

Please don't mix things. With "We" above I spoke on behalf of the OFBiz dev
team (ie the committers).
To state it clearly the <>
You owe something to a customer, it's your client.
The Apache OFBiz project does not owe anything to its users. You can speak around that, but it's a fact, only volunteers work is donated to this
project. Nobody is paid directly by the ASF or the OFBiz project.

I thought this was quite obvious for everyone (including Pierre which is
questioning in 2 other emails)

Now as you said indeed PMC members have customers. But that's another totally
unrelated thing to me.

Jacques

I hope it's more clear

Jacques

Thanks,

Jacopo

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Pierre @GMail

The others participating in this project ( with and without customers are of no 
importance?

Regards,

Pierre

Sent from my iPhone

> On 23 okt. 2014, at 18:04, Ron Wheeler  wrote:
> 
>> On 23/10/2014 11:33 AM, Jacques Le Roux wrote:
>> 
>> Le 23/10/2014 17:11, Ron Wheeler a écrit :
>>> On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
 
 Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
> On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
>  wrote:
> 
>> I agree about the idea, but this applies only to releases or checked out 
>> code. Because there are no ways for users to enable/disable a component 
>> in demos, moreover demos are shared.
> Could you please explain the above sentence? I don't understand the 
> meaning of it.
 
 Your idea of disabling some specialpurpose component can't be applied in 
 R13.07 demo until we decide which component should be disabled in trunk.
 In the meantime we should keep the current state (ie all specialpurpose 
 components present in trunk should be available in R13.07 demo)
>>> 
>>> If they are in the demo they should be in the release.
>> 
>> Actually the specialpurpose components are in the R13.07 demos because they 
>> can be there. But they are not maintained in the R13.07 branch (but 
>> ecommerce) only in trunk.
>> 
>>> As you can guess, I am troubled about the relation between releases and the 
>>> trunk and demos in OFBiz.
>> 
>> Would you prefer to not have the specialpurpose components in R13.07 demo?
>> 
>>> It is a bit odd and certainly goes against most product release strategies 
>>> wherein the current release is the recommended download and carries 
>>> whatever warranty that the project offers in terms of testing and rapidity 
>>> of bug fixes and the trunk is usually called something that 
>>> includes"nightly build" and "unstable" in the name and comes with no 
>>> warranty and a warning about using it at your own risk.
>>> 
>>> Demos should be of the latest release and should be stable and have a fixed 
>>> functionality that can be documented in the wiki and marketing pages.
>> 
>> They are, just that they use the branch instead of the packaged releases.  
>> For R13.07 (current stable) there is an exception, because I thought it was 
>> better to have the specialpurpose components available. This is what Jacopo 
>> contests
>> 
>>> It could be maintained by the documentation team once it is set up since it 
>>> should not require any technical skills to keep working and fed with demo 
>>> data.
>>> 
>>> 
>>> If the developers need a test site based on the nightly build, they should 
>>> be free to set up as many combinations of configurations as they require 
>>> and can support  to be sure that the trunk still works but this should not 
>>> be the public demo or even be called a "demo".
>> 
>> It's also, there are no official mention of the trunk demo, it's only a 
>> developers thing.
>> 
>>> 
>>> Of course, this only works if a release is actually a Release and the team 
>>> stands behind it and uses it when establishing new customers.
>> 
>> We have no customers, only users
> 
> The PMC members have the customers to whom I was referring.
> 
>> 
>> Jacques
>> 
>>> 
>>> Does anyone have an opinion about the gap between 13.07.01 and what the 
>>> main SI companies are getting from using the trunk instead.
>>> Would a monthly release pattern reduce this gap to a point where it would 
>>> be possible to use the official Release as the actual release?
>>> 
 
 I hope it's more clear
 
 Jacques
 
> 
> Thanks,
> 
> Jacopo
> 
> 
> -- 
> Ron Wheeler
> President
> Artifact Software Inc
> email: rwhee...@artifact-software.com
> skype: ronaldmwheeler
> phone: 866-970-2435, ext 102
>

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Pierre @GMail

Is it a good thing to not regard the ofbiz user as a customer?

Regards, 

Pierre

Sent from my iPhone

> On 23 okt. 2014, at 17:33, Jacques Le Roux  
> wrote:
> 
> 
> Le 23/10/2014 17:11, Ron Wheeler a écrit :
>> On 23/10/2014 10:39 AM, Jacques Le Roux wrote:
>>> 
>>> Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
 On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
  wrote:
 
> I agree about the idea, but this applies only to releases or checked out 
> code. Because there are no ways for users to enable/disable a component 
> in demos, moreover demos are shared.
 Could you please explain the above sentence? I don't understand the 
 meaning of it.
>>> 
>>> Your idea of disabling some specialpurpose component can't be applied in 
>>> R13.07 demo until we decide which component should be disabled in trunk.
>>> In the meantime we should keep the current state (ie all specialpurpose 
>>> components present in trunk should be available in R13.07 demo)
>> 
>> If they are in the demo they should be in the release.
> 
> Actually the specialpurpose components are in the R13.07 demos because they 
> can be there. But they are not maintained in the R13.07 branch (but 
> ecommerce) only in trunk.
> 
>> As you can guess, I am troubled about the relation between releases and the 
>> trunk and demos in OFBiz.
> 
> Would you prefer to not have the specialpurpose components in R13.07 demo?
> 
>> It is a bit odd and certainly goes against most product release strategies 
>> wherein the current release is the recommended download and carries whatever 
>> warranty that the project offers in terms of testing and rapidity of bug 
>> fixes and the trunk is usually called something that includes"nightly build" 
>> and "unstable" in the name and comes with no warranty and a warning about 
>> using it at your own risk.
>> 
>> Demos should be of the latest release and should be stable and have a fixed 
>> functionality that can be documented in the wiki and marketing pages.
> 
> They are, just that they use the branch instead of the packaged releases.  
> For R13.07 (current stable) there is an exception, because I thought it was 
> better to have the specialpurpose components available. This is what Jacopo 
> contests
> 
>> It could be maintained by the documentation team once it is set up since it 
>> should not require any technical skills to keep working and fed with demo 
>> data.
>> 
>> 
>> If the developers need a test site based on the nightly build, they should 
>> be free to set up as many combinations of configurations as they require and 
>> can support  to be sure that the trunk still works but this should not be 
>> the public demo or even be called a "demo".
> 
> It's also, there are no official mention of the trunk demo, it's only a 
> developers thing.
> 
>> 
>> Of course, this only works if a release is actually a Release and the team 
>> stands behind it and uses it when establishing new customers.
> 
> We have no customers, only users
> 
> Jacques
> 
>> 
>> Does anyone have an opinion about the gap between 13.07.01 and what the main 
>> SI companies are getting from using the trunk instead.
>> Would a monthly release pattern reduce this gap to a point where it would be 
>> possible to use the official Release as the actual release?
>> 
>>> 
>>> I hope it's more clear
>>> 
>>> Jacques
>>> 
 
 Thanks,
 
 Jacopo
>> 
>>

Re: specialpurpose in R13.07 demo


On 23/10/2014 11:33 AM, Jacques Le Roux wrote:


Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 wrote:


I agree about the idea, but this applies only to releases or 
checked out code. Because there are no ways for users to 
enable/disable a component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand the 
meaning of it.


Your idea of disabling some specialpurpose component can't be 
applied in R13.07 demo until we decide which component should be 
disabled in trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.


Actually the specialpurpose components are in the R13.07 demos because 
they can be there. But they are not maintained in the R13.07 branch 
(but ecommerce) only in trunk.


As you can guess, I am troubled about the relation between releases 
and the trunk and demos in OFBiz.


Would you prefer to not have the specialpurpose components in R13.07 
demo?


It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download 
and carries whatever warranty that the project offers in terms of 
testing and rapidity of bug fixes and the trunk is usually called 
something that includes"nightly build" and "unstable" in the name and 
comes with no warranty and a warning about using it at your own risk.


Demos should be of the latest release and should be stable and have a 
fixed functionality that can be documented in the wiki and marketing 
pages.


They are, just that they use the branch instead of the packaged 
releases.  For R13.07 (current stable) there is an exception, because 
I thought it was better to have the specialpurpose components 
available. This is what Jacopo contests


It could be maintained by the documentation team once it is set up 
since it should not require any technical skills to keep working and 
fed with demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as 
they require and can support  to be sure that the trunk still works 
but this should not be the public demo or even be called a "demo".


It's also, there are no official mention of the trunk demo, it's only 
a developers thing.




Of course, this only works if a release is actually a Release and the 
team stands behind it and uses it when establishing new customers.


We have no customers, only users


The PMC members have the customers to whom I was referring.



Jacques



Does anyone have an opinion about the gap between 13.07.01 and what 
the main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it 
would be possible to use the official Release as the actual release?




I hope it's more clear

Jacques



Thanks,

Jacopo











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

Re: svn commit: r1632760 - in /ofbiz/branches/release13.07/applications: order/webapp/ordermgr/WEB-INF/actions/entry/catalog/ order/webapp/ordermgr/entry/catalog/ product/servicedef/ product/src/org/o

2014-10-23 Thread gil portenseigne


I ashish,

Is there a reason to introduce these imports in : CategoryServices.java, 
these might be remains of devel


 import java.io.Writer;
+import java.math.BigDecimal;
 import java.sql.Timestamp;
+import java.util.ArrayList;
 import java.util.List;

[...]

 import org.ofbiz.entity.util.EntityListIterator;
+import org.ofbiz.entity.util.EntityTypeUtil;
 import org.ofbiz.entity.util.EntityUtil;
[...]
+import org.ofbiz.service.GenericServiceException;

My eclipse tell me they are no use here :).

Not so important i guess, but to have less import is better.

Other thing is formatting where you remove an empty line for spaces :

@@ -237,7 +245,7 @@ public class CategoryServices {
 }
 
 Timestamp nowTimestamp = UtilDateTime.nowTimestamp();

-
+
 int viewIndex = 0;
 try {


Best Regards

Gil

Le 18/10/2014 13:23, ash...@apache.org a écrit :

Author: ashish
Date: Sat Oct 18 11:23:45 2014
New Revision: 1632760

URL: http://svn.apache.org/r1632760
Log:
Applied bug fix from trunk r1632750.
===
Applied patch from jira issue - OFBIZ-4528 - Out of stock products screw up the 
pagination during category browsing.
===
Pagination is handled in getProductCategoryAndLimitedMembers
Then the out of stock filtering is done in CategoryDetail.groovy.
Hence the pagination is screwed up. Certain pages might show less records or no 
records based upon data condition.
===
Thanks Arun for the contribution and Thanks Kiran for creating the issue.

Modified:
 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/entry/catalog/categorydetail.ftl
 
ofbiz/branches/release13.07/applications/product/servicedef/services_view.xml
 
ofbiz/branches/release13.07/applications/product/src/org/ofbiz/product/category/CategoryServices.java
 
ofbiz/branches/release13.07/applications/product/src/org/ofbiz/product/product/ProductWorker.java

Modified: 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
URL: 
http://svn.apache.org/viewvc/ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy?rev=1632760&r1=1632759&r2=1632760&view=diff
==
--- 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
 (original)
+++ 
ofbiz/branches/release13.07/applications/order/webapp/ordermgr/WEB-INF/actions/entry/catalog/CategoryDetail.groovy
 Sat Oct 18 11:23:45 2014
@@ -54,52 +54,20 @@ andMap = [productCategoryId : productCat
  limitView : limitView];
  andMap.put("prodCatalogId", currentCatalogId);
  andMap.put("checkViewAllow", true);
+// Prevents out of stock product to be displayed on site
+productStore = ProductStoreWorker.getProductStore(request);
+if (productStore) {
+andMap.put("productStoreId", productStore.productStoreId);
+}
  if (context.orderByFields) {
  andMap.put("orderByFields", context.orderByFields);
  } else {
  andMap.put("orderByFields", ["sequenceNum", "productId"]);
  }
  catResult = dispatcher.runSync("getProductCategoryAndLimitedMembers", andMap);
-
  productCategory = catResult.productCategory;
  productCategoryMembers = catResult.productCategoryMembers;
-
-// Prevents out of stock product to be displayed on site
-productStore = ProductStoreWorker.getProductStore(request);
-if(productStore) {
-if("N".equals(productStore.showOutOfStockProducts)) {
-productsInStock = [];
-productCategoryMembers.each { productCategoryMember ->
-product = delegator.findOne("Product", [productId : 
productCategoryMember.productId], true);
-boolean isMarketingPackage = EntityTypeUtil.hasParentType(delegator, "ProductType", 
"productTypeId", product.productTypeId, "parentTypeId", "MARKETING_PKG");
-context.isMarketingPackage = (isMarketingPackage? "true": "false");
-if (isMarketingPackage) {
-resultOutput = dispatcher.runSync("getMktgPackagesAvailable", 
[productId : productCategoryMember.productId]);
-availableInventory = resultOutput.availableToPromiseTotal;
-if(availableInventory > 0) {
-productsInStock.add(productCategoryMember);
-}
-} else {
-facilities = delegator.findList("ProductFacility", 
EntityCondition.makeCondition([productId : productCategoryMember.productId]), null, null, 
null, false);
-availableInventory = 0.0;
-if (facilities) {
-facilities.each { facility ->
-lastInventoryCount

Re: specialpurpose in R13.07 demo

Le 23/10/2014 17:11, Ron Wheeler a écrit :

On 23/10/2014 10:39 AM, Jacques Le Roux wrote:

Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux
wrote:

I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a component
in demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of
it.

If they are in the demo they should be in the release.

Actually the specialpurpose components are in the R13.07 demos because they can be there. But they are not maintained in the R13.07 branch (but
ecommerce) only in trunk.

As you can guess, I am troubled about the relation between releases and the
trunk and demos in OFBiz.

Would you prefer to not have the specialpurpose components in R13.07 demo?

It is a bit odd and certainly goes against most product release strategies wherein the current release is the recommended download and carries
whatever warranty that the project offers in terms of testing and rapidity of bug fixes and the trunk is usually called something that
includes"nightly build" and "unstable" in the name and comes with no warranty and a warning about using it at your own risk.

Demos should be of the latest release and should be stable and have a fixed
functionality that can be documented in the wiki and marketing pages.

They are, just that they use the branch instead of the packaged releases. For R13.07 (current stable) there is an exception, because I thought it was
better to have the specialpurpose components available. This is what Jacopo contests

It could be maintained by the documentation team once it is set up since it should not require any technical skills to keep working and fed with
demo data.

If the developers need a test site based on the nightly build, they should be free to set up as many combinations of configurations as they require
and can support to be sure that the trunk still works but this should not be the public demo or even be called a "demo".

It's also, there are no official mention of the trunk demo, it's only a
developers thing.

Of course, this only works if a release is actually a Release and the team
stands behind it and uses it when establishing new customers.

We have no customers, only users

Jacques

I hope it's more clear

Jacques

Thanks,

Jacopo

Re: Remove R11.04 from Fix/versions in Jira


On 23/10/2014 10:48 AM, Jacques Le Roux wrote:


Le 23/10/2014 14:47, Ron Wheeler a écrit :

There should be a note on the home page


and download page



It would be a good time to think about the OndOfSupport and EndOfLife 
for 12.xx. and 13.xx.
What does EOS mean (or more important - what does Support mean prior 
to EOS

What does EOL mean and what happens between EOS and EOL.


I'm not a fervent supporter of planned dates, I find they are often 
postponed. Thought a deadline during a year seems reasonable, it gives 
you enoufh flexiblity (and an open source project needs it, we have no 
clients, just users)


It is always just a guideline but it does give users a sense of what the 
environment will be.
The project is old enough to have some sense of its own history and 
should be able to set some goals for support.


Adding clarity also makes it easier for contributors to get involved.
If there is no leadership in these areas, it is hard for people to see 
what is required.
If the PMC says that 12.04. will reach EOS on January 1, 2015 and EOL on 
March 31, 2015, the companies that want to stay on this release know 
that they have to step up to the plate with a plan and resources to 
extend this.

If the PMC is vague about this, no one knows that they have to take action.

If the companies do not want to step up then they know that they have 
2-5 months to get on 13.07.01 and will have to step up to the plate with 
resources and a plan to address the features that were dropped between 
12 and 13 if they need them.


The current method of working means that anyone wanting to use OFBiz has 
to fork it the way that the core PMC members do.
This makes it hard to grow the project and probably reduces the profits 
for all the companies using OFBiz as a base of their business.


Ron


Jacques



Ron


On 23/10/2014 7:36 AM, Jacques Le Roux wrote:
OK, it's now 4 days w/o answers, so I guess everybody agree and I 
remove R11.04 from the Fix/versions multi-dropdown in Jira.

It finally seems no changes are necessary in the Download page.

Jacques

Le 19/10/2014 12:04, Jacques Le Roux a écrit :

Hi,

We decided to label as "Old superseded releases" the 
antepenultimate release (today R11.04). This means also that we 
tend to no longer support this release and those before.


So I think we should remove it from the Fix/versions in Jira 
multi-dropdown in Jira. What about the Download page?


Also it was maybe intended to be done later, but I began to fill 
the Fix/versions for some Jira fixed by the last bug crush HWM team 
effort. Please committers, if it's an oversight, remember we use 
them in releases change logs.


Jacques











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

Re: specialpurpose in R13.07 demo


On 23/10/2014 10:39 AM, Jacques Le Roux wrote:


Le 23/10/2014 15:01, Jacopo Cappellato a écrit :
On Oct 23, 2014, at 2:07 PM, Jacques Le Roux 
 wrote:


I agree about the idea, but this applies only to releases or checked 
out code. Because there are no ways for users to enable/disable a 
component in demos, moreover demos are shared.
Could you please explain the above sentence? I don't understand the 
meaning of it.


Your idea of disabling some specialpurpose component can't be applied 
in R13.07 demo until we decide which component should be disabled in 
trunk.
In the meantime we should keep the current state (ie all 
specialpurpose components present in trunk should be available in 
R13.07 demo)


If they are in the demo they should be in the release.
As you can guess, I am troubled about the relation between releases and 
the trunk and demos in OFBiz.
It is a bit odd and certainly goes against most product release 
strategies wherein the current release is the recommended download and 
carries whatever warranty that the project offers in terms of testing 
and rapidity of bug fixes and the trunk is usually called something that 
includes"nightly build" and "unstable" in the name and comes with no 
warranty and a warning about using it at your own risk.


Demos should be of the latest release and should be stable and have a 
fixed functionality that can be documented in the wiki and marketing pages.
It could be maintained by the documentation team once it is set up since 
it should not require any technical skills to keep working and fed with 
demo data.



If the developers need a test site based on the nightly build, they 
should be free to set up as many combinations of configurations as they 
require and can support  to be sure that the trunk still works but this 
should not be the public demo or even be called a "demo".


Of course, this only works if a release is actually a Release and the 
team stands behind it and uses it when establishing new customers.


Does anyone have an opinion about the gap between 13.07.01 and what the 
main SI companies are getting from using the trunk instead.
Would a monthly release pattern reduce this gap to a point where it 
would be possible to use the official Release as the actual release?




I hope it's more clear

Jacques



Thanks,

Jacopo






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

Re: Remove R11.04 from Fix/versions in Jira

Le 23/10/2014 16:48, Jacques Le Roux a écrit :

Le 23/10/2014 14:47, Ron Wheeler a écrit :

There should be a note on the home page

BTW, thinking about it, why not only on the download page? We don't need to
clutter all pages with that.

Jacques

and download page

It would be a good time to think about the OndOfSupport and EndOfLife for
12.xx. and 13.xx.
What does EOS mean (or more important - what does Support mean prior to EOS
What does EOL mean and what happens between EOS and EOL.

I'm not a fervent supporter of planned dates, I find they are often postponed. Thought a deadline during a year seems reasonable, it gives you
enoufh flexiblity (and an open source project needs it, we have no clients, just users)

Jacques

Ron

On 23/10/2014 7:36 AM, Jacques Le Roux wrote:

OK, it's now 4 days w/o answers, so I guess everybody agree and I remove R11.04
from the Fix/versions multi-dropdown in Jira.
It finally seems no changes are necessary in the Download page.

Jacques

Le 19/10/2014 12:04, Jacques Le Roux a écrit :

Hi,

We decided to label as "Old superseded releases" the antepenultimate release (today R11.04). This means also that we tend to no longer support
this release and those before.

So I think we should remove it from the Fix/versions in Jira multi-dropdown in
Jira. What about the Download page?

Also it was maybe intended to be done later, but I began to fill the Fix/versions for some Jira fixed by the last bug crush HWM team effort.
Please committers, if it's an oversight, remember we use them in releases change logs.

Jacques

Re: Remove R11.04 from Fix/versions in Jira



Le 23/10/2014 14:47, Ron Wheeler a écrit :

There should be a note on the home page


and download page



It would be a good time to think about the OndOfSupport and EndOfLife for 
12.xx. and 13.xx.
What does EOS mean (or more important - what does Support mean prior to EOS
What does EOL mean and what happens between EOS and EOL.


I'm not a fervent supporter of planned dates, I find they are often postponed. Thought a deadline during a year seems reasonable, it gives you enoufh 
flexiblity (and an open source project needs it, we have no clients, just users)


Jacques



Ron


On 23/10/2014 7:36 AM, Jacques Le Roux wrote:

OK, it's now 4 days w/o answers, so I guess everybody agree and I remove R11.04 
from the Fix/versions multi-dropdown in Jira.
It finally seems no changes are necessary in the Download page.

Jacques

Le 19/10/2014 12:04, Jacques Le Roux a écrit :

Hi,

We decided to label as "Old superseded releases" the antepenultimate release (today R11.04). This means also that we tend to no longer support 
this release and those before.


So I think we should remove it from the Fix/versions in Jira multi-dropdown in 
Jira. What about the Download page?

Also it was maybe intended to be done later, but I began to fill the Fix/versions for some Jira fixed by the last bug crush HWM team effort. 
Please committers, if it's an oversight, remember we use them in releases change logs.


Jacques

Re: specialpurpose in R13.07 demo



Le 23/10/2014 15:01, Jacopo Cappellato a écrit :

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux  
wrote:


I agree about the idea, but this applies only to releases or checked out code. 
Because there are no ways for users to enable/disable a component in demos, 
moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of 
it.


Your idea of disabling some specialpurpose component can't be applied in R13.07 
demo until we decide which component should be disabled in trunk.
In the meantime we should keep the current state (ie all specialpurpose 
components present in trunk should be available in R13.07 demo)

I hope it's more clear

Jacques



Thanks,

Jacopo

Re: Release Strategy and Branch Support

 I think that many projects that are "important" and are hard to 
upgrade (user facing or customized at each installation) are fully 
supported until end of support and between EOS and EOL get fixes for 
bugs that have security implications where publishing the issue and fix 
to the current release or trunk will give hackers easy access  to data 
held in the old version or in some way open companies using that version 
to serious harm.

It may be somewhat difficult to get people to fix older versions but 
there may be things that we could do to make this more likely.
1) Bugs can not be closed until it is fixed in all of the versions to 
which it must be applied (according to our EOS and EOL rules). It might 
be better to generate new issue that specifically addresses the patch to 
be applied rather than a full description of the symptoms of the 
original problem which is a main feature of the original report and make 
this new issue a dependency of the original.
2) Open a sub-project for the older releases with different committers 
who are interested in the older version and are not committing to the trunk.

This might be a way for someone to get started in OFBiz programming.
The activity in this sub-project would be a good way to judge the 
community's interest in maintaining the older release. One would expect 
that companies running the old version would be interested in supporting 
this sub-project even if they have no interest in the trunk.

Ron

On 23/10/2014 8:17 AM, Jacques Le Roux wrote:

Inline

Le 23/09/2014 09:26, Jacques Le Roux a écrit :

Le 23/09/2014 06:35, Jacopo Cappellato a écrit :
On Sep 22, 2014, at 9:58 PM, Jacques Le Roux 
 wrote:

>

A more formal rule would be:
* commits to the trunk from Jira tickets of type Bugs can and 
*should* be backported to all the active releases
Yes, hopefully we (I mean the really concerned persons) will not have 
to enforce (ie do it ourselves) the "should" :/
* commits to the trunk from Jira tickets of type different from Bugs 
need an explicit approval from the committers group before they can 
be backported to a specific active release
Yes it's already like that and those are only rare exceptions, right 
way for me
>

+1 see below

As suggested Ron we could also define our own or refer to 
http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
Rather than referring to an external site, in my opinion we could 
improve (and make more evident) the information we already have in 
the download page where we already mention a tentative end of life; 
for example now we have:

• April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)

But when we specify an end of life, we should also make clear a few 
things:
* this is a community goal, and the help from the community is 
required to meet the goal (i.e. it is not guaranteed)
Yes that's an important point indeed. We begin to get traction with 
(mostly thanks to the bug crush effort so far) and hopefully it will 
continue :)
* the plan is flexible; for example, if a group of interested users 
will show up today telling us that they want to actively maintain 
the release branch 11.04 even if the scheduled end of life is 
passed, I would not object to it; the opposite is also true: if we 
experience low interest/support (from committers and non committers) 
in maintaining a given release branch we could vote to modify its 
end of life
The point I'd really want to be highlighted/explained is we don't 
guarantee that old bugs fixed in trunk are backported. Let's face it, 
we can't guarantee that, we have not real means to enforce it.

We have still no mention of that in the download page. I recently 
backported a number of bug fixes done in the last HWM bug crush in 
R12.04, but I (nobody I guess) can't guarantee we will always backport 
all bug fixes in living releases branches.  I don't know how other TLP 
projects do, but it seems to me that to be correct/honest with our 
users we need to clarify that. We should even give a mean, or at least 
a way, to check that by themselves. By comparing the trunk and 
releases change logs for instance? I also suggested below
>

Jacques

Now we need to think "technical" and automatize as possible with Jira
In my opinion it is possible to easily derive this from Jira, after 
the version configuration refactoring I did a few weeks ago (however 
the information will be more accurate with new releases).

The idea is to run

Re: specialpurpose in R13.07 demo

2014-10-23 Thread Jacopo Cappellato

On Oct 23, 2014, at 2:07 PM, Jacques Le Roux  
wrote:

> I agree about the idea, but this applies only to releases or checked out 
> code. Because there are no ways for users to enable/disable a component in 
> demos, moreover demos are shared.

Could you please explain the above sentence? I don't understand the meaning of 
it.

Thanks,

Jacopo

Re: Remove R11.04 from Fix/versions in Jira


There should be a note on the home page

It would be a good time to think about the OndOfSupport and EndOfLife 
for 12.xx. and 13.xx.

What does EOS mean (or more important - what does Support mean prior to EOS
What does EOL mean and what happens between EOS and EOL.

Ron


On 23/10/2014 7:36 AM, Jacques Le Roux wrote:
OK, it's now 4 days w/o answers, so I guess everybody agree and I 
remove R11.04 from the Fix/versions multi-dropdown in Jira.

It finally seems no changes are necessary in the Download page.

Jacques

Le 19/10/2014 12:04, Jacques Le Roux a écrit :

Hi,

We decided to label as "Old superseded releases" the antepenultimate 
release (today R11.04). This means also that we tend to no longer 
support this release and those before.


So I think we should remove it from the Fix/versions in Jira 
multi-dropdown in Jira. What about the Download page?


Also it was maybe intended to be done later, but I began to fill the 
Fix/versions for some Jira fixed by the last bug crush HWM team 
effort. Please committers, if it's an oversight, remember we use them 
in releases change logs.


Jacques






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

Re: Remove R11.04 from Fix/versions in Jira


Done, I have dropped the R13.07.01 version. I was agreably suprised by Jira 
proposing me to switch the related Jira issues to the Branch R11.04.
So I kept the Branch 11.04 accessible for change logs, but archived all 
releases R11.04 versions,

I now wonder though, if it's the right way, to archive all releases R11.04 
versions, because some people might be interested.
Though if we go this way we will end with a lot of still opened old releases 
versions.

Opinions?

Jacques


Le 23/10/2014 13:36, Jacques Le Roux a écrit :

OK, it's now 4 days w/o answers, so I guess everybody agree and I remove R11.04 
from the Fix/versions multi-dropdown in Jira.
It finally seems no changes are necessary in the Download page.

Jacques

Le 19/10/2014 12:04, Jacques Le Roux a écrit :

Hi,

We decided to label as "Old superseded releases" the antepenultimate release (today R11.04). This means also that we tend to no longer support this 
release and those before.


So I think we should remove it from the Fix/versions in Jira multi-dropdown in 
Jira. What about the Download page?

Also it was maybe intended to be done later, but I began to fill the Fix/versions for some Jira fixed by the last bug crush HWM team effort. Please 
committers, if it's an oversight, remember we use them in releases change logs.


Jacques





.

Re: Release Strategy and Branch Support (was: Re: Bug Crush)

Inline

Le 23/09/2014 09:26, Jacques Le Roux a écrit :

Le 23/09/2014 06:35, Jacopo Cappellato a écrit :

On Sep 22, 2014, at 9:58 PM, Jacques Le Roux  
wrote:

>

A more formal rule would be:
* commits to the trunk from Jira tickets of type Bugs can and *should* be 
backported to all the active releases

Yes, hopefully we (I mean the really concerned persons) will not have to enforce (ie do 
it ourselves) the "should" :/
* commits to the trunk from Jira tickets of type different from Bugs need an explicit approval from the committers group before they can be 
backported to a specific active release

Yes it's already like that and those are only rare exceptions, right way for me

<>

+1 see below

As suggested Ron we could also define our own or refer to 
http://en.wikipedia.org/wiki/End-of-life_%28product%29 and
Rather than referring to an external site, in my opinion we could improve (and make more evident) the information we already have in the download 
page where we already mention a tentative end of life; for example now we have:

• April 2015 - Apache OFBiz 12.04.06 (last release of the 12.04 series)

But when we specify an end of life, we should also make clear a few things:
* this is a community goal, and the help from the community is required to meet 
the goal (i.e. it is not guaranteed)

Yes that's an important point indeed. We begin to get traction with (mostly 
thanks to the bug crush effort so far) and hopefully it will continue :)
* the plan is flexible; for example, if a group of interested users will show up today telling us that they want to actively maintain the release 
branch 11.04 even if the scheduled end of life is passed, I would not object to it; the opposite is also true: if we experience low 
interest/support (from committers and non committers) in maintaining a given release branch we could vote to modify its end of life
The point I'd really want to be highlighted/explained is we don't guarantee that old bugs fixed in trunk are backported. Let's face it, we can't 
guarantee that, we have not real means to enforce it.

We have still no mention of that in the download page. I recently backported a number of bug fixes done in the last HWM bug crush in R12.04, but I 
(nobody I guess) can't guarantee we will always backport all bug fixes in living releases branches.  I don't know how other TLP projects do, but it 
seems to me that to be correct/honest with our users we need to clarify that. We should even give a mean, or at least a way, to check that by 
themselves. By comparing the trunk and releases change logs for instance? I also suggested below
>

Jacques

Now we need to think "technical" and automatize as possible with Jira
In my opinion it is possible to easily derive this from Jira, after the version configuration refactoring I did a few weeks ago (however the 
information will be more accurate with new releases).

The idea is to run a query on Jira with the following constraints:
project = OFBiz
type = Bug
status = not resolved
version *affected* = the release branch we are interested in (e.g. "release branch 12.04" OR the current latest release in the same branch (e.g. 
"Release 12.04.05")

The result should be a list of bugs affecting the release branch and/or the latest release in that branch; these are the bugs that are known and 
outstanding.

For them we will need help from the community (committers and non committers) 
to fix the bugs or backport existing fixes.

In the download page, we could add two links (to Jira) next to each available 
release:
1) known bugs (links to the above report)
2) release notes (link to the release notes available now)

One technicality is the following: when we release a new release from the branch (e.g. 12.04.06), if there are open tickets with "version affected" 
set to the current version (e.g. 12.04.05) then we will have to bulk update all of them by adding also the new version (e.g. add "12.04.06" to 
affected version).

This will need a strict observance from committers about versions to fix and fixed. I believe it's indeed the right way, anyway we have no 
others/betters (I mean offered by Jira) .

We should then explain to our releases users how they can use the Jira changes logs to check and amend what they use (maybe a link to wiki from 
download page to not clutter this main page).
I will think about what you wrote above and see how we can inform our our releases users (I mean a process to follow maybe even something more 
automated)

Jacques

What I have read so far from Jacopo seems a good start to me
Thank you for confirming that we are on the sam

Re: specialpurpose in R13.07 demo


Le 30/09/2014 08:47, Jacopo Cappellato a écrit :

Also, since (by design) the specialpurpose components there could be 
incompatible components (i.e. specialpurpose/a causes side effects in 
specialpurpose/b), or alternative components (i.e. specialpurpose/a is a 
different implementation of the same features of specialpurpose/b) or 
components that override some of the screens published by the applications 
(i.e. specialpurpose/a replaces applications/a screen with a custom version), 
we should, by default, disable (most of) them and provide a README file with 
the information on how to enable them selectively.


I agree about the idea, but this applies only to releases or checked out code. Because there are no ways for users to enable/disable a component in 
demos, moreover demos are shared.

So before this effort is accomplished it's better to run the R13.07 demo 
completed with the specialpurpose components also present in trunk demo.
Then we would put as external in R13.07 (and sequel releases) only the not (by 
default) disabled components in trunk, a bit convoluted though :/

A moment I even thought about Attic for some unmaintained components 
(ebaystore?, googlebase?, googlecheckout?, jetty?, webpos?, ...), WHO cares?

BTW I just noticed that we missed to adapt the ecommerce component in R13.07 
for the missing ebaystore and googlecheckout components.
I guess it's only about checking in trunk HEAD code for these components presence and hidding their buttons when they would otherwise show. This 
should be backported in R13.07 of course.


Jacques



Jacopo

On Sep 30, 2014, at 8:38 AM, Jacopo Cappellato 
 wrote:


in my opinion it is better to run the demo on the exact copy of the release 
branch.

Jacopo

On May 30, 2014, at 2:28 PM, Jacques Le Roux  
wrote:


Hi,

For the R13.07 demo I think we should set an external property from trunk into 
specialpurpose for some (those which make sense) components.

I created this svn external property:

specialpurpose/assetmaint/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/assetmaint
specialpurpose/birt/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/birt
specialpurpose/cmssite/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/cmssite
specialpurpose/ebay/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/ebay
specialpurpose/ebaystore/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/ebaystore
specialpurpose/example/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/example
specialpurpose/exampleext/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/exampleext
specialpurpose/googlecheckout/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/googlecheckout
specialpurpose/lucene/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/lucene
specialpurpose/myportal/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/myportal
specialpurpose/projectmgr/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/projectmgr
specialpurpose/scrum/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/scrum
specialpurpose/webpos/ 
https://svn.apache.org/repos/asf/ofbiz/trunk/specialpurpose/webpos

What do you think?

Jacques

Re: Suggestions on improving Buildbot Builds


Hi Gavin,

We are still running RAT report (at least in trunk), normal?

Jacques

Le 03/09/2014 12:02, Jacques Le Roux a écrit :

Ha forgot, you may still  have a copy of an email  "Rat xsl sylesheet used in 
builbot scripts"  from venkatmang...@gmail.com
At least I have it here if you think it can behelpful

Jacques

Le 03/09/2014 11:57, Jacques Le Roux a écrit :

Hi Gavin,

Thanks for your comments, inline...

Le 03/09/2014 10:23, Gavin McDonald a écrit :

Hi All,

So recently I worked on curing issues with your buildbot build at

http://ci.apache.org/builders/ofbiz-trunk

Part of the build involves running Apache RAT on your code and producing a 
report at

http://ci.apache.org/projects/ofbiz/rat-output.html

A summary of which also appears on the league table of participating projects at

http://ci.apache.org/projects/rat-master-summary.html


You have quite a bit of code that RAT has to go through in order to compile 
these reports and
this takes up over an hour of your build on its own. Your build gets run on a 
per commit basis
so this RAT report is run each and every time  a commit is made.

I'd like to propose two suggestions.

Suggestion One :
==

We remove the RAT report steps from your normal build and stick those steps
into its own build, separate of any other build steps. This build would run via 
a nightly trigger only.

This would bring your normal build down to just 15 minutes, and is then fine to 
continue to
run on a per commit basis, concentrating on compile checks, docs and uploading 
of snapshots.


I think in all cases we don't need to run the RAT report on each commit, 
nightly would be well enough



Suggestion Two :
==

Your RAT report says there are 2273 (currently) invalid or unlicensed files. 
There are obviously
some false reports in there, such as generated files that probably should not 
be checked.

The suggestion is, to go through the report at

http://ci.apache.org/projects/ofbiz/rat-output.html

and see what files and/or directories can be excluded from the RAT check.
Lets get it down to a realistic figure that can then show you exactly what 
genuine files are missing
license headers.

This can be self-served by the addition of a rat-excludes file in your svn. I 
then tell RAT to read this
file and the excludes are automatic.

See the 'More Reading and links' section of

http://ci.apache.org/projects/rat-master-summary.html

for example rat-exclude files.

I am happy to get you started and create a patch with a starter rat-excludes 
file.

If you are happy with these suggestions, let me know and I'll get started.


That would be great, even if at the moment we are not doing a great use of RAT.
This remembers me also this thread http://markmail.org/message/jkeqbdtf5im6zjlm 
I have completely forgottten it since :/ (as ever, bigger fishes...)

Jacques



Gav…

Re: svn commit: r1632793 - in /ofbiz/trunk/framework: common/widget/HelpScreens.xml resources/templates/CommonScreens.xml


Is somebody taking care of that? Is it a real issue?

Jacques

Le 18/10/2014 16:32, Adrian Crum a écrit :

I don't think we need to change the component templates. This is a regression - 
components created with the ant target will not function properly.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 10/18/2014 3:11 PM, apa...@apache.org wrote:

Author: apatel
Date: Sat Oct 18 14:11:50 2014
New Revision: 1632793

URL: http://svn.apache.org/r1632793
Log:
[OFBIZ-3329] Removing framework code on resources in commonext.
Thanks Divesh and Mridul for helping with resuluation.
Thanks Adrian for reporting it.
Thanks Chris Snow for reporting the issue

Modified:
 ofbiz/trunk/framework/common/widget/HelpScreens.xml
 ofbiz/trunk/framework/resources/templates/CommonScreens.xml

Modified: ofbiz/trunk/framework/common/widget/HelpScreens.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/widget/HelpScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
==
--- ofbiz/trunk/framework/common/widget/HelpScreens.xml (original)
+++ ofbiz/trunk/framework/common/widget/HelpScreens.xml Sat Oct 18 14:11:50 2014
@@ -25,7 +25,6 @@ under the License.
  
  
  
-
  
  
  

Modified: ofbiz/trunk/framework/resources/templates/CommonScreens.xml
URL: 
http://svn.apache.org/viewvc/ofbiz/trunk/framework/resources/templates/CommonScreens.xml?rev=1632793&r1=1632792&r2=1632793&view=diff
==
--- ofbiz/trunk/framework/resources/templates/CommonScreens.xml (original)
+++ ofbiz/trunk/framework/resources/templates/CommonScreens.xml Sat Oct 18 
14:11:50 2014
@@ -17,7 +17,7 @@
  
  
  
-
+

Re: Remove R11.04 from Fix/versions in Jira


OK, it's now 4 days w/o answers, so I guess everybody agree and I remove R11.04 
from the Fix/versions multi-dropdown in Jira.
It finally seems no changes are necessary in the Download page.

Jacques

Le 19/10/2014 12:04, Jacques Le Roux a écrit :

Hi,

We decided to label as "Old superseded releases" the antepenultimate release (today R11.04). This means also that we tend to no longer support this 
release and those before.


So I think we should remove it from the Fix/versions in Jira multi-dropdown in 
Jira. What about the Download page?

Also it was maybe intended to be done later, but I began to fill the Fix/versions for some Jira fixed by the last bug crush HWM team effort. Please 
committers, if it's an oversight, remember we use them in releases change logs.


Jacques

[jira] [Commented] (OFBIZ-5836) Integrate web analytics into the website

2014-10-23 Thread Jacques Le Roux (JIRA)


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

Jacques Le Roux commented on OFBIZ-5836:


Did you ask if the infra has not already something in place, like Webalizer or 
AWStats?

> Integrate web analytics into the website
> 
>
> Key: OFBIZ-5836
> URL: https://issues.apache.org/jira/browse/OFBIZ-5836
> Project: OFBiz
>  Issue Type: Improvement
>  Components: site
>Reporter: Pierre Smits
>
> Have some kind of web analytics integrated in the website to be able to some 
> kind analysis on visits, traffic etc.
> Refereces:
> * http://en.wikipedia.org/wiki/Web_analytics
> * http://en.wikipedia.org/wiki/List_of_web_analytics_software



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

Re: Theme bootstrap


Le 23/10/2014 10:52, Pierre Smits a écrit :

Tja

We have to make due with what we have got.


https://jira.atlassian.com/browse/JRA-4446 I don't think the infra would be 
willing to install a workaround plugin

Jacques



Regards,

Pierre Smits

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

On Thu, Oct 23, 2014 at 10:48 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Le 23/10/2014 09:57, Pierre Smits a écrit :


Hi Pierre, All,

Using an umbrella task in JIRA with for each app/component a sub task and
for each set of elements (menus, screens, forms, etc) a sub of sub task,


You can't have sub-sub-tasks in Jira, only sub-tasks

Jacques

Re: UOM of products

2014-10-23 Thread hoandv

Hi Julien
I use ofbiz 12.04 release

On Thu, Oct 23, 2014 at 1:20 PM, JulienNicolas [via OFBiz] <
ml-node+s135035n4657270...@n4.nabble.com> wrote:

> Hi Hoan,
>
> We are using add-on manager so if you know how it work, I can provide
> easily the add-on.
> The add-on can be integrate into 13.07 release.
>
> I think I have to modify it to delete dependency with other add-ons so
> tell me the release you work on. And I'll share it.
>
> Regards,
>
> Julien.
>
> Le 22/10/2014 07:29, hoandv a écrit :
>
> > Hi Julien
> > Yes, My case is the same as your case. I also read your issue, it is
> good
> > idea. I want to test it with you. Can you show me the way test it with
> you
> > Thanks
> > 
> >
> >
> >
> >
> > --
> > View this message in context:
> http://ofbiz.135035.n4.nabble.com/UOM-of-products-tp4657073p4657219.html
> > Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>
>
>
> --
>  If you reply to this email, your message will be added to the discussion
> below:
> http://ofbiz.135035.n4.nabble.com/UOM-of-products-tp4657073p4657270.html
>  To unsubscribe from UOM of products, click here
> 
> .
> NAML
> 
>



-- 
FullName: Đặng Văn Hoàn
Birthday: 14/06/1991
Contact: 0976.626.745




--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/UOM-of-products-tp4657073p4657292.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.

Re: [DISCUSSION] JIRA issues for web and wiki pages

2014-10-23 Thread Pierre Smits

Thanks, Jacques.

Regards,

Pierre Smits

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

On Wed, Oct 22, 2014 at 11:29 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

>
> Le 21/10/2014 22:53, Pierre Smits a écrit :
>
>> Jacques,
>>
>> The problem is indeed where to post the issues. There is no solution
>> available to do patches to pages in the website and improvement comments
>> in
>> the restricted spaces are all over the place.
>>
>
> Long ago, the community decided to go with comments. I don't see a need to
> change that. Not all comments in Confluence are important or even relevant.
>
>  And regarding the latter
>> aspect these comments can stay visible for quite some time due to busy
>> schedules (and other interests) of those capable to implement the changes.
>> Having those comments there for a longer time is not good regarding
>> branding and adoption.
>>
>
> If you are really interested/concerned simply add comments where you find
> relevant and I will do a complete review.
>
>
>> Having a JIRA setup for the website and restricted spaces will provide the
>> one place and will create insights about what is still open, what is fixed
>> and and when. Plus it helps identifying those committers that could become
>> committers.
>>
>
> If there are important things to tackle in Confluence which are neglected
> then of course the way is to create a Jira task type issue.
> I will add a Confluence component option for this (in Jira only of
> course!).
>
> Jacques
>
>
>> All in all not a bad suggestion and improvement.
>>
>> Regards,
>>
>> Pierre Smits
>>
>> *ORRTIZ.COM *
>> Services & Solutions for Cloud-
>> Based Manufacturing, Professional
>> Services and Retail & Trade
>> http://www.orrtiz.com
>>
>> On Tue, Oct 21, 2014 at 5:01 PM, Jacques Le Roux <
>> jacques.le.r...@les7arts.com> wrote:
>>
>>  I believe, the problem is more about people not knowing where to post
>>> things, else of course Jira is a perfect fit.
>>> Though I (hopefully I'm not alone) normally monitor Confluence (including
>>> comments) but https://issues.apache.org/jira/browse/INFRA-8323
>>> Anyway I normally receive all changes by mail.
>>>
>>> Pierre, do you have something specific in mind about overlooked comments,
>>> I mean a list, etc.?
>>>
>>> Jacques
>>>
>>> Le 21/10/2014 14:43, Ron Wheeler a écrit :
>>>
>>>   It would be good to have a well organized and supported system for
>>>
 tracking defects of all types including documentation.
 The JIRA has a very very helpful features that would allow us to
 identify
 the importance of problems, any version dependencies, assigned person,
 etc.

 Ron

 On 21/10/2014 7:45 AM, Pierre Smits wrote:

  Hi all,
>
> Currently we only register issues related to the OFBiz code. But we
> also
> see a lot of comments in wiki pages regarding corrections. These
> comments
> can exists quite a long time and it seems that these are frequently
> overlooked.
>
> Should we not also have a setup in JIRA regarding the web and wiki
> pages?
>
> This helps us to stay aware of bugs and improvements thereof, and help
> us
> to track contributors and patches. Having JIRA issues for this seems to
> be
> done also in a number of other Apache projects.
>
> Regards,
>
> Pierre Smits
>
> *ORRTIZ.COM *
> Services & Solutions for Cloud-
> Based Manufacturing, Professional
> Services and Retail & Trade
> http://www.orrtiz.com
>
>
>

Re: Theme bootstrap

2014-10-23 Thread Pierre Smits

Tja

We have to make due with what we have got.

Regards,

Pierre Smits

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

On Thu, Oct 23, 2014 at 10:48 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

>
> Le 23/10/2014 09:57, Pierre Smits a écrit :
>
>> Hi Pierre, All,
>>
>> Using an umbrella task in JIRA with for each app/component a sub task and
>> for each set of elements (menus, screens, forms, etc) a sub of sub task,
>>
>
> You can't have sub-sub-tasks in Jira, only sub-tasks
>
> Jacques
>

[jira] [Created] (OFBIZ-5839) Have the caroussel at the home page show images + bylines related to all apps

Pierre Smits created OFBIZ-5839:
---

 Summary: Have the caroussel at the home page show images + bylines 
related to all apps
 Key: OFBIZ-5839
 URL: https://issues.apache.org/jira/browse/OFBIZ-5839
 Project: OFBiz
  Issue Type: Improvement
  Components: site
Reporter: Pierre Smits


Currently the majority of the images and bylines are related to eCommerce. This 
could/should reflect other capabilities as well, e.g. by showing images and 
bylines related to the applications.



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

Re: Theme bootstrap



Le 23/10/2014 09:57, Pierre Smits a écrit :

Hi Pierre, All,

Using an umbrella task in JIRA with for each app/component a sub task and
for each set of elements (menus, screens, forms, etc) a sub of sub task,


You can't have sub-sub-tasks in Jira, only sub-tasks

Jacques


you'll have the structure that will also deliver the milestones.

As an alternative, you could use OFBiz ProjectMgr to manage this
(components as phases, component elements as tasks, but then you'll need to
have access to an OFBiz implementation that is available over a longer
period of time (demo doesn't cut it as it is cleaned every night).

A structure could look like:

Bootstrapping HTML5 CSS ETC (the umbrella Task)

- Theme aspects (sub task)
   - CSS (sub of sub task)
   - etc
- App 1
   - menus
   - screens
   - forms
   - etc
- App 2
- .
- .
- App N
- Development documentation


This way the completion of each sub of sub and sub task is a mile stone.
And as soon as all tasks are completed it can be considered implementation
ready.

I believe that we shouldn't consider revamping all themes currently
available in this.. If people want to have a specific theme revamped, they
can create the appropriate JIRA issues and work on that after this major
endeavour is completed.

Regards,

Pierre Smits

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

On Thu, Oct 23, 2014 at 8:46 AM, pierre  wrote:


Hi all,

One thing which seems to me important:
  It would be great to add a milestone of screens customisation. Even if
screens are thought well, for very numerous customer projects, it is often
necessary to modify screens to adapt them.

The idea is to make customizable screens without having to modify the
source code.

  I see at least 3 levels of configuration:
   - the menu:  mask / show items
   - the general structure of page :  Be able to add or mask a
"portlet" or " widget"
   - the structure of a form : be able to mask / to show fields.

All this should be done by a configuration in basis.

There is a technique of portlets already existing into OFBiz, I find that
it may be a good starting point.

Do you think it could be added as a milestone?

Pierre


On 23/10/2014 08:12, Julien NICOLAS wrote:


Hi Taher,

Le 21/10/2014 18:26, Taher Alkhateeb a écrit :


Hi Julien,

I think it might be a bit challenging and early to start creating teams
specialized in certain functions this early on.


Maybe team is not the word, we could tell "work group". Work group will
probably contain same people.


   We did not yet define what
we're going to do nor do we have a real feel for the size of this job and
the best way to split efforts, not to mention that some of the tasks are
probably dependent on each other.


Yes, it was a suggestion. And as you mention, tasks are dependent on each
other. That's why I wanted to go further.


If I may suggest instead, we need to perhaps go through the tasks
themselves and see what needs to be accomplished. To that end, I would
focus on the deliverables themselves in the beginning such as:

- Identify the major milestones or objectives
- Discuss and decide upon the best methodology for implementation of the
above objectives
- Decide on a collaboration platform (in addition to what exists) if any.
- Dive into code directly and just hand off tasks to volunteers who find
them interesting / appealing from the team

Once we get the project into momentum and you have enough interested and
dedicated people then you can put some structure and specialization into
it.


Right !


Now to that end, I would suggest the following major milestones as
necessary

- Integration of bootstrap and its dependencies to the framework,
specifically into the widget system


For this point I suggest to work on this way : Create tool to delegate
HTML widget structure (and other structure) into theme framework.
To be clear, I suggest to not integrate bootstrap only but modify the
framework to allow any other HTML/CSS frameworks integration without
modifying the OFBiz framework.
But we'll do it for bootstrap first.


- The utilization of bootstrap into the themes (each theme as a
milestone)
- Documentation including XSD file definitions, wiki, DocBook stuff etc
...
- Standardization of the UI everywhere (perhaps each component as a
milestone)

What do you think?


If everybody is ok, we can start the first step \o/

Thanks Taher,

Julien.


Taher Alkhateeb

On Tue, Oct 21, 2014 at 11:18 AM, Julien NICOLAS <
julien.nico...@nomaka.fr>
wrote:

  Hi,

My apologize for answering late, I was deep under the annual balance
sheet
for my company...
Thanks Jonatan for informations.

I try to find specific theme for the front end in the branch that you
told
me but I can't find were it can be enable... I didnt' search a lot so
maybe
it was just closed to my nose and I didn't seen it... ^^

[jira] [Created] (OFBIZ-5838) Have a descriptive page per application

Pierre Smits created OFBIZ-5838:
---

 Summary: Have a descriptive page per application
 Key: OFBIZ-5838
 URL: https://issues.apache.org/jira/browse/OFBIZ-5838
 Project: OFBiz
  Issue Type: Improvement
  Components: site
Reporter: Pierre Smits


Each application should have a page describing (briefly) what it is about.



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

[jira] [Created] (OFBIZ-5837) Rewrite the 'community' page

Pierre Smits created OFBIZ-5837:
---

 Summary: Rewrite the 'community' page
 Key: OFBIZ-5837
 URL: https://issues.apache.org/jira/browse/OFBIZ-5837
 Project: OFBiz
  Issue Type: Improvement
  Components: site
Reporter: Pierre Smits


Rewrite the community page to make it more appealing/inviting to participate in 
the project.



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

[jira] [Created] (OFBIZ-5836) Integrate web analytics into the website