Jump to content
Claris Engage 2025 - March 25-26 Austin Texas ×

Filter child records in portal


This topic is 5393 days old. Please don't post here. Open a new topic instead.

Recommended Posts

Posted

Hi. I have a document storage solution that shows in a portal all documents pertaining to a customer. Some are letters in, some letters out some product images etc. The solution works fine. In one layout, I want to limit the records in the portal to a particular document type. Doing a search (either scripted or manually) on the document type field (within the portal) and the customer ID (outside the portal) fails to show just the desired documents within the portal.

How can I achieve this goal?

Thanks

SB :

Posted

A portal can be filtered by adding a global field to the relationship, in your case your document type field. I am assuming that your document type field is a text field with a value list of such choices as "Excel, Word, PDF..". (You may wish to create a table for document types, create a value list from that table and actually store document type IDs with your document. Because, if you change from Excel to .xlw, your finds/filters will not be accurate).

Back to filtering. In your parent table, Customers, create a global field. Add this field to the relationship from the parent TO to the portal TO. If you want the user to be able to choose different document types and see the portal change, then put the global above the portal and give it the document type value list (you can set the field to a popup or checkboxes).

If you only want a certain type of document displayed in the portal, use a global calc field set to that document type, for example, global calc = "Word", and do not add it to your layout.

Posted

Thanks for that. I must be missing a step. I created the global text field "document type" in the (parent) customer file and linked it to a new TO of the document file. In the layout the global field is sitting above the portal and is a drop down box showing the value fields (of document types). Unfortunately selecting one of these makes no difference to the documents visible in the portal - all of which remain on view. Where am I going wrong? Many thanks

SB

Posted

You need to add the global to the relationship that you are using for the portal, not a new TO.

Posted

Thanks for that - works a treat. And so straightforward! Your assistance appreciated.

I thought also to have a portal where no filtering occurred. I made a new layout. I created a new TO of my documents table and linked it to the original customers TO just by customer id (ie excluding document type). I used this new TO for the new layout portal. Unfortunately it shows the right number of lines of documents but each line is a repetition of the document on display in the filtered portal. Wierd. Do I have to have a separate TO of the Customers table? Thanks again. SB

Posted

Sounds correct, one relationship from Customers to Documents just by Customer ID, shows all Docs. The other for the filtered portal which includes the Customer::gDocumentType filter. Hmm. They should both be able to come off of the same Customer TO anchor.

In your new layout, the one that has customers to all documents, is the layout based on the Customer TO anchor? Are the fields in the document portal from the correct Customer-Document relationship (perhaps you copied the filtered portal and forgot to change the fields--remember they use a non-filtered relationship).

Posted

Thanks Barbara - can't see that I've made those mistakes. In the all documents layout I had the portal based on a new TO of documents linked to the original TO of customers.

Even tried a new TO of customers linked to original customers via PK and to new TO of documents - still can't get a separate layout showing all documents with another showing filtered. No go.

Will have to ponder this some more.

SB

  • 2 years later...
  • Newbies
Posted

Hi there,

I am having the same dilemma. What do you mean by,

You need to add the global to the relationship that you are using for the portal, not a new TO.

But just above you state that the global needs to be related from the parent TO to the portal TO.

Could you please elaborate further?

Posted

Basic (unfiltered) relationship:

Parent::ParentID = Child::ParentID

Filtered relationship:

Parent::ParentID = Child::ParentID

AND

Parent::gCategory = Child::Category

See an example (with a twist) here:

http://fmforums.com/forum/showtopic.php?tid/201079/post/317020/#317020

  • 1 month later...
  • Newbies
Posted

Hello, I saw your lovely example file, which works great. but i have a similar, yet different job to do: I have a company client information database. It has Three tables i'm trying to relation properly:

ClientGenInfo (parent)

ClientLocations(Child)

Staff(Child of Child)

Here's what i'd like to do:

Have the main layout based off ClientGenInfo, where I list their website and other company notes. On this layout, I have two portals. One that displays the various locations that the company has, example: Germany, France, Italy. The other portal to display all the people associated with the company(parent) at all locations. Then filterable to display people from just one of the locations by clicking the locations portal.

The locations portal could be replaced by a drop down field, i guess, but i'm still stuck, because of the locations table in the middle of this relationship. How can i get this to show logically?

  • Newbies
Posted (edited)

WOW, that exactly did the trick. thanks so much.

Hmmm, I spoke too soon. Is there a way to work in the "show all" function like the other example? (show all per parent of course)

Edited by Guest

This topic is 5393 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 account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.