Filtering values in a relational field...Hot

There are lots of ways currently to filter the values shows in a relational field. Typically these require a dependency and another relational field by essentially creating a cross join between values between two auxiliary tables related to the same primary table as well as each other. This works fine when you have the three table triangle setup or when you don't mind all values begin filtered the same for an entire workflow. However, it would be nice to see the potential for filtering these relational records extended beyond dependencies. For example, between related primary tables. We have a Change Management application that has a relational field pointed at the CI records in our CMDB application. In many instances, we would like to be able to filter the list of CIs available in the relational field depending on the CI type, the state it might be in; the list of possible filters is endless. In theory, I'd like to see (in Composer) the filtering properties of a relational field have a similar interface as that of an embedded report. I'd like to create a listing report against my primary or auxiliary table, get the reference link for that report, and then have that populate the list of items returned in my relational field. The upside to this would be... 1: I can control the values returned in any way I want without having to manage a dependency or have additional aux tables. 2: The filtering would not be dependent on the workflow. 3: I could control the presentation of the results, rather than relying on the value display format (which for us changes depending on the context we are viewing the item in .

We were unable to deliver this in SBM 11.2. Deferring to 2HCY'17 release.

How about a Where Clause on the Relational Field Options Values. Have fields other than Title present, when providing the Application and Table information giving the Composer the ability to base the relational field selection on another field being on/off similar to how Active/Inactive works with the lists. E.g. AUX table for Locations.(title) also has fields entity fields APPDEV(binary), PMO(binary), etc. and based on the Values of these limit the lists.

How about a Where Clause on the Relational Field Options Values. Have fields other than Title present, when providing the Application and Table information giving the Composer the ability to base the relational field selection on another field being on/off similar to how Active/Inactive works with the lists. E.g. AUX table for Locations.(title) also has fields entity fields APPDEV(binary), PMO(binary), etc. and based on the Values of these limit the lists.

May I add that, while relational grid approach has it's value, its biggest drawback is that it is based on report meaning that users must have view and report privileges to target data which is not always desirable.

May I add that, while relational grid approach has it's value, its biggest drawback is that it is based on report meaning that users must have view and report privileges to target data which is not always desirable.

Hi Ryan,
I think this is a great idea. To restate it, you'd like to be able to filter the candidates for a relational field based on either static queries (e.g. only show item type x as a candidate) or dynamic queries (something on the form determine what the query will be. Presumably, we'd need to be able to do rule/report type queries against the target table.

From my perspective, it would be best if we could improve the relational grid until it meets your requirements for this purpose, since it already supports report queries with QAR parameters if you want them.

To meet the requirement with regular relational fields, we'd have to think about the data architecture and user experience. It may well be that a report (something familiar to the designer) against the target table comes close to what we'd need to do. In the future, we're looking at more thoroughly separating out the query portion of reports (i.e. the data source or feed) from the rendering portion of the reports (the views). Perhaps a feed specification would permit the appropriate filtering.

I'd be happy to chat with you more about this and collaborate on how we could move forward. Drop me a note if you're interested.

Hi Ryan,
I think this is a great idea. To restate it, you'd like to be able to filter the candidates for a relational field based on either static queries (e.g. only show item type x as a candidate) or dynamic queries (something on the form determine what the query will be. Presumably, we'd need to be able to do rule/report type queries against the target table.

From my perspective, it would be best if we could improve the relational grid until it meets your requirements for this purpose, since it already supports report queries with QAR parameters if you want them.

To meet the requirement with regular relational fields, we'd have to think about the data architecture and user experience. It may well be that a report (something familiar to the designer) against the target table comes close to what we'd need to do. In the future, we're looking at more thoroughly separating out the query portion of reports (i.e. the data source or feed) from the rendering portion of the reports (the views). Perhaps a feed specification would permit the appropriate filtering.

I'd be happy to chat with you more about this and collaborate on how we could move forward. Drop me a note if you're interested.

Tom

Owner's reply

Yep, your explanation covers it. The relation grids work great but I don't have the capability to display the results of the relational grid report in a field type drop down list, which would be critical for us because we may have multiple instances of this on a single form and would need to conserve screen real estate.