date:20141221


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

Scott Gray commented on OFBIZ-5035:
---

It looks like this problem popped up because of the introduction of the 
CatalogUrlFilter and ContentUrlFilter.  

The filters access the parameter map before the code in the RequestHandler gets 
the opportunity to set the request's character encoding to UTF-8, once the 
parameters are parsed on first access setting the character encoding afterwards 
has no effect. Because these filters are mapped to all path requests they also 
affect the normal /control/ path, which wouldn't have had this issue prior to 
their introduction.

We need to find somewhere very early in the request handling to set character 
encoding to UTF-8.  We can either add tomcat's SetCharacterEncodingFilter to 
all of the web.xml files or we can add similar code to the ContextFilter and 
ensure it is always the first filter to run.

> Special characters (latin, accent ...) are in error from an input (search, 
> contact us ...)
> --
>
> Key: OFBIZ-5035
> URL: https://issues.apache.org/jira/browse/OFBIZ-5035
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Trunk
> Environment: trunk-r1384251
>Reporter: Eric de Maulde
>Priority: Minor
>
> When a user tapes a special character on a search field or a contact us 
> field, OFBiz sends back a wrong character.
> Try on : http://demo-trunk.ofbiz.apache.org/ecommerce
> This error doesn't appear on old stable version : 10.04 & 09.04
> http://demo-stable.ofbiz.apache.org/ecommerce
> http://demo-old.ofbiz.apache.org/ecommerce



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

[jira] [Updated] (OFBIZ-5035) Special characters (latin, accent ...) are in error from an input (search, contact us ...)


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

Scott Gray updated OFBIZ-5035:
--
Priority: Major  (was: Minor)

> Special characters (latin, accent ...) are in error from an input (search, 
> contact us ...)
> --
>
> Key: OFBIZ-5035
> URL: https://issues.apache.org/jira/browse/OFBIZ-5035
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Trunk
> Environment: trunk-r1384251
>Reporter: Eric de Maulde
>
> When a user tapes a special character on a search field or a contact us 
> field, OFBiz sends back a wrong character.
> Try on : http://demo-trunk.ofbiz.apache.org/ecommerce
> This error doesn't appear on old stable version : 10.04 & 09.04
> http://demo-stable.ofbiz.apache.org/ecommerce
> http://demo-old.ofbiz.apache.org/ecommerce



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

Re: Creating a new release branch before the end of the year ("release14.12")

2014-12-21 Thread Jacopo Cappellato

In the past we have been flexible when we had to backport refactoring work to 
newly created branches, and we could continue this approach now.
As regards the specific changes, I am fine with Adrian's work but I am not sure 
about merging SEO because if I am not wrong it a debated change. By the way, 
this is not a discussion limited to backporting to the new release but rather 
about merging to trunk first.

Jacopo

On Dec 21, 2014, at 8:52 PM, Jacques Le Roux  
wrote:

> A I see it, the problem is more if we agree or not to allow Adrian's and my 
> changes to be committed in the branch after it's freezed.
> If not I think we should delay freezing the branch until those efforts are 
> committed in trunk.
> And we should both try to do it ASAP if others feel they are waiting for us.
> 
> Jacques
> 
> Le 21/12/2014 20:21, Jacopo Cappellato a écrit :
>> On Dec 21, 2014, at 3:48 PM, Taher Alkhateeb  
>> wrote:
>> 
>>> I think we agree to a large degree with your proposition in the below 
>>> archived thread Jacques. We see little advantage in upgrading our systems 
>>> to newer versions of OFBiz because the new features do not seem to be that 
>>> major!
>> In my opinion the amount of work done in the trunk since the creation of 
>> 13.07 is remarkable and definitely worth of a release branch: of course we 
>> can discuss timing and preferences but I wouldn't postpone just because of 
>> this consideration.
>> 
>> Jacopo
>>

[jira] [Updated] (OFBIZ-5920) Incorrect use of if-has-permission tag


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

Deepak Dixit updated OFBIZ-5920:

Description: 
action value used in if-has-permission tag is incorrect in some places. Ideally 
action value should be start with "_" but some places it used without "_"

ForumScreens.xml#ViewForumMessage
{code}

{code}

Due to this if user has correct permission then also it return false and user 
will not be able to view the screen.

  was:
action value used in if-has-permission tag is incorrect in some places. Ideally 
action value should be start with "_" but some places it used without "_"

ForumScreens.xml#ViewForumMessage
{code}

{code}

Due to this if user has correct permission then also it return false and user 
will be able to view the screen.


> Incorrect use of if-has-permission tag
> --
>
> Key: OFBIZ-5920
> URL: https://issues.apache.org/jira/browse/OFBIZ-5920
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 13.07, Trunk
>Reporter: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-5920.patch
>
>
> action value used in if-has-permission tag is incorrect in some places. 
> Ideally action value should be start with "_" but some places it used without 
> "_"
> ForumScreens.xml#ViewForumMessage
> {code}
> 
> {code}
> Due to this if user has correct permission then also it return false and user 
> will not be able to view the screen.



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

[jira] [Updated] (OFBIZ-5920) Incorrect use of if-has-permission tag


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

Deepak Dixit updated OFBIZ-5920:

Attachment: OFBIZ-5920.patch

Here is the patch for this issue, found some more places where 
if-has-permission tag used in different way, will create a new ticket to fix 
the if-has-permission tags and will used the consistent pattern.

> Incorrect use of if-has-permission tag
> --
>
> Key: OFBIZ-5920
> URL: https://issues.apache.org/jira/browse/OFBIZ-5920
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 13.07, Trunk
>Reporter: Deepak Dixit
>Priority: Minor
> Attachments: OFBIZ-5920.patch
>
>
> action value used in if-has-permission tag is incorrect in some places. 
> Ideally action value should be start with "_" but some places it used without 
> "_"
> ForumScreens.xml#ViewForumMessage
> {code}
> 
> {code}
> Due to this if user has correct permission then also it return false and user 
> will be able to view the screen.



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

[jira] [Commented] (OFBIZ-3321) Trying to wiew a forum message in eCommerce shows an error


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

Deepak Dixit commented on OFBIZ-3321:
-

Hi Jacques,

There is an permission check on add forum response screen, If user has 
CONTENTMGR_CRAETE permission then only add response section will be rendered.
I think we need to add the CONTENTMGR_CREATE permission for  ECOMMERCE_CUSTOMER 
 group.

Also action passed in if-has-permission tag is not correct, it should be 
"_CREATE".  Created another ticket to fix this issue OFBIZ-5920

> Trying to wiew a forum message in eCommerce shows an error
> --
>
> Key: OFBIZ-3321
> URL: https://issues.apache.org/jira/browse/OFBIZ-3321
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 09.04, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> OOTB 
> Error in eCommerce : <@renderSubContentCache mapKey="ARTICLE" 
> wrapTemplateId=""/>  
> URL : 
> http://localhost:8080/ecommerce/control/ViewForumMessage?forumId=GIZMOS&responseContentId=thread10021&threadContentId=thread10021
> This problem exists also in R9.04



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

[jira] [Created] (OFBIZ-5920) Incorrect use of if-has-permission tag

Deepak Dixit created OFBIZ-5920:
---

 Summary: Incorrect use of if-has-permission tag
 Key: OFBIZ-5920
 URL: https://issues.apache.org/jira/browse/OFBIZ-5920
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, Release Branch 13.07
Reporter: Deepak Dixit
Priority: Minor


action value used in if-has-permission tag is incorrect in some places. Ideally 
action value should be start with "_" but some places it used without "_"

ForumScreens.xml#ViewForumMessage
{code}

{code}

Due to this if user has correct permission then also it return false and user 
will be able to view the screen.



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

Re: svn commit: r1646917 - /ofbiz/trunk/framework/common/src/org/ofbiz/common/FindServices.java

2014-12-21 Thread Ashish Vijaywargiya

Thanks Adrian. Improved code in trunk at r1647239.

--
Ashish

