[GitHub] [ofbiz-framework] danwatford merged pull request #230: Implemented: Use NPM with gradle to get external JS dependencies (OFBIZ-11960)

2021-10-13 Thread GitBox


danwatford merged pull request #230:
URL: https://github.com/apache/ofbiz-framework/pull/230


   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscr...@ofbiz.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org




[jira] [Commented] (OFBIZ-12016) DiskFileItem as request attribute creates problems

2021-10-13 Thread Jacques Le Roux (Jira)


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

Jacques Le Roux commented on OFBIZ-12016:
-

Ah right, the commits in R18 and R17 are  different than in trunk, did not 
remember that. Note though that current code in R18 has changed since this 
commit (did not check R17, but I guess it's the same). 

Also the code of SafeObjectInputStream is the same in trunk and R18. It's not 
the case for UtilObject. Since I'm implied, for consistency sake and a bit 
peace of mind, I'll check why before confirming about the removal of fileItems 
in RequestHandler (which is safe anyway).

> DiskFileItem as request attribute creates problems
> --
>
> Key: OFBIZ-12016
> URL: https://issues.apache.org/jira/browse/OFBIZ-12016
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 18.12.01, Trunk
>Reporter: Sebastian Berg
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Hi,
> while working on a custom project based on the 18.12.01 version, I noticed a 
> problem with the request handling during a request-redirect-noparam if a 
> DiskFileItem was involved.
> So the situation for me is as follows: during the first request a file is 
> uploaded. I choose a wrong format on purpose, which results in an error 
> respond for that event. Nevertheless the DiskFileItem is set as request 
> attribute together with the error message.
> The request is finished and based on the controller configurations redirected 
> to a second request.
> While handling the second request the previous request's attributes get 
> restored (RequestHandler.java line 733ff). This goes down into 
> SafeObjectInfo.resolveClass() where an Incompatible class exception is 
> thrown. I compared my custom project with the current development status and 
> worked in the changes from commit 3f60efb343a11723aa56c1bc1f5afac3a2f26e9f in 
> OFBIZ-10837.
> While this fixes the issue with the incompatible class exception it also 
> makes it impossible to retrieve any attributes from the first request. 
> Therefore my error message cannot be shown.
> Is there a way to fix it or is it otherwise necessary to always set 
> "fileItems" as request attribute as added in -OFBIZ-11246-?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Updated] (OFBIZ-12336) Financial Account Transaction Unable to Edit

2021-10-13 Thread David S Hunter (Jira)


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

David S Hunter updated OFBIZ-12336:
---
Description: 
The accountant needs a way to edit the financial account transaction that have 
a status id of "Created". Otherwise, the financial account transaction will not 
be able to switch the status to "Approved." 

 To recreate the error: 

  -  Navigate to the Financial Account Screen:
   
https://demo-trunk.ofbiz.apache.org/accounting/control/FinAccountMain
  - click on a bank account account (e.g. "ABN Checking")
  - Navigate to the Transactions and hit Find 
  - For any of the financial account transactions that are "Created," there is 
not a simple way to change the status. 


  was:
The accountant needs a way to edit the financial account transaction at the 
that have a status id of "Created". Otherwise, the financial account 
transaction will not be able to switch the status to "Approved." 

 To recreate the error: 

  -  Navigate to the Financial Account Screen:
   
https://demo-trunk.ofbiz.apache.org/accounting/control/FinAccountMain
  - click on a bank account account (e.g. "ABN Checking")
  - Navigate to the Transactions and hit Find 
  - For any of the financial account transactions that are "Created," there is 
not a simple way to change the status. 



