Re: Showing Invoice address from PartyContactMech

[Arun Patidar]

Thanks Jacques and Rishi for your input and confirmation. I will take 
care of your suggestions.


Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development
HotWax Systems
www.hotwaxsystems.com

On Thursday 12 May 2016 09:03 PM, Jacques Le Roux wrote:

I agree with Rishi,

Jacques


Le 12/05/2016 à 16:23, Rishi Solanki a écrit :

Agree with overriding the method signature. Just one note is to keep the
existing behavior as default. That means, if developer use the same 
method

then it should behave how it behaves right now.


Regards,
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Wed, May 11, 2016 at 4:52 PM, Arun Patidar <
arun.pati...@hotwaxsystems.com> wrote:


Hello All,

In getInvoiceAddressByType() method of InvoiceWorker, it is fetching
address from PartyContactWithPurpose in case of empty 
InvoiceContactMech.

This method calls from two methods getBillToAddress() and
getSendFromAddress() of same class.

Here, my concerns are:
- There is no way to check that returned address is invoice associated
address or party address. It is misleading.
- There is no control of user to get the address linked to invoice 
only.


My proposals are:
1). System should return party address only if user really demand 
for it.
We can override method and pass additional parameter for achieving 
this.

2). We can remove PartyContactMech fetching logic from method by
considering that user don't want party addresses as Invoice address.

This will help user to know the exact source of address. Please let me
know your thoughts on this.

--
Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development
HotWax Systems
www.hotwaxsystems.com

[jira] [Updated] (OFBIZ-7067) Pagination in product price does not work correctly after a price creation

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux updated OFBIZ-7067:
---
Issue Type: Sub-task  (was: Bug)
Parent: OFBIZ-2330

> Pagination in product price does not work correctly after a price creation
> --
>
> Key: OFBIZ-7067
> URL: https://issues.apache.org/jira/browse/OFBIZ-7067
> Project: OFBiz
>  Issue Type: Sub-task
>  Components: product
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: Jacques Le Roux
>
> You get this error:
> {code}
> org.ofbiz.webapp.event.EventHandlerException: Found URL parameter [productId] 
> passed to secure (https) request-map with uri [createProductPrice] with an 
> event that calls service [createProductPrice]; this is not allowed for 
> security reasons! The data should be encrypted by making it part of the 
> request body (a form field) instead of the request URL. Moreover it would be 
> kind if you could create a Jira sub-task of 
> https://issues.apache.org/jira/browse/OFBIZ-2330 (check before if a sub-task 
> for this error does not exist). If you are not sure how to create a Jira 
> issue please have a look before at http://cwiki.apache.org/confluence/x/JIB2 
> Thank you in advance for your help.
> {code}



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

[jira] [Created] (OFBIZ-7067) Pagination in product price does not work correctly after a price creation

[Jacques Le Roux (JIRA)]

Jacques Le Roux created OFBIZ-7067:
--

 Summary: Pagination in product price does not work correctly after 
a price creation
 Key: OFBIZ-7067
 URL: https://issues.apache.org/jira/browse/OFBIZ-7067
 Project: OFBiz
  Issue Type: Bug
  Components: product
Affects Versions: Trunk
Reporter: Jacques Le Roux
Assignee: Jacques Le Roux


You get this error:
{code}
org.ofbiz.webapp.event.EventHandlerException: Found URL parameter [productId] 
passed to secure (https) request-map with uri [createProductPrice] with an 
event that calls service [createProductPrice]; this is not allowed for security 
reasons! The data should be encrypted by making it part of the request body (a 
form field) instead of the request URL. Moreover it would be kind if you could 
create a Jira sub-task of https://issues.apache.org/jira/browse/OFBIZ-2330 
(check before if a sub-task for this error does not exist). If you are not sure 
how to create a Jira issue please have a look before at 
http://cwiki.apache.org/confluence/x/JIB2 Thank you in advance for your help.
{code}



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

Re: Showing Invoice address from PartyContactMech

[Jacques Le Roux]

I agree with Rishi,

Jacques


Le 12/05/2016 à 16:23, Rishi Solanki a écrit :

Agree with overriding the method signature. Just one note is to keep the
existing behavior as default. That means, if developer use the same method
then it should behave how it behaves right now.


Regards,
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Wed, May 11, 2016 at 4:52 PM, Arun Patidar <
arun.pati...@hotwaxsystems.com> wrote:


Hello All,

In getInvoiceAddressByType() method of InvoiceWorker, it is fetching
address from PartyContactWithPurpose in case of empty InvoiceContactMech.
This method calls from two methods getBillToAddress() and
getSendFromAddress() of same class.

Here, my concerns are:
- There is no way to check that returned address is invoice associated
address or party address. It is misleading.
- There is no control of user to get the address linked to invoice only.

My proposals are:
1). System should return party address only if user really demand for it.
We can override method and pass additional parameter for achieving this.
2). We can remove PartyContactMech fetching logic from method by
considering that user don't want party addresses as Invoice address.

This will help user to know the exact source of address. Please let me
know your thoughts on this.

--
Thanks & Regards
---
Arun Patidar
Manager, Enterprise Software Development
HotWax Systems
www.hotwaxsystems.com

Re: Showing Invoice address from PartyContactMech

[Rishi Solanki]

Agree with overriding the method signature. Just one note is to keep the
existing behavior as default. That means, if developer use the same method
then it should behave how it behaves right now.


Regards,
--
Rishi Solanki
Manager, Enterprise Software Development
HotWax Systems Pvt. Ltd.
Direct: +91-9893287847
http://www.hotwaxsystems.com

On Wed, May 11, 2016 at 4:52 PM, Arun Patidar <
arun.pati...@hotwaxsystems.com> wrote:

> Hello All,
>
> In getInvoiceAddressByType() method of InvoiceWorker, it is fetching
> address from PartyContactWithPurpose in case of empty InvoiceContactMech.
> This method calls from two methods getBillToAddress() and
> getSendFromAddress() of same class.
>
> Here, my concerns are:
> - There is no way to check that returned address is invoice associated
> address or party address. It is misleading.
> - There is no control of user to get the address linked to invoice only.
>
> My proposals are:
> 1). System should return party address only if user really demand for it.
> We can override method and pass additional parameter for achieving this.
> 2). We can remove PartyContactMech fetching logic from method by
> considering that user don't want party addresses as Invoice address.
>
> This will help user to know the exact source of address. Please let me
> know your thoughts on this.
>
> --
> Thanks & Regards
> ---
> Arun Patidar
> Manager, Enterprise Software Development
> HotWax Systems
> www.hotwaxsystems.com
>
>

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6783:


Then we can also close OFBIZ-5872

> Refactor start.java
> ---
>
> 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, StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6783:


I totally agree, it's far better. When it will be committed, I'll update the 
wiki documentation. I mean at least 
[that|https://cwiki.apache.org/confluence/display/OFBIZ/Apache+OFBiz+Technical+Production+Setup+Guide?focusedCommentId=50234714#comment-50234714]

But before, we still need to check things of course... Should not be too long...

> Refactor start.java
> ---
>
> 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, StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

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

Taher Alkhateeb commented on OFBIZ-6783:


ok yes I get it now.

It's unfortunate that I cannot clean it up, but those are JVM arguments, so I 
cannot do anything about it and like you I also prefer ant start-debug

Still, I would say probably java -jar ofbiz.jar is now much, much better and 
prettier with these fixes. It used to be totally out of sync with the actual 
options being passed, documentation missing, and inconsistent commands (some 
take dashes and some don't)

> Refactor start.java
> ---
>
> 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, StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6783:


Oh, I see you last comment, I need to test that :)

> Refactor start.java
> ---
>
> 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, StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6783:


OK, clear thanks. BTW what I mean is I will still prefer
"ant start-debug"
over
"java -Xrunjdwp:transport=dt_socket,server=y,suspend=n,address=8091 -jar 
ofbiz.jar --debug"
see? :)


> Refactor start.java
> ---
>
> 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, StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Updated] (OFBIZ-6783) Refactor start.java