On Sat, Dec 20, 2014 at 9:35 PM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:

> boolean distinct = "Y".equals(context.get("distinct"));
>
> Adrian Crum
> Sandglass Software
> www.sandglass-software.com
>
>
> On 12/20/2014 5:48 AM, ash...@apache.org wrote:
>
>> Author: ashish
>> Date: Sat Dec 20 05:48:51 2014
>> New Revision: 1646917
>>
>> URL: http://svn.apache.org/r1646917
>> Log:
>> Bug fix, one small conditional check got missed in OFBIZ-5844 - Convert
>> java files to EntityQuery.
>>
>> Modified:
>>  ofbiz/trunk/framework/common/src/org/ofbiz/common/FindServices.java
>>
>> Modified: ofbiz/trunk/framework/common/src/org/ofbiz/common/
>> FindServices.java
>> URL: http://svn.apache.org/viewvc/ofbiz/trunk/framework/common/
>> src/org/ofbiz/common/FindServices.java?rev=1646917&
>> r1=1646916&r2=1646917&view=diff
>> 
>> ==
>> --- ofbiz/trunk/framework/common/src/org/ofbiz/common/FindServices.java
>> (original)
>> +++ ofbiz/trunk/framework/common/src/org/ofbiz/common/FindServices.java
>> Sat Dec 20 05:48:51 2014
>> @@ -603,6 +603,7 @@ public class FindServices {
>>   EntityConditionList entityConditionList =
>> UtilGenerics.cast(context.get("entityConditionList"));
>>   List orderByList = checkList(context.get("orderByList"),
>> String.class);
>>   boolean noConditionFind = "Y".equals(context.get("
>> noConditionFind"));
>> +boolean distinct = "Y".equals(context.get("distinct"))? true :
>> false;
>>   List fieldList =  UtilGenerics.checkList(
>> context.get("fieldList"));
>>   Locale locale = (Locale) context.get("locale");
>>   Set fieldSet = null;
>> @@ -624,7 +625,7 @@ public class FindServices {
>>   .orderBy(orderByList)
>>   .cursorScrollInsensitive()
>>   .maxRows(maxRows)
>> -.distinct()
>> +.distinct(distinct)
>>   .queryIterator();
>>   listSize = listIt.getResultsSizeAfterPartialList();
>>   }
>>
>>
>>

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Scott Gray commented on OFBIZ-5704:
---

Yes it is an established pattern for cases where a many-to-many relationship to 
Party is needed, but there's also plenty of examples where many-to-one is all 
that is needed so this pattern isn't followed (and some models use both 
approaches).  When I read through this ticket I was ready to comment in favor 
of your suggestion the same as everyone else, but then I couldn't come up with 
an additional association to Party to use as an example of why your design was 
needed so I decided to discuss that.  

My understanding of lots/batches is that a reseller needs to track the lot id 
for product recalls and for product returns (determining if a lot has abnormal 
QC issues).  Manufacturers using lots in OFBiz don't really need to track 
information using the Lot entity because the production run and inventory item 
models should capture everything that needs to be known about the lot.

Getting mad about the discussion or resorting to ad hominem arguments doesn't 
do anything to further the issue.  I thought it would be straightforward to get 
a use case that makes sense so that we could go with your approach and get on 
with life.  I couldn't care less who is right and who is wrong, I just want our 
designs (particularly data model) to match known/likely use cases.

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer

2014-12-21 Thread Adrian Crum (JIRA)


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

Adrian Crum commented on OFBIZ-5704:


Scott, Here is the cold hard reality of this issue: I suggested an intersection 
entity so that this feature follows a common design pattern found throughout 
the project. Others agree that is how things are done in the project. The rest 
of this issue is nothing more than a silly pissing contest. Look at how much 
typing Pierre has done so he can argue for argument's sake. Had he followed my 
advice, creating an intersection entity and a Mini-language service would have 
been LESS typing than he has done here. So, it is clear from this issue that 
Pierre is more interested in arguing than he is in contributing good code.

I would have been happy to give a more detailed use case, but it is clear that 
I am wasting my time. Nothing you or I say will change Pierre's mind - so I'm 
done.

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Scott Gray commented on OFBIZ-5704:
---

It's not about ignoring your advice Adrian.  It's more a case that to follow 
your advice as it stands currently would be to follow it blindly.  

For your use case you've given the absolute bare minimum required to form a 
single coherent sentence.

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5915) Error when viewing Shipment Plan from Manufacturing


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

Scott Gray commented on OFBIZ-5915:
---

Note: this is no longer applicable to the trunk since the switch to 
EntityQuery.  The other releases still need to be checked to see if they have 
the same problem though.

> Error when viewing Shipment Plan from Manufacturing
> ---
>
> Key: OFBIZ-5915
> URL: https://issues.apache.org/jira/browse/OFBIZ-5915
> Project: OFBiz
>  Issue Type: Bug
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Christian Carlow
> Attachments: OFBIZ-5915.patch
>
>
> This error appears when clicking on a shipment plan from the Manufacturing 
> Shipment Plans:  Error running script at location 
> [component://manufacturing/webapp/manufacturing/WEB-INF/actions/jobshopmgt/WorkWithShipmentPlans.groovy]:
>  java.lang.ClassCastException: java.util.LinkedHashMap cannot be cast to 
> java.lang.String
> The error is caused by an invalid call to delegator.findByAnd at line of 150 
> of WorkWithShipmentPlans.groovy.
> To reproduce:
> 1.  Create an order for an item associated with a ship group
> 2.  After order creation click "New Shipment" for the ship group
> 3.  Change the shipment status to "Scheduled'
> 4.  Add a Shipment Plan
> 5.  Navigate to Manufacturing -> Shipment Plans
> 6.  Click "View" for the shipment plan



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer

2014-12-21 Thread Adrian Crum (JIRA)


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

Adrian Crum commented on OFBIZ-5704:


I don't agree. I had a client who was a packaging company and lots had people 
assigned to them in various roles.

I gave my use case as requested. You are free to ignore my advice and do as you 
please.

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5916) Tasks Report from Manufacturing Shipment Plans throws error due to due to missing EntityCondition import


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

Scott Gray commented on OFBIZ-5916:
---

I'm a little confused here, your patch fix seems valid but not for the error 
you reported above.

The issue in the error posted in the description is that 'records' variable 
doesn't exist when records.add(...) is called in 
ShipmentWorkEffortTasks.groovy.  Did you upload the wrong patch for this ticket?

> Tasks Report from Manufacturing Shipment Plans throws error due to due to 
> missing EntityCondition import
> 
>
> Key: OFBIZ-5916
> URL: https://issues.apache.org/jira/browse/OFBIZ-5916
> Project: OFBiz
>  Issue Type: Bug
>  Components: manufacturing
>Affects Versions: Trunk
>Reporter: Christian Carlow
>Priority: Minor
> Attachments: OFBIZ-5916.patch
>
>
> This error occurs when clicking the "Tasks Report" button from the 
> Manufacturing -> Shipment Plans page once a production run has been created 
> for a planned shipment:
> Error running script at location 
> [component://manufacturing/webapp/manufacturing/WEB-INF/actions/reports/ShipmentWorkEffortTasks.groovy]:
>  groovy.lang.MissingPropertyException: No such property: records for class: 
> ShipmentWorkEffortTasks
> To reproduce:
> 1.  Create a shipment with status Schedued and a planned item
> 2.  Navigate to Manufacturing -> Shipment Plans and click "Create Production 
> Runs" for the shipment
> 3.  Click the "Tasks Report" button that appears once Production Runs have 
> been created



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Pierre Smits commented on OFBIZ-5704:
-

No, these incoming/outgoing innspections are related to the inventory items 
related to the shipment, when they are related to the goods of the shipment.

As for regulatory inspection, these are related to a) the goods produced (hence 
inventory item), or b) the process. Doing regulatory inspection of something in 
transition (like manufacturing is - especially when talking about process 
oriented manufacturing, like food and beverages, chemicals, pharmaceuticals, 
etc) is regarded as error prone. Because circumstances and result change the 
moment after the inspection.

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Updated] (OFBIZ-5919) CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist


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

