stefangs Posted August 9, 2019 Posted August 9, 2019 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
comment Posted August 9, 2019 Posted August 9, 2019 (edited) 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, 2019 by comment
stefangs Posted August 9, 2019 Author Posted August 9, 2019 (edited) 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, 2019 by stefangs
comment Posted August 9, 2019 Posted August 9, 2019 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: 1
stefangs Posted August 9, 2019 Author Posted August 9, 2019 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!
comment Posted August 9, 2019 Posted August 9, 2019 If you're using the extra TO where the global field is a match field, then you should not need a script trigger.
Recommended Posts
This topic is 1988 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now