Given that a portal can only directly reference a single table, I suggest a tab control with one panel for each table to be searched with a portal to that table on each tab panel. That also allows you to put buttons specific to that particular table on the relevant tab panels as well. If you want, copies of the same search text field can be put on each tab panel which would allow you to enter or select criteria in the search field and then you can see matching results from each table just be clicking the tabs.
For those following along at home, this solution has several tables: Leads, Proposals, contacts, Accounts that could all be searched via this method and we are discussing an extension of the portal search tool demo'd in this file: https://www.dropbox.com/s/0pm1gdqcfi2ndpv/EnhancedValueSelection.fp7
What is the best way to go about adding the drop-down that allows the user to select between viewing "all records" or "my records"?
I'd, ideally, like to use "global" fields that can be used amongst the various tabs, without having to create a custom field or each tab.
I'm also wondering if there would be any big snags if I opted to configure the browser as a window.
Consider this Filter Expression:
YourTable::gMode = "all records" or
If ( YourTable::gMode = "my records" ; Get(AccountName ) = SearchPortal::AccountName )
This assumes that the portal's table has a field set to enter the creator's account name.
Other options are possible, but all require that your system somehow identify the current user.
That is an aspect of the application I have not addressed, but I intend to. I want to identify and track users to offer an 'audit journal' to management. Plus, this would enable me to configure functionality like you've just mentioned. Would you sugges that I address that now? If so, where would I begin?
Add a text field to each table where you need this. Use Field options to auto-enter the account name. Account names are what you create via Manage | Security so you may want to research that in Help or any training materials you have handy.
Note: there are other ways to control who is linked to a given record. This is just the simplest to implement--especially if you plan to set up accounts and passwords for your users to use anyway.
So I've created a text field called User_Account and for the calculation I have used Get ( AccountName ).
Or you could could select the Creation check box and select Account Name from the drop down.
Either way, this only enters data for new records. This field will be blank for any existing records so you may want to update the field for any existing records in your table.
Any existing records will be removed, anyhow, once the final application is completed. I did go and double-check though, via creating a new record, to verify that the user account was being written.
I have done this potal thing a few different times in this application, but it seems that this time around I am missing something- as records are not populating in the portal for me. For this, I am providing information regarding the portal on the Leads tab of the browser window...
BrowseLeads = Occurence of Leads table
BrowseLeadsRefresh = Occurence of Browse table
And how many records exist in your Browse table?
Do you recall that I suggested using a tab control with portals for searching each different table on a different tab? That was to avoid the need for a browse table that combines data from all your tables to be searched. I don't quite see a way to make the browse table work without doing three things:
- A related record in browse would need to be created for every record in leads, every record in proposals, every record in accounts, every record in Reps and every record in contacts.
- The Occurrence of Browse used for the search portal then needs links to occurrences of each of these tables.
- And your portal filter becomes a very complex "layer cake" of Or clauses where the same data in the search field is compared to different fields from each of the table occurrences added in 2.
I do recall...
What I have done is created a window based on a tab layout, with one tab for each module able to be browsed. I was trying to create a one-stop location where a browser could browse through records. This layout is a window, so they can keep it open and work on records.
I will forward you a recent copy of the file so that you are able to see how I was building the browser.
This doesn't change what I am suggesting. There will be quite a lot of "overhead" in getting a single search portal to work with all of your tables.
I know I am going to get grumbles, but I have made the switch to your suggestion.
Am I able to use the same search field that I am using on the "create/edit" tab (The original Leads layout)?
I've created an occurrence of Leads called LeadsBrowse and attached it to the base occurrence of Leads via Lead_ID. Only one of my fields in the portal is populating with data though.