WithOUT having the file in front of me, I'm still 99% certain that if you look at the relationship between the Meeting TO and the TO used in the portal, you will see that the relationship is defined as linking the key fields with the "X" (Cartesian) operator.
What that operator does is link ALL records to ALL records in both tables, instead of matching based on whether the key fields are identical (using the "=").
You might also look into the conditional operators available in case you ever want to show related records based on ranges instead of only exact matches.
-- Drew Tenenholz
Yes but the portal is based on the meeting_PERSON__picker TO. The field that lists all of the people in the portal is called ::NameFirstLast (selected from the meeting_PERSON__picker TO)
The relationship between MEETING and meeting_PERSON__picker is set to to MEETING:: _kz_personPicker = PERSON::__kp_Person (If this relationshop used X I wouldn't be confused anymore. This is the relationship the portal is based off of too.)
_kz_personPicker field is a calulation field that stores a list of person IDs, auto-entered from the meeting_PERSON__picker relationship/
The relationships with X's seem irrelavant to how this portal is being displayed. The portal isn't based off of those relationships.
Then again one of the TO's is called meeting_RESOURCE which relates: MEETING:__kp_Meeting X meeting_RESOURCE:_kz_Constant
Could this be it? The value of the _kz_Constant Calculation is set to 1.
I guess if I just disregard all of the confusion in the FTS_Meetings file and just make a CATEGORY TO called AllCategories and use the X operator to relate it to __kp_PersonID. Then make a portal based on AllCategories. This would get me my list correct?
1 of 1 people found this helpful
The field "_kz__personPicker" on the left side of the relationship is defined in the Define Database Field definition uses the List function to get a return separated list of all the people filtered by the group. So the data in that field is each ID from the people table separated by a return character, so with each record in the people table that has it’s ID in the list is pulled into the portal as a match. This is a compound key, i.e. it holds more than one value.
Additionally, you can use the same idea to filter the list down(not showing previously selected people in the portal) by adding one more field to the meetings table defined with the List function to collect up the selected people ID's from the portal and adding an additional condition to the relationship. Making the relationship show records that are in the personpicker list and not in the selected list.
Hope this Helps
Message was edited by: timwhisenant
1 of 1 people found this helpful
I took a look at the file, and indeed, something more sophisticated is going on.
This arrangement (and a couple of details I didn't mention) allows two things to happen:
1) The key field on the left (_kz_personPicker) starts off with the list of all IDs for all people. (Look at the ResotreGlobals script where the field is first cleared, then the person filter is set to empty, causing the auto-enter to fire and grab the IDs of all current people.) Thus, the portal initially shows all people in the file.
2) If you select a 'group' in the picker window, the relationship for meeting_PERSON__pickerByGroup is changed, and the field automatically replaces itself with only the IDs for people that match that group. The portal then updates to show a limited list.
If you click on the 'show all' [people for all groups, then another little script runs, that clears out the group name, the unstored calc gets reset to 'ALL', the relationship is altered, the auto-enter field updates itself again to have the IDs for all records.
In general, the only problem that happens when using this sort of process occurs when the list of IDs gets VERY long. So, if you think you will have 5,000 categories, then this might not work for you. Up to a couple hundred should be fine. You'll need to figure out how to either include or remove the idea of creating 'groups' to whittle down the portal, (groups of categories?), and duplicate the startup process that sets the left side key field contents to the IDs for all the related records.
-- Drew Tenenholz
Wow thanks a lot for the great responses guys. Now that I actually understand how FTS_Meetings works I realized this is way more complex then what I actually need to do, but still somewhat similar.
Here is my situation maybe you will be able to send me in the right direction:
I have two tables. Vendor and SaleService. From the Vendor Detail View I want all of the services that a vendor is associated with to be listed in a portal (kind of how meeting participants are listed). Next to this list I would like an Add Service button that opens up a new window using a SaleServicePicker Layout. This Layout will consist of a portal that lists 10-15 SaleServices I will turn off data entry in browsemode so the services can be clicked on (selected). I will use conditional formating on an empty text field that will sit behind the portal field to show which services have been selected/deselected kind of how it is done in the PersonPicker layout within FTS_Meetings (it will also have a Select_SaleService script attached to it. I won't be needing Service Groups or Service Filters or any of that extra stuff. Just simply selecting services with a Cancel and Add button at the bottom of the list. I am also assuming I will need a join table called VendorSaleService to make this possible when hitting Add right? And also to list each Vendor's Sales Services on their detail view. I will make a script so when Add is hit, the _kf_SaleServiceID and the _kf_VendorID fields for the VendorSaleService table are set for each Selected value.
Under the list I am going to need 1 text field called ServiceName with an Add Button to add a new Service to the list (Similar to Add New Person with First and Last name global fields under the Person list) I am not going to worry about this until afterwords though.
Several years ago I saw Scott Love's presentation of popup pickers file and article @ http://www.soliantconsulting.com/blog/2009/02/picture-perfect-filemaker-pro-pop-up-pickers/
I have modified and extended his original idea into what my system uses today. Just to give you an idea. Here are some of my modifications...
1. I have lists of over 1,000 customers, vendors, etc so an A - Z row of buttons filters the list to only show companies whose names start with the letter pressed.
2. In the list of customers I added a credit status field to show those on credit hold. active, credit card only terms, etc and using conditional formatting to change the color based on the status field, so anyone looking up a customer can tell quickly if the customer's account has requirements.
3. In the vendor selector popup, I have product categories setup like the A-Z buttons to quickly find all vendors who provide the product category and sort the list to show the vendors in order based on the # of invoices we have received from them over the years. So our most common go-to vendors sort to the top of their category.
The implementation of this is very straight forward, just follow the instructions. After you become familiar with how this works, modifications/additions come fairly easy.
Since this model uses a filemaker layout in a new window your add new button can go in a footer section and it's script can perform your add routine.