Scott Gray updated OFBIZ-5919:
--
Summary: CatalogUrlServlet should return a 404 HTTP status if the category 
or product does not exist  (was: Category not found for Category ID 
dropShip1-err)

> CatalogUrlServlet should return a 404 HTTP status if the category or product 
> does not exist
> ---
>
> Key: OFBIZ-5919
> URL: https://issues.apache.org/jira/browse/OFBIZ-5919
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>
> To test: 
> http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err
> Doesn't work: Says catalog not found, but the logs show http status 200.



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

[jira] [Commented] (OFBIZ-5919) CatalogUrlServlet should return a 404 HTTP status if the category or product does not exist


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

Scott Gray commented on OFBIZ-5919:
---

Okay thanks I've changed the title to something a bit more useful.

> CatalogUrlServlet should return a 404 HTTP status if the category or product 
> does not exist
> ---
>
> Key: OFBIZ-5919
> URL: https://issues.apache.org/jira/browse/OFBIZ-5919
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>
> To test: 
> http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err
> Doesn't work: Says catalog not found, but the logs show http status 200.



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

[jira] [Comment Edited] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Pierre Smits edited comment on OFBIZ-5704 at 12/21/14 11:15 PM:


Yes, such roles (except Manufacturer) can be applicable in an organisation and 
its manufacturing and warehousing related business processes. But, only a 
manufacturer (internal or external) is directly related to an entire lot. 

The others roles can only be related to parts of the lot (via inventory items, 
and inventory item details) at best. E.g. when a good is externally 
manufactured, the persons involved in inspection can only assess inventory 
items the - internal - company has stock. They can't be in control of, or 
otherwise asserting something about goods that are not under the influence (or 
control) of the - control - company. 


was (Author: pfm.smits):
Yes, such roles (except Manufacturer) can be applicable in an organisation and 
its manufacturing and warehousing related business processes. But, only a 
manufacturer (internal or external) is directly related to an entire lot. 

The others roles can only be related to parts of the lot (via inventory items, 
and inventory items) at best. E.g. when a good is externally manufactured, the 
persons involved in inspection can only assess inventory items the - internal - 
company has stock. They can't be in control of, or otherwise asserting 
something about goods that are not under the influence (or control) of the - 
control - company. 

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Scott Gray commented on OFBIZ-5704:
---

Incoming/Outgoing inspections would more likely be associated to a Shipment 
since there's nothing about a lot/batch that says they move as one.
Product packaging would form part of the production run and shipment packaging 
part of the shipment.
Regulatory Inspection would again form part of the production run or shipment I 
would assume.



> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Comment Edited] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Pierre Smits edited comment on OFBIZ-5704 at 12/21/14 11:14 PM:


Yes, such roles (except Manufacturer) can be applicable in an organisation and 
its manufacturing and warehousing related business processes. But, only a 
manufacturer (internal or external) is directly related to an entire lot. 

The others roles can only be related to parts of the lot (via inventory items, 
and inventory items) at best. E.g. when a good is externally manufactured, the 
persons involved in inspection can only assess inventory items the - internal - 
company has stock. They can't be in control of, or otherwise asserting 
something about goods that are not under the influence (or control) of the - 
control - company. 


was (Author: pfm.smits):
Yes, such roles (except Manufacturer) can applicable in an organisation and its 
manufacturing and warehousing related business processes. But, only a 
manufacturer (internal or external) is directly related to an entire lot. 

The others roles can only be related to parts of the lot (via inventory items, 
and inventory items) at best. E.g. when a good is externally manufactured, the 
persons involved in inspection can only assess inventory items the - internal - 
company has stock. They can't be in control of, or otherwise asserting 
something about goods that are not under the influence (or control) of the - 
control - company. 

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Pierre Smits commented on OFBIZ-5704:
-

Yes, such roles (except Manufacturer) can applicable in an organisation and its 
manufacturing and warehousing related business processes. But, only a 
manufacturer (internal or external) is directly related to an entire lot. 

The others roles can only be related to parts of the lot (via inventory items, 
and inventory items) at best. E.g. when a good is externally manufactured, the 
persons involved in inspection can only assess inventory items the - internal - 
company has stock. They can't be in control of, or otherwise asserting 
something about goods that are not under the influence (or control) of the - 
control - company. 

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

Broken demo

2014-12-21 Thread Pierre Smits

It seems that our demo-stable is broken. I get a
'org.ofbiz.webapp.view.ViewHandlerException:
No handler found for type: screen' when trying to access catalog. It also
happened when trying to access webtools.

Pierre Smits

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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer

2014-12-21 Thread Adrian Crum (JIRA)


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

Adrian Crum commented on OFBIZ-5704:


Potential Lot Roles:

Incoming Inspection
Outgoing Inspection
Manufacturer
Packager
Regulatory Inspector


> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Scott Gray commented on OFBIZ-5704:
---

It seems the contentious debate here is whether there should be a 
manufacturerPartyId on the Lot entity or if we should support the ability to 
assign multiple parties in various roles to a Lot using a new LotRole entity.

There is nothing inherently wrong with using a manufacturerPartyId field if 
that is all that the currently known requirements dictate.  The reason not to 
is because the data model is a pain to change if we later decide we need to be 
able to assign more parties to a Lot.

So my opinion is that unless we know of a use case for multiple party 
assignment to Lots then we should use Pierre's single party assignment 
approach.  If we do know of a use case for multi party assignment to Lots then 
I agree with Adrian the a LotRole entity would make more sense.  But without 
known use cases we can't even be sure that a LotRole entity would fill a useful 
need when there's the possibility that each party assignment would require 
different supplementary data and thus require a completely different data model 
design.

Adrian, IMO it is not fair to disagree and claim a design flawed without at 
least providing a real world use case (even if only hypothetical) that the 
design fails to accommodate.

tldr: If we don't have a use case for multiple parties then let's use Pierre's 
approach.

> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

[jira] [Commented] (OFBIZ-1110) Default FOP Font


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

Jacques Le Roux commented on OFBIZ-1110:


OK, I created a new issue for that: OFBIZ-5917

> Default FOP Font
> 
>
> Key: OFBIZ-1110
> URL: https://issues.apache.org/jira/browse/OFBIZ-1110
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Krzysztof Podejma
>Assignee: Jacopo Cappellato
> Fix For: Trunk
>
> Attachments: widget.diff
>
>
> current ofbiz(OOTB) reporting does not support multilingual users. When you 
> use non-english locale you get '#" characters.
> additionally it is hard to track all changes in reports so here default font 
> comes up. 
> it would be great to add fop.xcon file to trunk with UNICODE font that could 
> print any characters in any languages.
> I've made up two another solutions 1) is a property in general.properties 
> that store default font
> 2) to associate font-family name  with locale as property (in property file) 
> and use this font-family to print reports in user language properly.
> with second solution users can define what fonts they have and want to use



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

[jira] [Commented] (OFBIZ-5919) Category not found for Category ID dropShip1-err


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

Jacques Le Roux commented on OFBIZ-5919:


It comes from here 
https://issues.apache.org/jira/browse/OFBIZ-4390?focusedCommentId=13162213

> Category not found for Category ID dropShip1-err
> 
>
> Key: OFBIZ-5919
> URL: https://issues.apache.org/jira/browse/OFBIZ-5919
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>
> To test: 
> http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err
> Doesn't work: Says catalog not found, but the logs show http status 200.



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

[jira] [Commented] (OFBIZ-5919) Category not found for Category ID dropShip1-err


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

Scott Gray commented on OFBIZ-5919:
---

What exactly is the issue Jacques?  dropShip1-err doesn't exist...

> Category not found for Category ID dropShip1-err
> 
>
> Key: OFBIZ-5919
> URL: https://issues.apache.org/jira/browse/OFBIZ-5919
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>
> To test: 
> http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err
> Doesn't work: Says catalog not found, but the logs show http status 200.



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

