Can you describe how your portal currently works?
It sounds like using a filtered relationship instead of a filtered portal would make what you want much easier to accomplish. Many portal filter expressions can be duplicated at the relationship level but not all.
2, however could be pretty easy to set up with a summary field from the portal's table in a one row portal with the same portal filter as your existing portal.
Right now the portal has one portal-filter, which I would actually love your help to get rid of, since that would help some other stuff as well:
The UI-layout has the portal, which sees all "item"-records through the rel (UI::id) x (items::id). The "items" table has a "items::status" calculation field that calculates upon "items::startdate" and "items::enddate" and returns 1 if the item is currently active and 2 if its not.
The UI-layout table has a _g_chosenstatus, that is a pop-up of a value list based on a "statuses" table, which stores the first field "id", but only shows the second field "status":
1 show active items only
2 show inactive items only
3 show all items
So as you can probably guess, the only reason that I need the portal level filter is to say (items;status) = (UI;_g_chosenstatus) OR (UI;_g_chosenstatus) = 3, since there is no way to say OR at the rel level as far as I know?
But I would really like to get rid of the portal-level filter, and have the value for the 3rd record in "statuses" somehow be equal to both "1" and "2". Is there any way to do this? Or is there a better way to do the "show all", than what I've got set up?
Again, thanks for your time
(i've renamed stuff for simplicity, but I hope it makes sense)
To get OR at at the relationship level, you can use either a return separated list of values or a repeating field with one value in each repetition as the match field.
Define this calculation field for cStatusList:
List ( UI::_g_Chosenstatus ; 3 )
Set up a relationship:
UI::cStatusList = Items::id
Now no portal filter is required.
I assume that you meant the relationship to be (UI::cStatusList = Items::Status), right? But then when "show all items"/3 is selected, the portal will show no records, because the field "Items::Status" never contains "3". Or am I missing something?
Shouldn't I, instead of adding the cStatusList to UI table, add it to the Items table?:
List ( Items::Status ; 3)
and then have the relationship be
UI::_g_ChosenStatus = Items::cStatusList
I'm guessing that that's what you were saying, but that the global UI::_g_ChosenStatus and the calculated Items::Status got mixed up?
Is that right? To use the List field as the match field for the Items table?
You are correct. I misinterpreted your post to be that you wanted the portal to show records that matched the selected status OR 3. What you want is the revers so the list calculation to combine status and "all" goes on the other side of the relationship.
Thank you PhilobiWan. This opens up yet another new learning-chapter for me.
Regarding Q#1, I have managed to do this based on an existing global UI field which is empty if the portal is "empty" (existing script triggers). Is that the way do do it, or is there a way to say "if the relationship has no records"?
Regarding Q#2, I've now done it with an unstored calc in UI, which counts through the same relationship as the portal itself. I couldn't figure out how to do it with a summary field in the Items table, since there is actually one more rel level filter in the portal relationship (and I'm not experienced in summary fields yet):
UI::_g_ChosenGroup = Items::_fk_Group AND UI::_g_ChosenStatus = Items::cStatusList
Can it be done better with a summary field?
IsEmpty ( relatedTable::primaryKeyfield )
Is a good test to see if there are any related records. It doesn't have to the primary key field, but it does need to be a field, like a primary key, that is never empty in the related table.
I don't see the purpose for a summary field. The relationship you've posted that matches on both chosen group and status would appear to produce the results you need here.
Ah, of course. I like IsEmpty, but hadn't thought of using it like that. Perfect since it lets me look directly at the portal without any "middleman". And I'll keep the unstored calc then.
A pleasure learning from you, as always.
It doesn't refer to the portal at all. It refers directly to the related table. If you completely removed the portal, it would still return the same results.
Of course of course. That's just my newb-terminology trying to say that "it lets me look directly at the same relationship that the portal is looking at".