[jira] [Commented] (OFBIZ-7139) Product Name

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-7139:


Wait, users should be warned that if they set the productName and later want to 
use content to override the productName it will not work. They will 1st need to 
remove the productName. See my comment at top of DemoProductI18nData.xml

> Product Name
> 
>
> Key: OFBIZ-7139
> URL: https://issues.apache.org/jira/browse/OFBIZ-7139
> Project: OFBiz
>  Issue Type: Improvement
>  Components: product
>Affects Versions: Trunk
>Reporter: Rishi Solanki
>Priority: Minor
>
> As per the discussion over user list (subject: "Product Name"), user should 
> be able to add product name in product creation process.
> On Catalog >> Products >> New Product section, user won't see any input field 
> to add product name. Same applies to Edit product screen.
> - Add field on the create and edit form.
> - Check for the support in the services used, if not then add support for it.



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


[jira] [Updated] (OFBIZ-7139) Product Name

2016-05-27 Thread Rishi Solanki (JIRA)

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

Rishi Solanki updated OFBIZ-7139:
-
Description: 
As per the discussion over user list (subject: "Product Name"), user should be 
able to add product name in product creation process.
On Catalog >> Products >> New Product section, user won't see any input field 
to add product name. Same applies to Edit product screen.

- Add field on the create and edit form.
- Check for the support in the services used, if not then add support for it.




  was:
As per the discussion over user list, user should be able to add product name 
in product creation process.
On Catalog >> Products >> New Product section, user won't see any input field 
to add product name. Same applies to Edit product screen.

- Add field on the create and edit form.
- Check for the support in the services used, if not then add support for it.



> Product Name
> 
>
> Key: OFBIZ-7139
> URL: https://issues.apache.org/jira/browse/OFBIZ-7139
> Project: OFBiz
>  Issue Type: Improvement
>  Components: product
>Affects Versions: Trunk
>Reporter: Rishi Solanki
>Priority: Minor
>
> As per the discussion over user list (subject: "Product Name"), user should 
> be able to add product name in product creation process.
> On Catalog >> Products >> New Product section, user won't see any input field 
> to add product name. Same applies to Edit product screen.
> - Add field on the create and edit form.
> - Check for the support in the services used, if not then add support for it.



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


[jira] [Created] (OFBIZ-7139) Product Name

2016-05-27 Thread Rishi Solanki (JIRA)
Rishi Solanki created OFBIZ-7139:


 Summary: Product Name
 Key: OFBIZ-7139
 URL: https://issues.apache.org/jira/browse/OFBIZ-7139
 Project: OFBiz
  Issue Type: Improvement
  Components: product
Affects Versions: Trunk
Reporter: Rishi Solanki
Priority: Minor


As per the discussion over user list, user should be able to add product name 
in product creation process.
On Catalog >> Products >> New Product section, user won't see any input field 
to add product name. Same applies to Edit product screen.

- Add field on the create and edit form.
- Check for the support in the services used, if not then add support for it.




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


[jira] [Updated] (OFBIZ-6931) Add XLS renderer

2016-05-27 Thread Nicolas Malin (JIRA)

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

Nicolas Malin updated OFBIZ-6931:
-
Attachment: OFBIZ-6931.patch

I updated the patch the last remark and the refactor work realise by Deepak

If no other suggest I will commit :)



> Add XLS renderer
> 
>
> Key: OFBIZ-6931
> URL: https://issues.apache.org/jira/browse/OFBIZ-6931
> Project: OFBiz
>  Issue Type: New Feature
>  Components: ALL COMPONENTS, framework
>Affects Versions: Trunk
>Reporter: Leila Mekika
>Assignee: Nicolas Malin
>Priority: Minor
> Attachments: OFBIZ-6931.patch, OFBIZ-6931.patch, Sélection_154.png, 
> xls-renderer.patch
>
>
> Add a new renderer type in order to enable XLS file output.



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


[jira] [Commented] (OFBIZ-6746) removePartyContent request is called twice,

2016-05-27 Thread Montalbano Florian (JIRA)

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

Montalbano Florian commented on OFBIZ-6746:
---

Hi,
I'm here from the issue OFBIZ-7135 where there is a service called twice too.

I think the problem come from the URL 
<@ofbizUrl>removePartyContent/viewprofile :
Is this a good practice to put 2 actions in the URL ? It doesn't appear a lot 
in the project.

Moreover, it seems that changing this URL to just 
<@ofbizUrl>removePartyContent corrects the problem while deleting 
the party content. For what I understood, the controller catch the delete 
request, it calls the service "removePartyContent" and then, upon success it 
sends the response specified in the  ("EditPartyContents" in this 
case").
{code}





{code}
This is the part of the controller associated with the removing.

It might be an old part of the code not upgraded yet. What do you think ?

> removePartyContent request is called twice, 
> 
>
> Key: OFBIZ-6746
> URL: https://issues.apache.org/jira/browse/OFBIZ-6746
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Priority: Minor
>
> Comments from OFBIZ-6708:
> Not sure why the removePartyContent request is called twice and the 2nd 
> fails, and I have no time to investigate.
> {code}
>  [java] 2015-11-21 22:52:38,110 |http-bio-8443-exec-6 |ControlServlet 
>|T| [[[removePartyContent(Domain:https://localhost)] Request Begun, 
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
>  [java] 2015-11-21 22:52:38,134 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/removePartyContent] finished in [18] 
> milliseconds
>  [java] 2015-11-21 22:52:38,134 |http-bio-8443-exec-6 |RequestHandler 
>|I| Ran Event [service:#removePartyContent] from [request], result 
> is [success]
>  [java] 2015-11-21 22:52:38,135 |http-bio-8443-exec-6 |RequestHandler 
>|I| Rendering View [viewprofile], 
> sessionId=56DBE28A391381E1B44D53CD49968F7E.jvm1
>  [java] 2015-11-21 22:52:38,136 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/getUserPreferenceGroup] finished in [1] 
> milliseconds
>  [java] 2015-11-21 22:52:38,138 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/getVisualThemeResources] finished in 
> [1] milliseconds
>  [java] 2015-11-21 22:52:38,163 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 39 screens in 0.008s from: 
> file:/C:/projectASF-Mars/ofbiz/applications/party/widget/partymgr/PartyScreens.xml
>  [java] 2015-11-21 22:52:38,210 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 4 screens in 0.005s from: 
> file:/C:/projectASF-Mars/ofbiz/applications/party/widget/partymgr/CommonScreens.xml
>  [java] 2015-11-21 22:52:38,216 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 1 screens in 0.005s from: 
> file:/C:/projectASF-Mars/ofbiz/applications/commonext/widget/CommonScreens.xml
>  [java] 2015-11-21 22:52:38,284 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/getLastSystemInfoNote] finished in [17] 
> milliseconds
>  [java] 2015-11-21 22:52:38,286 |http-bio-8443-exec-6 |PrimaryKeyFinder   
>|I| Returning null because found incomplete primary key in find: 
> [GenericEntity:PartyAcctgPrefAndGroup][partyId,Company
> (java.lang.String)][roleTypeId,null()]
>  [java] 2015-11-21 22:52:38,293 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 24 screens in 0.006s from: 
> file:/C:/projectASF-Mars/ofbiz/framework/common/widget/CommonScreens.xml
>  [java] 2015-11-21 22:52:38,392 |http-bio-8443-exec-6 |ServiceEcaRule 
>|I| For Service ECA [partyBasePermissionCheck] on [return] got 
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
>  [java] 2015-11-21 22:52:38,393 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/partyBasePermissionCheck] finished in 
> [46] milliseconds
>  [java] 2015-11-21 22:52:38,401 |http-bio-8443-exec-6 |ServiceEcaRule 
>|I| For Service ECA [partyBasePermissionCheck] on [return] got 
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
>  [java] 2015-11-21 22:52:38,402 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/partyBasePermissionCheck] finished in 
> [1] milliseconds
>  [java] 2015-11-21 22:52:38,419 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/acctgBasePermissionCheck] finished in 
> [12] milliseconds
>  [java] 2015-11-21 22:52:38,421 

[jira] [Commented] (OFBIZ-6931) Add XLS renderer

2016-05-27 Thread Nicolas Malin (JIRA)

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

Nicolas Malin commented on OFBIZ-6931:
--

This call directly the standard message :
{quote}

البحث
Vyhledat
Suchen
Search
Buscar
Chercher
खोजे
Ricerca
検索
Zoek
Procurar
Pesquisar
Cauta
Искать
ค้นหา
Tìm kiếm
搜索
搜尋

{quote}

And I think we can also remove  position="1"

> Add XLS renderer
> 
>
> Key: OFBIZ-6931
> URL: https://issues.apache.org/jira/browse/OFBIZ-6931
> Project: OFBiz
>  Issue Type: New Feature
>  Components: ALL COMPONENTS, framework
>Affects Versions: Trunk
>Reporter: Leila Mekika
>Assignee: Nicolas Malin
>Priority: Minor
> Attachments: OFBIZ-6931.patch, Sélection_154.png, xls-renderer.patch
>
>
> Add a new renderer type in order to enable XLS file output.



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


[jira] [Commented] (OFBIZ-6931) Add XLS renderer

2016-05-27 Thread Pierre Smits (JIRA)

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

Pierre Smits commented on OFBIZ-6931:
-

Is this removing of the title and the widget-style not a degradation?
{code}
-
{code}
has been replaced by
{code}
+
{code}