> Financial Account Transaction Unable to Edit
> 
>
> Key: OFBIZ-12336
> URL: https://issues.apache.org/jira/browse/OFBIZ-12336
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 17.12.08
>Reporter: David S Hunter
>Priority: Major
>
> The accountant needs a way to edit the financial account transaction that 
> have a status id of "Created". Otherwise, the financial account transaction 
> will not be able to switch the status to "Approved." 
>  To recreate the error: 
>   -  Navigate to the Financial Account Screen:
>
> https://demo-trunk.ofbiz.apache.org/accounting/control/FinAccountMain
>   - click on a bank account account (e.g. "ABN Checking")
>   - Navigate to the Transactions and hit Find 
>   - For any of the financial account transactions that are "Created," there 
> is not a simple way to change the status. 



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Created] (OFBIZ-12336) Financial Account Transaction Unable to Edit

2021-10-13 Thread David S Hunter (Jira)
David S Hunter created OFBIZ-12336:
--

 Summary: Financial Account Transaction Unable to Edit
 Key: OFBIZ-12336
 URL: https://issues.apache.org/jira/browse/OFBIZ-12336
 Project: OFBiz
  Issue Type: Bug
Affects Versions: 17.12.08
Reporter: David S Hunter


The accountant needs a way to edit the financial account transaction at the 
that have a status id of "Created". Otherwise, the financial account 
transaction will not be able to switch the status to "Approved." 

 To recreate the error: 

  -  Navigate to the Financial Account Screen:
   
https://demo-trunk.ofbiz.apache.org/accounting/control/FinAccountMain
  - click on a bank account account (e.g. "ABN Checking")
  - Navigate to the Transactions and hit Find 
  - For any of the financial account transactions that are "Created," there is 
not a simple way to change the status. 




--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (OFBIZ-12016) DiskFileItem as request attribute creates problems

2021-10-13 Thread Benjamin Jugl (Jira)


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

Benjamin Jugl commented on OFBIZ-12016:
---

I do not know for sure it it can be reproduced ootb. I think there is just no 
use-case atm.

There could be a file-upload leading into a request-redirect, that I am not 
aware of, yet.

 

I had another look. There are indeed three commits.

One for trunk, one for 17.12 and one for 18.12.

The commit for trunk is just fine and you are absolutely correct, that it is 
the way it should be.

The commits for the releases are quite different, though. That caused my 
confusion.

In those the ClassCastException is not handled.