[jira] [Commented] (OFBIZ-5807) Upgraded to Freemarker 2.3.21


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

Jacques Le Roux commented on OFBIZ-5807:


I don't think there are any. I will double check and if there are none I will 
remove Fixed and Implemented to keep thinks as simple as possible.

> Upgraded to Freemarker 2.3.21
> -
>
> Key: OFBIZ-5807
> URL: https://issues.apache.org/jira/browse/OFBIZ-5807
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
> Fix For: Upcoming Branch, 13.07.02
>
>




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

Re: Creating a new release branch before the end of the year ("release14.12")


A I see it, the problem is more if we agree or not to allow Adrian's and my 
changes to be committed in the branch after it's freezed.
If not I think we should delay freezing the branch until those efforts are 
committed in trunk.
And we should both try to do it ASAP if others feel they are waiting for us.

Jacques

Le 21/12/2014 20:21, Jacopo Cappellato a écrit :

On Dec 21, 2014, at 3:48 PM, Taher Alkhateeb  wrote:


I think we agree to a large degree with your proposition in the below archived 
thread Jacques. We see little advantage in upgrading our systems to newer 
versions of OFBiz because the new features do not seem to be that major!

In my opinion the amount of work done in the trunk since the creation of 13.07 
is remarkable and definitely worth of a release branch: of course we can 
discuss timing and preferences but I wouldn't postpone just because of this 
consideration.

Jacopo

[jira] [Commented] (OFBIZ-5807) Upgraded to Freemarker 2.3.21

2014-12-21 Thread Jacopo Cappellato (JIRA)


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

Jacopo Cappellato commented on OFBIZ-5807:
--

Frankly speaking I don't care much: Done, Fixed, Implemented are equivalent in 
this context.
Or am I missing some Jira feature that is using this information?

> Upgraded to Freemarker 2.3.21
> -
>
> Key: OFBIZ-5807
> URL: https://issues.apache.org/jira/browse/OFBIZ-5807
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
> Fix For: Upcoming Branch, 13.07.02
>
>




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

Re: Creating a new release branch before the end of the year ("release14.12")

2014-12-21 Thread Jacopo Cappellato

On Dec 21, 2014, at 3:48 PM, Taher Alkhateeb  wrote:

> I think we agree to a large degree with your proposition in the below 
> archived thread Jacques. We see little advantage in upgrading our systems to 
> newer versions of OFBiz because the new features do not seem to be that 
> major! 

In my opinion the amount of work done in the trunk since the creation of 13.07 
is remarkable and definitely worth of a release branch: of course we can 
discuss timing and preferences but I wouldn't postpone just because of this 
consideration.

Jacopo

Re: Creating a new release branch before the end of the year ("release14.12")

2014-12-21 Thread Sharan Foga

Hi Taher

At least two of your proposed milestones are in the draft project roadmap
that is currently out for community feedback.

I'm currently travelling so cant include the links but please search this
list for my post on project vision, direction and roadmap.

I would encouge anyone who has an opinion to provide feedback so that we
can look at incorporating them.

Thanks
Sharan
On 21 Dec 2014 15:49, "Taher Alkhateeb"  wrote:

> Hi Jacques and everyone,
>
> I think we agree to a large degree with your proposition in the below
> archived thread Jacques. We see little advantage in upgrading our systems
> to newer versions of OFBiz because the new features do not seem to be that
> major!
>
> I would prefer slowing down the release cycle and to focus on accumulation
> of enough features to warrant a release. Right now, both branches and
> releases seem to be simply snapshots in time for the project, but I see no
> substantial reward in upgrading nor do I see enough features to wet my
> appetite to play around with the new releases.
>
> For example, here are some milestones that would highly encourage me
> personally to upgrade:
>
> - Major overhaul of the UI (the bootstrap theme project for example)
> - Addition of builtin documentation and completing the contextual help
> system
> - Integration of third party systems (pentaho, CMSs, jackrabbit, etc ...)
> - Substantial improvements to existing components (too much form/field
> clutter in current design)
> - Translations and internationalization improvement
> - Change / upgrade of infrastructure (logging framework, transaction
> management, build systems like gradle, JVM, etc ...)
>
> My 2 cents
>
> Taher Alkhateeb
>
> - Original Message -
>
> From: "Jacques Le Roux" 
> To: dev@ofbiz.apache.org
> Sent: Sunday, 21 December, 2014 5:26:40 PM
> Subject: Re: Creating a new release branch before the end of the year
> ("release14.12")
>
> Just as a reminder http://markmail.org/message/2wwueeciltqxon4r
>
> Jacques
>
> Le 21/12/2014 14:32, Pierre Smits a écrit :
> > Did you get your wires crossed?
> >
> >
> > Pierre Smits
> >
> > *ORRTIZ.COM *
> > Services & Solutions for Cloud-
> > Based Manufacturing, Professional
> > Services and Retail & Trade
> > http://www.orrtiz.com
> >
> > On Sun, Dec 21, 2014 at 11:07 AM, Jacques Le Roux <
> > jacques.le.r...@les7arts.com> wrote:
> >>
> >> Nothing prevent us to not create a relase branch in 2014 and only create
> >> on in 2015 when ready.
> >> Actually, due to Adrian's and my request, I believe we should rather go
> >> that way
> >>
> >> This is as well a good argument to delay the branch creation, even if we
> >> can expect to have all patches reviewed each time we need to create a
> >> branch... but 60... !
> >>
> >> As I said above you invented this policy, we are free to skip a year
> >>
>
>

Re: Creating a new release branch before the end of the year ("release14.12")

2014-12-21 Thread Taher Alkhateeb

Hi Jacques and everyone, 

I think we agree to a large degree with your proposition in the below archived 
thread Jacques. We see little advantage in upgrading our systems to newer 
versions of OFBiz because the new features do not seem to be that major! 

I would prefer slowing down the release cycle and to focus on accumulation of 
enough features to warrant a release. Right now, both branches and releases 
seem to be simply snapshots in time for the project, but I see no substantial 
reward in upgrading nor do I see enough features to wet my appetite to play 
around with the new releases. 

For example, here are some milestones that would highly encourage me personally 
to upgrade: 

- Major overhaul of the UI (the bootstrap theme project for example) 
- Addition of builtin documentation and completing the contextual help system 
- Integration of third party systems (pentaho, CMSs, jackrabbit, etc ...) 
- Substantial improvements to existing components (too much form/field clutter 
in current design) 
- Translations and internationalization improvement 
- Change / upgrade of infrastructure (logging framework, transaction 
management, build systems like gradle, JVM, etc ...) 

My 2 cents 

Taher Alkhateeb 

- Original Message -

From: "Jacques Le Roux"  
To: dev@ofbiz.apache.org 
Sent: Sunday, 21 December, 2014 5:26:40 PM 
Subject: Re: Creating a new release branch before the end of the year 
("release14.12") 

Just as a reminder http://markmail.org/message/2wwueeciltqxon4r 

Jacques 

Le 21/12/2014 14:32, Pierre Smits a écrit : 
> Did you get your wires crossed? 
> 
> 
> Pierre Smits 
> 
> *ORRTIZ.COM * 
> Services & Solutions for Cloud- 
> Based Manufacturing, Professional 
> Services and Retail & Trade 
> http://www.orrtiz.com 
> 
> On Sun, Dec 21, 2014 at 11:07 AM, Jacques Le Roux < 
> jacques.le.r...@les7arts.com> wrote: 
>> 
>> Nothing prevent us to not create a relase branch in 2014 and only create 
>> on in 2015 when ready. 
>> Actually, due to Adrian's and my request, I believe we should rather go 
>> that way 
>> 
>> This is as well a good argument to delay the branch creation, even if we 
>> can expect to have all patches reviewed each time we need to create a 
>> branch... but 60... ! 
>> 
>> As I said above you invented this policy, we are free to skip a year 
>>

Re: Creating a new release branch before the end of the year ("release14.12")