> Add XLS renderer
> 
>
> Key: OFBIZ-6931
> URL: https://issues.apache.org/jira/browse/OFBIZ-6931
> Project: OFBiz
>  Issue Type: New Feature
>  Components: ALL COMPONENTS, framework
>Affects Versions: Trunk
>Reporter: Leila Mekika
>Assignee: Nicolas Malin
>Priority: Minor
> Attachments: OFBIZ-6931.patch, Sélection_154.png, xls-renderer.patch
>
>
> Add a new renderer type in order to enable XLS file output.



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


[jira] [Commented] (OFBIZ-7138) Manage Triangular European VAT

2016-05-27 Thread Pierre Smits (JIRA)

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

Pierre Smits commented on OFBIZ-7138:
-

There is also, with respect to selling cross-border, is that when there are tax 
treaties in place - like in the EU - that VAT might be deferred, when 
conditions are met.

> Manage Triangular European VAT 
> ---
>
> Key: OFBIZ-7138
> URL: https://issues.apache.org/jira/browse/OFBIZ-7138
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Minor
>  Labels: tax, vat
>
> I open an issue related to mailing thread 
> https://lists.apache.org/thread.html/Z8ksgxdskmbcg9n
> The origin came from here :
> {quote}
> In Europe with the B2B drop shipment process we have a specific rule to 
> calculate the VAT.
> The particularity comes from the purchase order, applying the VAT of the 
> product origin country if billing address OR shipping address is in the same 
> country.
> 1. I'm a French society that ordered product from Italy to sale in Denmark -> 
> No VAT
> 2. I'm a French society that ordered product from Italy to sale in Italy -> 
> Italian VAT
> 3. I'm a French society that ordered product from France to sale in Italy -> 
> French VAT
> Currently to resolve the taxAuth in OFBiz we use the shipping address only, 
> so we can see that the point 3. isn't covered because the product wasn't 
> shipped in France.
> {quote}
> I will load a patch in few week ;)



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


[jira] [Commented] (OFBIZ-7137) Both ExampleReportPdfOptions and ExampleReportPdfBarcode no longer work

2016-05-27 Thread Pierre Smits (JIRA)

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

Pierre Smits commented on OFBIZ-7137:
-

This looks quite similar to the issue we recently had with QR codes. See 
OFBIZ-7034