We can indeed redo the removal of fileItems as in 
[https://github.com/apache/ofbiz-framework/commit/4725ae6].

 

 

> DiskFileItem as request attribute creates problems
> --
>
> Key: OFBIZ-12016
> URL: https://issues.apache.org/jira/browse/OFBIZ-12016
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 18.12.01, Trunk
>Reporter: Sebastian Berg
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Hi,
> while working on a custom project based on the 18.12.01 version, I noticed a 
> problem with the request handling during a request-redirect-noparam if a 
> DiskFileItem was involved.
> So the situation for me is as follows: during the first request a file is 
> uploaded. I choose a wrong format on purpose, which results in an error 
> respond for that event. Nevertheless the DiskFileItem is set as request 
> attribute together with the error message.
> The request is finished and based on the controller configurations redirected 
> to a second request.
> While handling the second request the previous request's attributes get 
> restored (RequestHandler.java line 733ff). This goes down into 
> SafeObjectInfo.resolveClass() where an Incompatible class exception is 
> thrown. I compared my custom project with the current development status and 
> worked in the changes from commit 3f60efb343a11723aa56c1bc1f5afac3a2f26e9f in 
> OFBIZ-10837.
> While this fixes the issue with the incompatible class exception it also 
> makes it impossible to retrieve any attributes from the first request. 
> Therefore my error message cannot be shown.
> Is there a way to fix it or is it otherwise necessary to always set 
> "fileItems" as request attribute as added in -OFBIZ-11246-?



--
This message was sent by Atlassian Jira
(v8.3.4#803005)


[jira] [Commented] (OFBIZ-12016) DiskFileItem as request attribute creates problems

2021-10-13 Thread Jacques Le Roux (Jira)


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

Jacques Le Roux commented on OFBIZ-12016:
-

Hi Benjamin,

TLDR; : look for "Now about" at the end of this comment. It took me some time 
(I wrote it just below) before being sure about my answer.

I don't doubt you face an issue. Unfortunately, after Nicolas's request, it 
seems not reproductible OOTB?

If I understand well, the problem is only reproductible when using a 
request-redirect.

I'll try to understand the problem by following your comment.

You say
bq. In UtilObject.java (ll.99) the comment states that "DiskFileItem [...] are 
not serializable, so So SafeObjectInputStream::resolveClass return 
ClassNotFoundException". That is not true, SafeObjectInputStream::resolveClass 
returns ClassCastException.

Actually the removed comment in 
https://github.com/apache/ofbiz-framework/commit/1bc8a20 for  OFBIZ-12216 is
bq. DiskFileItem, FileItemHeadersImpl are not serializable. So 
SafeObjectInputStream::resolveClass return null

It has been removed, with the rest, for security and refactoring reasons (as 
the comment say in same commit <>). That's why indeed ClassCastException is 
throwed by SafeObjectInputStream::resolveClass and 
UtilObject::getObjectException which is its only caller.

Then you say
bq. In the actual version of UtilObject.java, ClassCastException ist not 
handled, but in the first version of OFBIZ-12216s resolution it had been.

That's not clear to me getObject and getObjectException methods throw 
ClassCastException. So what do you mean by ClassCastException ist not handled. 
And what is "the first version of OFBIZ-12216s resolution"? There is only 1 
commit there.

Also you say
bq. I cannot find an explanation anywhere, why it had been removed.
If you speak about ClassCastException is has not be removed but added, as 
explained above ("rather than returning null")

About
bq. Although handling this error would at least solve the hard exception on the 
frontend, this alone is not a sufficial solution.
Where would you handle "this error" and what is "this error"?

Now about
bq. Since Request-Redirects can not handle DiskFileItems, is anything 
contraindicative for removing them in the redirect 
(RequestHandler::callRedirect) and logging a warning, that it has been removed? 
Or are there other solutions that I am not aware of?
This was done before with 
https://github.com/apache/ofbiz-framework/commit/4725ae6 and removed by 
https://github.com/apache/ofbiz-framework/commit/3f60efb

I see no reasons to not do it again in this specific case (that we can't 
reproduce OOTB). I don't see any other solutions, though I wonder why it does 
not happen OOTB. Have you an idea about that?

Anyway it's not serialisable so impossible to be deserialised by 
UtilObject::getBytes and don't introduce security issues. It was actually 
changed more as a refactoring trying to clean code, which was ultimately 
cleaned by using ClassCastException. You don't even need to log a warning, it's 
specific to file upload and I guess nobody care about DiskFileItem and 
FileItemHeadersImpl being removed there. Maybe you even want to use something 
like in {{"if (obj instanceof Serializable)"}}

HTH


> DiskFileItem as request attribute creates problems
> --
>
> Key: OFBIZ-12016
> URL: https://issues.apache.org/jira/browse/OFBIZ-12016
> Project: OFBiz
>  Issue Type: Bug
>Affects Versions: 18.12.01, Trunk
>Reporter: Sebastian Berg
>Assignee: Jacques Le Roux
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Hi,
> while working on a custom project based on the 18.12.01 version, I noticed a 
> problem with the request handling during a request-redirect-noparam if a 
> DiskFileItem was involved.
> So the situation for me is as follows: during the first request a file is 
> uploaded. I choose a wrong format on purpose, which results in an error 
> respond for that event. Nevertheless the DiskFileItem is set as request 
> attribute together with the error message.
> The request is finished and based on the controller configurations redirected 
> to a second request.
> While handling the second request the previous request's attributes get 
> restored (RequestHandler.java line 733ff). This goes down into 
> SafeObjectInfo.resolveClass() where an Incompatible class exception is 
> thrown. I compared my custom project with the current development status and 
> worked in the changes from commit 3f60efb343a11723aa56c1bc1f5afac3a2f26e9f in 
> OFBIZ-10837.
> While this fixes the issue with the incompatible class exception it also 
> makes it impossible to retrieve any attributes from the first request. 
> Therefore my error message cannot be shown.
> Is there a way to fix it or is it