Just as a reminder http://markmail.org/message/2wwueeciltqxon4r

Jacques

Le 21/12/2014 14:32, Pierre Smits a écrit :

Did you get your wires crossed?


Pierre Smits

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

On Sun, Dec 21, 2014 at 11:07 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Nothing prevent us to not create a relase branch in 2014 and only create
on in 2015 when ready.
Actually, due to Adrian's and my request, I believe we should rather go
that way

This is as well a good argument to delay the branch creation, even if we
can expect to have all patches reviewed each time we need to create a
branch... but 60... !

As I said above you invented this policy, we are free to skip a year

Re: Creating a new release branch before the end of the year ("release14.12")

2014-12-21 Thread Pierre Smits

Did you get your wires crossed?


Pierre Smits

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

On Sun, Dec 21, 2014 at 11:07 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:
>
>
> Nothing prevent us to not create a relase branch in 2014 and only create
> on in 2015 when ready.
> Actually, due to Adrian's and my request, I believe we should rather go
> that way
>
> This is as well a good argument to delay the branch creation, even if we
> can expect to have all patches reviewed each time we need to create a
> branch... but 60... !
>
> As I said above you invented this policy, we are free to skip a year
>

[jira] [Comment Edited] (OFBIZ-5325) Deprecate doCacheClear in Delegator interface and class and related minilang classes


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

Jacques Le Roux edited comment on OFBIZ-5325 at 12/21/14 1:00 PM:
--

I removed the deprecated and useless stuff in trunk at revision: 1647132  



was (Author: jacques.le.roux):
I removed the deprecated and useless stuff in trunk

> Deprecate doCacheClear in Delegator interface and class and related minilang 
> classes
> 
>
> Key: OFBIZ-5325
> URL: https://issues.apache.org/jira/browse/OFBIZ-5325
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS, framework
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch, 12.04.06, 13.07.02
>
>
> At http://svn.apache.org/viewvc?view=revision&revision=r1476296 Adrian noted: 
> {quote}
> I updated the Delegator JavaDocs to warn against skipping the cache clearing 
> step - which shouldn't be done
> {quote}
> After I proposed to rather refactor it, Paul Foxworthy suggested:
> {quote}
> If doCacheClear will have no effect, I suggest deprecating the method
> signature with the doCacheClear. It can call another overloaded variant
> without that parameter. All calls in trunk should be changed to the second.
> We can leave the deprecated version for backwards compatibility for a time.
> I agree in the release branches that all we should do is add some JavaDoc
> and log a warning.
> {quote}
> I agree with Paul, and here is how I will do it:
> # Deprecate in trunk
> # Backport in releases
> # Remove useless deprecated in trunk



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

[jira] [Closed] (OFBIZ-4390) Ecommerce Error Page Does Not Work


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

Jacques Le Roux closed OFBIZ-4390.
--
Resolution: Done

Thanks for ther reminder Arun,

I have created OFBIZ-5918 and OFBIZ-5919 for that

I don't put any "Fix version" because the rest has been handled 3 years ago.

> Ecommerce Error Page Does Not Work
> --
>
> Key: OFBIZ-4390
> URL: https://issues.apache.org/jira/browse/OFBIZ-4390
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Reporter: Sam Hamilton
>Assignee: Jacques Le Roux
>Priority: Minor
> Attachments: OFBIZ-4390-error.txt, OFBIZ-4390.patch
>
>
> If you are using the ecommerce app and you force it to generate a 404 error 
> page it redirects back to /control/main.
> You can test the 404 error out here - 
> http://demo-trunk.ofbiz.apache.org/ecommerce/please-give-me-an-error/ 
> This default behaviour will confuse search engines as they expect to get a 
> 404 error if a pages does not exist on a website. 
> As pointed out by Bilgin on the mailing list adding the following code into 
> web.xml should resolve the problem however it just generates more errors due 
> to the redirect to /control/main is in place.
> 
>404
>/error/error.jsp
> 



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

[jira] [Updated] (OFBIZ-5919) Category not found for Category ID dropShip1-err


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

Jacques Le Roux updated OFBIZ-5919:
---
Description: 
To test: 
http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err

Doesn't work: Says catalog not found, but the logs show http status 200.

  was:To test: 
http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err


> Category not found for Category ID dropShip1-err
> 
>
> Key: OFBIZ-5919
> URL: https://issues.apache.org/jira/browse/OFBIZ-5919
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/ecommerce
>Affects Versions: Release Branch 12.04, Release Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>
> To test: 
> http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err
> Doesn't work: Says catalog not found, but the logs show http status 200.



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

[jira] [Created] (OFBIZ-5919) Category not found for Category ID dropShip1-err

Jacques Le Roux created OFBIZ-5919:
--

 Summary: Category not found for Category ID dropShip1-err
 Key: OFBIZ-5919
 URL: https://issues.apache.org/jira/browse/OFBIZ-5919
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, Release Branch 13.07, Release Branch 12.04
Reporter: Jacques Le Roux


To test: 
http://demo-trunk-ofbiz.apache.org/ecommerce/products/dropShip/dropShip1-err



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

[jira] [Created] (OFBIZ-5918) NPE at http://demo-trunk-ofbiz.apache.org/ecommerce/products/

Jacques Le Roux created OFBIZ-5918:
--

 Summary: NPE at 
http://demo-trunk-ofbiz.apache.org/ecommerce/products/
 Key: OFBIZ-5918
 URL: https://issues.apache.org/jira/browse/OFBIZ-5918
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/ecommerce
Affects Versions: Trunk, Release Branch 13.07, Release Branch 12.04
Reporter: Jacques Le Roux






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

[jira] [Closed] (OFBIZ-5325) Deprecate doCacheClear in Delegator interface and class and related minilang classes


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

Jacques Le Roux closed OFBIZ-5325.
--
   Resolution: Fixed
Fix Version/s: Upcoming Branch

I removed the deprecated and useless stuff in trunk

> Deprecate doCacheClear in Delegator interface and class and related minilang 
> classes
> 
>
> Key: OFBIZ-5325
> URL: https://issues.apache.org/jira/browse/OFBIZ-5325
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS, framework
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: Upcoming Branch, 12.04.06, 13.07.02
>
>
> At http://svn.apache.org/viewvc?view=revision&revision=r1476296 Adrian noted: 
> {quote}
> I updated the Delegator JavaDocs to warn against skipping the cache clearing 
> step - which shouldn't be done
> {quote}
> After I proposed to rather refactor it, Paul Foxworthy suggested:
> {quote}
> If doCacheClear will have no effect, I suggest deprecating the method
> signature with the doCacheClear. It can call another overloaded variant
> without that parameter. All calls in trunk should be changed to the second.
> We can leave the deprecated version for backwards compatibility for a time.
> I agree in the release branches that all we should do is add some JavaDoc
> and log a warning.
> {quote}
> I agree with Paul, and here is how I will do it:
> # Deprecate in trunk
> # Backport in releases
> # Remove useless deprecated in trunk



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

Re: Creating a new release branch before the end of the year ("release14.12")

Le 21/12/2014 11:07, Jacques Le Roux a écrit :

Le 20/12/2014 13:02, Pierre Smits a écrit :

Next year release branch 14 can also be created as it follows release
branch 13. This policy of having the branch number (and subsequent major
release number) *always* match the last two digits of the year it is
created in - and thus avoidance of gaps, is limiting us.

Nothing prevent us to not create a relase branch in 2014 and only create on in
2015 when ready.
Actually, due to Adrian's and my request, I believe we should rather go that way

If we create a new branch now in order to meet adherence to that policy, it
means that we are going to exclude the 60 patches available on the JIRA
issues marked as improvement in the upcoming release. Are we sure this is
what we want?

This is as well a good argument to delay the branch creation, even if we can expect to have all patches reviewed each time we need to create a
branch... but 60... !

can't

Creating branches should meet a higher project purpose than just such a
policy.

As I said above you invented this policy, we are free to skip a year

