Sunday, March 6, 2011

ADF BC Dependent LOV 11g PS2/PS3 Bug and Fix

There is one interesting bug I want to share with you, this bug is reproduced on ADF 11g PS2 and PS3, but it works fine on ADF 11g PS1. Its either magic or someone is not running proper test automation process :) Its not that I'm enjoying to post such type of blogs, but you should double check your applications if you have similar use cases. If you do, there is a chance for dependent LOV not to work properly and for the user to get entire list of values without filtering. I will describe how to reproduce dependent LOV filtering bug and will explain possible fixes. This bug was discovered by testers from one of my projects.

Download sample application, where you can reproduce described bug -

How to reproduce:

There is LOV VO, it defines View Criteria for filtering. View Criteria contains Bind Variable criteria item for First Name attribute:

Main Employees VO, declares view accessor to the LOV VO, it triggers View Criteria for dependent LOV filtering and sets bind variable value:

Based on that view accessor, main Employees VO contains LOV define for ManagerId attribute:

User don't want to see all searchable attributes inside LOV search region, so we are using predefined View Criteria to be rendered inside LOV search region:

So far all is simple - just regular LOV with View Criteria defined, for dependent value filtering. Let's test first, how it works in ADF BC tester - it works well:

Let's run UI and open same LOV - list of values is filtered correctly:

Close LOV by pressing Cancel button. Open same LOV again - now filtering suddenly is not applied anymore and all value are returned without applying View Criteria:

I have noticed, sometimes you need to open LOV and close with Cancel button couple of times, then this behavior is reproduced. Sometimes it works from the first time.

Do you know how to fix this? You would never believe, just set LOV search region to default one - include all queryable attributes:

Yes, thats a fix you need. Then all queryable attributes will be rendered inside LOV search region, but filtering will be triggered always:

If you still want to hide some of the attributes from LOV search region, you may set these attributes to be non queryable - EmployeeId for example:

EmployeeId is not available anymore in LOV search region:

If you still want to render View Criteria inside LOV search region, there is one fix. But this will limit one View Criteria per LOV and will make it not too much different from having static WHERE clause. Let's set back View Criteria as it was before for LOV search region:

Select View Accessor from main Employees VO:

Set false value for Row Level Binds property of View Accessor:

This will ensure executeQuery() method invocation for LOV VO. From this method we can apply View Criteria manually, every time when LOV is opened:

In this case, LOV will be filtered correctly as well:

However, this limits View Criteria usage by static reference from executeQuery() method. I would recommend, while this bug is not fixed, to avoid using View Criteria as LOV search region visual representation. Otherwise, users will get entire list by pressing LOV Cancel button.


Mario Ribeiro said...

Good Post Andrejus,

We also picked up this problem early on in our project, in version and, and came to the same workaround regarding "All Queryable Attributes". However, it seems to work if it's just a different View Criteria for the LOV search than the one used for the filtering. So in most cases we have at least 2 VC's, one for the filtering and one for the LOV search specifying the attributes we want to be able to search on. That way you don't have to change Queryable properties to cater for what is displayed when using "All Queryable Attributes" VC.


Andrej Baranovskij said...

Good point. Then we would need to duplicate View Criteria on each VO.


Andrej Baranovskij said...

I tested this workaround, it solves bug issue - works fine. But log still shows - <_modifySearchVC> ViewCriteriaItem for lov attribute not found.


Octopus said...

Good Post Andrejus,
I also faced this kind of problem in my project, but soon i sort out with my coleauge.Nice blogs.