I have a parent table with contacts. This points to a child table in a portal with various skills the contacts have. Some contacts may not have any skills filled out, others may have one or several. Adding skills dynamically fills a value list of all entries in this field.

There is also a portal which shows all contacts and I want to be able to filter it by skill. So I have added a global field, formatted as a drop down menu listing all the skills. So far, so good.

Choosing a skill is supposed to filter the portal with all matching contacts, of course, but this does not work. I can kind of see why it doesn’t work, based on the way I set up the relationship, but I don’t know how to go about it.

Hope this is clear. I have attached a template to my question for you to try. Thanks for your help!

portal_filter.fmp12

The filtering expression is evaluated from the context of the parent TO (contacts in your file). Therefore your expression:

globals::gFilter = resources::skill

will be true whenever the current record's first related skill matches the global field - and it will be true for false equally for all records in the portal TO (contacts_list).

Edited August 9, 20196 yr by comment

Thanks for your suggestions. I'd rather not switch layouts if I don't need to, because in the real solution is are already a sizeable number of layouts. Adding another TO seems to be the easiest way, but I don't see how that fixes the problem and how it ties in with the selection of the global field. Would it be easier if the global field is part of the contacts table?

I don't want to add that calc field in contacts, because it's actually a separation model solution, however, I suppose I could script a field instead. If a field had several skills, would that work as long as they are separated by a return character?

At any rate, using an extra TO would be the best idea.

Thanks

Edited August 9, 20196 yr by stefangs

My previous reply had some inaccuracies - I have edited it.
 

6 minutes ago, stefangs said:

Adding another TO seems to be the easiest way, but I don't see how that fixes the problem

I am afraid I was mistaken on this point (I have overlooked the significance of the relationship using the x relational operator). The simple fix here would be add a calculation field to the contacts table - see the attached file.

portal_filterA.fmp12

 

6 minutes ago, stefangs said:

Would it be easier if the global field is part of the contacts table?

It would enable you to solve this using relationships instead of portal filtering - at the expense of making your graph more complex:

 

 

Yes, that last tip with the extra TO is great. Just adding a script trigger to the drop down menu and it's just what I was hoping for. Thank you very much!

If you're using the extra TO where the global field is a match field, then you should not need a script trigger.