> Both ExampleReportPdfOptions and ExampleReportPdfBarcode no longer work
> ---
>
> Key: OFBIZ-7137
> URL: https://issues.apache.org/jira/browse/OFBIZ-7137
> Project: OFBiz
>  Issue Type: Bug
>  Components: specialpurpose/example
>Affects Versions: Trunk, Release Branch 15.12
>Reporter: Jacques Le Roux
>Priority: Minor
>
> While working on OFBIZ-7136 "Ugrade PDFBox to 1.8.12 (or 2.0.1?) due to 
> vulnerability" I noticed these PDF options no longer work. This was done with 
> OFBIZ-6504 "how to Create PDF with password Protected in Ofbiz"
> I did not get any error with ExampleReportPdfOptions but a blank screen. 
> Here is the error in log for ExampleReportPdfBarcode 
> {code}
> 2016-05-27 14:11:35,737 |http-nio-8443-exec-7 |FOUserAgent   
> |E| Image not available. URI: 
> /example/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201=b
> mp=UTF-8=true=20=20.
>  Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format 
> is not supported. No ImagePreloader found for /examp
> le/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201=bmp=UTF-8=true=20=20
>  (See position 43:308)
> org.apache.xmlgraphics.image.loader.ImageException: The file format is not 
> supported. No ImagePreloader found for 
> /example/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201
> ormat=bmp=UTF-8=true=20=20
> at 
> org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
>  ~[xmlgraphics-commons-2.0.1.jar:2.0.1]
> at 
> org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128)
>  ~[xmlgraphics-commons-2.0.1.jar:2.0.1]
> at 
> org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
>  ~[xmlgraphics-commons-2.0.1.jar:2.0.1]
> at 
> org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81) 
> [fop-2.0.jar:?]
> at org.apache.fop.fo.FObj.processNode(FObj.java:129) [fop-2.0.jar:?]
> at 
> org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:291)
>  [fop-2.0.jar:?]
> at 
> org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:179) 
> [fop-2.0.jar:?]
> [...]
> 2016-05-27 14:11:36,084 |http-nio-8443-exec-7 |FOUserAgent   
> |E| Image not found. URI: 
> /example/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201=bmp
> ncoding=UTF-8=true=20=20. 
> (No context info available)
> 2016-05-27 14:11:36,088 |http-nio-8443-exec-7 |ServerHitBin  
> |I| Visit delegatorName=default, ServerHitBin delegatorName=default
> 2016-05-27 14:11:36,099 |http-nio-8443-exec-7 |ControlServlet
> |T| [[[ExampleReportPdfBarcode(Domain:https://localhost)] Request Done- 
> total:1.131,since last([ExampleReportPdf...):1.131]]
> {code}



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


[jira] [Commented] (OFBIZ-6931) Add XLS renderer

2016-05-27 Thread Nicolas Malin (JIRA)

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

Nicolas Malin commented on OFBIZ-6931:
--

{quote}
+
?
I'm not against, just wondering because maybe we could harmonize everywhere?
{quote}
Yes you right Jacques, maybe I change it when I view the code. If we set an 
image here with hard link we can't surcharge it by the theme. 

{quote}
Why not rather?
View as spreadsheet
{quote}
No pb with it ! 



> Add XLS renderer
> 
>
> Key: OFBIZ-6931
> URL: https://issues.apache.org/jira/browse/OFBIZ-6931
> Project: OFBiz
>  Issue Type: New Feature
>  Components: ALL COMPONENTS, framework
>Affects Versions: Trunk
>Reporter: Leila Mekika
>Assignee: Nicolas Malin
>Priority: Minor
> Attachments: OFBIZ-6931.patch, Sélection_154.png, xls-renderer.patch
>
>
> Add a new renderer type in order to enable XLS file output.



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


Re: Triangular VAT in Europe ?

2016-05-27 Thread Nicolas Malin

Le 27/05/2016 07:35, Jacques Le Roux a écrit :


Thanks Nicolas,

Could you please open a Jira improvement with your comments below?


Ok done Jacques,

https://issues.apache.org/jira/browse/OFBIZ-7138

All suggest are welcome because my solution came from my brain ... warn !!

Nicolas


Thanks

Jacques


Le 26/05/2016 à 22:25, Nicolas Malin a écrit :

Hi Jacques,


Le 01/05/2016 19:47, Jacques Le Roux a écrit :

Le 27/01/2016 à 16:37, Nicolas Malin a écrit :
Hello, In Europe with the B2B drop shipment process we have a 
specific rule to calculate the VAT. The particularity comes from 
the purchase order, applying the VAT of the product origin country 
if billing address OR shipping address is in the same country. 1. 
I'm a French society that ordered product from Italy to sale in 
Denmark -> No VAT 2. I'm a French society that ordered product from 
Italy to sale in Italy -> Italian VAT 3. I'm a French society that 
ordered product from France to sale in Italy -> French VAT 
Currently to resolve the taxAuth in OFBiz we use the shipping 
address only, so we can see that the point 3. isn't covered because 
the product wasn't shipped in France. Does anyone ever met the same 
problem ? I propose to improve the taxAuth resolution with also the 
origin address and the billing address. After that, I have the 
problem to say when we need to check the origin instead of the 
shipping. H ... my first idea would be to check if the 
payToPartyId is an internal organisation. If yes, resolve taxAuth 
with the shipping else, I check if the origin is the same country 
than the shipping or billing. After TaxAuth the rate resolved come 
without change. However, I suggest to add a customMethodId on 
taxAuthRateProduct to increase the configuration of complex cases.


Any suggest ?

--
#jeSuisCharlie
logoNrd 
Nicolas Malin
Ingénieur d'étude. Dernier sujet : "Les vaches portant un prénom 
pouvent trouver la sortie d'un labyrinthe en cas de toxoplasmose

informat...@nereide.fr
8 rue des Déportés 37000 TOURS, 02 47 50 30 54

Apache OFBiz  | ofbiz-fr 
 | | réseau LE 


Hi Nicolas,

Did you finally implement this? If yes would you contribute (just 
curious)?

I sharing with pleasure, because is now in production ;)

To manage this I extend the function 
TaxAuthorityServices.getTaxAuthorities with this  (I implement the 
solution on 13.07):


EntityCondition cond = EntityCondition.makeCondition(UtilMisc.toList(
EntityCondition.makeCondition("partyId", payToPartyId),
EntityCondition.makeCondition("isNexus", "Y")));
List taxAuthorityRawList = 
delegator.findList("PartyTaxAuthInfo", cond, null, null, null, true);
List taxCondList = new 
ArrayList();

if (!taxAuthorityRawList.isEmpty()) {
taxCondList.add(EntityCondition.makeCondition("taxAuthPartyId", 
EntityOperator.IN, 
EntityUtil.getFieldListFromEntityList(taxAuthorityRawList, 
"taxAuthPartyId", true)));
if (Debug.infoOn()) Debug.logInfo("Search tax authority 
relation for " + payToPartyId + " " + taxCondList, module);

if (originAddress == null) {
originAddress = 
ContactMechWorker.getTaxOriginAddress(delegator, payToPartyId);

}
if (billingAddress == null) {
billingAddress = 
ContactMechWorker.getTaxBillingAddress(delegator, billToPartyId);

}
if (originAddress != null && billingAddress != null) {
if 
(originAddress.getString("countryGeoId").equals(billingAddress.getString("countryGeoId"))) 
{
//ok we will analyse the country where come from 
the flow

address = originAddress;
}
}
if (Debug.infoOn()) {
Debug.logInfo("  shipping found " + 
shippingAddress.getString("countryGeoId"), module);
Debug.logInfo("  origin found " + 
originAddress.getString("countryGeoId"), module);
Debug.logInfo("  billing found " + 
billingAddress.getString("countryGeoId"), module);
Debug.logInfo("  country found " + 
address.getString("countryGeoId"), module);

}
} else {
if (Debug.infoOn()) Debug.logInfo("No specific relation, 
run the std resolution", module);

}
**

The idea, when an order check the vat, I resolv the taxAuth to use 
first with the payToParty. I check if this party have a dedicate 
relation with a specific tax authority by PartyTaxAuthInfo. If yes, I 
check with the shipping and the billing adress to understand if this 
order is cover by the same country.


If no I continue with the standard method.

This is a simple hack, because a better solution would be use the 
orderContachMech to resolve the 

[jira] [Commented] (OFBIZ-7138) Manage Triangular European VAT

2016-05-27 Thread Nicolas Malin (JIRA)

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

Nicolas Malin commented on OFBIZ-7138:
--

To manage this I extend the function TaxAuthorityServices.getTaxAuthorities 
with this  (I implement the solution on 13.07):
{code}
EntityCondition cond = EntityCondition.makeCondition(UtilMisc.toList(
EntityCondition.makeCondition("partyId", payToPartyId),
EntityCondition.makeCondition("isNexus", "Y")));
List taxAuthorityRawList = 
delegator.findList("PartyTaxAuthInfo", cond, null, null, null, true);
List taxCondList = new ArrayList();
if (!taxAuthorityRawList.isEmpty()) {
taxCondList.add(EntityCondition.makeCondition("taxAuthPartyId", 
EntityOperator.IN, EntityUtil.getFieldListFromEntityList(taxAuthorityRawList, 
"taxAuthPartyId", true)));
if (Debug.infoOn()) Debug.logInfo("Search tax authority relation 
for " + payToPartyId + " " + taxCondList, module);
if (originAddress == null) {
originAddress = 
ContactMechWorker.getTaxOriginAddress(delegator, payToPartyId);
}
if (billingAddress == null) {
billingAddress = 
ContactMechWorker.getTaxBillingAddress(delegator, billToPartyId);
}
if (originAddress != null && billingAddress != null) {
if 
(originAddress.getString("countryGeoId").equals(billingAddress.getString("countryGeoId")))
 {
//ok we will analyse the country where come from the flow
address = originAddress;
}
}
if (Debug.infoOn()) {
Debug.logInfo("  shipping found " + 
shippingAddress.getString("countryGeoId"), module);
Debug.logInfo("  origin found " + 
originAddress.getString("countryGeoId"), module);
Debug.logInfo("  billing found " + 
billingAddress.getString("countryGeoId"), module);
Debug.logInfo("  country found " + 
address.getString("countryGeoId"), module);
}
} else {
if (Debug.infoOn()) Debug.logInfo("No specific relation, run the 
std resolution", module);
}
{code}

The idea, when an order check the vat, I resolv the taxAuth to use first with 
the payToParty. I check if this party have a dedicate relation with a specific 
tax authority by PartyTaxAuthInfo. If yes, I check with the shipping and the 
billing adress to understand if this order is cover by the same country.

If no I continue with the standard method.

This is a simple hack, because a better solution would be use the 
orderContachMech to resolve the shipping, billing and origin adress, but this 
works fine like that :) .

The rest is only data configuration on the PartyAuth and bill from vendor.


After to implement a specific text on invoice template and resolve the reason 
of an exoneration, I use a seca like this :

{code}

 
 

{code}

The service checkInvoiceForVATExemptReason, check if the invoice have vat line 
and if not call this :

{code}
 GenericValue partyAuth = EntityUtil.getFirst(partyAuths);
EntityCondition condTax = EntityCondition.makeCondition(UtilMisc.toList(
EntityExpr.makeCondition("taxAuthPartyId", 
partyAuth.get("taxAuthPartyId")),
EntityExpr.makeCondition("taxAuthGeoId", 
partyAuth.get("taxAuthGeoId")),
EntityExpr.makeCondition("taxPercentage", 
GenericEntity.NULL_FIELD),
EntityExpr.makeCondition("taxAmount",GenericEntity.NULL_FIELD),
EntityCondition.makeCondition("taxAuthorityRateTypeId", 
EntityOperator.NOT_EQUAL, "SALES_TAX")));
List taxRates = 
delegator.findList("TaxAuthorityRateProduct", condTax, null, 
UtilMisc.toList("sequenceNum"), null, true);
if (Debug.infoOn()) Debug.logInfo(" ### taxRates " + taxRates.size(), 
module);
taxRates = EntityUtil.filterByDate(taxRates, 
invoice.getTimestamp("invoiceDate"));
if (UtilValidate.isEmpty(taxRates)) {
if (Debug.infoOn()) Debug.logInfo(" no specific rules find", 
module);
return result;
}
//check match case rate
for (GenericValue taxRate : taxRates) {
GenericValue custMethod = null;
String serviceName = null;
if (UtilValidate.isNotEmpty(taxRate.getString("customMethodId"))) {
custMethod = delegator.findOne("CustomMethod", true, 
"customMethodId", taxRate.get("customMethodId"));
}
if (custMethod != null) serviceName = 
custMethod.getString("customMethodName");
if (UtilValidate.isNotEmpty(serviceName)) {
ModelService service = dctx.getModelService(serviceName);
if (service != null) {
if (Debug.infoOn()) 

[jira] [Created] (OFBIZ-7138) Manage Triangular European VAT

2016-05-27 Thread Nicolas Malin (JIRA)
Nicolas Malin created OFBIZ-7138:


 Summary: Manage Triangular European VAT 
 Key: OFBIZ-7138
 URL: https://issues.apache.org/jira/browse/OFBIZ-7138
 Project: OFBiz
  Issue Type: Bug
Affects Versions: Trunk
Reporter: Nicolas Malin
Assignee: Nicolas Malin
Priority: Minor


I open an issue related to mailing thread 
https://lists.apache.org/thread.html/Z8ksgxdskmbcg9n

The origin came from here :
{quote}
In Europe with the B2B drop shipment process we have a specific rule to 
calculate the VAT.
The particularity comes from the purchase order, applying the VAT of the 
product origin country if billing address OR shipping address is in the same 
country.

1. I'm a French society that ordered product from Italy to sale in Denmark -> 
No VAT
2. I'm a French society that ordered product from Italy to sale in Italy -> 
Italian VAT
3. I'm a French society that ordered product from France to sale in Italy -> 
French VAT

Currently to resolve the taxAuth in OFBiz we use the shipping address only, so 
we can see that the point 3. isn't covered because the product wasn't shipped 
in France.
{quote}

I will load a patch in few week ;)



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


[jira] [Commented] (OFBIZ-7136) Ugrade PDFBox to 1.8.12 (or 2.0.1?) due to vulnerability

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-7136:


Done in 
trunk at r1745751
R15.12 r1745752

I did not try to update to version 2.0.1. 
I only tested by using 
https://localhost:8443/example/control/ExampleReportPdfOptions?exampleId=EX01 
but I got nothing. So I tried with R15.12 before backporting and got the same 
issue. So I guess it's unrelated with this update. Moreover with both branches 
I get an error in log for the barcode PDF: I opened OFBIZ-7137

I don't close yet, I'll look at other releases later, it's no obvious if 
upgrading from 1.7.1 to 1.8.12 can be done w/o side effects.

> Ugrade PDFBox to 1.8.12 (or 2.0.1?) due to vulnerability
> 
>
> Key: OFBIZ-7136
> URL: https://issues.apache.org/jira/browse/OFBIZ-7136
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: framework
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>
> CVE-2016-2175: Apache PDFBox XML External Entity vulnerability
> Severity: Important
> Versions Affected:
> Apache PDFBox 1.8.0 to 1.8.11
> Apache PDFBox 2.0.0
> Earlier, unsupported Apache PDFBox versions may be affected as well
> Description:
> Apache PDFBox parses different XML data within PDF files such as XMP and the 
> initialization of the XML parsers did not protect against XML External Entity 
> (XXE) vulnerabilities. According to www.owasp.org [1]: "This attack may lead 
> to the disclosure of confidential data, denial of service, server side 
> request forgery, port scanning from the perspective of the machine where the 
> parser is located, and other system impacts."
> Mitigation:
> Upgrade to Apache PDFBox 1.8.12 respectively 2.0.1
> Credit:
> This issue was discovered by Arthur Khashaev (https://khashaev.ru), Seulgi 
> Kim, Mesut Timur and Microsoft Vulnerability Research.
> [1] https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing



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


[jira] [Created] (OFBIZ-7137) Both ExampleReportPdfOptions and ExampleReportPdfBarcode no longer work

2016-05-27 Thread Jacques Le Roux (JIRA)
Jacques Le Roux created OFBIZ-7137:
--

 Summary: Both ExampleReportPdfOptions and ExampleReportPdfBarcode 
no longer work
 Key: OFBIZ-7137
 URL: https://issues.apache.org/jira/browse/OFBIZ-7137
 Project: OFBiz
  Issue Type: Bug
  Components: specialpurpose/example
Affects Versions: Release Branch 15.12, Trunk
Reporter: Jacques Le Roux
Priority: Minor


While working on OFBIZ-7136 "Ugrade PDFBox to 1.8.12 (or 2.0.1?) due to 
vulnerability" I noticed these PDF options no longer work. This was done with 
OFBIZ-6504 "how to Create PDF with password Protected in Ofbiz"

I did not get any error with ExampleReportPdfOptions but a blank screen. 

Here is the error in log for ExampleReportPdfBarcode 
{code}
2016-05-27 14:11:35,737 |http-nio-8443-exec-7 |FOUserAgent   
|E| Image not available. URI: 
/example/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201=b
mp=UTF-8=true=20=20. 
Reason: org.apache.xmlgraphics.image.loader.ImageException: The file format is 
not supported. No ImagePreloader found for /examp
le/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201=bmp=UTF-8=true=20=20
 (See position 43:308)
org.apache.xmlgraphics.image.loader.ImageException: The file format is not 
supported. No ImagePreloader found for 
/example/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201
ormat=bmp=UTF-8=true=20=20
at 
org.apache.xmlgraphics.image.loader.ImageManager.preloadImage(ImageManager.java:181)
 ~[xmlgraphics-commons-2.0.1.jar:2.0.1]
at 
org.apache.xmlgraphics.image.loader.cache.ImageCache.needImageInfo(ImageCache.java:128)
 ~[xmlgraphics-commons-2.0.1.jar:2.0.1]
at 
org.apache.xmlgraphics.image.loader.ImageManager.getImageInfo(ImageManager.java:123)
 ~[xmlgraphics-commons-2.0.1.jar:2.0.1]
at org.apache.fop.fo.flow.ExternalGraphic.bind(ExternalGraphic.java:81) 
[fop-2.0.jar:?]
at org.apache.fop.fo.FObj.processNode(FObj.java:129) [fop-2.0.jar:?]
at 
org.apache.fop.fo.FOTreeBuilder$MainFOHandler.startElement(FOTreeBuilder.java:291)
 [fop-2.0.jar:?]
at org.apache.fop.fo.FOTreeBuilder.startElement(FOTreeBuilder.java:179) 
[fop-2.0.jar:?]
[...]
2016-05-27 14:11:36,084 |http-nio-8443-exec-7 |FOUserAgent   
|E| Image not found. URI: 
/example/control/qrcode;jsessionid=B15ED8C1DE5124CA1769B8DEBDD8C1BD.jvm1?message=Example%201=bmp
ncoding=UTF-8=true=20=20. (No 
context info available)
2016-05-27 14:11:36,088 |http-nio-8443-exec-7 |ServerHitBin  
|I| Visit delegatorName=default, ServerHitBin delegatorName=default
2016-05-27 14:11:36,099 |http-nio-8443-exec-7 |ControlServlet
|T| [[[ExampleReportPdfBarcode(Domain:https://localhost)] Request Done- 
total:1.131,since last([ExampleReportPdf...):1.131]]
{code}



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


[jira] [Created] (OFBIZ-7136) Ugrade PDFBox to 1.8.12 (or 2.0.1?) due to vulnerability

2016-05-27 Thread Jacques Le Roux (JIRA)
Jacques Le Roux created OFBIZ-7136:
--

 Summary: Ugrade PDFBox to 1.8.12 (or 2.0.1?) due to vulnerability
 Key: OFBIZ-7136
 URL: https://issues.apache.org/jira/browse/OFBIZ-7136
 Project: OFBiz
  Issue Type: Sub-task
  Components: framework
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux


CVE-2016-2175: Apache PDFBox XML External Entity vulnerability

Severity: Important
Versions Affected:
Apache PDFBox 1.8.0 to 1.8.11
Apache PDFBox 2.0.0
Earlier, unsupported Apache PDFBox versions may be affected as well

Description:
Apache PDFBox parses different XML data within PDF files such as XMP and the 
initialization of the XML parsers did not protect against XML External Entity 
(XXE) vulnerabilities. According to www.owasp.org [1]: "This attack may lead to 
the disclosure of confidential data, denial of service, server side request 
forgery, port scanning from the perspective of the machine where the parser is 
located, and other system impacts."


Mitigation:
Upgrade to Apache PDFBox 1.8.12 respectively 2.0.1

Credit:
This issue was discovered by Arthur Khashaev (https://khashaev.ru), Seulgi Kim, 
Mesut Timur and Microsoft Vulnerability Research.

[1] https://www.owasp.org/index.php/XML_External_Entity_(XXE)_Processing





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


[jira] [Commented] (OFBIZ-6746) removePartyContent request is called twice,

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-6746:
-

Thanks Scott for your input. I dig around it and found that error ocures due to 
incorrect url pattern used in getJSONuiLabels js method.

Ideally it url used in js should be prepared using <@ofbuzUrl> transform 
pattern.

We need to found an way to prepare url correctly for js well.
{code}
function getJSONuiLabels(requiredLabels, callback) {
var requiredLabelsStr = JSON.stringify(requiredLabels)

if (requiredLabels != null && requiredLabels != "") {
jQuery.ajax({
url: "getJSONuiLabelArray",
type: "POST",
data: {"requiredLabels" : requiredLabelsStr},
complete: function(data) {
callback(data);
}
});
}
}
{code}
And getJSONuiLabels called in PartyProfileContent.js  on document.ready.

As per current pattern getJSONuiLabels method using url: "getJSONuiLabelArray", 
this pattern append the current window url and execute it like 
/partymgr/control/removePartyContent/getJSONuiLabelArray and causing the issue.

To test this I useed "/partymgr/control/getJSONuiLabelArray" this in 
getJSONuiLabels method and it works fine.

> removePartyContent request is called twice, 
> 
>
> Key: OFBIZ-6746
> URL: https://issues.apache.org/jira/browse/OFBIZ-6746
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Deepak Dixit
>Priority: Minor
>
> Comments from OFBIZ-6708:
> Not sure why the removePartyContent request is called twice and the 2nd 
> fails, and I have no time to investigate.
> {code}
>  [java] 2015-11-21 22:52:38,110 |http-bio-8443-exec-6 |ControlServlet 
>|T| [[[removePartyContent(Domain:https://localhost)] Request Begun, 
> encoding=[UTF-8]- total:0.0,since last(Begin):0.0]]
>  [java] 2015-11-21 22:52:38,134 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/removePartyContent] finished in [18] 
> milliseconds
>  [java] 2015-11-21 22:52:38,134 |http-bio-8443-exec-6 |RequestHandler 
>|I| Ran Event [service:#removePartyContent] from [request], result 
> is [success]
>  [java] 2015-11-21 22:52:38,135 |http-bio-8443-exec-6 |RequestHandler 
>|I| Rendering View [viewprofile], 
> sessionId=56DBE28A391381E1B44D53CD49968F7E.jvm1
>  [java] 2015-11-21 22:52:38,136 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/getUserPreferenceGroup] finished in [1] 
> milliseconds
>  [java] 2015-11-21 22:52:38,138 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/getVisualThemeResources] finished in 
> [1] milliseconds
>  [java] 2015-11-21 22:52:38,163 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 39 screens in 0.008s from: 
> file:/C:/projectASF-Mars/ofbiz/applications/party/widget/partymgr/PartyScreens.xml
>  [java] 2015-11-21 22:52:38,210 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 4 screens in 0.005s from: 
> file:/C:/projectASF-Mars/ofbiz/applications/party/widget/partymgr/CommonScreens.xml
>  [java] 2015-11-21 22:52:38,216 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 1 screens in 0.005s from: 
> file:/C:/projectASF-Mars/ofbiz/applications/commonext/widget/CommonScreens.xml
>  [java] 2015-11-21 22:52:38,284 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/getLastSystemInfoNote] finished in [17] 
> milliseconds
>  [java] 2015-11-21 22:52:38,286 |http-bio-8443-exec-6 |PrimaryKeyFinder   
>|I| Returning null because found incomplete primary key in find: 
> [GenericEntity:PartyAcctgPrefAndGroup][partyId,Company
> (java.lang.String)][roleTypeId,null()]
>  [java] 2015-11-21 22:52:38,293 |http-bio-8443-exec-6 |ScreenFactory  
>|I| Got 24 screens in 0.006s from: 
> file:/C:/projectASF-Mars/ofbiz/framework/common/widget/CommonScreens.xml
>  [java] 2015-11-21 22:52:38,392 |http-bio-8443-exec-6 |ServiceEcaRule 
>|I| For Service ECA [partyBasePermissionCheck] on [return] got 
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
>  [java] 2015-11-21 22:52:38,393 |http-bio-8443-exec-6 |ServiceDispatcher  
>|T| Sync service [partymgr/partyBasePermissionCheck] finished in 
> [46] milliseconds
>  [java] 2015-11-21 22:52:38,401 |http-bio-8443-exec-6 |ServiceEcaRule 
>|I| For Service ECA [partyBasePermissionCheck] on [return] got 
> false for condition: [hasPermission][equals][false][true
> ][Boolean]
>  [java] 

[jira] [Commented] (OFBIZ-7135) Adding role for a party show error on the second add

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-7135:
-

I think its related to OFBIZ-6746

> Adding role for a party show error on the second add
> 
>
> Key: OFBIZ-7135
> URL: https://issues.apache.org/jira/browse/OFBIZ-7135
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Priority: Minor
>  Labels: addrole, party
> Attachments: OFBIZ-7135.patch
>
>
> Hi all,
> How to reproduce :
> 1) Go to the profile of a party and then to the "Role" tab : 
> https://localhost:8443/partymgr/control/viewroles?partyId=admin
> 2) Add any role
> 3) Wait for the page to reload
> 4) Try to add another role
> 5) Notice the error showing up and the redirection to the "profile" page
> Problem : The problem comes from a bad request send. When you select a "main 
> role" (without clicking on the add button), a request is send to get the form 
> for the "secondary role". On the first time, there is no problem, the request 
> is something such as : 
> https://localhost:8443/partymgr/control/addsecondaryroles
> On the second time, it becomes something like this : 
> https://localhost:8443/partymgr/control/addrole/addsecondaryroles
> When the controller receives this second request, it does both the "addrole" 
> and the "addsecondaryroles" request. So when you chose a role in the first 
> select, it actually sends a request to add the role before you even click on 
> the "add" button.
> Root of the problem :
> First, the target of the forms (PartyForms#AddPartyRole, 
> PartyForms#AddPartyMainRole and PartyForms#AddPartySecondaryRole) adding the 
> "main" and "secondary" roles is "addrole/viewroles" (it seems to be the only 
> place in the code where a target is done this way). To clear up the request, 
> I tried to remove the "/viewroles" to match what is done in another case : 
> when a task is added to a project.
> It seems to work but I want to know what is your point of view on this.
> Then, in the controller, there is a weird redirection to "viewprofile" 
> instead of allowing the user to stay on "viewroles". All of this seems 
> related to an update of the coding way in the project that didn't affect this 
> part yet.
> I'll provide a patch that seems to work.
> Thanks,
> Florian



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


[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-7079:


Sounds good to me, another similar product (with different  
product.inventoryItemTypeId) can always be created, nothing blocking

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Comment Edited] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux edited comment on OFBIZ-7079 at 5/27/16 10:06 AM:
--

[~deepak.dixit], thanks it's clear
[~rishisolankii], it's clear also, I'm trying to understand if [~pfm.smits]'s 
(Pierre you have 2 Jira usernames) comment could no be a burden, namely
{quote}
Suppose this is and inventory in of the product in the warehouse, with the 
serialisation set, is on hold (as per other issue OFBIZ-7094), it is then easy 
to move it to the warehouse without serialisation set and the inventory is then 
available for delivery...
{quote}

>From your both answers so far it seems we are good to go... :)


was (Author: jacques.le.roux):
Thanks it's clear

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-7079:


Thanks it's clear

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Comment Edited] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux edited comment on OFBIZ-7079 at 5/27/16 10:01 AM:
--

I think its default inventory item type not facility inventory item type, it 
means if no inventory item type is define than it will be considered as 
facility.defaultInvenotryItemType. But if we set other than this then it will 
be used.


was (Author: deepak.dixit):
I think its default inventory item type not facility inventory item type, it 
means if no inventory item type is define than it will be considered as 
facility.defaultInvenotryItemType. But if we set other than this then it will 
be sued.

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Updated] (OFBIZ-7135) Adding role for a party show error on the second add

2016-05-27 Thread Montalbano Florian (JIRA)

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

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

A first try for a patch solution

> Adding role for a party show error on the second add
> 
>
> Key: OFBIZ-7135
> URL: https://issues.apache.org/jira/browse/OFBIZ-7135
> Project: OFBiz
>  Issue Type: Bug
>  Components: party
>Affects Versions: Trunk
>Reporter: Montalbano Florian
>Priority: Minor
>  Labels: addrole, party
> Attachments: OFBIZ-7135.patch
>
>
> Hi all,
> How to reproduce :
> 1) Go to the profile of a party and then to the "Role" tab : 
> https://localhost:8443/partymgr/control/viewroles?partyId=admin
> 2) Add any role
> 3) Wait for the page to reload
> 4) Try to add another role
> 5) Notice the error showing up and the redirection to the "profile" page
> Problem : The problem comes from a bad request send. When you select a "main 
> role" (without clicking on the add button), a request is send to get the form 
> for the "secondary role". On the first time, there is no problem, the request 
> is something such as : 
> https://localhost:8443/partymgr/control/addsecondaryroles
> On the second time, it becomes something like this : 
> https://localhost:8443/partymgr/control/addrole/addsecondaryroles
> When the controller receives this second request, it does both the "addrole" 
> and the "addsecondaryroles" request. So when you chose a role in the first 
> select, it actually sends a request to add the role before you even click on 
> the "add" button.
> Root of the problem :
> First, the target of the forms (PartyForms#AddPartyRole, 
> PartyForms#AddPartyMainRole and PartyForms#AddPartySecondaryRole) adding the 
> "main" and "secondary" roles is "addrole/viewroles" (it seems to be the only 
> place in the code where a target is done this way). To clear up the request, 
> I tried to remove the "/viewroles" to match what is done in another case : 
> when a task is added to a project.
> It seems to work but I want to know what is your point of view on this.
> Then, in the controller, there is a weird redirection to "viewprofile" 
> instead of allowing the user to stay on "viewroles". All of this seems 
> related to an update of the coding way in the project that didn't affect this 
> part yet.
> I'll provide a patch that seems to work.
> Thanks,
> Florian



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


[jira] [Commented] (OFBIZ-3500) Umbrella issue for components dependency

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-3500:


IIRW there are interesting ideas and some work already done, not sure how it 
fits today, but I'd not close before being sure about that...


> Umbrella issue for components dependency
> 
>
> Key: OFBIZ-3500
> URL: https://issues.apache.org/jira/browse/OFBIZ-3500
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
> Attachments: dependencyCheck.groovy
>
>
> This issue is dedicated to group components dependency related issues.
> Chris Snow created [this related Wiki 
> page|http://cwiki.apache.org/confluence/x/eIOJ]



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


[jira] [Created] (OFBIZ-7135) Adding role for a party show error on the second add

2016-05-27 Thread Montalbano Florian (JIRA)
Montalbano Florian created OFBIZ-7135:
-

 Summary: Adding role for a party show error on the second add
 Key: OFBIZ-7135
 URL: https://issues.apache.org/jira/browse/OFBIZ-7135
 Project: OFBiz
  Issue Type: Bug
  Components: party
Affects Versions: Trunk
Reporter: Montalbano Florian
Priority: Minor


Hi all,

How to reproduce :
1) Go to the profile of a party and then to the "Role" tab : 
https://localhost:8443/partymgr/control/viewroles?partyId=admin
2) Add any role
3) Wait for the page to reload
4) Try to add another role
5) Notice the error showing up and the redirection to the "profile" page

