Clarity

What might be the easiest way for converting a static lookup to static dependent lookup?

The lookup is used for one attribute for an object and in the filer for half a dozen of portlets with heavy NSQL.

can you explain your problem little bit more?

If you have a static list and the lookup is in use, you cannot change it to NSQL...

br

Davor

There is a static lookup with a number of values.

Then the requester request more values.

However, they could be grouped in a couple of groups so a static dependend lookup would keep the displayed lists shorter.

I am aware that you cannot change the type of an existing lookup so I am wondering what is the best way to do it the hard way.

I am not sure that I understand your requirenments 100%…

Let us say you have 15 different values that you want to place within three different groups:

A: (1,2,3,4,5) B: (6,7,8,9,10) C: (11,12,13,14,15)

This can be solved with four static lookups, one NSQL lookup and two attributes on e.g. project object. First Attribute will point at static lookup (A,B,C) and second attribute will use NSQL lookup to display list of values that is dependent on what is chosen in (A,B,C) lookup.

Is this the solution you are looking for?

Br

Davor

Thank you for your effort.

It is more like the user said that they wanted an attribute for an object and to filter with that field in half a dozen portlets.

The values given were A, B, C, D and E.

A week later they say we want also values D1 - D7 and E1 - E10

The may use them in a single list which allows to use the static lookup created with the five first values.

I was just wondering if a two level dependent lookup were better the first five on the top level and the next set on the second level. One static dependent lookup would do that.

Doing that the hard way would be to create a new attribute and the new lookup. Copy the values from the first field to the new. Modify the gueries in the portlets and so on and finally to delete the obsolete ones.

I would recommend to keep it simple and stay with one list. If you use filter browse it is easy and quick to find wanted values even though the list is long.

br

Davor

Thanks again.

When it was just five items it fitted on one page.

When there are more than 20 and it is on the second page you need to navigate there.

The dependent lookup is not better: If it not at the top level you need to open the next level.

But back to the question - is hard way the only way?

The hard way is the only way...

Hi urmas - Were you able to get a correct answer for this one? Thanks! Chris

Not really: if hard way is the only way.