Jacques

Pierre Smits

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

On Fri, Dec 19, 2014 at 7:01 PM, Nicolas Malin
wrote:

I'm neutral, I prefer planed the branch creation like 15.04 instead of
create stable release branch with many synchronize at the begin (so more
work) because some technology swap are in process and enable (and it's good
! :)).

Nicolas

Le 18/12/2014 09:53, Jacopo Cappellato a écrit :

Hi all,

the end of 2014 is getting closer and it would be nice to have a new
release branch created before it ends: its name will be "release14.12"
(14=2014 and 12=December).
In this way we will have a sequential numbering: 10, 11, 12, 13, 14.
Pending the discussion on specialpurpose components (exclude them all
apart from ecommerce as we did in 13.07, include some of them selectively
etc...) I would temporarily include them all, and when we will have a clear
plan of action we will adjust the branch accordingly.

Any objections?

Jacopo

[jira] [Commented] (OFBIZ-5807) Upgraded to Freemarker 2.3.21


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

Jacques Le Roux commented on OFBIZ-5807:


BTW we could keep only Done and have it as default instead of Fixed, KISS way, 
agreed?

> Upgraded to Freemarker 2.3.21
> -
>
> Key: OFBIZ-5807
> URL: https://issues.apache.org/jira/browse/OFBIZ-5807
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
> Fix For: Upcoming Branch, 13.07.02
>
>




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

Re: Jira and releases change logs


Nicolas said he will :p

Jacques

Le 21/12/2014 11:06, Pierre Smits a écrit :

In stead of pointing to past mail threads and to where the explanation
'should' go it is better to put the explanation in said place and point to
there.

Pierre Smits

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

On Sun, Dec 21, 2014 at 11:01 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


To explain why we can reuse Jacopo's explanation
http://markmail.org/message/v3yswhnusu4elta5

And this should go in https://cwiki.apache.org/
confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
http://markmail.org/message/jy3qzmsaoxj56otf

Jacques

Le 21/12/2014 08:45, Jacques Le Roux a écrit :

  Please Nicolas, when you will do it, add that committers should fill the

"Fix Version/s" field with relevant "Unreleased Versions" for improvements
and bug as well

Thanks

Jacques

Le 18/12/2014 08:26, Jacques Le Roux a écrit :


Thanks Nicolas, I wanted to do it, but did not get a chance, your help
is appreciated :)

I take advantage of this mail to correct my sentence below (that's what
happen when you "refactor" ;) )
<>

Jacques

Le 18/12/2014 00:20, Nicolas Malin a écrit :


Ok Jacques,

I propose to complete the page https://cwiki.apache.org/
confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
with your sensible remarks !
I will do that tomorrow.

Nicolas

Le 17/12/2014 15:29, Jacques Le Roux a écrit :


Hi Committers,

Please take the time to correctly fill the different Jira fields we
now use for our releases change logs.

For instance for  in
* Improvement:s use either Done or Implemented Status as you feel right
* New features: use either Implemented Status
* Bug: use the Fixed Status

Don't forget to fill the Fix version/s field according to your
changes. Notably, use Upcoming Branch and not trunk there.

Also, even if when the svn commits comments are correctly done with a
reference to the Jira issue number we can then get to the commits in
Fisheye from the Development section of the Jira issue, I'd still recommend
to put the commits references in a comment. It's always handy, and insures
we have those references at hand even if the commits comments don't contain
the Jira issue reference.

Thanks for all the good work  :)

Jacques

[jira] [Commented] (OFBIZ-5807) Upgraded to Freemarker 2.3.21


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

Jacques Le Roux commented on OFBIZ-5807:


I agree that using done and implemented does not add much, but if they are 
there I think they should be used, else we should remove them, for the sake of 
clarity.

> Upgraded to Freemarker 2.3.21
> -
>
> Key: OFBIZ-5807
> URL: https://issues.apache.org/jira/browse/OFBIZ-5807
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
> Fix For: Upcoming Branch, 13.07.02
>
>




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

[jira] [Updated] (OFBIZ-5325) Deprecate doCacheClear in Delegator interface and class and related minilang classes


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

Jacques Le Roux updated OFBIZ-5325:
---
Fix Version/s: 13.07.02
   12.04.06

> Deprecate doCacheClear in Delegator interface and class and related minilang 
> classes
> 
>
> Key: OFBIZ-5325
> URL: https://issues.apache.org/jira/browse/OFBIZ-5325
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS, framework
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
> Fix For: 12.04.06, 13.07.02
>
>
> At http://svn.apache.org/viewvc?view=revision&revision=r1476296 Adrian noted: 
> {quote}
> I updated the Delegator JavaDocs to warn against skipping the cache clearing 
> step - which shouldn't be done
> {quote}
> After I proposed to rather refactor it, Paul Foxworthy suggested:
> {quote}
> If doCacheClear will have no effect, I suggest deprecating the method
> signature with the doCacheClear. It can call another overloaded variant
> without that parameter. All calls in trunk should be changed to the second.
> We can leave the deprecated version for backwards compatibility for a time.
> I agree in the release branches that all we should do is add some JavaDoc
> and log a warning.
> {quote}
> I agree with Paul, and here is how I will do it:
> # Deprecate in trunk
> # Backport in releases
> # Remove useless deprecated in trunk



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

[jira] [Commented] (OFBIZ-5325) Deprecate doCacheClear in Delegator interface and class and related minilang classes


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

Jacques Le Roux commented on OFBIZ-5325:


Backported in 
R13.07 r1647120
R12.04 r1647121


> Deprecate doCacheClear in Delegator interface and class and related minilang 
> classes
> 
>
> Key: OFBIZ-5325
> URL: https://issues.apache.org/jira/browse/OFBIZ-5325
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS, framework
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>
> At http://svn.apache.org/viewvc?view=revision&revision=r1476296 Adrian noted: 
> {quote}
> I updated the Delegator JavaDocs to warn against skipping the cache clearing 
> step - which shouldn't be done
> {quote}
> After I proposed to rather refactor it, Paul Foxworthy suggested:
> {quote}
> If doCacheClear will have no effect, I suggest deprecating the method
> signature with the doCacheClear. It can call another overloaded variant
> without that parameter. All calls in trunk should be changed to the second.
> We can leave the deprecated version for backwards compatibility for a time.
> I agree in the release branches that all we should do is add some JavaDoc
> and log a warning.
> {quote}
> I agree with Paul, and here is how I will do it:
> # Deprecate in trunk
> # Backport in releases
> # Remove useless deprecated in trunk



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

[jira] [Commented] (OFBIZ-5807) Upgraded to Freemarker 2.3.21

2014-12-21 Thread Jacopo Cappellato (JIRA)


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

Jacopo Cappellato commented on OFBIZ-5807:
--

I wouldn't be too picky (for example I don't see a big added value in marking 
"Done" vs "Fixed" based on the type of ticket): we upgraded the jar because we 
were using a patched version after the official release (with the fix included) 
was released.


> Upgraded to Freemarker 2.3.21
> -
>
> Key: OFBIZ-5807
> URL: https://issues.apache.org/jira/browse/OFBIZ-5807
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
> Fix For: Upcoming Branch, 13.07.02
>
>




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

[jira] [Updated] (OFBIZ-5634) Error in pagination in createProductSubscriptionResource (Catalog)


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

Jacques Le Roux updated OFBIZ-5634:
---
Description: When you paginate, after creating a sufficient number of 
subscriptions for pagination to appear, you get an error  (was: When you create 
paginate after creating a sufficient number of subscriptions for pagination to 
show you get an error)

> Error in pagination in createProductSubscriptionResource (Catalog) 
> ---
>
> Key: OFBIZ-5634
> URL: https://issues.apache.org/jira/browse/OFBIZ-5634
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: product
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Jacques Le Roux
>Priority: Minor
>
> When you paginate, after creating a sufficient number of subscriptions for 
> pagination to appear, you get an error



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

[jira] [Commented] (OFBIZ-5807) Upgraded to Freemarker 2.3.21


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