Problem : The problem comes from a bad request send. When you select a "main 
role" (without clicking on the add button), a request is send to get the form 
for the "secondary role". On the first time, there is no problem, the request 
is something such as : 
https://localhost:8443/partymgr/control/addsecondaryroles

On the second time, it becomes something like this : 
https://localhost:8443/partymgr/control/addrole/addsecondaryroles

When the controller receives this second request, it does both the "addrole" 
and the "addsecondaryroles" request. So when you chose a role in the first 
select, it actually sends a request to add the role before you even click on 
the "add" button.

Root of the problem :
First, the target of the forms (PartyForms#AddPartyRole, 
PartyForms#AddPartyMainRole and PartyForms#AddPartySecondaryRole) adding the 
"main" and "secondary" roles is "addrole/viewroles" (it seems to be the only 
place in the code where a target is done this way). To clear up the request, I 
tried to remove the "/viewroles" to match what is done in another case : when a 
task is added to a project.
It seems to work but I want to know what is your point of view on this.

Then, in the controller, there is a weird redirection to "viewprofile" instead 
of allowing the user to stay on "viewroles". All of this seems related to an 
update of the coding way in the project that didn't affect this part yet.

I'll provide a patch that seems to work.

Thanks,
Florian



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


[jira] [Commented] (OFBIZ-6849) Use only HTTPS in OFBiz

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-6849:


Quoting Deepak on dev ML

Hi Jacques,

I think in fop.xconf file we have to keep http url, as FOP does not support
https baseUrl for external graphics due to certificate issue (not remember
exact reason).

{code}
 
-  http://localhost:8080
+  https://localhost:8443
{code}

If we set the https as  than images will not be rendered. Please
refer
http://demo-trunk-ofbiz.apache.org/ordermgr/control/order.pdf?orderId=DEMO10091

and we get following error on console:
{code}

 [java] 2016-05-27 13:51:48,308 |http-nio-8443-exec-3 |FOUserAgent
  |E| Image not found. URI: /images/ofbiz_logo.gif. (No context
info available)

{code}
If we set the http url than its working fine.

Thanks Deepak, fixed revision: 1745732  



> Use only HTTPS in OFBiz
> ---
>
> Key: OFBIZ-6849
> URL: https://issues.apache.org/jira/browse/OFBIZ-6849
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-6849.patch, OFBIZ-6849.patch, OFBIZ-6849.patch
>
>
> I recently (~4 weeks ago) started the ["Performance over security, is that 
> reasonable?"|http://markmail.org/message/ubgacfzfxvlvlqva] thread on dev ML. 
> I think I did not explain me well then. I must say it's easy to drown down in 
> details with this subject when you want to illustrate the reasons.
> So instead of only answering on the dev ML, I decided it will be good to 
> create a Jira task with maybe related tasks, here it is.
> For now I consider it only an improvement, but since it's a security matter 
> we can discuss backporting later.
> \\
> 
> h2. TL;DR
> h3. Performance over security?
> So why was this thread opposing performance and security? First we need to 
> understand that here performance stands for HTTP and security for HTTPS.
> h5. Why is HTTP standing for performance?
> Actually is now not much performance difference between the 2 protocols, but 
> you can't cache HTTPS requests and it sometimes (inter-continental requests) 
> matters.
> h3. And why the question about being reasonable or not?
> I think it's unreasonable to put performance over security. And nowadays you 
> are not secure when you use HTTP mixed with HTTPS. Most of the time when you 
> mix both is because you want to identity an user using a sessionId. So with 
> HTTPS, after the user started with HTTP. As concisely explained Forrest in 
> the above referenced thread
> {quote}
> If you're switching between HTTPS and HTTP based on some criteria, an 
> attacker can leverage that to trick the user into all kind of things.
> {quote}
> It's also well and simply explained (with other things) in [this 
> article|http://arstechnica.com/business/2011/03/https-is-great-here-is-why-everyone-needs-to-use-it-so-ars-can-too/]:
> {quote}
> The HTTP spec defines a “Secure” flag for cookies, which instructs the 
> browser to only send that cookie value over SSL. If sites set that cookie 
> like they’re supposed to, then yes, SSL is helping you out. Most sites don’t, 
> however, and browsers will happily send the sensitive cookies over 
> unencrypted HTTP. Our hypothetical skeezebag really just needs some way to 
> trick you into opening a normal HTTP URL, maybe by e-mailing you a link to 
> http://yourbank.com/a-picture-of-ponies-and-rainbows.gif so he can sniff the 
> plain-text cookie off your unencrypted HTTP request, or by surreptitiously 
> embedding a JavaScript file via some site’s XSS vulnerability.
> {quote}
> Of course if you site is only showing things but nobody has never to 
> identify, then you are not at risk and HTTP only is perfect. But with 
> ecommerce kind of site or such, it's rarely the case, most of the time users 
> need to identify!
> 
> \\
> So why are people still mixing HTTP and HTTPS on their site? In the 1st 
> answer at 
> [\[1\]|https://security.stackexchange.com/questions/4369/why-is-https-not-the-default-protocol#answer-4376]
>  Thomas Pornin and others gave some interesting points and answers. At 
> [\[2\]|http://arstechnica.com/business/2011/03/https-is-more-secure-so-why-isnt-the-web-using-it/]
>  Yves Lafon gave also a good summary even if a bit old now. I took some 
> questions/answers from 
> [\[3\]|https://stackoverflow.com/questions/2746047/why-not-use-https-for-everything]
>  also. So you might check those links by yourself, here is an abstract:
> # *"Some browsers may not support SSL"* Only old Lynx versions, negligible
> # *"Connection initiation requires some extra network roundtrips"* Negligible 
> but for sites which serve mostly 

[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Rishi Solanki (JIRA)

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

Rishi Solanki commented on OFBIZ-7079:
--

Agree with Deepak on this  Overall functionality should work as follows;

- A productX with no inventoryItemType set then system will use 
Facility.defaultInventoryItemTypeId, otherwise system will use what set at the 
Product level.
- Generally Facility manage one Inventory Item Type of inventories. But it does 
not mean facility with default type as serialized will never and/or can not 
store non-serialized products.
- That means even if facility is set default as serialized then it should serve 
same as it serve for InventoryItem.inventoryItemTypeId.
- As we are able to receive non serialized inventory in default serialized 
Facility same we should be able to do for Product.

On the basis of above observations I would say code is good to go. I think 
Deepak you would like to check how inventoryItemTypeId behaves with Facility 
and InvetoryItem, and if it matches then we are good. 

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Commented] (OFBIZ-7008) Support to add condition for Geo Location in Promo Engine

2016-05-27 Thread Vishal Chhabria (JIRA)

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

Vishal Chhabria commented on OFBIZ-7008:


[~mridul.pathak] I am on it. I will fix the tests and provide the updated patch.

> Support to add condition for Geo Location in Promo Engine
> -
>
> Key: OFBIZ-7008
> URL: https://issues.apache.org/jira/browse/OFBIZ-7008
> Project: OFBiz
>  Issue Type: New Feature
>Affects Versions: Trunk
>Reporter: Vishal Chhabria
>Assignee: Mridul Pathak
>Priority: Trivial
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7008.patch, OFBIZ-7008.patch, SampleData.xml
>
>




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


[jira] [Updated] (OFBIZ-6783) Refactor the start component

2016-05-27 Thread Taher Alkhateeb (JIRA)

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

Taher Alkhateeb updated OFBIZ-6783:
---
Attachment: OFBIZ-6783.patch

This patch has reference to the thread 
http://ofbiz.markmail.org/message/b4jovfhurczunbam?q=proposal+to+remove+cobertura+and+sonar+from+ofbiz

The thread approves (so far) removing cobertura and sonar from the framework to 
have a leaner cleaner startup code base.

I ran all the tests and did some smoke tests and nothing is on fire so far. 
Please check and help if you can.

> Refactor the start component
> 
>
> Key: OFBIZ-6783
> URL: https://issues.apache.org/jira/browse/OFBIZ-6783
> Project: OFBiz
>  Issue Type: Improvement
>  Components: framework
>Affects Versions: Upcoming Branch
>Reporter: Taher Alkhateeb
>Assignee: Taher Alkhateeb
>  Labels: framework, main, refactoring, start
> Attachments: OFBIZ-6783.patch, OFBIZ-6783.patch, OFBIZ-6783.patch, 
> OFBIZ-6783.patch, OFBIZ-6783.patch, OFBIZ-6783.patch, OFBIZ-6783.patch, 
> OFBIZ-6783.patch, OFBIZ-6783.patch, OFBIZ-6783.patch, OFBIZ-6783.patch, 
> OFBIZ-6783.patch, OFBIZ-6783.patch, OFBIZ-6783.patch, StartCommandUtil.java, 
> error.log, ofbiz.log
>
>
> Looking at the main method and design of Start.java and the start component 
> overall looks ugly. The things I would like to fix so far are:
> - the files are too long
> - some variables are not even needed (loaderArgs?)
> - the level of abstraction is wrong
> - main throws an exception!
> - the arguments processing logic is terrible, need to move it to commons-cli
> It's just so messy and ugly to look at. So for me refactoring starts at 
> Start! Given that this is an important component, I will provide a patch to 
> be reviewed by the community before committing just to be on the safe side.



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


Re: proposal to remove cobertura and sonar from ofbiz

2016-05-27 Thread Taher Alkhateeb
Hello Everyone,

Thank you all for your votes and support. I will submit a patch in
https://issues.apache.org/jira/browse/OFBIZ-6783 and refer to this thread
accordingly.

I really appreciate your support. Also thank you Adam for the tips, I did a
little bit of research and it seems that yes cobertura is the best coverage
tool to use with ofbiz and I am definitely interested in reintroducing it
in the future.

I won't commit anything to give time for everyone to test and/or contribute
more to this thread.

Cheers

Taher Alkhateeb

On Fri, May 27, 2016 at 10:00 AM, Sharan-F  wrote:

> +1 to go ahead too.
>
> If we have had these issues hanging around for years without being resolved
> then I think a clean start sounds the best.
>
> Thanks
> Sharan
>
>
>
> --
> View this message in context:
> http://ofbiz.135035.n4.nabble.com/proposal-to-remove-cobertura-and-sonar-from-ofbiz-tp4681662p4681716.html
> Sent from the OFBiz - Dev mailing list archive at Nabble.com.
>


Re: svn commit: r1745525 - in /ofbiz/trunk: ./ applications/accounting/config/ applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/ applications/content/config/ framework/common/src/org/

2016-05-27 Thread Deepak Dixit
Hi Jacques,

I think in fop.xconf file we have to keep http url, as FOP does not support
https baseUrl for external graphics due to certificate issue (not remember
exact reason).

{code}
 
-  http://localhost:8080
+  https://localhost:8443
{code}

If we set the https as  than images will not be rendered. Please
refer
http://demo-trunk-ofbiz.apache.org/ordermgr/control/order.pdf?orderId=DEMO10091

and we get following error on console:
{code}

 [java] 2016-05-27 13:51:48,308 |http-nio-8443-exec-3 |FOUserAgent
  |E| Image not found. URI: /images/ofbiz_logo.gif. (No context
info available)

{code}
If we set the http url than its working fine.


Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Wed, May 25, 2016 at 11:32 PM,  wrote:

> Author: jleroux
> Date: Wed May 25 18:02:23 2016
> New Revision: 1745525
>
> URL: http://svn.apache.org/viewvc?rev=1745525=rev
> Log:
> Implements "Use only HTTPS in OFBiz" -
> https://issues.apache.org/jira/browse/OFBIZ-6849
>
> All tests passes and the normal use of OFBiz seems to work
>
> Modified:
> ofbiz/trunk/README
> ofbiz/trunk/applications/accounting/config/payment.properties
> ofbiz/trunk/applications/accounting/config/paymentTest.properties
>
> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
>
> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/readme
> ofbiz/trunk/applications/content/config/content.properties
> ofbiz/trunk/framework/common/src/org/ofbiz/common/CommonServices.java
> ofbiz/trunk/framework/service/config/serviceengine.xml
> ofbiz/trunk/framework/webapp/config/fop.xconf
> ofbiz/trunk/framework/webapp/config/url.properties
> ofbiz/trunk/framework/webtools/webapp/webtools/WEB-INF/controller.xml
> ofbiz/trunk/specialpurpose/cmssite/template/ofbiz/OfbizFooter.ftl
> ofbiz/trunk/specialpurpose/ecommerce/data/DemoSurvey.xml
> ofbiz/trunk/specialpurpose/ecommerce/data/DemoTestSurveyData.xml
>
> ofbiz/trunk/specialpurpose/googlecheckout/config/googleCheckout.properties
>
> Modified: ofbiz/trunk/README
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/README?rev=1745525=1745524=1745525=diff
>
> ==
> --- ofbiz/trunk/README (original)
> +++ ofbiz/trunk/README Wed May 25 18:02:23 2016
> @@ -21,7 +21,7 @@ ant start
>  (you can also run directly "ant load-demo start")
>
>  Once OFBiz starts, you can look at the demo storefront at:
> -http://localhost:8080/ecommerce
> +https://localhost:8443/ecommerce
>
>  the back office at:
>  https://localhost:8443/ordermgr
>
> Modified: ofbiz/trunk/applications/accounting/config/payment.properties
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/payment.properties?rev=1745525=1745524=1745525=diff
>
> ==
> --- ofbiz/trunk/applications/accounting/config/payment.properties
> (original)
> +++ ofbiz/trunk/applications/accounting/config/payment.properties Wed May
> 25 18:02:23 2016
> @@ -423,7 +423,7 @@ merchantSubId=0
>
>  # URL van de pagina in de webshop waarnaar de consument wordt geredirect
> na de iDEAL transactie
>  #merchantReturnURL=http://[yourServerName]/ecommerce/control/payPalNotify
> -merchantReturnURL=http://localhost:8080/ecommerce/control/idealNotify
> +merchantReturnURL=https://localhost:8443/ecommerce/control/idealNotify
>
>  ## acquirer attributes
>  # URL van de acquirer van de acceptant; niet wijzigen
>
> Modified: ofbiz/trunk/applications/accounting/config/paymentTest.properties
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/config/paymentTest.properties?rev=1745525=1745524=1745525=diff
>
> ==
> --- ofbiz/trunk/applications/accounting/config/paymentTest.properties
> (original)
> +++ ofbiz/trunk/applications/accounting/config/paymentTest.properties Wed
> May 25 18:02:23 2016
> @@ -79,7 +79,7 @@ merchantSubId=0
>
>  # URL van de pagina in de webshop waarnaar de consument wordt geredirect
> na de iDEAL transactie
>  #merchantReturnURL=http://[yourServerName]/ecommerce/control/payPalNotify
> -merchantReturnURL=http://localhost:8080/ecommerce/control/idealNotify
> +merchantReturnURL=https://localhost:8443/ecommerce/control/idealNotify
>
>  ## acquirer attributes
>  # URL van de acquirer van de acceptant; niet wijzigen
>
> Modified:
> ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java
> URL:
> http://svn.apache.org/viewvc/ofbiz/trunk/applications/accounting/src/org/ofbiz/accounting/thirdparty/ideal/IdealPaymentServiceTest.java?rev=1745525=1745524=1745525=diff
>
> ==
> ---
> 

[jira] [Closed] (OFBIZ-7134) View return screen broken

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit closed OFBIZ-7134.
---
   Resolution: Fixed
Fix Version/s: 13.07.04
   15.12.01
   14.12.01

> View return screen broken
> -
>
> Key: OFBIZ-7134
> URL: https://issues.apache.org/jira/browse/OFBIZ-7134
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 
> Release Branch 15.12
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
>Priority: Minor
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> Here is the steps to regenerate issue.
> - Create return against sales order
> - Receive return
> - Navigate to return header page



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


[jira] [Commented] (OFBIZ-7134) View return screen broken

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-7134:
-

This has been fixed at

Trunk at r#1745713
15.12 at r#1745714
14.12 at r#1745715
13.07 at r#1745720

> View return screen broken
> -
>
> Key: OFBIZ-7134
> URL: https://issues.apache.org/jira/browse/OFBIZ-7134
> Project: OFBiz
>  Issue Type: Bug
>  Components: order
>Affects Versions: Release Branch 13.07, Release Branch 14.12, Trunk, 
> Release Branch 15.12
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
>Priority: Minor
> Fix For: 14.12.01, 15.12.01, 13.07.04
>
>
> Here is the steps to regenerate issue.
> - Create return against sales order
> - Receive return
> - Navigate to return header page



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


[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-7079:
-

Let me explain the "default" word :

We have attribute default-value in service definition, its behavior is if value 
passed in service context than its uses passed value else it set the default 
value :)

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


Re: proposal to remove cobertura and sonar from ofbiz

2016-05-27 Thread Sharan-F
+1 to go ahead too.

If we have had these issues hanging around for years without being resolved
then I think a clean start sounds the best.

Thanks
Sharan



--
View this message in context: 
http://ofbiz.135035.n4.nabble.com/proposal-to-remove-cobertura-and-sonar-from-ofbiz-tp4681662p4681716.html
Sent from the OFBiz - Dev mailing list archive at Nabble.com.


[jira] [Commented] (OFBIZ-3500) Umbrella issue for components dependency

2016-05-27 Thread Pierre Smits (JIRA)

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

Pierre Smits commented on OFBIZ-3500:
-

Is this issue still valid?

> Umbrella issue for components dependency
> 
>
> Key: OFBIZ-3500
> URL: https://issues.apache.org/jira/browse/OFBIZ-3500
> Project: OFBiz
>  Issue Type: Improvement
>  Components: ALL COMPONENTS
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
> Attachments: dependencyCheck.groovy
>
>
> This issue is dedicated to group components dependency related issues.
> Chris Snow created [this related Wiki 
> page|http://cwiki.apache.org/confluence/x/eIOJ]



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


buildbot success in on ofbiz-branch15

2016-05-27 Thread buildbot
The Buildbot has detected a restored build on builder ofbiz-branch15 while 
building . Full details are available at:
https://ci.apache.org/builders/ofbiz-branch15/builds/90

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

Buildslave for this Build: silvanus_ubuntu

Build Reason: The AnyBranchScheduler scheduler named 'on-ofbiz15-commit' 
triggered this build
Build Source Stamp: [branch ofbiz/branches/release15.12] 1745714
Blamelist: deepak

Build succeeded!

Sincerely,
 -The Buildbot





[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-7079:
-

I think its default inventory item type not facility inventory item type, it 
means if no inventory item type is define than it will be considered as 
facility.defaultInvenotryItemType. But if we set other than this then it will 
be sued.

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-7079:


I mean if the Facility is set to receive serialised products 
(Facility.defaultInventoryItemTypeId set to SERIALIZED_INV_ITEM) and we move a 
non serialised product there, should we not at least warn the user?

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


Re: proposal to remove cobertura and sonar from ofbiz

2016-05-27 Thread Jacques Le Roux

+1 to get ahead :)

Jacques

Le 27/05/2016 à 08:03, Taher Alkhateeb a écrit :

Hi Jacques,

I am interested first and foremost in cleaning the code base which is hard
work and i don't want to be sidetracked by other tasks.

The links below confirm my concerns that the code is problematic, and after
your feedback as well as Jacopo's I am more inclined to remove the code
than work _around_ it. I am just not sure what to do next or whether to
request a vote or just go ahead and try to isolate the code away from the
startup component.

FYI I have a ready patch that can remove the whole thing, so my hesitation
is only in terms ok getting the thumbs up. Suggestions?

Taher Alkhateeb
On May 27, 2016 8:33 AM, "Jacques Le Roux" 
wrote:


Hi Taher,

While at it, FYI: I'd love to see this flight
https://issues.apache.org/jira/browse/INFRA-3590

See also https://issues.apache.org/jira/browse/OFBIZ-4757

Jacques


Le 26/05/2016 à 19:24, Taher Alkhateeb a écrit :


Hi Adam

Ok your objection is a good enough "no" for me to back off. I will try to
think of a way to work on the integration as you suggested.

I am not picking specifically on your work. However the entire startup
logic has many problems and lengthy messy code scattered all over the
place. I am trying as much as I can to "cut out" code until some one says
no like your good self.

I will fix the build.xml to ensure correct behavior in cobertura.

Taher Alkhateeb

On Thursday, 26 May 2016, Adam Heath  wrote:

Let me restate, do not remove the code coverage tool; fix the integration.

Every single time I used code coverage to design more tests, I *always*
found bugs.  Real bugs.  And, I also found unreachable code.  I'll give
an
example:

==
public void printMap(Map value) {
if (value == null) {
  return;
}
String foo = safeToString(value);
System.err.println(foo);
}

private String safeToString(Object value) {
if (value == null) {
  return null;
}
return value.toString();
}
==

Granted, the above unreachable code in safeToString *code* be discovered
with deep study, but an *automated* tool makes it much easier to find.
And, the above example is a *very* simple example. Please take a look at
the test cases for UtilCache.

On 05/26/2016 11:26 AM, Adam Heath wrote:

Not to Pierre, but ugly and broken?  How so?  Please expand with concrete

issues.

ps: I'm the original integrator of cobertura into ofbiz.

pps: I have a local branch that converted ofbiz to maven, and actually
produced a runnable output.  Should I revive that?

On 05/26/2016 07:54 AM, Pierre Smits wrote:

+1 as it never got off the ground properly. We can always revisit later

when desire to do so rises again.

I use Sonar, but that is another subject.

Best regards,

Pierre Smits

ORRTIZ.COM 
OFBiz based solutions & services

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

On Thu, May 26, 2016 at 2:46 PM, Taher Alkhateeb <
slidingfilame...@gmail.com

wrote:

Hello everyone,

As part of the refactoring process, I suggest to completely remove
cobertura and sonar from the framework. My proposal is based on the
following:

- The startup logic is more complex because of the existence of legacy
classes (Instrumenter, InstrumenterWorker, etc ...).
- No one (AFAIK) is actively using cobertura or sonar, and the targets
in
build.xml are actually broken
- The way cobertura is integrated with ofbiz is poor and ugly
- Before integrating cobertura, ofbiz first needs a better testing
framework that allows for TDD and red-green-refactor. Otherwise, this
whole
issue with test coverage is a moot point
- Too much complexity and legacy code in build.xml, common.xml,
ivy.xml,
macros.xml and others. It's just really ugly

All the code that I saw for cobertura is just ugly and broken. Now
it's
perfectly fine to reintroduce cobertura cleanly in the future, but I
would
not use the existing code anyway, I would just wipe it all out and
start
fresh.

I'm not sure whether we need to vote on this? Appreciate your
feedback.

Taher Alkhateeb







[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-7079:
-

One more thing I would like to set product.inventoryItemTypeId only at the time 
of product creation. We can't edit this setting as this is only one time setup 
thing, like we have product.orderDecimalQuantity.

If sounds looks good than I'd like to commit this as well.

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Deepak Dixit (JIRA)

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

Deepak Dixit commented on OFBIZ-7079:
-

Thanks Jacques,

How we can say that facility is serialized or non-serialized?

I think facility.defaultInventoryItemTypeId should be used to recognize only 
default type while receiving, means if I am receiving product and did not pass 
the inventoryItemTypeId then it will use the 
facility.defaultInventoryItemTypeId.

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


Re: svn commit: r1745710 - /ofbiz/trunk/applications/product/template/inventory/ReceiveInventory.ftl

2016-05-27 Thread Jacques Le Roux

Ho, no needs to apologize for a typo ;)

Thanks for your work!

Jacques


Le 27/05/2016 à 07:43, Deepak Dixit a écrit :

My Bad :( ,  Thanks Jacques.

Thanks & Regards
--
Deepak Dixit
www.hotwaxsystems.com

On Fri, May 27, 2016 at 11:11 AM,  wrote:


Author: jleroux
Date: Fri May 27 05:41:25 2016
New Revision: 1745710

URL: http://svn.apache.org/viewvc?rev=1745710=rev
Log:
Fixes a typo, no functional change

Modified:

ofbiz/trunk/applications/product/template/inventory/ReceiveInventory.ftl

Modified:
ofbiz/trunk/applications/product/template/inventory/ReceiveInventory.ftl
URL:
http://svn.apache.org/viewvc/ofbiz/trunk/applications/product/template/inventory/ReceiveInventory.ftl?rev=1745710=1745709=1745710=diff

==
---
ofbiz/trunk/applications/product/template/inventory/ReceiveInventory.ftl
(original)
+++
ofbiz/trunk/applications/product/template/inventory/ReceiveInventory.ftl
Fri May 27 05:41:25 2016
@@ -154,8 +154,8 @@ under the License.

  

-  <#assign isSeriazed =
Static["org.ofbiz.product.product.ProductWorker"].isSerialized(delegator,
product.productId)!/>
-  <#if isSeriazed?has_content>
+  <#assign isSerialized =
Static["org.ofbiz.product.product.ProductWorker"].isSerialized(delegator,
product.productId)!/>
+  <#if isSerialized?has_content>
  

${uiLabelMap.ProductSerialNumber}
@@ -485,8 +485,8 @@ under the License.


  
-  <#assign isSeriazed =
Static["org.ofbiz.product.product.ProductWorker"].isSerialized(delegator,
product.productId)!/>
-  <#if isSeriazed?has_content>
+  <#assign isSerialized =
Static["org.ofbiz.product.product.ProductWorker"].isSerialized(delegator,
product.productId)!/>
+  <#if isSerialized?has_content>
  ${uiLabelMap.ProductSerialNumber} :
  
  







[jira] [Commented] (OFBIZ-7079) Extend Product entity and add serialized field

2016-05-27 Thread Jacques Le Roux (JIRA)

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

Jacques Le Roux commented on OFBIZ-7079:


Thanks,

OK cool, so we have no check when someone move a serialised product to a non 
serialised facility or vice-versa, right? Could we not at least add a warning 
(TODO) in code about that before backporting? Of course having the 
functionality would be even better ;)

> Extend Product entity and add serialized field
> --
>
> Key: OFBIZ-7079
> URL: https://issues.apache.org/jira/browse/OFBIZ-7079
> Project: OFBiz
>  Issue Type: Improvement
>Reporter: Deepak Dixit
>Assignee: Deepak Dixit
> Fix For: Upcoming Branch
>
> Attachments: OFBIZ-7079.patch
>
>
> Extend Product entity and add serialized field to recognize product behavior. 
> Will use product.serialized at the time of receiving to identified inventory 
> item behavior.
> This will be setup time configuration, At the time of Product creation will 
> set this flag. 



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


Re: proposal to remove cobertura and sonar from ofbiz

2016-05-27 Thread Taher Alkhateeb
Hi Jacques,

I am interested first and foremost in cleaning the code base which is hard
work and i don't want to be sidetracked by other tasks.

The links below confirm my concerns that the code is problematic, and after
your feedback as well as Jacopo's I am more inclined to remove the code
than work _around_ it. I am just not sure what to do next or whether to
request a vote or just go ahead and try to isolate the code away from the
startup component.

FYI I have a ready patch that can remove the whole thing, so my hesitation
is only in terms ok getting the thumbs up. Suggestions?

Taher Alkhateeb
On May 27, 2016 8:33 AM, "Jacques Le Roux" 
wrote:

> Hi Taher,
>
> While at it, FYI: I'd love to see this flight
> https://issues.apache.org/jira/browse/INFRA-3590
>
> See also https://issues.apache.org/jira/browse/OFBIZ-4757
>
> Jacques
>
>
> Le 26/05/2016 à 19:24, Taher Alkhateeb a écrit :
>
>> Hi Adam
>>
>> Ok your objection is a good enough "no" for me to back off. I will try to
>> think of a way to work on the integration as you suggested.
>>
>> I am not picking specifically on your work. However the entire startup
>> logic has many problems and lengthy messy code scattered all over the
>> place. I am trying as much as I can to "cut out" code until some one says
>> no like your good self.
>>
>> I will fix the build.xml to ensure correct behavior in cobertura.
>>
>> Taher Alkhateeb
>>
>> On Thursday, 26 May 2016, Adam Heath  wrote:
>>
>> Let me restate, do not remove the code coverage tool; fix the integration.
>>>
>>> Every single time I used code coverage to design more tests, I *always*
>>> found bugs.  Real bugs.  And, I also found unreachable code.  I'll give
>>> an
>>> example:
>>>
>>> ==
>>> public void printMap(Map value) {
>>>if (value == null) {
>>>  return;
>>>}
>>>String foo = safeToString(value);
>>>System.err.println(foo);
>>> }
>>>
>>> private String safeToString(Object value) {
>>>if (value == null) {
>>>  return null;
>>>}
>>>return value.toString();
>>> }
>>> ==
>>>
>>> Granted, the above unreachable code in safeToString *code* be discovered
>>> with deep study, but an *automated* tool makes it much easier to find.
>>> And, the above example is a *very* simple example. Please take a look at
>>> the test cases for UtilCache.
>>>
>>> On 05/26/2016 11:26 AM, Adam Heath wrote:
>>>
>>> Not to Pierre, but ugly and broken?  How so?  Please expand with concrete
 issues.

 ps: I'm the original integrator of cobertura into ofbiz.

 pps: I have a local branch that converted ofbiz to maven, and actually
 produced a runnable output.  Should I revive that?

 On 05/26/2016 07:54 AM, Pierre Smits wrote:

 +1 as it never got off the ground properly. We can always revisit later
> when desire to do so rises again.
>
> I use Sonar, but that is another subject.
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM 
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Thu, May 26, 2016 at 2:46 PM, Taher Alkhateeb <
> slidingfilame...@gmail.com
>
> wrote:
>> Hello everyone,
>>
>> As part of the refactoring process, I suggest to completely remove
>> cobertura and sonar from the framework. My proposal is based on the
>> following:
>>
>> - The startup logic is more complex because of the existence of legacy
>> classes (Instrumenter, InstrumenterWorker, etc ...).
>> - No one (AFAIK) is actively using cobertura or sonar, and the targets
>> in
>> build.xml are actually broken
>> - The way cobertura is integrated with ofbiz is poor and ugly
>> - Before integrating cobertura, ofbiz first needs a better testing
>> framework that allows for TDD and red-green-refactor. Otherwise, this
>> whole
>> issue with test coverage is a moot point
>> - Too much complexity and legacy code in build.xml, common.xml,
>> ivy.xml,
>> macros.xml and others. It's just really ugly
>>
>> All the code that I saw for cobertura is just ugly and broken. Now
>> it's
>> perfectly fine to reintroduce cobertura cleanly in the future, but I
>> would
>> not use the existing code anyway, I would just wipe it all out and
>> start
>> fresh.
>>
>> I'm not sure whether we need to vote on this? Appreciate your
>> feedback.
>>
>> Taher Alkhateeb
>>
>>
>>
>