When I look at the system say the projects and the OBS's.
They use the lookup OBS_BROWSE_FLT_PRJ
There is no selection for the OBS type nor the association mode though that is in the query
OBS Projects Filter Browse Translate OBS_BROWSE_FLT_PRJ List of OBS units associated with Project (Filter) Dynamic Niku Query System-restricted
SELECT @SELECT:a.name:name@, @SELECT:a.id:id@,
@SELECT:a.type_id:type_id@ FROM prj_obs_units a
When I use the lookup in a custom object based portlet it behaves differently
It puts the association in the filter by default and when I use the filter I have to choose the OBS type first
When I use the same lookup in a query based portet I do not have the association mode in the filter
It is in the filter field definitions, but I am not quite sure it works. When using the filter I have to select the OBS type first
That is if the top one is not the one I want to use.
The benefit of this lookup is the hierarchy which make is somewhat easier to find the OBS units compared to a custom lookup with exactly the same query which gives there results flat.
Please educate me: How do I get a hierarchical OBS lookup for a query based portlet so that the user does not have to select the OBS type first.
You can't easily.
The object-specific OBS filters (like the one for projects OBS_BROWSE_FLT_PRJ, but there will also be ones for other objects that have OBS's associated to them) always look like that and always present the first (alphabetically) relevant OBS-type for that object.
So heres the trick I think ; find an object type that you are NOT USING - associate it with the one OBS that you are interested in - you now have a system-lookup for only that one OBS type which you can use is custom portlets.
(this is problematic if you can't find an object or you decide to use the object in the future of course)
Thanks for the quick response. You make it sound that I*d better start preparing the users for attitude adjustment and for choosing the least of the evils.
Just wondering if it would work with a custom object as well.
I don't think we get the system-created lookups for custom objects, only stock ones - I see only 12 OBS_BROWSE_FLT_* lookups available in my local development v13 system, so if you use all 12 you are out of luck!
(I'm unsure if the OBS changes that came in 13.2 change the way any of this works though?)
EDIT : Oops make that 11, one of them is the "ALL" version which is obviously no use!
can confirm this works very well, even on reports and page filters
Please, elaborate exactly what works very well..
Dave's suggestion of taking advantage of an object you don't use, attaching that to an OBS and then using its OBS filter in reports/portlets etc
Well, if you (I, we etc) gotta live with it and it were chosen to use the standard OBS filter because it has the hierarchical display
- is there a way to specify which OBS to have as default ( and not the first in the alphabetical order and without affecting the use of that lookup elsewhere)
- does the OBS Filter Mode in the portlet filter field properteis work? I get the results for Unit only also when I select Unit and descendants.
This is my work around which I mark as the correct answer:
Handle the OBS unit association mode in the portlet query either one option only or with the option using a parameter when using the std Resource OBS filter.
Alternatively handle the OBS selection with a custom lookup and display the OBS path alphabetically sorted as a. drop down.
Granted that is only practical with a couple of hundreds of units in the OBS to be displayed.
When the selection is made from the drop down the hidden key will be the same plus database wild card characters at both ends which will allow to use operator Like for the parameter values