Jacques Le Roux commented on OFBIZ-5807:


HI Jacopo,

This is a peculiar case were we put an improvement in a release, maybe we could 
add a short explanation?

> Upgraded to Freemarker 2.3.21
> -
>
> Key: OFBIZ-5807
> URL: https://issues.apache.org/jira/browse/OFBIZ-5807
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Reporter: Jacopo Cappellato
>Assignee: Jacopo Cappellato
> Fix For: Upcoming Branch, 13.07.02
>
>




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

[jira] [Commented] (OFBIZ-5917) Improve the way FOP handles fonts notably for currency symbols


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

Jacques Le Roux commented on OFBIZ-5917:


A I forgot one thing (more a reminder for myself), the LICENSE file should be 
updated about the NotoSans font.

> Improve the way FOP handles fonts notably for currency symbols
> --
>
> Key: OFBIZ-5917
> URL: https://issues.apache.org/jira/browse/OFBIZ-5917
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: rupee, symbol
> Fix For: Upcoming Branch
>
>
> In the dev ML I suggested we could add
> 
> in the fonts section of our fop.xconf
> We can do more than that. For instance currently there are no easy ways to 
> render the "new" (since 2010) rupee symbol: ₹.
> One is to use the Google NotoSans font which is Apache licensed
> * http://www.google.com/fonts/specimen/Noto+Sans
> * https://www.google.com/get/noto/#/
> We need also to
> * Add the rupee symbol (₹) to antisamy-esapi.xml file like we have the euro 
> symbol (€)
> * Use NotoSans as the default FOP font. For that we can put the NotoSans font 
> 4 files in framework/resources/fonts and add 
> framework/resources/fonts/NotoSansFonts in our 
> fop.xconf
> * Render ₹ in content/control/fonts.pdf as we do for €. Other symbols could 
> be added later when needed, backed by Google NotoSans font...



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

Re: FOP fonts detection


I have created https://issues.apache.org/jira/browse/OFBIZ-5917 for that

Jacques

Le 19/12/2014 13:53, Jacques Le Roux a écrit :

Hi,

Would anybody minds if we add

in the fonts section of our fop.xconf?

Jacques

[jira] [Created] (OFBIZ-5917) Improve the way FOP handles fonts notably for currency symbols

Jacques Le Roux created OFBIZ-5917:
--

 Summary: Improve the way FOP handles fonts notably for currency 
symbols
 Key: OFBIZ-5917
 URL: https://issues.apache.org/jira/browse/OFBIZ-5917
 Project: OFBiz
  Issue Type: Improvement
  Components: framework
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux
Priority: Minor
 Fix For: Upcoming Branch


In the dev ML I suggested we could add

in the fonts section of our fop.xconf

We can do more than that. For instance currently there are no easy ways to 
render the "new" (since 2010) rupee symbol: ₹.

One is to use the Google NotoSans font which is Apache licensed
* http://www.google.com/fonts/specimen/Noto+Sans
* https://www.google.com/get/noto/#/

We need also to
* Add the rupee symbol (₹) to antisamy-esapi.xml file like we have the euro 
symbol (€)
* Use NotoSans as the default FOP font. For that we can put the NotoSans font 4 
files in framework/resources/fonts and add 
framework/resources/fonts/NotoSansFonts in our fop.xconf
* Render ₹ in content/control/fonts.pdf as we do for €. Other symbols could be 
added later when needed, backed by Google NotoSans font...




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

[jira] [Updated] (OFBIZ-5917) Improve the way FOP handles fonts notably for currency symbols


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

Jacques Le Roux updated OFBIZ-5917:
---
Labels: rupee symbol  (was: )

> Improve the way FOP handles fonts notably for currency symbols
> --
>
> Key: OFBIZ-5917
> URL: https://issues.apache.org/jira/browse/OFBIZ-5917
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>Priority: Minor
>  Labels: rupee, symbol
> Fix For: Upcoming Branch
>
>
> In the dev ML I suggested we could add
> 
> in the fonts section of our fop.xconf
> We can do more than that. For instance currently there are no easy ways to 
> render the "new" (since 2010) rupee symbol: ₹.
> One is to use the Google NotoSans font which is Apache licensed
> * http://www.google.com/fonts/specimen/Noto+Sans
> * https://www.google.com/get/noto/#/
> We need also to
> * Add the rupee symbol (₹) to antisamy-esapi.xml file like we have the euro 
> symbol (€)
> * Use NotoSans as the default FOP font. For that we can put the NotoSans font 
> 4 files in framework/resources/fonts and add 
> framework/resources/fonts/NotoSansFonts in our 
> fop.xconf
> * Render ₹ in content/control/fonts.pdf as we do for €. Other symbols could 
> be added later when needed, backed by Google NotoSans font...



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

Re: Creating a new release branch before the end of the year ("release14.12")

Le 20/12/2014 13:02, Pierre Smits a écrit :

Nothing prevent us to not create a relase branch in 2014 and only create on in
2015 when ready.
Actually, due to Adrian's and my request, I believe we should rather go that way

This is as well a good argument to delay the branch creation, even if we can expect to have all patches reviewed each time we need to create a
branch... but 60... !

Creating branches should meet a higher project purpose than just such a
policy.

As I said above you invented this policy, we are free to skip a year

Jacques

Pierre Smits

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

On Fri, Dec 19, 2014 at 7:01 PM, Nicolas Malin
wrote:

Nicolas

Le 18/12/2014 09:53, Jacopo Cappellato a écrit :

Hi all,

Any objections?

Jacopo

Re: Jira and releases change logs

2014-12-21 Thread Pierre Smits

In stead of pointing to past mail threads and to where the explanation
'should' go it is better to put the explanation in said place and point to
there.

Pierre Smits

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

On Sun, Dec 21, 2014 at 11:01 AM, Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> To explain why we can reuse Jacopo's explanation
> http://markmail.org/message/v3yswhnusu4elta5
>
> And this should go in https://cwiki.apache.org/
> confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> http://markmail.org/message/jy3qzmsaoxj56otf
>
> Jacques
>
> Le 21/12/2014 08:45, Jacques Le Roux a écrit :
>
>  Please Nicolas, when you will do it, add that committers should fill the
>> "Fix Version/s" field with relevant "Unreleased Versions" for improvements
>> and bug as well
>>
>> Thanks
>>
>> Jacques
>>
>> Le 18/12/2014 08:26, Jacques Le Roux a écrit :
>>
>>> Thanks Nicolas, I wanted to do it, but did not get a chance, your help
>>> is appreciated :)
>>>
>>> I take advantage of this mail to correct my sentence below (that's what
>>> happen when you "refactor" ;) )
>>> <>> * Improvements: use either Done or Implemented Status as you feel right
>>> * New features: use the Implemented Status
>>> * Bug: use the Fixed Status >>
>>>
>>> Jacques
>>>
>>> Le 18/12/2014 00:20, Nicolas Malin a écrit :
>>>
 Ok Jacques,

 I propose to complete the page https://cwiki.apache.org/
 confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
 with your sensible remarks !
 I will do that tomorrow.

 Nicolas

 Le 17/12/2014 15:29, Jacques Le Roux a écrit :

> Hi Committers,
>
> Please take the time to correctly fill the different Jira fields we
> now use for our releases change logs.
>
> For instance for  in
> * Improvement:s use either Done or Implemented Status as you feel right
> * New features: use either Implemented Status
> * Bug: use the Fixed Status
>
> Don't forget to fill the Fix version/s field according to your
> changes. Notably, use Upcoming Branch and not trunk there.
>
> Also, even if when the svn commits comments are correctly done with a
> reference to the Jira issue number we can then get to the commits in
> Fisheye from the Development section of the Jira issue, I'd still 
> recommend
> to put the commits references in a comment. It's always handy, and insures
> we have those references at hand even if the commits comments don't 
> contain
> the Jira issue reference.
>
> Thanks for all the good work  :)
>
> Jacques
>