[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

ok, this is the latest patch which adds the following to the previous patch

- fixes the incorrect target arguments --start-debug and --start-batch
- updates the documentation of java -jar ofbiz.jar --debug

> Refactor start.java
> ---
>
> 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, StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-3847:
--

When I highlighted the line, I meant that oldValue is null not parameter value 
is null. 

I have just tested it again, value is not null but it is a GenericPK so it has 
no references all non pk fields

Here is a stack trace from eclipse

Daemon Thread [ajp-bio-8019-exec-3] (Suspended (breakpoint at line 137 in 
EntityEcaRule))   
owns: SocketWrapper  (id=194)
EntityEcaRule.eval(String, DispatchContext, GenericEntity, boolean, 
Set) line: 137  
DelegatorEcaHandler.evalRules(String, Map, 
String, GenericEntity, boolean) line: 109
GenericDelegator$EntityEcaRuleRunner.evalRules(String, String, 
GenericEntity, boolean) line: 2274
GenericDelegator.removeByPrimaryKey(GenericPK) line: 1004   
GenericWebEvent.updateGeneric(HttpServletRequest, HttpServletResponse) 
line: 158
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not 
available [native method]  
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 62  
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 43  
Method.invoke(Object, Object...) line: 498  
JavaEventHandler.invoke(String, String, Class, Class[], Object[]) 
line: 92
JavaEventHandler.invoke(ConfigXMLReader$Event, 
ConfigXMLReader$RequestMap, HttpServletRequest, HttpServletResponse) line: 78   
 
RequestHandler.runEvent(HttpServletRequest, HttpServletResponse, 
ConfigXMLReader$Event, ConfigXMLReader$RequestMap, String) line: 759   
RequestHandler.doRequest(HttpServletRequest, HttpServletResponse, 
String, GenericValue, Delegator) line: 476
ControlServlet.doGet(HttpServletRequest, HttpServletResponse) line: 213 
ControlServlet(HttpServlet).service(HttpServletRequest, 
HttpServletResponse) line: 620  
ControlServlet(HttpServlet).service(ServletRequest, ServletResponse) 
line: 727  
ApplicationFilterChain.internalDoFilter(ServletRequest, 
ServletResponse) line: 303  
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 
208  
ContextFilter.doFilter(ServletRequest, ServletResponse, FilterChain) 
line: 323  
ApplicationFilterChain.internalDoFilter(ServletRequest, 
ServletResponse) line: 241  
ApplicationFilterChain.doFilter(ServletRequest, ServletResponse) line: 
208  
StandardWrapperValve.invoke(Request, Response) line: 220
StandardContextValve.invoke(Request, Response) line: 122
NonLoginAuthenticator(AuthenticatorBase).invoke(Request, Response) 
line: 505
StandardHostValve.invoke(Request, Response) line: 170   
ErrorReportValve.invoke(Request, Response) line: 103
StandardEngineValve.invoke(Request, Response) line: 116 
AccessLogValve.invoke(Request, Response) line: 956  
CoyoteAdapter.service(Request, Response) line: 423  
AjpProcessor.process(SocketWrapper) line: 190   

AjpProtocol$AjpConnectionHandler(AbstractProtocol$AbstractConnectionHandler).process(SocketWrapper,
 SocketStatus) line: 625 
JIoEndpoint$SocketProcessor.run() line: 316 

ThreadPoolExecutor(ThreadPoolExecutor).runWorker(ThreadPoolExecutor$Worker) 
line: 1142  
ThreadPoolExecutor$Worker.run() line: 617   
TaskThread$WrappingRunnable.run() line: 61  
TaskThread(Thread).run() line: 745  


> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
> Fix For: Upcoming Branch
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store 

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

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

Taher Alkhateeb commented on OFBIZ-6783:


Oh sorry for the confusion, you did not understand me because I'm talking about 
an earlier discussion. Let me make it clear below

If you look at our conversation above, you said "I will still prefer ant 
start-debug". And if you look at the new build.xml which I'm going to send, it 
will be exactly like you want it i.e. ant start-debug. I'm not changing ant 
start-debug to ant debug. Instead what I'm changing is the arguments inside the 
ant target start-debug. Specifically, I will change the argument --start-debug 
to be --debug (which is passed to ofbiz.jar).

I hope this makes clear for you now. In short, all the ant targets are going to 
remain the same. The only thing that changes is the arguments inside of them to 
comply with the new requirements of jara -jar ofbiz.jar

> Refactor start.java
> ---
>
> 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, 
> StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Paul Foxworthy (JIRA)]

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

Paul Foxworthy commented on OFBIZ-3847:
---

Hi Gareth,

I haven't tried to duplicate this yet, but on the line where I thought you 
suggested the NPE occurs, the value.getPrimaryKey() is the only thing I can see 
that might go wrong - thus my suggestion that value itself might be null. Does 
that make sense to you?

I think that in principle, it ought to be possible to do an ECA check on 
remove, much like a delete trigger in a relational database.

