[Blama]

Hi Isomorphic,

Yes, please do start a new thread, and we'll assign to be looked into.

please see here.

Best regards
Blama

[Isomorphic]

Yes, please do start a new thread, and we'll assign to be looked into.

[Blama]

Hi Isomorphic,

thanks for the fast answer. Yes, I think I can continue with for now.
"other internal methods when combining implicitCriteria with other criteria for ResultSet" reads like the fix applied.

So from my side this clientside issue is fixed in current version (v12.1p_2022-12-06) and a "works with workaround" in my used version (v12.1p_2022-08-10).

The only open point (not implicitCriteria related, but serverside) is the CustomCriterion issue in current versions of 12.1p/13.0p (v12.1p_2022-12-06, v13.0p_2022-12-09) , as shown in #20/#25.
If you want I can create a new thread for this in order not to mix it with implicitCriteria.

Best regards
Blama

[Isomorphic]

hi Blama ,

It's difficult to confirm exactly because there was some general reworking and a number of fixes for implicitCriteria since the summer, up until October 20. However, those included some changes to correctly pass textMatchStyle through combineCriteria() and some other internal methods when combining implicitCriteria with other criteria for ResultSet and ResultTree - that's probably where this issue was arising.

It sounds like you are able to proceed without updating your framework version anyway, right? We'll make sure we have an autotest for multi-criterion (and/or) implicitCriteria in combination with regular criteria, and if you see any other issues, please do let us know.

thanks

Isomorphic Support

[Blama]

Hi Isomorphic,

regarding #20 and #24 it seems that not having AND- or OR-Criteria as implicitCriteria prevents the bug from happening. This would be fine for me.
Can you see in you code and the changes since v12.1p_2022-08-10 that this is actually correct?

Thank you & Best regards
Blama

[Blama]

Hi Isomorphic,

Can you easily test this in 13.0? If so, we'd be interested to see those results. We have some differences across those branches in this area

I retested with v13.0p_2022-12-09 (Eval), the server logs look exactly like in #20 (regarding "CustomCriterion").

Best regards
Blama

[Blama]

Hi Isomorphic,

no, I read enough forums post in order not to do that :)
But as said in #20 I'd prefer to stay on v12.1p_2022-08-10 if I can work around the issue by not using a certain API or not nesting Criteria too deep or ...
That version is the one I have been using in production for a few months without issues - and I don't like to do the manual testing required with an update - especially serverside regressions can cause big problems for me and I need to test and compare a few things before and after in the server logs.

Best regards
Blama

[Isomorphic]

We do typically mean the latest - are you asking for a fix for a bug in specific older build, when the bug is already fixed in current builds?

[Blama]

Hi Isomorphic,

yes, I should be able to do that (with Eval), most likely on Monday.
Do you mean current 13.0p or from 2022-08-10?

Best regards
Blama

[Isomorphic]

hi Blama ,

Can you easily test this in 13.0? If so, we'd be interested to see those results. We have some differences across those branches in this area

[Blama]

Hi Isomorphic,

doing further development I noticed problems with nested AND-AdvancedCriteria using v12.1p_2022-08-10 (the inner criteria of an AND-AdvancedCriteria in implicitCriteria where interpreted wrongly clientside and turned into these rubbish iEquals-criteria in the request (the "good" iContainsPattern-criteria below come from the normal fetch-criteria)).

Developer Console RPC DS Request Tab excerpt:
componentId:"LeadlistManagement_picked",
    data:{
        operator:"and",
        criteria:[
            {
                fieldName:"CUST_NAME_CONTACTPERSFULLNAME",
                operator:"iContainsPattern",
                value:"ac"
            },
            {
                fieldName:"operator",
                operator:"iEquals",
                value:"and"
            },
            {
                operator:"or",
                criteria:[
                    {
                        fieldName:"criteria",
                        operator:"iEquals",
                        value:{
                            fieldName:"STATUS_WONLOST_ID",
                            operator:"isNull"
                        }
                    },
                    {
                        fieldName:"criteria",
                        operator:"iEquals",
                        value:{
                            fieldName:"STATUS_CLOSED",
                            operator:"equals",
                            value:false
                        }
                    },
                    {
                        fieldName:"criteria",
                        operator:"iEquals",
                        value:{
                            fieldName:"STATUS_PICKED",
                            operator:"equals",
                            value:true
                        }
                    }
                ]
            }
        ]
    },

Is this something known in v12.1p_2022-08-10 and could I work around it when not using certain APIs?
If not (but I'd really prefer this), the good news is that these problems seem to be gone with v12.1p_2022-12-06, as you can see in the December server logs below, where "good" criteria where sent by the client and received serverside.

But I can see an unexpected warning now in the server logs:

com.iso.dat.DSRequest [https-openssl-nio-443-exec-10] Executing LeadlistManagement_picked->V_LEAD_MANAGEMENT.fetch[fetchMyPickedLeads] rows: 0->75 with
criteria: {
    operator:"and",
    _constructor:"AdvancedCriteria",
    criteria:[
        {fieldName:"STATUS_WONLOST_ID", operator:"isNull"},
        {fieldName:"STATUS_CLOSED", operator:"equals", value:false},
        {fieldName:"STATUS_PICKED", operator:"equals", value:true},
        {fieldName:"CUST_NAME_CONTACTPERSFULLNAME", operator:"iContainsPattern", value:"ac"}
    ]
}
sortBy: [STATUS_SHORTNAME, STATUS_STATUSDATE, PICKED_DATE];
com.iso.cri.Evaluator [https-openssl-nio-443-exec-10] Unrecognized operator "iContainsPattern", treating as a CustomCriterion.;
com.iso.cri.Evaluator [https-openssl-nio-443-exec-10] Unrecognized operator "iContainsPattern", treating as a CustomCriterion.;
com.iso.cri.Evaluator [https-openssl-nio-443-exec-10] Unrecognized operator "iContainsPattern", treating as a CustomCriterion.;
com.iso.cri.Evaluator [https-openssl-nio-443-exec-10] Unrecognized operator "iContainsPattern", treating as a CustomCriterion.;
...
...

I have no idea where this is coming from. I assume this is a bogus warning?
Also, can I work around the top issue clientside in v12.1p_2022-08-10?

Thank you & Best regards
Blama

[Blama]

Hi Isomorphic,

it seems that using v12.1p_2022-10-22 my issue with the null-criteria crash from #13 is gone. Also, I don't see the twice applied criteria from #15 anymore.
I think all the issues from this thread are gone now, but will double check that the initial issue from #1 is still gone within my application.

Thank you & Best regards
Blama

[Isomorphic]

The issue with implicitCriteria being included twice (and also, as a side-effect, simple crit being upscaled to advanced) has been addressed.

Please retest with a build dated October 21 or later.

[Isomorphic]

Quick follow-up on our comment in #14 - as we said we might, we've made some enhancements to DBC.setImplicitCriteria()

- added a "callback" param that fires if a fetch is issued
- added an "initialFetch" param, which allows setImplicitCriteria() to issue an initial-fetch if the component's data has not previously been fetched against
- added a return value - true if a fetch was issued, false otherwise

SGWT will have a second signature that matches the above, and you can try these changes out in tomorrow's builds, dated October 20 or later.

We'll fix the double criteria shortly and update here again.

[Isomorphic]

We'll take a look and get back to you