[jira] [Commented] (OFBIZ-12272) Miscellaneous improvements to FindWorkEffort screen
[
https://issues.apache.org/jira/browse/OFBIZ-12272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379454#comment-17379454
]
Xin Wang commented on OFBIZ-12272:
--
Hi [~nmalin],
With your latest commit, error messages can be displayed now.
Now there is another problem, the reproduce steps are mostly same to the
preivous one, with one additional step:
a) create a WorkEffort with type as "Available" and status as "[General]
Cancelled"
b) update this newly created WorkEffort, change status to "[Task] Completed"
and click "save"
c) after an error message is displayed, click the "save" button again
In step (c), an "undefined" message with black background color is displayed.
> Miscellaneous improvements to FindWorkEffort screen
> ---
>
> Key: OFBIZ-12272
> URL: https://issues.apache.org/jira/browse/OFBIZ-12272
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Xin Wang
>Assignee: Nicolas Malin
>Priority: Major
> Attachments:
> 0001-Miscellaneous-improvements-to-FindWorkEffort-screen.patch,
> OFBIZ-12272-WithDynamism.patch
>
>
> Attached patch add miscellaneous improvements to FindWorkEffort screen:
> 1. Add "noConditionFind" field with value "Y" to FindWorkEffort screen to
> show results without click "Find" button
> 2. Change response type of deleteWorkEffort from "view" to
> "request-redirect", so that user can stay in FindWorkEffort screen after
> deletion
> 3. Remove "buttontext" widget style of workEffortId column, as text of this
> column also contains workEffortName, and it may be very long and even wrapped
> for two lines, "buttontext" does not fit it quite well
> 4. Change ListWorkEfforts from "form" to "grid", and enable "sort-field" for
> most of the columns (except "description")
> 5. Change "workEffortId" field text from "${workEffortName}
> [${workEffortId}]" to "[${workEffortId}] ${workEffortName}", to be consistent
> with the sort order, as this column is sort by workEffortId
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-12280) Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640)
[ https://issues.apache.org/jira/browse/OFBIZ-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-12280. --- Resolution: Fixed > Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640) > - > > Key: OFBIZ-12280 > URL: https://issues.apache.org/jira/browse/OFBIZ-12280 > Project: OFBiz > Issue Type: Bug > Components: framework, Gradle >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: 18.12.01, Release Branch 17.12 > > > h1. CVE-2021-33037 HTTP request smuggling > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.6 > Apache Tomcat 9.0.0.M1 to 9.0.46 > Apache Tomcat 8.5.0 to 8.5.66 > Description: > Apache Tomcat did not correctly parse the HTTP transfer-encoding request > header in some circumstances leading to the possibility to request smuggling > when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the > transfer-encoding header if the client declared it would only accept an > HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not > ensure that, if present, the chunked encoding was the final encoding. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.7 or later > - Upgrade to Apache Tomcat 9.0.48 or later > - Upgrade to Apache Tomcat 8.5.68 or later > Note that issue was fixed in 9.0.47 and 8.5.67 but the release votes for > those versions did not pass. > h1. CVE-2021-30639 Denial of Service > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.3 to 10.0.4 > Apache Tomcat 9.0.44 > Apache Tomcat 8.5.64 > Description: > An error introduced as part of a change to improve error handling during > non-blocking I/O meant that the error flag associated with the Request object > was not reset between requests. This meant that once a non-blocking I/O error > occurred, all future requests handled by that request object would fail. > Users were able to trigger non-blocking I/O errors, e.g. by dropping a > connection, thereby creating the possibility of triggering a DoS. > Applications that do not use non-blocking I/O are not exposed to this > vulnerability. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.5 or later > - Upgrade to Apache Tomcat 9.0.45 or later > - Upgrade to Apache Tomcat 8.5.65 or later > h1. CVE-2021-30640 JNDI Realm Authentication Weakness > Severity: Low > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.5 > Apache Tomcat 9.0.0.M1 to 9.0.45 > Apache Tomcat 8.5.0 to 8.5.65 > Apache Tomcat 7.0.0 to 7.0.108 > Description: > Queries made by the JNDI Realm did not always correctly escape parameters. > Parameter values could be sourced from user provided data (eg user names) as > well as configuration data provided by an administrator. > In limited circumstances it was possible for users to authenticate using > variations of their user name and/or to bypass some of the protection > provided by the LockOut Realm. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.6 or later > - Upgrade to Apache Tomcat 9.0.46 or later > - Upgrade to Apache Tomcat 8.5.66 or later > - Upgrade to Apache Tomcat 7.0.109 or later > History: > 2021-07-12 Original advisory > References: > [1] https://tomcat.apache.org/security-10.html > [2] https://tomcat.apache.org/security-9.html > [3] https://tomcat.apache.org/security-8.html > [4] https://tomcat.apache.org/security-7.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12280) Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640)
[ https://issues.apache.org/jira/browse/OFBIZ-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379269#comment-17379269 ] ASF subversion and git services commented on OFBIZ-12280: - Commit 2e88059bfc96494af4447693b28de5a2f1c9f2ed in ofbiz-framework's branch refs/heads/release17.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=2e88059 ] Fixed: Upgrades Tomcat from 9.0.43 to 9.0.48 (OFBIZ-12280) Due to CVEs-2021-30037/30639/30640 > Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640) > - > > Key: OFBIZ-12280 > URL: https://issues.apache.org/jira/browse/OFBIZ-12280 > Project: OFBiz > Issue Type: Bug > Components: framework, Gradle >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: 18.12.01, Release Branch 17.12 > > > h1. CVE-2021-33037 HTTP request smuggling > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.6 > Apache Tomcat 9.0.0.M1 to 9.0.46 > Apache Tomcat 8.5.0 to 8.5.66 > Description: > Apache Tomcat did not correctly parse the HTTP transfer-encoding request > header in some circumstances leading to the possibility to request smuggling > when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the > transfer-encoding header if the client declared it would only accept an > HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not > ensure that, if present, the chunked encoding was the final encoding. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.7 or later > - Upgrade to Apache Tomcat 9.0.48 or later > - Upgrade to Apache Tomcat 8.5.68 or later > Note that issue was fixed in 9.0.47 and 8.5.67 but the release votes for > those versions did not pass. > h1. CVE-2021-30639 Denial of Service > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.3 to 10.0.4 > Apache Tomcat 9.0.44 > Apache Tomcat 8.5.64 > Description: > An error introduced as part of a change to improve error handling during > non-blocking I/O meant that the error flag associated with the Request object > was not reset between requests. This meant that once a non-blocking I/O error > occurred, all future requests handled by that request object would fail. > Users were able to trigger non-blocking I/O errors, e.g. by dropping a > connection, thereby creating the possibility of triggering a DoS. > Applications that do not use non-blocking I/O are not exposed to this > vulnerability. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.5 or later > - Upgrade to Apache Tomcat 9.0.45 or later > - Upgrade to Apache Tomcat 8.5.65 or later > h1. CVE-2021-30640 JNDI Realm Authentication Weakness > Severity: Low > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.5 > Apache Tomcat 9.0.0.M1 to 9.0.45 > Apache Tomcat 8.5.0 to 8.5.65 > Apache Tomcat 7.0.0 to 7.0.108 > Description: > Queries made by the JNDI Realm did not always correctly escape parameters. > Parameter values could be sourced from user provided data (eg user names) as > well as configuration data provided by an administrator. > In limited circumstances it was possible for users to authenticate using > variations of their user name and/or to bypass some of the protection > provided by the LockOut Realm. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.6 or later > - Upgrade to Apache Tomcat 9.0.46 or later > - Upgrade to Apache Tomcat 8.5.66 or later > - Upgrade to Apache Tomcat 7.0.109 or later > History: > 2021-07-12 Original advisory > References: > [1] https://tomcat.apache.org/security-10.html > [2] https://tomcat.apache.org/security-9.html > [3] https://tomcat.apache.org/security-8.html > [4] https://tomcat.apache.org/security-7.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12280) Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640)
[ https://issues.apache.org/jira/browse/OFBIZ-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379270#comment-17379270 ] ASF subversion and git services commented on OFBIZ-12280: - Commit fc96ffacca15cc9a616d2c11ee6098fdb02cd185 in ofbiz-framework's branch refs/heads/release18.12 from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=fc96ffa ] Fixed: Upgrades Tomcat from 9.0.43 to 9.0.48 (OFBIZ-12280) Due to CVEs-2021-30037/30639/30640 > Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640) > - > > Key: OFBIZ-12280 > URL: https://issues.apache.org/jira/browse/OFBIZ-12280 > Project: OFBiz > Issue Type: Bug > Components: framework, Gradle >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: 18.12.01, Release Branch 17.12 > > > h1. CVE-2021-33037 HTTP request smuggling > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.6 > Apache Tomcat 9.0.0.M1 to 9.0.46 > Apache Tomcat 8.5.0 to 8.5.66 > Description: > Apache Tomcat did not correctly parse the HTTP transfer-encoding request > header in some circumstances leading to the possibility to request smuggling > when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the > transfer-encoding header if the client declared it would only accept an > HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not > ensure that, if present, the chunked encoding was the final encoding. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.7 or later > - Upgrade to Apache Tomcat 9.0.48 or later > - Upgrade to Apache Tomcat 8.5.68 or later > Note that issue was fixed in 9.0.47 and 8.5.67 but the release votes for > those versions did not pass. > h1. CVE-2021-30639 Denial of Service > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.3 to 10.0.4 > Apache Tomcat 9.0.44 > Apache Tomcat 8.5.64 > Description: > An error introduced as part of a change to improve error handling during > non-blocking I/O meant that the error flag associated with the Request object > was not reset between requests. This meant that once a non-blocking I/O error > occurred, all future requests handled by that request object would fail. > Users were able to trigger non-blocking I/O errors, e.g. by dropping a > connection, thereby creating the possibility of triggering a DoS. > Applications that do not use non-blocking I/O are not exposed to this > vulnerability. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.5 or later > - Upgrade to Apache Tomcat 9.0.45 or later > - Upgrade to Apache Tomcat 8.5.65 or later > h1. CVE-2021-30640 JNDI Realm Authentication Weakness > Severity: Low > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.5 > Apache Tomcat 9.0.0.M1 to 9.0.45 > Apache Tomcat 8.5.0 to 8.5.65 > Apache Tomcat 7.0.0 to 7.0.108 > Description: > Queries made by the JNDI Realm did not always correctly escape parameters. > Parameter values could be sourced from user provided data (eg user names) as > well as configuration data provided by an administrator. > In limited circumstances it was possible for users to authenticate using > variations of their user name and/or to bypass some of the protection > provided by the LockOut Realm. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.6 or later > - Upgrade to Apache Tomcat 9.0.46 or later > - Upgrade to Apache Tomcat 8.5.66 or later > - Upgrade to Apache Tomcat 7.0.109 or later > History: > 2021-07-12 Original advisory > References: > [1] https://tomcat.apache.org/security-10.html > [2] https://tomcat.apache.org/security-9.html > [3] https://tomcat.apache.org/security-8.html > [4] https://tomcat.apache.org/security-7.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12280) Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640)
[ https://issues.apache.org/jira/browse/OFBIZ-12280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379252#comment-17379252 ] ASF subversion and git services commented on OFBIZ-12280: - Commit 1f71cfec9ef26c186e9119ba2e9bd670a1cf7770 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=1f71cfe ] Fixed: Upgrades Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640) (OFBIZ-12280) > Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640) > - > > Key: OFBIZ-12280 > URL: https://issues.apache.org/jira/browse/OFBIZ-12280 > Project: OFBiz > Issue Type: Bug > Components: framework, Gradle >Affects Versions: Trunk >Reporter: Jacques Le Roux >Assignee: Jacques Le Roux >Priority: Major > Fix For: 18.12.01, Release Branch 17.12 > > > h1. CVE-2021-33037 HTTP request smuggling > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.6 > Apache Tomcat 9.0.0.M1 to 9.0.46 > Apache Tomcat 8.5.0 to 8.5.66 > Description: > Apache Tomcat did not correctly parse the HTTP transfer-encoding request > header in some circumstances leading to the possibility to request smuggling > when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the > transfer-encoding header if the client declared it would only accept an > HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not > ensure that, if present, the chunked encoding was the final encoding. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.7 or later > - Upgrade to Apache Tomcat 9.0.48 or later > - Upgrade to Apache Tomcat 8.5.68 or later > Note that issue was fixed in 9.0.47 and 8.5.67 but the release votes for > those versions did not pass. > h1. CVE-2021-30639 Denial of Service > Severity: Important > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.3 to 10.0.4 > Apache Tomcat 9.0.44 > Apache Tomcat 8.5.64 > Description: > An error introduced as part of a change to improve error handling during > non-blocking I/O meant that the error flag associated with the Request object > was not reset between requests. This meant that once a non-blocking I/O error > occurred, all future requests handled by that request object would fail. > Users were able to trigger non-blocking I/O errors, e.g. by dropping a > connection, thereby creating the possibility of triggering a DoS. > Applications that do not use non-blocking I/O are not exposed to this > vulnerability. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.5 or later > - Upgrade to Apache Tomcat 9.0.45 or later > - Upgrade to Apache Tomcat 8.5.65 or later > h1. CVE-2021-30640 JNDI Realm Authentication Weakness > Severity: Low > Vendor: The Apache Software Foundation > Versions Affected: > Apache Tomcat 10.0.0-M1 to 10.0.5 > Apache Tomcat 9.0.0.M1 to 9.0.45 > Apache Tomcat 8.5.0 to 8.5.65 > Apache Tomcat 7.0.0 to 7.0.108 > Description: > Queries made by the JNDI Realm did not always correctly escape parameters. > Parameter values could be sourced from user provided data (eg user names) as > well as configuration data provided by an administrator. > In limited circumstances it was possible for users to authenticate using > variations of their user name and/or to bypass some of the protection > provided by the LockOut Realm. > Mitigation: > Users of the affected versions should apply one of the following > mitigations: > - Upgrade to Apache Tomcat 10.0.6 or later > - Upgrade to Apache Tomcat 9.0.46 or later > - Upgrade to Apache Tomcat 8.5.66 or later > - Upgrade to Apache Tomcat 7.0.109 or later > History: > 2021-07-12 Original advisory > References: > [1] https://tomcat.apache.org/security-10.html > [2] https://tomcat.apache.org/security-9.html > [3] https://tomcat.apache.org/security-8.html > [4] https://tomcat.apache.org/security-7.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12268) Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas
[ https://issues.apache.org/jira/browse/OFBIZ-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379243#comment-17379243 ] ASF subversion and git services commented on OFBIZ-12268: - Commit 7792565fcfadf5328e17ee88a586072462811ff2 in ofbiz-framework's branch refs/heads/trunk from Nicolas Malin [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=7792565 ] Fixed: Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas, some errors don't appear (OFBIZ-12268) After the refactoring realized on issue OFBIZ-12268, a typo has been introduce when we scanned the presence of error during an ajax call. The typo raised that ignore the case of an error is present as list. The same typo is also present for event message list. Thanks to Xin Wang to alert on this problem through issue OFBIZ-12272 > Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas > --- > > Key: OFBIZ-12268 > URL: https://issues.apache.org/jira/browse/OFBIZ-12268 > Project: OFBiz > Issue Type: Sub-task > Components: themes >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Labels: ajax, js, screen, theme > Fix For: Upcoming Branch > > Attachments: OFBIZ-12268.patch > > > At this time the function ajaxSubmitFormUpdateAreas present on > themes/common-theme/webapp/common/js/util/OfbizUtil.js take a form, submit it > thought ajax and wait a success to analyse a json result for update an area > with the cvsAreaString given on paramater. > I propose different imrpovements : > * refactoring some js code to centralize the analyze of json result for > check if the call is a success or error > * Analyze the content-type of the response if is a json continue as before, > else take the return and update first area (useful for submit search or > filtering form) > * Manage the case who the ajax call failed and we inform the user > * Add a trigger to force the modal close on submit success -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12272) Miscellaneous improvements to FindWorkEffort screen
[
https://issues.apache.org/jira/browse/OFBIZ-12272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379244#comment-17379244
]
ASF subversion and git services commented on OFBIZ-12272:
-
Commit 7792565fcfadf5328e17ee88a586072462811ff2 in ofbiz-framework's branch
refs/heads/trunk from Nicolas Malin
[ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=7792565 ]
Fixed: Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas, some errors
don't appear (OFBIZ-12268)
After the refactoring realized on issue OFBIZ-12268, a typo has been introduce
when we scanned the presence of error during an ajax call.
The typo raised that ignore the case of an error is present as list.
The same typo is also present for event message list.
Thanks to Xin Wang to alert on this problem through issue OFBIZ-12272
> Miscellaneous improvements to FindWorkEffort screen
> ---
>
> Key: OFBIZ-12272
> URL: https://issues.apache.org/jira/browse/OFBIZ-12272
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Xin Wang
>Assignee: Nicolas Malin
>Priority: Major
> Attachments:
> 0001-Miscellaneous-improvements-to-FindWorkEffort-screen.patch,
> OFBIZ-12272-WithDynamism.patch
>
>
> Attached patch add miscellaneous improvements to FindWorkEffort screen:
> 1. Add "noConditionFind" field with value "Y" to FindWorkEffort screen to
> show results without click "Find" button
> 2. Change response type of deleteWorkEffort from "view" to
> "request-redirect", so that user can stay in FindWorkEffort screen after
> deletion
> 3. Remove "buttontext" widget style of workEffortId column, as text of this
> column also contains workEffortName, and it may be very long and even wrapped
> for two lines, "buttontext" does not fit it quite well
> 4. Change ListWorkEfforts from "form" to "grid", and enable "sort-field" for
> most of the columns (except "description")
> 5. Change "workEffortId" field text from "${workEffortName}
> [${workEffortId}]" to "[${workEffortId}] ${workEffortName}", to be consistent
> with the sort order, as this column is sort by workEffortId
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-12268) Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas
[ https://issues.apache.org/jira/browse/OFBIZ-12268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379241#comment-17379241 ] ASF subversion and git services commented on OFBIZ-12268: - Commit 7792565fcfadf5328e17ee88a586072462811ff2 in ofbiz-framework's branch refs/heads/trunk from Nicolas Malin [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=7792565 ] Fixed: Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas, some errors don't appear (OFBIZ-12268) After the refactoring realized on issue OFBIZ-12268, a typo has been introduce when we scanned the presence of error during an ajax call. The typo raised that ignore the case of an error is present as list. The same typo is also present for event message list. Thanks to Xin Wang to alert on this problem through issue OFBIZ-12272 > Improve js function OfbizUtil.ajaxSubmitFormUpdateAreas > --- > > Key: OFBIZ-12268 > URL: https://issues.apache.org/jira/browse/OFBIZ-12268 > Project: OFBiz > Issue Type: Sub-task > Components: themes >Affects Versions: Trunk >Reporter: Nicolas Malin >Assignee: Nicolas Malin >Priority: Minor > Labels: ajax, js, screen, theme > Fix For: Upcoming Branch > > Attachments: OFBIZ-12268.patch > > > At this time the function ajaxSubmitFormUpdateAreas present on > themes/common-theme/webapp/common/js/util/OfbizUtil.js take a form, submit it > thought ajax and wait a success to analyse a json result for update an area > with the cvsAreaString given on paramater. > I propose different imrpovements : > * refactoring some js code to centralize the analyze of json result for > check if the call is a success or error > * Analyze the content-type of the response if is a json continue as before, > else take the return and update first area (useful for submit search or > filtering form) > * Manage the case who the ajax call failed and we inform the user > * Add a trigger to force the modal close on submit success -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Created] (OFBIZ-12280) Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640)
Jacques Le Roux created OFBIZ-12280: --- Summary: Upgrade Tomcat from 9.0.43 to 9.0.48 (due to CVEs-2021-30037/30639/30640) Key: OFBIZ-12280 URL: https://issues.apache.org/jira/browse/OFBIZ-12280 Project: OFBiz Issue Type: Bug Components: framework, Gradle Affects Versions: Trunk Reporter: Jacques Le Roux Assignee: Jacques Le Roux Fix For: 18.12.01, Release Branch 17.12 h1. CVE-2021-33037 HTTP request smuggling Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.6 Apache Tomcat 9.0.0.M1 to 9.0.46 Apache Tomcat 8.5.0 to 8.5.66 Description: Apache Tomcat did not correctly parse the HTTP transfer-encoding request header in some circumstances leading to the possibility to request smuggling when used with a reverse proxy. Specifically: Tomcat incorrectly ignored the transfer-encoding header if the client declared it would only accept an HTTP/1.0 response; Tomcat honoured the identify encoding; and Tomcat did not ensure that, if present, the chunked encoding was the final encoding. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.0.7 or later - Upgrade to Apache Tomcat 9.0.48 or later - Upgrade to Apache Tomcat 8.5.68 or later Note that issue was fixed in 9.0.47 and 8.5.67 but the release votes for those versions did not pass. h1. CVE-2021-30639 Denial of Service Severity: Important Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.3 to 10.0.4 Apache Tomcat 9.0.44 Apache Tomcat 8.5.64 Description: An error introduced as part of a change to improve error handling during non-blocking I/O meant that the error flag associated with the Request object was not reset between requests. This meant that once a non-blocking I/O error occurred, all future requests handled by that request object would fail. Users were able to trigger non-blocking I/O errors, e.g. by dropping a connection, thereby creating the possibility of triggering a DoS. Applications that do not use non-blocking I/O are not exposed to this vulnerability. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.0.5 or later - Upgrade to Apache Tomcat 9.0.45 or later - Upgrade to Apache Tomcat 8.5.65 or later h1. CVE-2021-30640 JNDI Realm Authentication Weakness Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Tomcat 10.0.0-M1 to 10.0.5 Apache Tomcat 9.0.0.M1 to 9.0.45 Apache Tomcat 8.5.0 to 8.5.65 Apache Tomcat 7.0.0 to 7.0.108 Description: Queries made by the JNDI Realm did not always correctly escape parameters. Parameter values could be sourced from user provided data (eg user names) as well as configuration data provided by an administrator. In limited circumstances it was possible for users to authenticate using variations of their user name and/or to bypass some of the protection provided by the LockOut Realm. Mitigation: Users of the affected versions should apply one of the following mitigations: - Upgrade to Apache Tomcat 10.0.6 or later - Upgrade to Apache Tomcat 9.0.46 or later - Upgrade to Apache Tomcat 8.5.66 or later - Upgrade to Apache Tomcat 7.0.109 or later History: 2021-07-12 Original advisory References: [1] https://tomcat.apache.org/security-10.html [2] https://tomcat.apache.org/security-9.html [3] https://tomcat.apache.org/security-8.html [4] https://tomcat.apache.org/security-7.html -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12272) Miscellaneous improvements to FindWorkEffort screen
[
https://issues.apache.org/jira/browse/OFBIZ-12272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379196#comment-17379196
]
Nicolas Malin commented on OFBIZ-12272:
---
Thanks for your look and feedback, it's welcome :)
I will check encoutered problems, If I can solve its easily.
> Miscellaneous improvements to FindWorkEffort screen
> ---
>
> Key: OFBIZ-12272
> URL: https://issues.apache.org/jira/browse/OFBIZ-12272
> Project: OFBiz
> Issue Type: Improvement
>Affects Versions: Trunk
>Reporter: Xin Wang
>Assignee: Nicolas Malin
>Priority: Major
> Attachments:
> 0001-Miscellaneous-improvements-to-FindWorkEffort-screen.patch,
> OFBIZ-12272-WithDynamism.patch
>
>
> Attached patch add miscellaneous improvements to FindWorkEffort screen:
> 1. Add "noConditionFind" field with value "Y" to FindWorkEffort screen to
> show results without click "Find" button
> 2. Change response type of deleteWorkEffort from "view" to
> "request-redirect", so that user can stay in FindWorkEffort screen after
> deletion
> 3. Remove "buttontext" widget style of workEffortId column, as text of this
> column also contains workEffortName, and it may be very long and even wrapped
> for two lines, "buttontext" does not fit it quite well
> 4. Change ListWorkEfforts from "form" to "grid", and enable "sort-field" for
> most of the columns (except "description")
> 5. Change "workEffortId" field text from "${workEffortName}
> [${workEffortId}]" to "[${workEffortId}] ${workEffortName}", to be consistent
> with the sort order, as this column is sort by workEffortId
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Closed] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux closed OFBIZ-12279. --- Fix Version/s: Upcoming Branch Resolution: Implemented Finally I changed my mind, it's hard to backport, so it's an improvement :). And actually there is no real bug you can increase the size of the (small) window. > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Fix For: Upcoming Branch > > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379115#comment-17379115 ] ASF subversion and git services commented on OFBIZ-12279: - Commit 414e4d83ed10338267f40ef1aa032a6f97e1e927 in ofbiz-framework's branch refs/heads/trunk from Jacques Le Roux [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=414e4d8 ] Fixed: Macro renderLink default height and width not retrieved on menus (OFBIZ-12279) Menus link defaut parameters for height and width are not considered when the link is generated. When parameter with empty value is passed to the macro, macro default values are not retrieved. To reproduce you can create a "layered-modal" type link in a menu and click on the link (without height nor width): this will generate the link with parameters "data-dialog-height" and "data-dialog-width" empty Patch provided When applied, the MacroMenuRenderer.renderLink will not send empty values to the macro so that default value will be retrieved (what is actually done on MacroFormRenderer.renderLookup) Thanks: Leila > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-12279: Issue Type: Improvement (was: Bug) > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-12279: Issue Type: Bug (was: Improvement) > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379079#comment-17379079 ] Jacques Le Roux commented on OFBIZ-12279: - Thanks Leila, Working on it... > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Bug > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Comment Edited] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379030#comment-17379030 ] Leila Mekika edited comment on OFBIZ-12279 at 7/12/21, 8:06 AM: Hello [~jleroux], the implication is that when we open the layered modal, it is reduce to the minimum (title bar size) and we have to expand the modal window to see its content. I think it can be considered like a bug :) was (Author: mleila): Hello [~jleroux], the implication is that when we open the layered modal, it is reduce to the minimum and we have to expand the window to see its content. I think it can be considered like a bug :) > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-12279) Macro renderLink default height and width not retrieved on menus
[ https://issues.apache.org/jira/browse/OFBIZ-12279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379030#comment-17379030 ] Leila Mekika commented on OFBIZ-12279: -- Hello [~jleroux], the implication is that when we open the layered modal, it is reduce to the minimum and we have to expand the window to see its content. I think it can be considered like a bug :) > Macro renderLink default height and width not retrieved on menus > > > Key: OFBIZ-12279 > URL: https://issues.apache.org/jira/browse/OFBIZ-12279 > Project: OFBiz > Issue Type: Improvement > Components: ALL APPLICATIONS >Affects Versions: Trunk >Reporter: Leila Mekika >Assignee: Jacques Le Roux >Priority: Minor > Attachments: OFBIZ-12279.patch > > > Menus link defaut parameters for height and width are not considered when the > link is generated > The problem seems to be that when parameter with empty value is passed to the > macro, macro default values are not retrieved. > *To reproduce* > you can create a "layered-modal" type link in a menu and click on the link > (without height nor width): > this will generate the link with parameters "data-dialog-height" and > "data-dialog-width" empty > *Patch provided* > When applied, the MacroMenuRenderer.renderLink will not send empty values to > the macro so that default value will be retrieved (what is actually done on > MacroFormRenderer.renderLookup) -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11919) Convert SystemInfoServices.xml mini lang to groovy
[ https://issues.apache.org/jira/browse/OFBIZ-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17379024#comment-17379024 ] Jacques Le Roux commented on OFBIZ-11919: - You mean you also validate? > Convert SystemInfoServices.xml mini lang to groovy > -- > > Key: OFBIZ-11919 > URL: https://issues.apache.org/jira/browse/OFBIZ-11919 > Project: OFBiz > Issue Type: Sub-task > Components: commonext >Reporter: Rohit Koushal >Assignee: Rohit Koushal >Priority: Major > Attachments: OFBIZ-11919.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11919) Convert SystemInfoServices.xml mini lang to groovy
[ https://issues.apache.org/jira/browse/OFBIZ-11919?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17378957#comment-17378957 ] Pierre Smits commented on OFBIZ-11919: -- That was done on August 22nd in 2020. > Convert SystemInfoServices.xml mini lang to groovy > -- > > Key: OFBIZ-11919 > URL: https://issues.apache.org/jira/browse/OFBIZ-11919 > Project: OFBiz > Issue Type: Sub-task > Components: commonext >Reporter: Rohit Koushal >Assignee: Rohit Koushal >Priority: Major > Attachments: OFBIZ-11919.patch > > -- This message was sent by Atlassian Jira (v8.3.4#803005)