The normal way to adjust the availableToPromise for an InventoryItem would be 
to *create* an InventoryItemDetail. IID is like a delta in a version control 
system - it keeps a history of what changed. Why do you need to remove an IID?

Regards

Paul

> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
> Fix For: Upcoming Branch
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Jacques Le Roux (JIRA)]

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

Jacques Le Roux commented on OFBIZ-6783:


bq.  i'm not renaming them, the args to them are wrong. i did not rename any 
ant target.
What do you mean by that exactly?
bq.  i did not rename any ant target.
I know you did not, it's unrelated because I get it with an up todate and 
unpatched local Working Copy

> Refactor start.java
> ---
>
> 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, 
> StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)

[jira] [Commented] (OFBIZ-3847) Entity ECAs not triggered correctly when using Delegator.storeAll() method

[Gareth Carter (JIRA)]

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

Gareth Carter commented on OFBIZ-3847:
--

Hi Paul

Thanks for the quick response!

My guess is the field (availableToPromiseDiff in InventoryItemDetail example) 
is available in the value parameter but the field value is null.

InventoryItemDetail is a bad example here but we had to remove some records 
because of invalid data. We could not do this via webtools but could using 
pgadmin.

As for a fix, all I can think of is either check for null on oldValue or don't 
run the check on remove operation. This will eliminate NPE and 
setLastInventoryCount would not run though I am not sure if this would be 
correct behaviour if availableToPromiseDiff = null?


> Entity ECAs not triggered correctly when using Delegator.storeAll() method
> --
>
> Key: OFBIZ-3847
> URL: https://issues.apache.org/jira/browse/OFBIZ-3847
> Project: OFBiz
>  Issue Type: Bug
>  Components: framework
>Affects Versions: Release Branch 10.04
>Reporter: Martin Kreidenweis
>Assignee: Paul Foxworthy
> Fix For: Upcoming Branch
>
> Attachments: GenericDelegator.java.diff, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch, 
> OFBIZ-3847_Entity-ECAs-not-triggered-correctly.patch
>
>
> The conditions don't work when updating (not creating) entities using the 
> Delegator.storeAll() method. E.g. the following condition does not work:
> {code}
> 
>  value="N"/>
>  value-attr="productInstance"/>
> 
> {code}
> The indexProductKeywords service is called anyway when the product is updated 
> and the autoCreateKeywords was "N" and stays "N". It works correctly for 
> newly created products. 
> The problem is in the method GenericDelegator.storeAll(), where unchanged 
> field values are not passed down to the store() method. The store method 
> calls the ECA engine, which does not receive the unchanged values at all and 
> thus cannot evaluate the EECA conditions correctly. 



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

[jira] [Commented] (OFBIZ-6783) Refactor start.java

[Taher Alkhateeb (JIRA)]

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

Taher Alkhateeb commented on OFBIZ-6783:


Hi Hans,

I'm glad you're participating. FYI This is becoming more than just refactoring 
start as I'm also changing Config, CommonsDaemonStart and 2 build.xml files.

Anyway, back to your question, I'm a guy who's acquired TDD down to my bones. 
However, testing the changes here pose multiple challenges and I appreciate 
your feedback on them:

- The code is still horrible and messy and everything jumbled together. So I 
can not do isolated unit tests in most places. I still need to refactor and 
breakdown the code some more to make it clean and testable.
- The start component does not allow for testing (it's bootstrapping code). So 
the only way I can test anything is from another component (say, base).
- The magic work of commons-cli is all happening in 
StartupCommandUtil.parseOfbizCommands(args). However, I declared it package 
protected. If I want to test it, then I have to declare it public, and I'm 
trying as much as I can to isolate start from the rest of the framework.

I worked hard to decouple ofbiz from both the command line arguments and also 
from commons-cli. Start is a special component in which it is not easy to test. 
In fact, it was really hard work to change build.xml to make it work with the 
commons-cli jar.

So in summary, I'm not sure what the best course of action is, but I feel 
exposing my methods as public only for the purpose of testing is not a pretty 
solution. The same can also said about reflection.

Maybe I can create a public adapter class or something, I'm not sure. Do you 
have any thoughts?

> Refactor start.java
> ---
>
> 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, 
> StartCommandUtil.java
>
>
> Looking at the main method and design of Start.java looks ugly. The things I 
> would like to fix so far are:
> - the file is 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 file, 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)