[jira] [Commented] (OFBIZ-11341) Possible NullPointerException in FinAccountServices
[ https://issues.apache.org/jira/browse/OFBIZ-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031356#comment-17031356 ] ASF subversion and git services commented on OFBIZ-11341: - Commit 69bdef10585e931520cc6ec1b27aefec7cc2209b in ofbiz-framework's branch refs/heads/release17.12 from Michael Brohl [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=69bdef1 ] Fixed: Prevent possible NullPointerException in FinAccountServices. (OFBIZ-11341) > Possible NullPointerException in FinAccountServices > --- > > Key: OFBIZ-11341 > URL: https://issues.apache.org/jira/browse/OFBIZ-11341 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: 17.12.01, Release Branch 16.11 >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > > In r1828233 I fixed a bug which was not tracked by Jira and needs backporting > to 17.12. > I also noticed that this is also present in the 16.11 release branch. Should > it be backported there also? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (OFBIZ-11341) Possible NullPointerException in FinAccountServices
[ https://issues.apache.org/jira/browse/OFBIZ-11341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Brohl updated OFBIZ-11341: -- Fix Version/s: 17.12.01 > Possible NullPointerException in FinAccountServices > --- > > Key: OFBIZ-11341 > URL: https://issues.apache.org/jira/browse/OFBIZ-11341 > Project: OFBiz > Issue Type: Bug > Components: accounting >Affects Versions: 17.12.01, Release Branch 16.11 >Reporter: Michael Brohl >Assignee: Michael Brohl >Priority: Major > Fix For: 17.12.01 > > > In r1828233 I fixed a bug which was not tracked by Jira and needs backporting > to 17.12. > I also noticed that this is also present in the 16.11 release branch. Should > it be backported there also? -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10956) Have a service to load records in the CountryDimension
[
https://issues.apache.org/jira/browse/OFBIZ-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031419#comment-17031419
]
Jacopo Cappellato commented on OFBIZ-10956:
---
[~ankit.joshi] , I have noticed a syntax error at line 25 of the
DwhDimensionServices.groovy script contributed by [~pierresmits]:
{{queryListIterator = from("Geo").where("geoTypeId","COUNTRY")queryIterator();}}
(before queryIterator() we should have a '.')
With this error no other code in the script could be executed (and tested) so
please make sure it is well tested before you commit it, thanks!
> Have a service to load records in the CountryDimension
> --
>
> Key: OFBIZ-10956
> URL: https://issues.apache.org/jira/browse/OFBIZ-10956
> Project: OFBiz
> Issue Type: Improvement
> Components: bi
>Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12
>Reporter: Pierre Smits
>Assignee: Ankit Joshi
>Priority: Major
> Labels: CountryDimension, birt, country, dimension, dwh, service
>
> Depending on [OFBIZ-10954|https://issues.apache.org/jira/browse/OFBIZ-10954]
> The service should be invoked on initialisation of the data warehouse.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
[jira] [Commented] (OFBIZ-10956) Have a service to load records in the CountryDimension
[ https://issues.apache.org/jira/browse/OFBIZ-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031423#comment-17031423 ] Ankit Joshi commented on OFBIZ-10956: - Thanks [~pierresmits], [~jacopoc] for the details. I'll review and test the patch and update it as per the need. > Have a service to load records in the CountryDimension > -- > > Key: OFBIZ-10956 > URL: https://issues.apache.org/jira/browse/OFBIZ-10956 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Assignee: Ankit Joshi >Priority: Major > Labels: CountryDimension, birt, country, dimension, dwh, service > > Depending on [OFBIZ-10954|https://issues.apache.org/jira/browse/OFBIZ-10954] > The service should be invoked on initialisation of the data warehouse. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10956) Have a service to load records in the CountryDimension
[ https://issues.apache.org/jira/browse/OFBIZ-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031453#comment-17031453 ] Pierre Smits commented on OFBIZ-10956: -- Thank you, [~jacopoc], for the speedy reaction and the keen eye. Recent F*-up in my dev environment for ofbiz-framework development (git related), prevented me - and it still does - to test the contribution. I will correct the error found, and will submit a PR so that the changes can be reviewed (and tested) more easily in the reviewer's test environment. > Have a service to load records in the CountryDimension > -- > > Key: OFBIZ-10956 > URL: https://issues.apache.org/jira/browse/OFBIZ-10956 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Assignee: Ankit Joshi >Priority: Major > Labels: CountryDimension, birt, country, dimension, dwh, service > > Depending on [OFBIZ-10954|https://issues.apache.org/jira/browse/OFBIZ-10954] > The service should be invoked on initialisation of the data warehouse. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10956) Have a service to load records in the CountryDimension
[ https://issues.apache.org/jira/browse/OFBIZ-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031454#comment-17031454 ] Pierre Smits commented on OFBIZ-10956: -- Me like this way of collaboration. :D > Have a service to load records in the CountryDimension > -- > > Key: OFBIZ-10956 > URL: https://issues.apache.org/jira/browse/OFBIZ-10956 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Assignee: Ankit Joshi >Priority: Major > Labels: CountryDimension, birt, country, dimension, dwh, service > > Depending on [OFBIZ-10954|https://issues.apache.org/jira/browse/OFBIZ-10954] > The service should be invoked on initialisation of the data warehouse. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-10956) Have a service to load records in the CountryDimension
[ https://issues.apache.org/jira/browse/OFBIZ-10956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031470#comment-17031470 ] Pierre Smits commented on OFBIZ-10956: -- I have submitted [https://github.com/apache/ofbiz-plugins/pull/4] regarding this. > Have a service to load records in the CountryDimension > -- > > Key: OFBIZ-10956 > URL: https://issues.apache.org/jira/browse/OFBIZ-10956 > Project: OFBiz > Issue Type: Improvement > Components: bi >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: Pierre Smits >Assignee: Ankit Joshi >Priority: Major > Labels: CountryDimension, birt, country, dimension, dwh, service > > Depending on [OFBIZ-10954|https://issues.apache.org/jira/browse/OFBIZ-10954] > The service should be invoked on initialisation of the data warehouse. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[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&focusedCommentId=17031495#comment-17031495 ] Jacopo Cappellato commented on OFBIZ-10953: --- Unfortunately it is not desirable to use uomId (i.e. the natural key) to populate the dimensionId (i.e. the primary key of the dimension table): in fact, based on the update strategy adopted for the dimension table (type 1, type 2 etc... as described in "The Datawarehouse Toolkit" book) the CurrencyDimension table may contain several rows with the same uomId as this is important for properly implementing drill-up and drill-down reports. > 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-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&focusedCommentId=17031527#comment-17031527 ] Pierre Smits commented on OFBIZ-10953: -- Currency definitions are not defined by the project, but rather by the ISO (see 1). And based on publicly available information(this may take some time to find) the meaning of a currency code does not change over time. As you can see in the referred webpage there have been several updates to the currency of Zimbabwe (formerly known as Rodesia), where each new currency got a new code while the name stayed the same. We can therefore safely assume/expect that over the lifespan of a country-currency relationship the currency stays unique. We thus don't need to worry about multiple records (both in the transaction database in the Uom table) as in the dwh in the currency dimensionTable) with duplicate natural keys. As a fact: this is not possible because the natural key can not exist more than once in the source table (UoM). In DWH and BI circles it is very common to use the natural key in dimension and fact table for currencies (as opposed to the business-own generated sequencedId for other transaction tables), as it reduces the need to have additional effort to set up - in star schemas and fact tables - the relation between the (sequenced) dimensionId and what the common meaning is (the natural key or currency code). Even with regards to the adopted load/update strategies (type 1, type 2, etc) the DWH toolkit book does not dictate that values in the dimensionId field of dimension tables must be of the sequence type. [1] https://en.wikipedia.org/wiki/ISO_4217 > 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] [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
]
Wiebke Pätzold updated OFBIZ-11150:
---
Attachment: OFBIZ-11150_UtilCodec.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
>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%2013:28:32.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%2013:28:32.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%2013:28:32.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&focusedCommentId=17031604#comment-17031604
]
Wiebke Pätzold commented on OFBIZ-11150:
I add “:“ to the list of immune characters for the html encoder. The
testIntegration was successful. I don't think this could cause an error
somewhere or can anyone think of a situation where this could cause an error?
> 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
>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%2013:28:32.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%2013:28:32.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%2013:28:32.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-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&focusedCommentId=17031607#comment-17031607 ] Jacopo Cappellato commented on OFBIZ-10953: --- The many reasons to use surrogate keys as primary keys in dimension tables instead of natural keys are well articulated in the section titled "Surrogate Keys" at page 58 of the DWH Toolkit book. We can always consider to adopt exceptions to these rules if there are strong reasons for doing this, but I don't see them here and also, in my opinion, it is better to postpone exceptions when they are really required and instead implement the same, consistent, simple and clear patterns for all the dimensions since we are still building the foundations of this OLAP data model in the BI component and future contributors will use this code as templates to build new dimensions and facts. > 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-11340) Crashed Scheduled jobs are not getting rescheduled with temporal expression
[ https://issues.apache.org/jira/browse/OFBIZ-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031717#comment-17031717 ] ASF subversion and git services commented on OFBIZ-11340: - Commit 47e689b360f370bba4f512c314879711aee3d96d in ofbiz-framework's branch refs/heads/trunk from Nicolas Malin [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=47e689b ] Fixed: Crashed Scheduled jobs are not getting rescheduled with temporal expression (OFBIZ-11340) When a OFBiz server are stopped or crashed with job on queued state, at the start, they are restarted but without information on tempExprId and recurrenceInfoId This causes a break for recurrence jobs to their planning Thanks to Mohammed Rehan Khan for this issue and Scott Gray for the review. > Crashed Scheduled jobs are not getting rescheduled with temporal expression > --- > > Key: OFBIZ-11340 > URL: https://issues.apache.org/jira/browse/OFBIZ-11340 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Mohammed Rehan Khan >Assignee: Nicolas Malin >Priority: Major > Attachments: OFBIZ-11340.patch, OFBIZ-11340.patch, OFBiz_ > JobSandbox_1.png, OFBiz_ JobSandbox_2.png > > > *Scenario:* > # Import Schedule service data with temporal expression id. > # JobManager creates a child Job with temExprId in _pending_ status when the > imported Job is in _running_ status. > # Now the parent Job is in _running_ status and the child Job, which is in > _pending_ status, transitions to _queued_ status if Job Poll size is full. In > this scenario, if we restart the server then both Jobs are Crashed and > JobManager creates child Job without tempExprdId. > > *Example:* Please refer to the attached screenshots. > # Job 32993100 is imported with TempExprId > # When Job 32993100 is in running status, then Job 32993101 is created with > TempExprId in pending status but job 32993101 is moved to Queued status if > job poll size is full. > # If we restart the server then JobPoller runs reloadCrashedJobs() and both > jobs are crashed and JobManager creates two child jobs (32993200, 32993201) > without TempExprId. > So in this case of missing temporal expression id job manager will not be > able to schedule further jobs. > > *Expected:* If Queued Job (32993101) is crashed then its corresponding Job > (32993200) should have TempExprId to continue further scheduling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Closed] (OFBIZ-11340) Crashed Scheduled jobs are not getting rescheduled with temporal expression
[ https://issues.apache.org/jira/browse/OFBIZ-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nicolas Malin closed OFBIZ-11340. - Fix Version/s: 18.12.01 Upcoming Branch 17.12.01 Resolution: Fixed > Crashed Scheduled jobs are not getting rescheduled with temporal expression > --- > > Key: OFBIZ-11340 > URL: https://issues.apache.org/jira/browse/OFBIZ-11340 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Mohammed Rehan Khan >Assignee: Nicolas Malin >Priority: Major > Fix For: 17.12.01, Upcoming Branch, 18.12.01 > > Attachments: OFBIZ-11340.patch, OFBIZ-11340.patch, OFBiz_ > JobSandbox_1.png, OFBiz_ JobSandbox_2.png > > > *Scenario:* > # Import Schedule service data with temporal expression id. > # JobManager creates a child Job with temExprId in _pending_ status when the > imported Job is in _running_ status. > # Now the parent Job is in _running_ status and the child Job, which is in > _pending_ status, transitions to _queued_ status if Job Poll size is full. In > this scenario, if we restart the server then both Jobs are Crashed and > JobManager creates child Job without tempExprdId. > > *Example:* Please refer to the attached screenshots. > # Job 32993100 is imported with TempExprId > # When Job 32993100 is in running status, then Job 32993101 is created with > TempExprId in pending status but job 32993101 is moved to Queued status if > job poll size is full. > # If we restart the server then JobPoller runs reloadCrashedJobs() and both > jobs are crashed and JobManager creates two child jobs (32993200, 32993201) > without TempExprId. > So in this case of missing temporal expression id job manager will not be > able to schedule further jobs. > > *Expected:* If Queued Job (32993101) is crashed then its corresponding Job > (32993200) should have TempExprId to continue further scheduling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11340) Crashed Scheduled jobs are not getting rescheduled with temporal expression
[ https://issues.apache.org/jira/browse/OFBIZ-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031715#comment-17031715 ] Nicolas Malin commented on OFBIZ-11340: --- Thanks [~rehan.khan] for the quality of this issue and [~lektran] for the review. I also detected this error on production site with huge jobs, where I didn't understand why I losted some jobs after a server crash without take the time to found the root cause. > Crashed Scheduled jobs are not getting rescheduled with temporal expression > --- > > Key: OFBIZ-11340 > URL: https://issues.apache.org/jira/browse/OFBIZ-11340 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Mohammed Rehan Khan >Assignee: Nicolas Malin >Priority: Major > Attachments: OFBIZ-11340.patch, OFBIZ-11340.patch, OFBiz_ > JobSandbox_1.png, OFBiz_ JobSandbox_2.png > > > *Scenario:* > # Import Schedule service data with temporal expression id. > # JobManager creates a child Job with temExprId in _pending_ status when the > imported Job is in _running_ status. > # Now the parent Job is in _running_ status and the child Job, which is in > _pending_ status, transitions to _queued_ status if Job Poll size is full. In > this scenario, if we restart the server then both Jobs are Crashed and > JobManager creates child Job without tempExprdId. > > *Example:* Please refer to the attached screenshots. > # Job 32993100 is imported with TempExprId > # When Job 32993100 is in running status, then Job 32993101 is created with > TempExprId in pending status but job 32993101 is moved to Queued status if > job poll size is full. > # If we restart the server then JobPoller runs reloadCrashedJobs() and both > jobs are crashed and JobManager creates two child jobs (32993200, 32993201) > without TempExprId. > So in this case of missing temporal expression id job manager will not be > able to schedule further jobs. > > *Expected:* If Queued Job (32993101) is crashed then its corresponding Job > (32993200) should have TempExprId to continue further scheduling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11340) Crashed Scheduled jobs are not getting rescheduled with temporal expression
[ https://issues.apache.org/jira/browse/OFBIZ-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031714#comment-17031714 ] ASF subversion and git services commented on OFBIZ-11340: - Commit d0e2ebbb9889f64be47709ee22101a6c9fe02bc5 in ofbiz-framework's branch refs/heads/release18.12 from Nicolas Malin [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=d0e2ebb ] Fixed: Crashed Scheduled jobs are not getting rescheduled with temporal expression (OFBIZ-11340) When a OFBiz server are stopped or crashed with job on queued state, at the start, they are restarted but without information on tempExprId and recurrenceInfoId This causes a break for recurrence jobs to their planning Thanks to Mohammed Rehan Khan for this issue and Scott Gray for the review. > Crashed Scheduled jobs are not getting rescheduled with temporal expression > --- > > Key: OFBIZ-11340 > URL: https://issues.apache.org/jira/browse/OFBIZ-11340 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Mohammed Rehan Khan >Assignee: Nicolas Malin >Priority: Major > Attachments: OFBIZ-11340.patch, OFBIZ-11340.patch, OFBiz_ > JobSandbox_1.png, OFBiz_ JobSandbox_2.png > > > *Scenario:* > # Import Schedule service data with temporal expression id. > # JobManager creates a child Job with temExprId in _pending_ status when the > imported Job is in _running_ status. > # Now the parent Job is in _running_ status and the child Job, which is in > _pending_ status, transitions to _queued_ status if Job Poll size is full. In > this scenario, if we restart the server then both Jobs are Crashed and > JobManager creates child Job without tempExprdId. > > *Example:* Please refer to the attached screenshots. > # Job 32993100 is imported with TempExprId > # When Job 32993100 is in running status, then Job 32993101 is created with > TempExprId in pending status but job 32993101 is moved to Queued status if > job poll size is full. > # If we restart the server then JobPoller runs reloadCrashedJobs() and both > jobs are crashed and JobManager creates two child jobs (32993200, 32993201) > without TempExprId. > So in this case of missing temporal expression id job manager will not be > able to schedule further jobs. > > *Expected:* If Queued Job (32993101) is crashed then its corresponding Job > (32993200) should have TempExprId to continue further scheduling. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Commented] (OFBIZ-11340) Crashed Scheduled jobs are not getting rescheduled with temporal expression
[ https://issues.apache.org/jira/browse/OFBIZ-11340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031716#comment-17031716 ] ASF subversion and git services commented on OFBIZ-11340: - Commit 7c8fc080f30085b75d4b1ea783fc5b537124508e in ofbiz-framework's branch refs/heads/release17.12 from Nicolas Malin [ https://gitbox.apache.org/repos/asf?p=ofbiz-framework.git;h=7c8fc08 ] Fixed: Crashed Scheduled jobs are not getting rescheduled with temporal expression (OFBIZ-11340) When a OFBiz server are stopped or crashed with job on queued state, at the start, they are restarted but without information on tempExprId and recurrenceInfoId This causes a break for recurrence jobs to their planning Thanks to Mohammed Rehan Khan for this issue and Scott Gray for the review. > Crashed Scheduled jobs are not getting rescheduled with temporal expression > --- > > Key: OFBIZ-11340 > URL: https://issues.apache.org/jira/browse/OFBIZ-11340 > Project: OFBiz > Issue Type: Bug > Components: framework >Affects Versions: Trunk >Reporter: Mohammed Rehan Khan >Assignee: Nicolas Malin >Priority: Major > Attachments: OFBIZ-11340.patch, OFBIZ-11340.patch, OFBiz_ > JobSandbox_1.png, OFBiz_ JobSandbox_2.png > > > *Scenario:* > # Import Schedule service data with temporal expression id. > # JobManager creates a child Job with temExprId in _pending_ status when the > imported Job is in _running_ status. > # Now the parent Job is in _running_ status and the child Job, which is in > _pending_ status, transitions to _queued_ status if Job Poll size is full. In > this scenario, if we restart the server then both Jobs are Crashed and > JobManager creates child Job without tempExprdId. > > *Example:* Please refer to the attached screenshots. > # Job 32993100 is imported with TempExprId > # When Job 32993100 is in running status, then Job 32993101 is created with > TempExprId in pending status but job 32993101 is moved to Queued status if > job poll size is full. > # If we restart the server then JobPoller runs reloadCrashedJobs() and both > jobs are crashed and JobManager creates two child jobs (32993200, 32993201) > without TempExprId. > So in this case of missing temporal expression id job manager will not be > able to schedule further jobs. > > *Expected:* If Queued Job (32993101) is crashed then its corresponding Job > (32993200) should have TempExprId to continue further scheduling. -- 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&focusedCommentId=17031722#comment-17031722
]
Jacques Le Roux commented on OFBIZ-11150:
-
Thanks Wiebke, this is working for me.
Note: I was not able to confirm that the colon can be considered an immune HTML
character.
> 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
>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%2013:28:32.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%2013:28:32.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%2013:28:32.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-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_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&focusedCommentId=17031790#comment-17031790
]
Jacques Le Roux commented on OFBIZ-11306:
-
Hi James,
Now that OFBIZ-11329 is closed, here is my last patch [^OFBIZ-11306.patch]
Not much changes since your last (most of my recent work was on
setUserTimeZone):
* The cache size for the Tokens Map that stores the CSRF tokens,
removeEldestEntry is used to get above csrf.cache.size (in security.properties)
* By default the CSRF defense is enabled, developers need to disable it:
csrf-defense-enabled in requestHandler.properties
* Also some formatting, mostly in new files.
Some questions still pending:
* I did not remove changes in TopAppBar.ftl and AppBarClose.ftl. But why do we
need a crsf token there? It's about help, so only content, so is idempotent,
isn't?
* What about my point on RequestHandlerExceptionAllowExternalRequests?
* You wrote
{quote}Switched to UtilCache (instead of http sessions) to store tokens after
user login, as some pages contain links to other webapps e.g. acctg trans page
contains links to partymgr's viewprofile. Still using sessions to store tokens
for ajax and before user login.
{quote}
Could we not do the same for Ajax inter webapps calls? I understand that for
HTTP requests partyId is used after login. For Ajax requests we have not always
a such ID. Maybe we could use userLogin and PartyId which has (sometimes?/most
of the time?) present. Or put in a specific ID? To be continued...
> 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#80300
[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&focusedCommentId=17031794#comment-17031794 ] Jacques Le Roux commented on OFBIZ-11306: - Of course I'll continue to work on the issue related to REST 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] [Commented] (OFBIZ-11306) POC for CSRF Token
[
https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031830#comment-17031830
]
Michael Brohl commented on OFBIZ-11306:
---
{quote}Switched to UtilCache (instead of http sessions) to store tokens after
user login, as some pages contain links to other webapps e.g. acctg trans page
contains links to partymgr's viewprofile. Still using sessions to store tokens
for ajax and before user login.
{quote}
Just spotted this: why do you want to store the tokens in the cache instead of
the session?
What if someone clears the cache through the webtools?
> 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-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&focusedCommentId=17031840#comment-17031840
]
Nicolas Malin commented on OFBIZ-11335:
---
Good question :)
Currently we haven't different style on single form. I introduce this as
suggest "and if we have two styles by default for single ?".
Just to propage the idea to extend form style by theme.
Passed this case, only CommonBasicSingle would be fine to start
> 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] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17031966#comment-17031966 ] Jacques Le Roux commented on OFBIZ-11306: - bq. What if someone clears the cache through the webtools? I'm still reviewing, as James wrote that I'll let him have the last words. In dev and demo mode the CSRF defense should not be used, so not a concern there. If in production for a reason you need to clear all caches, it's a problem. We could use another LinkedHashMap of the same type than the UtilCache with another removeEldestEntry method. This said you can certainly clear all caches by hand. But, as long as you know which cache/s you need tp clear, that would be a mistake and is not recommended. If ever someone does that then, among other possible issues, all the tokens will be lost and users in the middle of a request will have to get another one by clicking on a link asking them to do so, not a good user experience...The best way to clear cache/s is to clear only the cache/s that you really need to clear. > 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&focusedCommentId=17031969#comment-17031969 ] Jacques Le Roux commented on OFBIZ-11306: - 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] [Commented] (OFBIZ-11306) POC for CSRF Token
[ https://issues.apache.org/jira/browse/OFBIZ-11306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17032169#comment-17032169 ] Michael Brohl commented on OFBIZ-11306: --- I'm currently not sure about the state of this POC: there were a few commits already. Is it already committed to trunk? If yes, wouldn't it be better to work it out in a feature branch so that we have a clear view what has changes with the POC? It seems not a trivial change to me and from the brief overview of the comments it was not an easy task and I think it needs review from others too. 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. Maybe I am missing something so I recommend to provide the solution in a feature branch for others to review before it gets committed to trunk. > 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] [Updated] (OFBIZ-11319) processorder is submitted as GET instead of POST
[ https://issues.apache.org/jira/browse/OFBIZ-11319?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jacques Le Roux updated OFBIZ-11319: Fix Version/s: (was: Upcoming Branch) Hi James, I removed Upcoming Branch from the "Fix Version/s". Our rule is that when as son as a backport has been done to a release branch then only the release/s branche/s are put in this field. This is to ease the release process: https://cwiki.apache.org/confluence/display/OFBIZ/OFBiz+Committers+Roles+and+Responsibilities section about Jira (I can't get to this page today, Confluence seems to have an issue) > processorder is submitted as GET instead of POST > > > Key: OFBIZ-11319 > URL: https://issues.apache.org/jira/browse/OFBIZ-11319 > Project: OFBiz > Issue Type: Bug > Components: ecommerce >Affects Versions: Trunk, Release Branch 17.12, Release Branch 18.12 >Reporter: James Yong >Assignee: James Yong >Priority: Minor > Fix For: Release Branch 17.12, Release Branch 18.12 > > Attachments: OFBIZ-11319_Plugins.patch, OFBIZ-11319_Plugins.patch > > > During checkout of shopping cart, it is observed that the processorder of the > form action is submitted as GET which is incorrect. -- 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&focusedCommentId=17032169#comment-17032169 ] Jacques Le Roux edited comment on OFBIZ-11306 at 2/7/20 7:53 AM: - I'm currently not sure about the state of this POC: there were a few commits already. Is it already committed to trunk? If yes, wouldn't it be better to work it out in a feature branch so that we have a clear view what has changes with the POC? It seems not a trivial change to me and from the brief overview of the comments it was not an easy task and I think it needs review from others too. 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. Maybe I am missing something so I recommend to provide the solution in a feature branch for others to review before it gets committed to trunk. was (Author: mbrohl): I'm currently not sure about the state of this POC: there were a few commits already. Is it already committed to trunk? If yes, wouldn't it be better to work it out in a feature branch so that we have a clear view what has changes with the POC? It seems not a trivial change to me and from the brief overview of the comments it was not an easy task and I think it needs review from others too. 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. Maybe I am missing something so I recommend to provide the solution in a feature branch for others to review before it gets committed to trunk. > 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 Re
