12.1d: New "requiredCriterion" sample feedback

[Isomorphic]

We'll go ahead and enable internationalization here - it was already a client-side string constant, so just needed to be added to the language packs.

As far as your suggestion, this strikes us as one of those shortcuts that is barely more compact than other approaches (eg Server Script) and infrequently needed, hence no one would ever notice it existed, so not worth adding. Sorry.

[Blama]

Hi Isomorphic,

OK, but i18n'ing this message would make sense w.r.t. to your intended effect and "just throwing FilterBuilder at some DataSource" for all users. As I'm not using FilterBuilder, this does not affect me, but I do think this might make sense as it is most likely an easy change.

W.r.t. to allowMultiFetch="false" (=fetch requires an top level equals criteria on the primaryKey field(s)): Can you log this as an enhancement, like you did for DataSource.serverOnly here?
It should be easy and I'll most likely implement such a thing myself in my IDACall subclass, but I do think this does also make sense for all developers.
Other than allowMultiUpdate it should default to true.

Best regards
Blama

[Isomorphic]

Yes, this isn't really a security feature, more intended as an extra layer of protection against unintentionally broad queries or updates. However, like security features, the intent is to make the same check in your UI code, so that you are not sending requests to the server unnecessarily, hence the message is not internationalized - do that in your UI.

[Blama]

Hi Isomorphic,

actually this can't be used as security feature right now, as it only requires some condition to be set. See this modified sample.
Operator changed to "or", notNull-criterion on a required="true" field -> fetch will always include all rows.

In order to be usable as security feature, requiredCriterion must enforce setting the criteria as top-level "and"-criteria.

isc.VStack.create({
    membersMargin: 10,
    width:600, 
    members: [
        isc.FilterBuilder.create({
            ID:"countryFilter",
            dataSource:"worldDS",
            criteria: { _constructor: "AdvancedCriteria",
[B]operator: "or"[/B], criteria: [
                    {fieldName: "area", operator: "greaterThan", value: 50},
                    {fieldName: "population", operator: "greaterThan", value: 100000},
[B]{fieldName: "code", operator: "notNull"}[/B]
                ]
            }
        }),
        isc.IButton.create({
            ID:"filterButton",
            title:"Filter",
            click : function () {
                countryList.setData([]);
                countryList.filterData(countryFilter.getCriteria());
            }
        }),
        isc.ListGrid.create({
            ID: "countryList",
            height:224, alternateRecordStyles:true, 
            dataSource: worldDS,
            fetchOperation: "fetchByRequiredCriterion",
            fields:[
                {name:"countryName"},
                {name:"continent"},
                {name:"population"},
                {name:"area"},
                {name:"gdp"},
                {name:"independence", width:100}
            ]
        })
    ]
});

Best regards
Blama

[Blama]

Hi Isomorphic,

after your blog entry I tested the new requiredCriterion sample.

I think this is another good feature w.r.t to security, as I assume one could enforce "1-row fetches allowed only" with

<field name="id" primaryKey="true">
    <validOperators>
        <operator>equals</operator>
    </validOperators>
<field>
...
<operationBindings>
    <operationBinding operationType="fetch" operationId="fetchByRequiredCriterion" requiredCriterion="id" />
</operationBindings>

which would translate to a allowMultiFetch="false" (analogue to allowMultiUpdate), if such an attribute existed. Is this correct?


As an improvement suggestion:
Right now (SNAPSHOT_v12.1d_2019-02-03) you return "Operation requires criteria for the following field(s): [area, population]" which is not localized, see e.g. here in German.
As this is supposed to be a GUI feature, too, and not only a security feature (my assumption), it would be good if the message would be localized and if you returned the field title instead of the field name. name -> title is clear here, but this might not always be the case.
If it is not meant to be a GUI feature, but only a security one, this does not apply. But then a shorthand for the primaryKey-field like the suggested allowMultiFetch="false" would be nice as well.

Best regards
Blama