[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032823#comment-17032823 ] Jacques Le Roux commented on OFBIZ-11306: - Hi James, Please try this one: [^OFBIZ-11306.patch] > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Attachment: OFBIZ-11306.patch > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032817#comment-17032817 ] James Yong commented on OFBIZ-11306: Hi Jacques, Applying the current patch gives me the followng error: "Can't read patch: Second file name expected (line:159) > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[
https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032541#comment-17032541
]
James Yong commented on OFBIZ-11306:
Hi Michael,
{quote}Yes, my main point is that we should avoid committing (portions) of a
new feature into trunk directly until the feature is finished, reviewed, testet
and accepted.
{quote}
Agreed.
Some bugs (OFBIZ-11319, OFBIZ-11329) are discovered while working on this
feature. Without fixing the bugs, the feature cannot be adequately tested.
The improvement (OFBIZ-11317) introduced a 'controlPath' attribute to ofbizUrl
macro to allow ofbizUrl macro to accept "inter-app" URL. As the new feature
make uses of ofbizUrl macro to dynamically add the csrf token to links, this
improvement allow the new feature to add csrf token to both "intra-app" and
"inter-app" links with equal ease.
{quote}why do you want to store the tokens in the cache instead of the session?
{quote}
To add on to Jacques reply.
OFBiz contains a group of web applications. Pages in a web application (e.g. A)
may contain links to another web application (e.g. B). These links which can
contain CSRF tokens, are generated by A. However B needs to know whether the
CSRF tokens received are correct or not. Storing the tokens in a cache map
allows B to read the CSRF tokens generated by A.
Do note that the following tokens are stored in cache map:
# Tokens for non-ajax links after user has logged in.
The following tokens are stored in http sessions as there is no need for
inter-app link:
# Tokens for Ajax links
# Tokens for links where user has not login.
> POC for CSRF Token
> --
>
> Key: OFBIZ-11306
> URL: https://issues.apache.org/jira/browse/OFBIZ-11306
> Project: OFBiz
> Issue Type: Improvement
> Components: ALL APPLICATIONS
>Affects Versions: Upcoming Branch
>Reporter: James Yong
>Assignee: Jacques Le Roux
>Priority: Minor
> Labels: CSRF
> Fix For: Upcoming Branch
>
> Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java,
> CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch,
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch,
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch,
> OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch,
> OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch,
> OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch,
> OFBIZ-11306_Plugins.patch
>
>
> CRSF tokens are generated using SecureRandom class (maybe later a JWT with a
> "time out").
> They are stored in the user sessions (for AJAX calls and unauthenticated HTTP
> calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during
> POST request.
> # In *controllers* a new csrf-token attribute is added to the security tag to
> exempt or force CSRF token check.
> # In *Widget Forms* a hidden token field is auto-generated.
> # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the
> change. Using <@ofbizUrl> macro to generate the CSRF token means there is no
> need to manually add the CSRF token field to each form in the ftl files. It
> will save time for users doing custom implementation and maintenance. While
> there is CSRF token in the form URL, the token is invalidated during form
> submission. So it's uniqueand harmless even though the CSRF token of the form
> submission is shown in the browser address bar.
> # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added
> through OfbizUtil.js (itself called at start in decorators and such)
> # The html metadata is storing the csrf token used by JQuery AJAX. This token
> will not change to another value after it is consumed
> # Csrf tokens for the user are removed from the UtilCache when the user logs
> out or session invalidated.
> The general rule are as follows:
> * RequestMap configured with 'get' method will be exempted from CSRF token
> check.
> * RequestMap configured with 'post' or 'all' method will be subjected to CSRF
> token check. (Note there are discussions that RequestMap with ‘all’ method
> should also not be subjected to CSRF token check. This will be done after
> ensuring a separate uri is used when posting changes.)
> * "main" request URIs are exempted from CSRF token check.
> * Setting csrf-token to false or true on the Request Map will override the
> general rules above.
> To implement:
> * -Allow token map size to be configurable in properties.- OK that's done
> locally
> To Discuss:
> * Invalidate authenticated user session when CSRF token check fails.
> * Configure the general rules in a Service method (which will be run inside
> the constructor of RequestMap class) when
[jira] [Commented] (OFBIZ-11342) Error in user impersonation with sub permission
[ https://issues.apache.org/jira/browse/OFBIZ-11342?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032513#comment-17032513 ] Gil Portenseigne commented on OFBIZ-11342: -- Three patch that, applied in order do : * add a basic unit test for permission validation * add a test addressing the issue * implements a fix for the issue > Error in user impersonation with sub permission > --- > > Key: OFBIZ-11342 > URL: https://issues.apache.org/jira/browse/OFBIZ-11342 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch, Release Branch 17.12, Release Branch > 18.12 >Reporter: Gil Portenseigne >Assignee: Gil Portenseigne >Priority: Minor > Attachments: > 0001-Add-a-new-unit-test-to-validate-adminPermissionTesti.patch, > 0002-Add-a-new-test-for-multi-level-permission.patch, > 0003-Implements-multiLevel-permission-control.patch > > > When impersonating user with sub permission such as : PARTYMGR_PCM_CREATE, > with an admin user that only has PARTYMGR_ADMIN, the impersonation is refused > stating that the impersonated user has more permission than the impersonator. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11342) Error in user impersonation with sub permission
[ https://issues.apache.org/jira/browse/OFBIZ-11342?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gil Portenseigne updated OFBIZ-11342: - Attachment: 0001-Add-a-new-unit-test-to-validate-adminPermissionTesti.patch 0002-Add-a-new-test-for-multi-level-permission.patch 0003-Implements-multiLevel-permission-control.patch > Error in user impersonation with sub permission > --- > > Key: OFBIZ-11342 > URL: https://issues.apache.org/jira/browse/OFBIZ-11342 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Upcoming Branch, Release Branch 17.12, Release Branch > 18.12 >Reporter: Gil Portenseigne >Assignee: Gil Portenseigne >Priority: Minor > Attachments: > 0001-Add-a-new-unit-test-to-validate-adminPermissionTesti.patch, > 0002-Add-a-new-test-for-multi-level-permission.patch, > 0003-Implements-multiLevel-permission-control.patch > > > When impersonating user with sub permission such as : PARTYMGR_PCM_CREATE, > with an admin user that only has PARTYMGR_ADMIN, the impersonation is refused > stating that the impersonated user has more permission than the impersonator. > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032510#comment-17032510 ] Jacques Le Roux commented on OFBIZ-11306: - Agreed, I'll rather use OFBIZ-11301 and https://cwiki.apache.org/confluence/display/OFBIZ/Contributing+via+Git+and+Github++-+WIP > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-11342) Error in user impersonation with sub permission
Gil Portenseigne created OFBIZ-11342: Summary: Error in user impersonation with sub permission Key: OFBIZ-11342 URL: https://issues.apache.org/jira/browse/OFBIZ-11342 Project: OFBiz Issue Type: Bug Components: framework Affects Versions: Upcoming Branch, Release Branch 17.12, Release Branch 18.12 Reporter: Gil Portenseigne Assignee: Gil Portenseigne When impersonating user with sub permission such as : PARTYMGR_PCM_CREATE, with an admin user that only has PARTYMGR_ADMIN, the impersonation is refused stating that the impersonated user has more permission than the impersonator. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[ https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032495#comment-17032495 ] Jacques Le Roux commented on OFBIZ-11329: - OK, all clear here then. > setUserTimeZone should ran only once based on error > --- > > Key: OFBIZ-11329 > URL: https://issues.apache.org/jira/browse/OFBIZ-11329 > Project: OFBiz > Issue Type: Bug > Components: framework, webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: James Yong >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch, > OFBIZ-11329.patch > > > This will be useful when committing CSRF solution as explained in OFBIZ-11306 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[ https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032481#comment-17032481 ] James Yong commented on OFBIZ-11329: bq. You mean that if you use RequestHandlerException the link does not work? Exactly :) > setUserTimeZone should ran only once based on error > --- > > Key: OFBIZ-11329 > URL: https://issues.apache.org/jira/browse/OFBIZ-11329 > Project: OFBiz > Issue Type: Bug > Components: framework, webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: James Yong >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch, > OFBIZ-11329.patch > > > This will be useful when committing CSRF solution as explained in OFBIZ-11306 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032479#comment-17032479 ] Michael Brohl commented on OFBIZ-11306: --- Hi Jacques, we should stop hijacking the issue for these discussions (I did it too here and stop it now because it is the wrong place). Maybe we should remove the comments there and discuss further in the dev mailing list. Regards, Michael > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032478#comment-17032478 ] Jacques Le Roux commented on OFBIZ-11306: - Sorry to make this issue more confusing, but since we are on it and before we write that in stone using the related wiki page. I wrote: bq. The reasons I'd privilege cloned user repositories is about responsability and proliferation of branches in official repos. That would uselessly clutter the repo and scramble things. Anyway, again that's not mine to decide but the community... Actually if you think about it these options are not contradictory. We could use both. When we agree that sufficient work has been done in a cloned repo then we can create an OFBiz repo branch before possibly committing it. What I wonder about is if we need to keep it later? > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11150) Form widget field with input-method="time-dropdown" unable to understand the default time
[
https://issues.apache.org/jira/browse/OFBIZ-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl closed OFBIZ-11150.
-
Fix Version/s: 18.12.01
17.12.01
Resolution: Fixed
Thanks Wiebke,
your patch is in trunk and backported to release branches 17.12/18.12.
> Form widget field with input-method="time-dropdown" unable to understand the
> default time
> -
>
> Key: OFBIZ-11150
> URL: https://issues.apache.org/jira/browse/OFBIZ-11150
> Project: OFBiz
> Issue Type: Sub-task
> Components: example
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Fix For: 17.12.01, 18.12.01
>
> Attachments: OFBIZ-11150_UtilCodec.patch
>
>
> I noticed this error in the example component some time ago (months), it's
> still there:
> {noformat}
> 2019-08-12 13:28:32,868 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field4] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,877 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field5] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,918 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field12] with input-method="time-dropdown" was not
> able to understand the default time [2019-08-12%20132832.833].
> The parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11150) Form widget field with input-method="time-dropdown" unable to understand the default time
[
https://issues.apache.org/jira/browse/OFBIZ-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032472#comment-17032472
]
ASF subversion and git services commented on OFBIZ-11150:
-
Commit 732172787ed51e65b30a654dfbcef90b5805077a in ofbiz-framework's branch
refs/heads/release17.12 from Michael Brohl
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=7321727 ]
Fixed: Form widget field with input-method="time-dropdown" unable to
understand the default time.
(OFBIZ-11150)
Thanks Wiebke Pätzold for reporting and providing the patch.
> Form widget field with input-method="time-dropdown" unable to understand the
> default time
> -
>
> Key: OFBIZ-11150
> URL: https://issues.apache.org/jira/browse/OFBIZ-11150
> Project: OFBiz
> Issue Type: Sub-task
> Components: example
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11150_UtilCodec.patch
>
>
> I noticed this error in the example component some time ago (months), it's
> still there:
> {noformat}
> 2019-08-12 13:28:32,868 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field4] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,877 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field5] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,918 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field12] with input-method="time-dropdown" was not
> able to understand the default time [2019-08-12%20132832.833].
> The parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-9673) CommonEvents improvements
[ https://issues.apache.org/jira/browse/OFBIZ-9673?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-9673. -- Fix Version/s: (was: 17.12.01) Resolution: Won't Do > CommonEvents improvements > - > > Key: OFBIZ-9673 > URL: https://issues.apache.org/jira/browse/OFBIZ-9673 > Project: OFBiz > Issue Type: Improvement > Components: ALL COMPONENTS >Affects Versions: Trunk >Reporter: Wai >Assignee: Jacques Le Roux >Priority: Major > Attachments: OFBIZ-9673.patch, OFBIZ-9673.patch > > > replaced private to protected so that CommonEvents.java is more usable to > derived classes. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11335) Add CommonForms as template pattern configured by theme
[
https://issues.apache.org/jira/browse/OFBIZ-11335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032470#comment-17032470
]
James Yong commented on OFBIZ-11335:
Thanks for the explanation :)
> Add CommonForms as template pattern configured by theme
> ---
>
> Key: OFBIZ-11335
> URL: https://issues.apache.org/jira/browse/OFBIZ-11335
> Project: OFBiz
> Issue Type: New Feature
> Components: framework, themes
>Affects Versions: Trunk
>Reporter: Nicolas Malin
>Assignee: Nicolas Malin
>Priority: Major
> Attachments: OFBIZ-11335.patch
>
>
> Currently on OFBiz we implemented a process to define some different screen
> and menu that can be implemented by the theming
> But for the form we have nothing. All style are hard coded on each
> {code:java}
> odd-row-style="alternate-row" default-table-style="basic-table
> hover-bar">{code}
>
> I propose to extend the theming implementation principle to forms element.
> To start low, I define seven form tempates :
> * grid CommonSimpleGrid
> * grid CommonBasicGrid
> * form CommonSimpleList
> * form CommonBasicList
> * form CommonInLineEditList
> * form CommonSimpleSingle
> * form CommonBasicSingle
>
> We can use its like :
> {code:java}
> extends-resource="component://common/widget/CommonForms.xml"{code}
> The main difficulty raise to this task was propage the visualTheme during the
> ModelForm intanciation, because we need to load wiget style (and some other
> information wanted on the template) on model load in memory.
> With the linked patch I improved form present on screen
> [https://localhost:8443/webtools/control/WebtoolsLayoutDemo]
>
> Finally with this we can extend style form (pagination, header, line and so
> on ...) direclty by your theme without change the framework
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[ https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032464#comment-17032464 ] Jacques Le Roux edited comment on OFBIZ-11329 at 2/7/20 3:39 PM: - Hi James, Thanks for the explanation, one worry less. You mean that if you use RequestHandlerException the link does not work? was (Author: jacques.le.roux): Hi James, Thanks for the explanation, one worry less. > setUserTimeZone should ran only once based on error > --- > > Key: OFBIZ-11329 > URL: https://issues.apache.org/jira/browse/OFBIZ-11329 > Project: OFBiz > Issue Type: Bug > Components: framework, webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: James Yong >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch, > OFBIZ-11329.patch > > > This will be useful when committing CSRF solution as explained in OFBIZ-11306 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11150) Form widget field with input-method="time-dropdown" unable to understand the default time
[
https://issues.apache.org/jira/browse/OFBIZ-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032466#comment-17032466
]
ASF subversion and git services commented on OFBIZ-11150:
-
Commit 91d136bb3e277196ef1e9639b4ad7be1ac357a3e in ofbiz-framework's branch
refs/heads/release18.12 from Michael Brohl
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=91d136b ]
Fixed: Form widget field with input-method="time-dropdown" unable to
understand the default time.
(OFBIZ-11150)
Thanks Wiebke Pätzold for reporting and providing the patch.
> Form widget field with input-method="time-dropdown" unable to understand the
> default time
> -
>
> Key: OFBIZ-11150
> URL: https://issues.apache.org/jira/browse/OFBIZ-11150
> Project: OFBiz
> Issue Type: Sub-task
> Components: example
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11150_UtilCodec.patch
>
>
> I noticed this error in the example component some time ago (months), it's
> still there:
> {noformat}
> 2019-08-12 13:28:32,868 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field4] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,877 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field5] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,918 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field12] with input-method="time-dropdown" was not
> able to understand the default time [2019-08-12%20132832.833].
> The parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[ https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032464#comment-17032464 ] Jacques Le Roux commented on OFBIZ-11329: - Hi James, Thanks for the explanation, one worry less. > setUserTimeZone should ran only once based on error > --- > > Key: OFBIZ-11329 > URL: https://issues.apache.org/jira/browse/OFBIZ-11329 > Project: OFBiz > Issue Type: Bug > Components: framework, webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: James Yong >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch, > OFBIZ-11329.patch > > > This will be useful when committing CSRF solution as explained in OFBIZ-11306 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11150) Form widget field with input-method="time-dropdown" unable to understand the default time
[
https://issues.apache.org/jira/browse/OFBIZ-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032463#comment-17032463
]
ASF subversion and git services commented on OFBIZ-11150:
-
Commit fc21237feeb8e9a6b7d8af52e618d4e6dfaef8bb in ofbiz-framework's branch
refs/heads/trunk from Michael Brohl
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=fc21237 ]
Fixed: Form widget field with input-method="time-dropdown" unable to
understand the default time.
(OFBIZ-11150)
Thanks Wiebke Pätzold for reporting and providing the patch.
> Form widget field with input-method="time-dropdown" unable to understand the
> default time
> -
>
> Key: OFBIZ-11150
> URL: https://issues.apache.org/jira/browse/OFBIZ-11150
> Project: OFBiz
> Issue Type: Sub-task
> Components: example
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11150_UtilCodec.patch
>
>
> I noticed this error in the example component some time ago (months), it's
> still there:
> {noformat}
> 2019-08-12 13:28:32,868 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field4] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,877 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field5] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,918 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field12] with input-method="time-dropdown" was not
> able to understand the default time [2019-08-12%20132832.833].
> The parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[
https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17030832#comment-17030832
]
Jacques Le Roux edited comment on OFBIZ-11329 at 2/7/20 3:36 PM:
-
Since you are interested in (simple version):
{noformat}
Jacques@LDLC MINGW64 /c/projectsASF/Git/ofbiz-framework (trunk)
$ git pull
First, rewinding head to replay your work on top of it...
Applying: Improved: Updated plugins url in release17.12
Using index info to reconstruct a base tree...
M build.gradle
Falling back to patching base and 3-way merge...
Auto-merging build.gradle
CONFLICT (content): Merge conflict in build.gradle
Staged 'build.gradle' using previous resolution.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 Improved: Updated plugins url in release17.12
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase
--abort".
{noformat}
Better solution:
{noformat}
git fetch origin
git reset --hard origin/trunk
{noformat}
Then I got my stash, previous to backport, clean... pfew...
was (Author: jacques.le.roux):
Since you are interested in (simple version):
{noformat}
Jacques@LDLC MINGW64 /c/projectsASF/Git/ofbiz-framework (trunk)
$ git pull
First, rewinding head to replay your work on top of it...
Applying: Improved: Updated plugins url in release17.12
Using index info to reconstruct a base tree...
M build.gradle
Falling back to patching base and 3-way merge...
Auto-merging build.gradle
CONFLICT (content): Merge conflict in build.gradle
Staged 'build.gradle' using previous resolution.
error: Failed to merge in the changes.
hint: Use 'git am --show-current-patch' to see the failed patch
Patch failed at 0001 Improved: Updated plugins url in release17.12
Resolve all conflicts manually, mark them as resolved with
"git add/rm ", then run "git rebase --continue".
You can instead skip this commit: run "git rebase --skip".
To abort and get back to the state before "git rebase", run "git rebase
--abort".
{noformat}
Better solution:
{noformat}
git fetch origin
git reset --hard origin/master
{noformat}
Then I got my stash, previous to backport, clean... pfew...
> setUserTimeZone should ran only once based on error
> ---
>
> Key: OFBIZ-11329
> URL: https://issues.apache.org/jira/browse/OFBIZ-11329
> Project: OFBiz
> Issue Type: Bug
> Components: framework, webpos
>Affects Versions: Trunk
>Reporter: Jacques Le Roux
>Assignee: James Yong
>Priority: Minor
> Fix For: 17.12.01, 18.12.01
>
> Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch,
> OFBIZ-11329.patch
>
>
> This will be useful when committing CSRF solution as explained in OFBIZ-11306
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11150) Form widget field with input-method="time-dropdown" unable to understand the default time
[
https://issues.apache.org/jira/browse/OFBIZ-11150?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Brohl updated OFBIZ-11150:
--
Affects Version/s: Release Branch 18.12
Release Branch 17.12
> Form widget field with input-method="time-dropdown" unable to understand the
> default time
> -
>
> Key: OFBIZ-11150
> URL: https://issues.apache.org/jira/browse/OFBIZ-11150
> Project: OFBiz
> Issue Type: Sub-task
> Components: example
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Jacques Le Roux
>Assignee: Michael Brohl
>Priority: Minor
> Attachments: OFBIZ-11150_UtilCodec.patch
>
>
> I noticed this error in the example component some time ago (months), it's
> still there:
> {noformat}
> 2019-08-12 13:28:32,868 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field4] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,877 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field5] with input-method="time-dropdown" was not able
> to understand the default time [2019-08-12%20132832.833]. The
> parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> 2019-08-12 13:28:32,918 |jsse-nio-8443-exec-8 |MacroFormRenderer
> |W| Form widget field [field12] with input-method="time-dropdown" was not
> able to understand the default time [2019-08-12%20132832.833].
> The parsing
> error was: Timestamp format must be -mm-dd hh:mm:ss[.f]
> {noformat}
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Updated] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[ https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11329: Parent: (was: OFBIZ-11306) Issue Type: Bug (was: Sub-task) > setUserTimeZone should ran only once based on error > --- > > Key: OFBIZ-11329 > URL: https://issues.apache.org/jira/browse/OFBIZ-11329 > Project: OFBiz > Issue Type: Bug > Components: framework, webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: James Yong >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch, > OFBIZ-11329.patch > > > This will be useful when committing CSRF solution as explained in OFBIZ-11306 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11329) setUserTimeZone should ran only once based on error
[ https://issues.apache.org/jira/browse/OFBIZ-11329?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032458#comment-17032458 ] James Yong commented on OFBIZ-11329: Thanks Jacques. Verified that no additional info is sent to the SetTimeZoneFromBrowser javascript function. Reason why RequestHandlerExceptionAllowExternalRequests is used: # To allow clickable link within an error message. Also thanks for mentioning OFBIZ-5037. Although RequestHandlerExceptionAllowExternalRequests and throwRequestHandlerExceptionOnMissingLocalRequest are created from OFBIZ-5037, I found that the former can be used without the latter. > setUserTimeZone should ran only once based on error > --- > > Key: OFBIZ-11329 > URL: https://issues.apache.org/jira/browse/OFBIZ-11329 > Project: OFBiz > Issue Type: Sub-task > Components: framework, webpos >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: James Yong >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11329-plugins.patch, OFBIZ-11329.patch, > OFBIZ-11329.patch > > > This will be useful when committing CSRF solution as explained in OFBIZ-11306 -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032455#comment-17032455 ] Jacques Le Roux edited comment on OFBIZ-11306 at 2/7/20 3:26 PM: - I just noticed that my yesterday pacth was in the Git format. Here is attached the same but in diff format [^OFBIZ-11306.patch] was (Author: jacques.le.roux): I just noticed that my yesterday path is in the Git format. Here is attached the same but in diff format [^OFBIZ-11306.patch] > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032457#comment-17032457 ] Jacques Le Roux commented on OFBIZ-11306: - Michael, Pierre, If you read James's 20/Dec/19 12:21 comments you will notice that he just learned to use Git... So maybe you still prefer patches James? Both ways are OK with me for this issue. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11306: Attachment: OFBIZ-11306.patch > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032455#comment-17032455 ] Jacques Le Roux commented on OFBIZ-11306: - I just noticed that my yesterday path is in the Git format. Here is attached the same but in diff format [^OFBIZ-11306.patch] > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032452#comment-17032452 ] Jacques Le Roux commented on OFBIZ-11306: - bq. Yes, my main point is that we should avoid committing (portions) of a new feature into trunk directly until the feature is finished, reviewed, testet and accepted. It avoids cluttering the history, having to revert commits and also having unfinished work in trunk if the work got stuck etc. +1 bq. With git we have several ways to achieve that. Personally I have no problems with feature branches in the main repository (that's how we organize our work here at ecomify), but having it in cloned user repositories is also fine. The reasons I'd privilege cloned user repositories is about responsability and proliferation of branches in official repos. That would uselessly clutter the repo and scramble things. Anyway, again that's not mine to decide but the community... > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032429#comment-17032429 ] Jacques Le Roux commented on OFBIZ-10489: - Ha, I see now what you asked about. I have no ideas :) > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032401#comment-17032401 ] Pierre Smits commented on OFBIZ-11306: -- A community member's fork from the Github repository is - in essence - not different to an organisation's fork in a private environment. Both are expected to have development/feature branches and both can have release branches and tags based on different criteria than those of the project. That is one of the key benefits of the git's approach to version control and collaboration. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032400#comment-17032400 ] Pierre Smits commented on OFBIZ-10489: -- [~jleroux] IMO that is not the correct answer to my question. I am not asking about the need for backporting to r16, nor about potential difficulties as a result of the self-inflicted flaws due to partial migration. > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032398#comment-17032398 ] Michael Brohl commented on OFBIZ-11306: --- Yes, my main point is that we should avoid committing (portions) of a new feature into trunk directly until the feature is finished, reviewed, testet and accepted. It avoids cluttering the history, having to revert commits and also having unfinished work in trunk if the work got stuck etc. With git we have several ways to achieve that. Personally I have no problems with feature branches in the main repository (that's how we organize our work here at ecomify), but having it in cloned user repositories is also fine. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032395#comment-17032395 ] Jacques Le Roux commented on OFBIZ-10489: - Hi Pierre, It's hard to bacport from Git to Svn all would be manual and R16 should be considered to be no longer supported. At least security will not... > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032391#comment-17032391 ] Jacques Le Roux commented on OFBIZ-11306: - Michael, BTW maybe we don't need to discuss all that about feature branch under OFBiz repo. See's Pierre proposition in OFBIZ-10577 I seconded at https://s.apache.org/jmls7 > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032390#comment-17032390 ] Jacques Le Roux commented on OFBIZ-10577: - I second Pierre's request. It would be a better alternative than obviously (big) patches and IMO feature branches. Because the responsability is on the side of the initial contributor and the one getting together to make the issue going forward. This is how for instance I assisted Nicolas who initiated the common-theme... > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch, > screenshot-1-find-session.png, screenshot-2-pending-locations.png, > screenshot-3-add-location-to-session.png, > screenshot-4-list-of-review-session.png, > screenshot-5-review-session-detail.png, screenshot-6-accept-session.png, > screenshot-7-complete-review.png, screenshot-8-report-screen.png > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId > statusId > createdDatetime > *InventoryCountItem* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > itemStatusId > locationSeqId > productId > productIdentifier > quantity > *InventoryCountVariance* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > productId > productIdentifier > locationSeqId > systemQuantityOnHand > actualQuantityOnHand > varianceQuantityOnHand > totalCost > actualCost > costVariance > actualValue > totalValue > valueVariance > unitCost > ***Extended
[jira] [Closed] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-11318. --- Fix Version/s: 18.12.01 17.12.01 Resolution: Fixed > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17013671#comment-17013671 ] Jacques Le Roux edited comment on OFBIZ-11318 at 2/7/20 1:52 PM: - -It should be noted that this issue does not currently exist on trunk HEAD as can be checked on trunk demo. It's only related to OFBIZ-11306 when patches there are appplied.- was (Author: jacques.le.roux): It should be noted that this issue does not currently exist on trunk HEAD as can be checked on trunk demo. It's only related to OFBIZ-11306 when patches there are appplied. > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10588) Incorrect PartyContactMechPurpose created while calling createUpdateBillingAddress service
[ https://issues.apache.org/jira/browse/OFBIZ-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032381#comment-17032381 ] ASF subversion and git services commented on OFBIZ-10588: - Commit 77d6a5ff910fc112c69cf37bf92b32ad26e8b17d in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=77d6a5f ] Fixed: Unable to continue to Step 3 in One Page Checkout (OFBIZ-11318) The following error is returned when trying to continue to Step3 when checking out using One Page Checkout. Could not create new purpose, a purpose with that type already exists.: [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 19:48:18.29 (java.sql.Timestamp)][contactMechId,10020(java.lang.String)] [contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)] [partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 19:48:18.332 (java.sql.Timestamp) It does not happen with DemoCustomer but at least with admin user It was caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in createUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks: James Young for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Incorrect PartyContactMechPurpose created while calling > createUpdateBillingAddress service > -- > > Key: OFBIZ-10588 > URL: https://issues.apache.org/jira/browse/OFBIZ-10588 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12 >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > Fix For: 17.12.01, 16.11.06 > > Attachments: OFBIZ-10588.patch > > > createUpdateBillingAddress and createUpdateShippingAddress services create > incorrect PartyContactMechPurpose records with userLogin.partyId. > These services works well in case of when e-commerce logged-in user perform > these operation. But in-correct data is created by these services if called > from admin or any other user. > Need to check relevant code and fix it. > I called createUpdateBillingAddress service from webtools and and didn't get > desired results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10588) Incorrect PartyContactMechPurpose created while calling createUpdateBillingAddress service
[ https://issues.apache.org/jira/browse/OFBIZ-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032379#comment-17032379 ] ASF subversion and git services commented on OFBIZ-10588: - Commit 2f479d56ce7b715961ba2fa1b67362b13351ebcb in ofbiz-framework's branch refs/heads/release17.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=2f479d5 ] Fixed: Unable to continue to Step 3 in One Page Checkout (OFBIZ-11318) The following error is returned when trying to continue to Step3 when checking out using One Page Checkout. Could not create new purpose, a purpose with that type already exists.: [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 19:48:18.29 (java.sql.Timestamp)][contactMechId,10020(java.lang.String)] [contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)] [partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 19:48:18.332 (java.sql.Timestamp) It does not happen with DemoCustomer but at least with admin user It was caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in createUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks: James Young for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Incorrect PartyContactMechPurpose created while calling > createUpdateBillingAddress service > -- > > Key: OFBIZ-10588 > URL: https://issues.apache.org/jira/browse/OFBIZ-10588 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12 >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > Fix For: 17.12.01, 16.11.06 > > Attachments: OFBIZ-10588.patch > > > createUpdateBillingAddress and createUpdateShippingAddress services create > incorrect PartyContactMechPurpose records with userLogin.partyId. > These services works well in case of when e-commerce logged-in user perform > these operation. But in-correct data is created by these services if called > from admin or any other user. > Need to check relevant code and fix it. > I called createUpdateBillingAddress service from webtools and and didn't get > desired results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032380#comment-17032380 ] ASF subversion and git services commented on OFBIZ-11318: - Commit 77d6a5ff910fc112c69cf37bf92b32ad26e8b17d in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=77d6a5f ] Fixed: Unable to continue to Step 3 in One Page Checkout (OFBIZ-11318) The following error is returned when trying to continue to Step3 when checking out using One Page Checkout. Could not create new purpose, a purpose with that type already exists.: [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 19:48:18.29 (java.sql.Timestamp)][contactMechId,10020(java.lang.String)] [contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)] [partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 19:48:18.332 (java.sql.Timestamp) It does not happen with DemoCustomer but at least with admin user It was caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in createUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks: James Young for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032378#comment-17032378 ] ASF subversion and git services commented on OFBIZ-11318: - Commit 2f479d56ce7b715961ba2fa1b67362b13351ebcb in ofbiz-framework's branch refs/heads/release17.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=2f479d5 ] Fixed: Unable to continue to Step 3 in One Page Checkout (OFBIZ-11318) The following error is returned when trying to continue to Step3 when checking out using One Page Checkout. Could not create new purpose, a purpose with that type already exists.: [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 19:48:18.29 (java.sql.Timestamp)][contactMechId,10020(java.lang.String)] [contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)] [partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 19:48:18.332 (java.sql.Timestamp) It does not happen with DemoCustomer but at least with admin user It was caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in createUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks: James Young for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10588) Incorrect PartyContactMechPurpose created while calling createUpdateBillingAddress service
[ https://issues.apache.org/jira/browse/OFBIZ-10588?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032384#comment-17032384 ] ASF subversion and git services commented on OFBIZ-10588: - Commit 9ce3118cc2f1d207886e58656cf181759cbb1de4 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=9ce3118 ] Fixed: Unable to continue to Step 3 in One Page Checkout (OFBIZ-11318) The following error is returned when trying to continue to Step3 when checking out using One Page Checkout. Could not create new purpose, a purpose with that type already exists.: [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 19:48:18.29 (java.sql.Timestamp)][contactMechId,10020(java.lang.String)] [contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)] [partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 19:48:18.332 (java.sql.Timestamp) It does not happen with DemoCustomer but at least with admin user It was caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in createUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks: James Young for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Incorrect PartyContactMechPurpose created while calling > createUpdateBillingAddress service > -- > > Key: OFBIZ-10588 > URL: https://issues.apache.org/jira/browse/OFBIZ-10588 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 16.11, Release Branch 17.12 >Reporter: Suraj Khurana >Assignee: Suraj Khurana >Priority: Major > Fix For: 17.12.01, 16.11.06 > > Attachments: OFBIZ-10588.patch > > > createUpdateBillingAddress and createUpdateShippingAddress services create > incorrect PartyContactMechPurpose records with userLogin.partyId. > These services works well in case of when e-commerce logged-in user perform > these operation. But in-correct data is created by these services if called > from admin or any other user. > Need to check relevant code and fix it. > I called createUpdateBillingAddress service from webtools and and didn't get > desired results. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032382#comment-17032382 ] ASF subversion and git services commented on OFBIZ-11318: - Commit 9ce3118cc2f1d207886e58656cf181759cbb1de4 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=9ce3118 ] Fixed: Unable to continue to Step 3 in One Page Checkout (OFBIZ-11318) The following error is returned when trying to continue to Step3 when checking out using One Page Checkout. Could not create new purpose, a purpose with that type already exists.: [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 19:48:18.29 (java.sql.Timestamp)][contactMechId,10020(java.lang.String)] [contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)] [partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 19:48:18.332 (java.sql.Timestamp) It does not happen with DemoCustomer but at least with admin user It was caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in createUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks: James Young for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032366#comment-17032366 ] Pierre Smits commented on OFBIZ-10489: -- Can we expect this issue also to exist in pre r17 branches? > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre Smits updated OFBIZ-10489: - Affects Version/s: Release Branch 18.12 Release Branch 17.12 > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akash Jain closed OFBIZ-10489. -- Fix Version/s: (was: Trunk) 18.12.01 17.12.01 Resolution: Fixed > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: 17.12.01, 18.12.01 > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032358#comment-17032358 ] Akash Jain commented on OFBIZ-10489: This issue has been fixed at: Trunk: 701ec7f3ea66e6e3cff50516a8a30897136a58a7 R18: 37b8e5b0e89e5ce332bee396bc3ccb705e6875d2 R17: 8de770f701189522d8910f5f6592c5cf94c4fd12 Thanks, [~redcat] and [~Mohammad K] for your contribution. > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032355#comment-17032355 ] ASF subversion and git services commented on OFBIZ-10489: - Commit 8de770f701189522d8910f5f6592c5cf94c4fd12 in ofbiz-framework's branch refs/heads/release17.12 from akash [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=8de770f ] Fixed: Unnecessary ship groups in orders. (OFBIZ-10489) Thanks, Oleg Andreyev and Mohammad Kathawala for your contribution. > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032354#comment-17032354 ] ASF subversion and git services commented on OFBIZ-10489: - Commit 37b8e5b0e89e5ce332bee396bc3ccb705e6875d2 in ofbiz-framework's branch refs/heads/release18.12 from akash [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=37b8e5b ] Fixed: Unnecessary ship groups in orders. (OFBIZ-10489) Thanks, Oleg Andreyev and Mohammad Kathawala for your contribution. > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032353#comment-17032353 ] ASF subversion and git services commented on OFBIZ-10489: - Commit 701ec7f3ea66e6e3cff50516a8a30897136a58a7 in ofbiz-framework's branch refs/heads/trunk from akash [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=701ec7f ] Fixed: Unnecessary ship groups in orders. (OFBIZ-10489) Thanks, Oleg Andreyev and Mohammad Kathawala for your contribution. > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-10489) Unnecessary ship groups in orders
[ https://issues.apache.org/jira/browse/OFBIZ-10489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Akash Jain reassigned OFBIZ-10489: -- Assignee: Akash Jain (was: Mohammad Kathawala) > Unnecessary ship groups in orders > - > > Key: OFBIZ-10489 > URL: https://issues.apache.org/jira/browse/OFBIZ-10489 > Project: OFBiz > Issue Type: Bug > Components: order >Affects Versions: Trunk >Reporter: Oleg Andreyev >Assignee: Akash Jain >Priority: Minor > Fix For: Trunk > > Attachments: OFBIZ-10489.patch, empty_ship_group.diff > > > Under some conditions, checkout creates extra ship groups in the order. > Steps to reproduce: > # create a couple of products P1 and P2 (just to get clear results). > # create a new order and add 1 P1 and 1 P2 > # change quantity P1 to 2 (or both) and Recalculate Order (key step really) > # finish checkout > You will see 2 order items linked with ship group 1 and another ship > group 2 that should not have been created. You may see in the patch that > the code address a ship group using index of the order item and the shopping > cart creates new ship group if the index is greater than the number of > existing groups. > In one of my projects based on 16.11, I noticed even more serious trouble > that takes place if both products are drop-shipping order but don't explain > it here because it seems do not appear in the trunk. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032343#comment-17032343 ] Jacques Le Roux commented on OFBIZ-11318: - It was indeed caused by OFBIZ-10588. I checked for similar issues and found that, in unlike in createUpdateBillingAddress, in reateUpdateShippingAddress and createUpdateCreditCard partyId was used without a prior setting from parameters.partyId Thanks James for proposing a solution. I rather fixed otherwise this and another similar case in createUpdateCreditCard > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032326#comment-17032326 ] Pierre Smits commented on OFBIZ-10577: -- Hi [~yashwant.dhakad], Is this patch also somewhere implemented in a development/feature branch in a publicly available git repo (e.g. on Github)? If so, it may be beneficial to fellow community members to use that for review (and other collaboration) purposes. And if everything checks out, the project can/may decide to use a pull request to establish an officially endorsed 'OFBiz feature branch' to make it available to the entire community, or directly merge it into another branch (trunk and or release branch). IMO, providing enhancement contributions (bug fixes, improvements and new features) through development branches in public git repos is more favourable as it leverages the key feature(s) of git. It avoids you to upload additional enhancements to the solution to this tickets, but also to have reviewing community members to download these enhancements and apply them to their review branch. > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch, > screenshot-1-find-session.png, screenshot-2-pending-locations.png, > screenshot-3-add-location-to-session.png, > screenshot-4-list-of-review-session.png, > screenshot-5-review-session-detail.png, screenshot-6-accept-session.png, > screenshot-7-complete-review.png, screenshot-8-report-screen.png > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId >
[jira] [Commented] (OFBIZ-10953) have CurrencyDimension have a dimensionId that is based on the natural key
[
https://issues.apache.org/jira/browse/OFBIZ-10953?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032320#comment-17032320
]
Pierre Smits commented on OFBIZ-10953:
--
The reasoning we applied to having a different primary key for the Uom table in
the transaction db (an exception to the primary key definition for majority of
the tables) applies also to the DWH.
For those not having access to the Data Warehouse Toolkit book (which is the
starting point for the project's approach to Bi through the same named
component) the first line states:
??Surrogate keys are used to implement the primary keys of *almost all*
dimension tables.??
So, which dimension tables can the project consider to be the exceptions?
These are the generic dimension tables that are uniform in meaning across
businesses, e.g. those data sets defined by standardisation bodies.
Measurement dimension tables, like date, time, but also country, currency and
all those other groups of records which are relating to records in the Uom
table in the transaction db are such generic tables. These tables don't need a
'self defined' primary keys added, because the natural key is self-explanatory.
That is why Kimball in his book suggests for the Date dimension table to use
the ISO 8601 (specifically YYMMDD) for the date as the definition for the
primary key. And the same is suggested for the Time dimension table (HHMM in
that case).
The validation for these exceptions are:
# the natural key is self-explanatory,
# data abstraction negatively impacts query performance and legibility.
Compare following examples:
{code:java}
{code}
vs
{code:java}
{code}
The latter means that in a production infrastructure the using company is
penalised (performance and cost-wise) with an additional query (for the
*origCurrencyDimId*) to the currency dimension to retrieve the underlying
explanation/meaning (EUR). And similarly for the *quantityUomDimId* and other
generically defined measurements (e.g. in the examples the *invoiceDateDimId*).
This may not mean much in DHW implementations with a low number of records in
fact tables. But when there a multitude of such fact tables with each having
millions/billions of records in those tables using such keys of generic tables
(these measurement tables), then it adds up significantly.
> have CurrencyDimension have a dimensionId that is based on the natural key
> --
>
> Key: OFBIZ-10953
> URL: https://issues.apache.org/jira/browse/OFBIZ-10953
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Assignee: Pierre Smits
>Priority: Major
> Labels: CurrencyDimension, birt, currency, dimension, dwh
> Attachments: OFBIZ-10953-BI.patch
>
>
> Currently the record sequencer (delegator.getNextSeqId) is used to determine
> the dimensionId for the CurrencyDimension. This is unnecessary as the uomId
> from the UOM table can be used for currency.
> It also makes it easier to set the foreign-key in fact tables by generating
> it based on the date provided, than by retrieving the dimensionId based on a
> retrieval through the getDimensionIdFromNaturalKey service.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032318#comment-17032318 ] Yashwant Dhakad commented on OFBIZ-10577: - I have attached some screenshots for reference. Please have a look and provide your feedback. > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch, > screenshot-1-find-session.png, screenshot-2-pending-locations.png, > screenshot-3-add-location-to-session.png, > screenshot-4-list-of-review-session.png, > screenshot-5-review-session-detail.png, screenshot-6-accept-session.png, > screenshot-7-complete-review.png, screenshot-8-report-screen.png > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId > statusId > createdDatetime > *InventoryCountItem* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > itemStatusId > locationSeqId > productId > productIdentifier > quantity > *InventoryCountVariance* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > productId > productIdentifier > locationSeqId > systemQuantityOnHand > actualQuantityOnHand > varianceQuantityOnHand > totalCost > actualCost > costVariance > actualValue > totalValue > valueVariance > unitCost > ***Extended entity:* > *FacilityLocation* > locked > lastCountDate > nextCountDate > **We will prevent the following inbound and outbound transactions within the > application if the location is locked for counting: > Inventory
[jira] [Updated] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yashwant Dhakad updated OFBIZ-10577: Attachment: screenshot-1-find-session.png screenshot-8-report-screen.png screenshot-7-complete-review.png screenshot-6-accept-session.png screenshot-5-review-session-detail.png screenshot-4-list-of-review-session.png screenshot-3-add-location-to-session.png screenshot-2-pending-locations.png > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch, > screenshot-1-find-session.png, screenshot-2-pending-locations.png, > screenshot-3-add-location-to-session.png, > screenshot-4-list-of-review-session.png, > screenshot-5-review-session-detail.png, screenshot-6-accept-session.png, > screenshot-7-complete-review.png, screenshot-8-report-screen.png > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId > statusId > createdDatetime > *InventoryCountItem* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > itemStatusId > locationSeqId > productId > productIdentifier > quantity > *InventoryCountVariance* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > productId > productIdentifier > locationSeqId > systemQuantityOnHand > actualQuantityOnHand > varianceQuantityOnHand > totalCost > actualCost > costVariance > actualValue > totalValue >
[jira] [Commented] (OFBIZ-10292) Add Document Content: acc-invoices.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032313#comment-17032313 ] Olivier Heintz commented on OFBIZ-10292: The acc-invoices.adoc file and all the help files, which are included in documentation on the sub-chapter "Invoices management in User Interface" [^Invoice-Help-Docbook-file-migration-to-asciidoc_diff.patch] > Add Document Content: acc-invoices.adoc > --- > > Key: OFBIZ-10292 > URL: https://issues.apache.org/jira/browse/OFBIZ-10292 > Project: OFBiz > Issue Type: Sub-task >Reporter: Sharan Foga >Assignee: Olivier Heintz >Priority: Major > Attachments: > Invoice-Help-Docbook-file-migration-to-asciidoc_diff.patch > > > Add content for acc-invoices.adoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-10292) Add Document Content: acc-invoices.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Heintz updated OFBIZ-10292: --- Attachment: Invoice-Help-Docbook-file-migration-to-asciidoc_diff.patch > Add Document Content: acc-invoices.adoc > --- > > Key: OFBIZ-10292 > URL: https://issues.apache.org/jira/browse/OFBIZ-10292 > Project: OFBiz > Issue Type: Sub-task >Reporter: Sharan Foga >Assignee: Olivier Heintz >Priority: Major > Attachments: > Invoice-Help-Docbook-file-migration-to-asciidoc_diff.patch > > > Add content for acc-invoices.adoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-10292) Add Document Content: acc-invoices.adoc
[ https://issues.apache.org/jira/browse/OFBIZ-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Olivier Heintz reassigned OFBIZ-10292: -- Assignee: Olivier Heintz > Add Document Content: acc-invoices.adoc > --- > > Key: OFBIZ-10292 > URL: https://issues.apache.org/jira/browse/OFBIZ-10292 > Project: OFBiz > Issue Type: Sub-task >Reporter: Sharan Foga >Assignee: Olivier Heintz >Priority: Major > > Add content for acc-invoices.adoc -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032290#comment-17032290 ] Jacques Le Roux commented on OFBIZ-11318: - This issue does not exist in stable demo (R16). It seems to have been caused by OFBIZ-10588. I'm trying to check R18 and R17 but stumbled upon a weird compiling issue in R18, WIP... > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yashwant Dhakad updated OFBIZ-10577: Attachment: (was: OFBIZ-10577.patch) > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId > statusId > createdDatetime > *InventoryCountItem* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > itemStatusId > locationSeqId > productId > productIdentifier > quantity > *InventoryCountVariance* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > productId > productIdentifier > locationSeqId > systemQuantityOnHand > actualQuantityOnHand > varianceQuantityOnHand > totalCost > actualCost > costVariance > actualValue > totalValue > valueVariance > unitCost > ***Extended entity:* > *FacilityLocation* > locked > lastCountDate > nextCountDate > **We will prevent the following inbound and outbound transactions within the > application if the location is locked for counting: > Inventory Transfer > Issuance against Sales Order > Sales Return receiving > Inventory receive > Issuance and return inventory in manufacturing Job > Kit breakup > Update Location > Physical Variance creation > The locked locations won’t have any bearing on the transactions that are > affecting the only ATP of parts i.e. Reserving component for Jobs/Sales > Orders etc. as they don’t affect QOH
[jira] [Updated] (OFBIZ-10577) New Feature: Inventory Cycle Count
[ https://issues.apache.org/jira/browse/OFBIZ-10577?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yashwant Dhakad updated OFBIZ-10577: Attachment: OFBIZ-10577.patch > New Feature: Inventory Cycle Count > -- > > Key: OFBIZ-10577 > URL: https://issues.apache.org/jira/browse/OFBIZ-10577 > Project: OFBiz > Issue Type: New Feature > Components: hhfacility >Affects Versions: Trunk >Reporter: Yashwant Dhakad >Assignee: Yashwant Dhakad >Priority: Major > Attachments: OFBIZ-10577-Database-Changes.patch, OFBIZ-10577.patch > > > *Here are the design notes for cycle count workflow:* > *Find Session Screen:* In this screen, we will show all the sessions created > in the system with respect to the facility, locations, inventory count item, > current status, and created date. We have a search field to filter the > records on the basis of the facility, status. > *Find Pending Locations:* In this screen, we have a table listing all the > pending locations whose countings are pending and we can create a session for > them. All details regarding the pending locations are listed here with the > location, next count date, last count date and days extended for the count, > total inventory item and product for this location. We have facets for > filtering the records on the basis of the facility, not scanned since and > scheduled for next scan. Also, we have a global search at the top of the > screen. In Pending Locations screen, we have a Create Session button. To > create a session we can either select one or more records from the below list > or create a new session by yourself. > In Create Session screen, the basic overview is shown in the "Overview" > section and the items are listed in the "Items" section. We can create a new > line item by clicking on the 'Add' button and we can also update the item > quantity. After completing this, we can proceed with this session and mark it > with 'Pending for Review' status from the 'Status' button at the top of the > screen or we can simply 'Reject'. 'Reject' status button is available at the > top of the screen. > *Find Review Screen:* In this screen, we have a table listing all the > locations pending for the review. All the details regarding the review > sessions are listed with the facility, locations and counted inventory item. > We have facets for filtering records on the basis of the facility. By > clicking any session we can go to its detail screen, where basic details > regarding this session are listed in the 'Overview' section and items are > listed in the 'Items' section. We can select any number of rows and mark them > as 'Accept' or 'Reject'. When these items are marked as 'Accepted' then the > variance is created and these are added in the Count Progress report. Only > authorized persons can accept or reject the sessions and once the session is > accepted it is marked as 'Completed'. > *Count Progress Report:* In this screen, User can view the advanced counting > related analytics with respect to all the 'Completed' status session from > Reports Screen. We can filter the records on the basis of the facility and > within the date range. We can also see the percentage of the total locations, > inventory items counted and errors occurred during the process. Item variance > details are listed in the below section in tabular form. > Following changes to the existing data model to support end to end counting > process flow: > *New entities:* > *InventoryCount* > inventoryCountId > uploadedByUserLogin > facilityId > statusId > createdDatetime > *InventoryCountItem* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > itemStatusId > locationSeqId > productId > productIdentifier > quantity > *InventoryCountVariance* > inventoryCountId > inventoryCountItemSeqId > inventoryItemId > productId > productIdentifier > locationSeqId > systemQuantityOnHand > actualQuantityOnHand > varianceQuantityOnHand > totalCost > actualCost > costVariance > actualValue > totalValue > valueVariance > unitCost > ***Extended entity:* > *FacilityLocation* > locked > lastCountDate > nextCountDate > **We will prevent the following inbound and outbound transactions within the > application if the location is locked for counting: > Inventory Transfer > Issuance against Sales Order > Sales Return receiving > Inventory receive > Issuance and return inventory in manufacturing Job > Kit breakup > Update Location > Physical Variance creation > The locked locations won’t have any bearing on the transactions that are > affecting the only ATP of parts i.e. Reserving component for Jobs/Sales > Orders etc. as they don’t affect QOH in any way.
[jira] [Updated] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11318: Fix Version/s: (was: Upcoming Branch) Priority: Blocker (was: Critical) > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Blocker > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Assigned] (OFBIZ-11318) Unable to continue to Step 3 in One Page Checkout
[ https://issues.apache.org/jira/browse/OFBIZ-11318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux reassigned OFBIZ-11318: --- Assignee: Jacques Le Roux > Unable to continue to Step 3 in One Page Checkout > -- > > Key: OFBIZ-11318 > URL: https://issues.apache.org/jira/browse/OFBIZ-11318 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Critical > Fix For: Upcoming Branch > > Attachments: OFBIZ-11318.patch > > > The following error is returned when trying to continue to Step3 when > checking out using One Page Checkout. > Could not create new purpose, a purpose with that type already exists.: > [GenericEntity:PartyContactWithPurpose][contactFromDate,2020-01-05 > 19:48:18.29(java.sql.Timestamp)][contactMechId,10020(java.lang.String)][contactMechPurposeTypeId,SHIPPING_LOCATION(java.lang.String)][partyId,admin(java.lang.String)][purposeFromDate,2020-01-05 > 19:48:18.332(java.sql.Timestamp) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11301) Clarify usage of Github PR
[ https://issues.apache.org/jira/browse/OFBIZ-11301?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032244#comment-17032244 ] Pierre Smits commented on OFBIZ-11301: -- The first draft of the guidelines document is now available for review. > Clarify usage of Github PR > -- > > Key: OFBIZ-11301 > URL: https://issues.apache.org/jira/browse/OFBIZ-11301 > Project: OFBiz > Issue Type: Sub-task > Components: git >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Jacques Le Roux >Assignee: Pierre Smits >Priority: Major > Labels: documentation > > The PullRequest reflex is now an acquired behaviour. > I started a discussion at [https://markmail.org/message/jx426hxxwvllynx3], > summary: > Our workflow is to contribute patches through Jira. We need to clearly > document how the project is going to work with Pull Requests. as part of > [https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Contributors+Best+Practices] > Remark Jacques: _But I know that it will not be enough. So I'll also add a > notice in the top of our main README.adoc to make it clear on our main Github > page_. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032237#comment-17032237 ] Jacques Le Roux commented on OFBIZ-11306: - I think that before possibly discussing Git workflow we need to complete OFBIZ-11301, could be part of it also. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032231#comment-17032231 ] Jacques Le Roux commented on OFBIZ-11306: - BTW our "bible" is https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-3699) ServiceDispatcher.checkAuth modifies the context if the invocation service has a permissionServiceName
[
https://issues.apache.org/jira/browse/OFBIZ-3699?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nicolas Malin closed OFBIZ-3699.
Fix Version/s: Upcoming Branch
Resolution: Done
This issue is include on STORE-7113
> ServiceDispatcher.checkAuth modifies the context if the invocation service
> has a permissionServiceName
> --
>
> Key: OFBIZ-3699
> URL: https://issues.apache.org/jira/browse/OFBIZ-3699
> Project: OFBiz
> Issue Type: Bug
> Components: framework
>Affects Versions: Trunk
>Reporter: Bob Morley
>Assignee: Nicolas Malin
>Priority: Major
> Fix For: Upcoming Branch
>
>
> Created as a result of thread:
> http://n4.nabble.com/Magically-converted-types-from-simpleTypeConvert-td1838891.html
> The follow code in the ServiceDispatcher ...
> if (UtilValidate.isNotEmpty(origService.permissionServiceName)) {
> ...
> if (hasPermission.booleanValue()) {
> context.putAll(permResp);
> context = origService.makeValid(context,
> ModelService.IN_PARAM);
> ... causes the incoming context to be modified both by adding values from the
> results of the permission service but also by converting any datatypes to
> match those in the service definition. This hides any invalid service
> invocations (from a data type pov) and if the permisionServiceName is
> removed, the code would start failing with the incorrect data types.
> Suggest is to change this to something like ...
> Map permRespContext = ServiceUtil.setServiceFields(dctx,
> serviceName, permResp);
> context.putAll(permRespContext);
> The concern is that by doing this there may be some services that were
> relying on the data type conversion (because they were invalid requests)
> which would start to fail. Appropriate impact analysis of services that
> define "permissionServiceName" and appropriate resolutions need to be
> included with this change.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032224#comment-17032224 ] Jacques Le Roux edited comment on OFBIZ-11306 at 2/7/20 9:10 AM: - Hi Michael, Nothing directly related to this issue is commited. There is a reference to this issue when I committed OFBIZ-11329 which was a blocking subtask but not directly related to this work, hence it's committed. It was discovered wrong while working on this issue and had been fixed. Then the Jira-Git relation makes these commits appears here. [As I already explained|https://s.apache.org/72j22] I'm not a fan of feature branches. If we want to adopt a specific Git workflow we need a consensus and I guess a vote. If we do a such thing I urge all participants to seriouyly read the articles I cited. Anyway there is not need here, the last patch is the reference. bq. Regarding the store of the tokens inside the OFBiz cache: this seems to be an invalid approach to me. The tokens should be hold in the session or a cookie. As I (actually James) already explained in my last answer to you, the session can't be used because of inter webapps requests. Could you please explain how you envision to use cookies for that? You might be interested to read https://stackoverflow.com/questions/20504846/why-is-it-common-to-put-csrf-prevention-tokens-in-cookies. I also recommend you to read the exchanges we already had with James. For instance we don't want a sole token value (in a cookie for instance) but have a strategy where the tokens are generated for each request. Though allowing the back and forth buttons which is normally an issue with tokens by requests. Still, this is a WIP. At the moment our main remaining issue is related with the introduction of REST requests with OFBIZ-11007 (James began before this was committed). Of course all ideas are welcome, but please backed up with reviews and strong support. was (Author: jacques.le.roux): Hi Michael, Nothing directly related to this issue is commited. There is a reference to this issue when I committed OFBIZ-11329 which was a blocking subtask but not directly related to this work, hence it's committed. It was discovered wrong while working on this issue and had been fixed. Then the Jira-Git relation makes these commits appears here. [As I already explainedhttps://s.apache.org/72j22] I'm not a fan of feature branches. If we want to adopt a specific Git workflow we need a consensus and I guess a vote. If we do a such thing I urge all participants to seriouyly read the articles I cited. Anyway there is not need here, the last patch is the reference. bq. Regarding the store of the tokens inside the OFBiz cache: this seems to be an invalid approach to me. The tokens should be hold in the session or a cookie. As I (actually James) already explained in my last answer to you, the session can't be used because of inter webapps requests. Could you please explain how you envision to use cookies for that? You might be interested to read https://stackoverflow.com/questions/20504846/why-is-it-common-to-put-csrf-prevention-tokens-in-cookies. I also recommend you to read the exchanges we already had with James. For instance we don't want a sole token value (in a cookie for instance) but have a strategy where the tokens are generated for each request. Though allowing the back and forth buttons which is normally an issue with tokens by requests. Still, this is a WIP. At the moment our main remaining issue is related with the introduction of REST requests with OFBIZ-11007 (James began before this was committed). Of course all ideas are welcome, but please backed up with reviews and strong support. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and
[jira] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032224#comment-17032224 ] Jacques Le Roux commented on OFBIZ-11306: - Hi Michael, Nothing directly related to this issue is commited. There is a reference to this issue when I committed OFBIZ-11329 which was a blocking subtask but not directly related to this work, hence it's committed. It was discovered wrong while working on this issue and had been fixed. Then the Jira-Git relation makes these commits appears here. [As I already explainedhttps://s.apache.org/72j22] I'm not a fan of feature branches. If we want to adopt a specific Git workflow we need a consensus and I guess a vote. If we do a such thing I urge all participants to seriouyly read the articles I cited. Anyway there is not need here, the last patch is the reference. bq. Regarding the store of the tokens inside the OFBiz cache: this seems to be an invalid approach to me. The tokens should be hold in the session or a cookie. As I (actually James) already explained in my last answer to you, the session can't be used because of inter webapps requests. Could you please explain how you envision to use cookies for that? You might be interested to read https://stackoverflow.com/questions/20504846/why-is-it-common-to-put-csrf-prevention-tokens-in-cookies. I also recommend you to read the exchanges we already had with James. For instance we don't want a sole token value (in a cookie for instance) but have a strategy where the tokens are generated for each request. Though allowing the back and forth buttons which is normally an issue with tokens by requests. Still, this is a WIP. At the moment our main remaining issue is related with the introduction of REST requests with OFBIZ-11007 (James began before this was committed). Of course all ideas are welcome, but please backed up with reviews and strong support. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token
[jira] [Comment Edited] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17031969#comment-17031969 ] Jacques Le Roux edited comment on OFBIZ-11306 at 2/7/20 9:09 AM: - About your question bq. why do you want to store the tokens in the cache instead of the session? Again I let James have the last words, but I think he already explained: bq. as some pages contain links to other webapps e.g. acctg trans page contains links to partymgr's viewprofile. As we have a session by webapp, it would not work for inter app requests. was (Author: jacques.le.roux): About your question bq. why do you want to store the tokens in the cache instead of the session? Again I let James had the last words, but I think he already explained: bq. as some pages contain links to other webapps e.g. acctg trans page contains links to partymgr's viewprofile. As we have a session by webapp, it would not work for inter app requests. > POC for CSRF Token > -- > > Key: OFBIZ-11306 > URL: https://issues.apache.org/jira/browse/OFBIZ-11306 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Upcoming Branch >Reporter: James Yong >Assignee: Jacques Le Roux >Priority: Minor > Labels: CSRF > Fix For: Upcoming Branch > > Attachments: CsrfTokenAjaxTransform.java, CsrfTokenTransform.java, > CsrfUtil.java, OFBIZ-11306-v2.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, OFBIZ-11306.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch, OFBIZ-11306_Plugins.patch, > OFBIZ-11306_Plugins.patch > > > CRSF tokens are generated using SecureRandom class (maybe later a JWT with a > "time out"). > They are stored in the user sessions (for AJAX calls and unauthenticated HTTP > calls) or OFBiz UtilCache (for authenticated HTTP calls), and verified during > POST request. > # In *controllers* a new csrf-token attribute is added to the security tag to > exempt or force CSRF token check. > # In *Widget Forms* a hidden token field is auto-generated. > # In *FTL form* a CSRF token is passed through <@ofbizUrl> to automatise the > change. Using <@ofbizUrl> macro to generate the CSRF token means there is no > need to manually add the CSRF token field to each form in the ftl files. It > will save time for users doing custom implementation and maintenance. While > there is CSRF token in the form URL, the token is invalidated during form > submission. So it's uniqueand harmless even though the CSRF token of the form > submission is shown in the browser address bar. > # For *Ajax calls* an ajaxPrefilter function (observer on DOM ready) is added > through OfbizUtil.js (itself called at start in decorators and such) > # The html metadata is storing the csrf token used by JQuery AJAX. This token > will not change to another value after it is consumed > # Csrf tokens for the user are removed from the UtilCache when the user logs > out or session invalidated. > The general rule are as follows: > * RequestMap configured with 'get' method will be exempted from CSRF token > check. > * RequestMap configured with 'post' or 'all' method will be subjected to CSRF > token check. (Note there are discussions that RequestMap with ‘all’ method > should also not be subjected to CSRF token check. This will be done after > ensuring a separate uri is used when posting changes.) > * "main" request URIs are exempted from CSRF token check. > * Setting csrf-token to false or true on the Request Map will override the > general rules above. > To implement: > * -Allow token map size to be configurable in properties.- OK that's done > locally > To Discuss: > * Invalidate authenticated user session when CSRF token check fails. > * Configure the general rules in a Service method (which will be run inside > the constructor of RequestMap class) when determining the final > securityCsrfToken value. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-7113) Refactoring permission model call
[ https://issues.apache.org/jira/browse/OFBIZ-7113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Malin closed OFBIZ-7113. Fix Version/s: Upcoming Branch Resolution: Implemented > Refactoring permission model call > - > > Key: OFBIZ-7113 > URL: https://issues.apache.org/jira/browse/OFBIZ-7113 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Fix For: Upcoming Branch > > Attachments: OFBIZ-7113.patch, OFBIZ-7113.patch, OFBIZ-7113.patch > > > With the subject on mailing list "Permission service not on the same > transaction" : http://markmail.org/message/34vxi4ntmbj7vzcr > I started the improvement but the java code need to be clean and refactoring. > I share my first draft patch, but need more works. I realize : > * unified call evalPermission > * move all related field for permission service on ModelService to > ModelPermission > * Remove deprecated code > * start labelized error message > * add new attributes on permission model : required-new-transaction and > return-error-on-failure -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11200) Refactoring old job process
[ https://issues.apache.org/jira/browse/OFBIZ-11200?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17032193#comment-17032193 ] Nicolas Malin commented on OFBIZ-11200: --- Hi [~lektran] can you have few time for a quick review and criticize my approach ? > Refactoring old job process > --- > > Key: OFBIZ-11200 > URL: https://issues.apache.org/jira/browse/OFBIZ-11200 > Project: OFBiz > Issue Type: Improvement > Components: framework >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Labels: job, service > Attachments: OFBIZ-11200.patch > > > Currently to purge old job, we use the thread job manager to check if some > job need to be run and if the pool is empty, check the old job to purge. > I detected a problem when you have many job's server and two pools. > In my case, I have a first pool that run regular job and a second that > receive huge asynchrone services (by persist call). > Server who manage the second pool have rarely the possibility to purge their > jobs that, by the way, increase JobSandbox table > Server who manage the first pool, call often the purge process, but the table > size generate a long query time to purge few element. Long query time, run > often, this purge process consume 15% of the database load (with correct > reindex) > After analyze, I propose this refactoring : > * When you call JobSandbox table for a purge, use a limit on the query with > the max thread pool because when you have the database return, you purge only > with this limit so this help the database to not scan the whole table. Other > small improvement, do not sort the result (no functional gain). With this > each query pass to 3.5s at 0.30s (on postgres). > * Purge by the pool thread is nice, each server can only purge their own job > (filtered on run_by_instance_id), to help an overloaded server, I was > rehabiliting service purgeOldJobs that you can run with specific parameter to > make assistance. > * Last, all job services are historical on class > org.apache.ofbiz.service.ServiceUtil, I moved them all in a new dedicate > class org.apache.ofbiz.service.job.JobServices -- This message was sent by Atlassian Jira (v8.3.4#803005)