>>>
>>

[jira] [Comment Edited] (OFBIZ-5704) Extend lot entity to include party Id of manufacturer


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

Pierre Smits edited comment on OFBIZ-5704 at 12/21/14 10:02 AM:


The uses cases are straight forward:

The user must (in case the product has the flag stating lot management is 
mandatory) or shoud (in case the product has the flag stating lot management is 
optional) provide all necessary details to do proper tracking and tracing. 

In the case of registering inbound deliveries from external parties (suppliers 
et. al) this means he has to provide the partyID of the manufacturer and its 
batch reference. 
This is more complicated in the case of manufacturing as there are options 
possible:
# automatically from productionRunId for each production run
# manually (user defined)
# based on some custom (integrated) batch reference determination program
# automatically from productionRunId from the parent production run

With respect to manufacturerId this should by default come from the partyID of 
the associated party with roleTypeId="MANUFACTURER".

The inventory item registration process should then check whether a lot record 
exists with the parameters partyID  (of the manufacturing party) and the batch 
reference. If and when such a lot exists that lotID must be referenced in the 
inventory item record. If no lot record exists, the process should create a new 
lot record with those details. And the lotID of that newly created lot record 
should be referenced in the inventory item.

We have to keep in mind that everything done in relation to the lot record is 
executed through the processes related to inventory items. This also applies to 
tracking and tracing.



was (Author: pfm.smits):
The uses cases are straight forward:

The user must (in case the product has the flag stating lot management is 
mandatory) or shoud (in case the product has the flag stating lot management is 
optional) all necessary details to do proper tracking and tracing. 
In the case of registering external deliveries this means he has to provide the 
partyID of the manufacturer and its batch reference. With respect to the batch 
reference this is more complicated in the case of manufacturing as there are 
options possible:
# automatically from productionRunId for each production run
# manually (user defined)
# based on some custom (integrated) batch reference determination program
# automatically from productionRunId from the parent production run

With respect to manufacturerId this should by default come from the partyID of 
the associated party with roleTypeId="MANUFACTURER".

The inventory item registration process should then check whether a lot record 
exists with the parameters partyID  (of the manufacturing party) and the batch 
reference. If and when such a lot exists that lotID must be referenced in the 
inventory item record. If no lot record exists, the process should create a new 
lot record with those details. And the lotID of that newly created lot record 
should be referenced in the inventory item.

We have to keep in mind that everything done in relation to the lot record is 
executed through the processes related to inventory items. This also applies to 
tracking and tracing.


> Extend lot entity to include party Id of manufacturer
> -
>
> Key: OFBIZ-5704
> URL: https://issues.apache.org/jira/browse/OFBIZ-5704
> Project: OFBiz
>  Issue Type: Improvement
>  Components: manufacturing, product, workeffort
>Affects Versions: Release Branch 11.04, Release Branch 12.04, Release 
> Branch 13.07, Trunk
>Reporter: Pierre Smits
> Attachments: OFBiz-5704-Product-EntityModel-Lot.patch, Screen Shot 
> 2014-09-03 at 13.52.47.png
>
>
> Rationale
> Lot or batch management affects two places, namely the outbound process (and 
> its functionalities) and inbound. 
> It is possible that multiple parties have the same ID for the batch or the 
> lot. Howver, in current feature set there is no discrimination between lots 
> from supplier A, supplier B, or even the primary (internal) company in OFBiz.
> Therefore the entity 'Lot' should be extended with another key, namely that 
> of the partyId of the manufacturer (or supplier).



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

Re: Jira and releases change logs


To explain why we can reuse Jacopo's explanation
http://markmail.org/message/v3yswhnusu4elta5

And this should go in 
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
http://markmail.org/message/jy3qzmsaoxj56otf

Jacques

Le 21/12/2014 08:45, Jacques Le Roux a écrit :
Please Nicolas, when you will do it, add that committers should fill the "Fix Version/s" field with relevant "Unreleased Versions" for improvements 
and bug as well


Thanks

Jacques

Le 18/12/2014 08:26, Jacques Le Roux a écrit :

Thanks Nicolas, I wanted to do it, but did not get a chance, your help is 
appreciated :)

I take advantage of this mail to correct my sentence below (that's what happen when you 
"refactor" ;) )
<>

Jacques

Le 18/12/2014 00:20, Nicolas Malin a écrit :

Ok Jacques,

I propose to complete the page https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities with your sensible 
remarks !

I will do that tomorrow.

Nicolas

Le 17/12/2014 15:29, Jacques Le Roux a écrit :

Hi Committers,

Please take the time to correctly fill the different Jira fields we now use for 
our releases change logs.

For instance for  in
* Improvement:s use either Done or Implemented Status as you feel right
* New features: use either Implemented Status
* Bug: use the Fixed Status

Don't forget to fill the Fix version/s field according to your changes. 
Notably, use Upcoming Branch and not trunk there.

Also, even if when the svn commits comments are correctly done with a reference to the Jira issue number we can then get to the commits in 
Fisheye from the Development section of the Jira issue, I'd still recommend to put the commits references in a comment. It's always handy, and 
insures we have those references at hand even if the commits comments don't contain the Jira issue reference.


Thanks for all the good work  :)

Jacques

Re: R12 and R13 Branches Broken

2014-12-21 Thread Nicolas Malin


Lazy and IT engineer aren't synonym ?

At the beginning, it's the reason that I has been chosen this jobs !
We would have lied to me !

PS : it's a joke :)

Le 21/12/2014 09:30, Adrian Crum a écrit :
By then it is too late - you have already announced to the world that 
you are a lazy committer.


Adrian Crum
Sandglass Software
www.sandglass-software.com

Re: R12 and R13 Branches Broken

2014-12-21 Thread Adrian Crum

By then it is too late - you have already announced to the world that 
you are a lazy committer.


Adrian Crum
Sandglass Software
www.sandglass-software.com

On 12/21/2014 7:30 AM, Jacques Le Roux wrote:

Or at least check Buildbot thereafter (though too late when you commit a
lot, since it also handles other projects...)

Jacques

Le 21/12/2014 07:50, Adrian Crum a écrit :

Before you commit:

ant clean-all load-demo run-tests

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 12/21/2014 6:23 AM, Ashish Vijaywargiya wrote:

Thanks Jacopo.

PS: Adrian, Taher thanks for reporting the issue and please accept my
sincere apologies. This has happened due to hand merging the trunk
related
changes to R13.07 and R12.04 and somehow I missed to add import
statement.
I will be extra careful from next time.

--
Regards,
Ashish

On Sun, Dec 21, 2014 at 11:17 AM, Jacopo Cappellato <
jacopo.cappell...@hotwaxmedia.com> wrote:


Taher, Adrian,

you are indeed right, thanks for the report and thanks to Taher for
spotting the issue and providing the fix: I have committed it in the
two
branches.

Jacopo

On Dec 21, 2014, at 12:13 AM, Adrian Crum <
adrian.c...@sandglass-software.com> wrote:


The R13 branch is broken too.

Adrian Crum
Sandglass Software
www.sandglass-software.com

On 12/20/2014 10:59 PM, Taher Alkhateeb wrote:

Hi All,

I was trying to build branch 12.04 today which failed. I believe
it is

from commit r1646971. The fix is simply by importing the right
libraries as
shown below. Is this normal though? I thought stable branches are not
supposed to crash while building.


Index: framework/widget/src/org/ofbiz/widget/tree/ModelTree.java
===
--- framework/widget/src/org/ofbiz/widget/tree/ModelTree.java
(revision

1647061)

+++ framework/widget/src/org/ofbiz/widget/tree/ModelTree.java
(working

copy)

@@ -20,6 +20,8 @@

import java.io.IOException;
import java.io.StringWriter;
+import java.util.ArrayList;
+import java.util.Collections;
import java.util.HashMap;
import java.util.Iterator;
import java.util.List;


Taher Alkhateeb

[jira] [Closed] (OFBIZ-5874) Fixes the stable demo