11 Replies Latest reply on May 4, 2012 10:45 AM by Embee

    Two portal-related questions



      Two portal-related questions


      Hi fmp's

      There are two things I would like to do with a portal (which is dynamically filtered off of a couple of pop-up value list choices):

      1: Do some conditional formatting of a text field based on if whether or not the portal is displaying any records.

      2: Have some kind of field next to the portal, state the number of records currently being shown in the portal.

      I hope you can tell me if and how this can be done.

      - Embee

        • 1. Re: Two portal-related questions

          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. Re: Two portal-related questions

            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.

            • 3. Re: Two portal-related questions

              Hi Phil,

              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":

              id   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)

              • 4. Re: Two portal-related questions

                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.

                • 5. Re: Two portal-related questions

                  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?

                  Thanks again

                  • 6. Re: Two portal-related questions

                    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.

                    • 7. Re: Two portal-related questions

                      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?

                      • 8. Re: Two portal-related questions

                        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.

                        • 9. Re: Two portal-related questions

                          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.

                          - Embee

                          • 10. Re: Two portal-related questions

                            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.

                            • 11. Re: Two portal-related questions

                              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".

                              Duly noted.