6 Replies Latest reply on Dec 1, 2016 2:12 PM by philmodjunk

    Hide Duplicate Records in a Portal


      I'm working on a scheduling solution for managing shifts of hourly employees. In the solution, a manager is working in the context of a global table to view a calendar of the current schedule, and adding records in the shifts table. I'm using timestamp fields to define a relationship for a portal that shows more detailed info about all of the shifts within the defined range.


      The problem is that I'd like to only show each worker once in that list, regardless of how many shifts they are working in the selected date range. I've tried multiple different methods of filtering the portal list, but

        • 1. Re: Hide Duplicate Records in a Portal

          I know of two, possibly three approaches that can do this.


          But I'd need a clear understanding of the tables and relationships involved to tell which of these might work for you and which might be simplest to implement. Please provide a more detailed description of the tables and relationships that you are using for this portal. Note that a "global table" can be interpreted in more than one way.

          • 2. Re: Hide Duplicate Records in a Portal

            By "Global Table", I mean that the table has only 1 record in it.

            Screen Shot 2016-12-01 at 9.45.00 AM.png

            Attached is a screenshot of my relationship graph. "CalendarInterface" is the global table, the other 2 TOs are based on the same base table containing my events. The portal is in the context of the "StudentWorkers_portal" TO


            The global table is related to the portal table with timestamp fields, as shown below.

            Screen Shot 2016-12-01 at 9.52.31 AM.png

            • 3. Re: Hide Duplicate Records in a Portal
              David Moyer


              I think your filter (shown above) should be DateStartGlob <= endStamp AND DateEndGlob >= startStamp.

              Addendum:  That's if you want anything that overlaps the period, as opposed to a date range entirely within the period.

              1 of 1 people found this helpful
              • 4. Re: Hide Duplicate Records in a Portal

                Best option is to have a table of workers where you have one record for each worker. If you have that table, you can do this:




                StudentWorkerShiftAssignments::_fkStudentWorkderID = StudentWorkers::__pkStudentWorkderID


                I've renamed StudentWorkers_po.... to be StudentWorkersShiftAssignements. It's my understanding that you can have a student listed there more than once. You can then put a portal to StudentWorkers to list each worker only once for the specified shift.


                If you don't have such a table, but do have a field that uniquely identifies each worker in the StudentWorkers_po.... table, you can also set up a self join such as:


                StudentWorkers_po...::WorkerID = StudentWorkers_po...|Sameworkder::WorkderID


                You can then set a portal filter on your current portal with this expression:


                StudentWorkers_po...::PrimaryKey = StudentWorkers_po...|SameWorker::StudentWorkers_po...PrimaryKey


                This will only be true for the first instance of a given worker in the portal and so any additional rows will be filtered out. Note that this Primarykey field has to auto-enter a serial number or Get ( UUID ) so that every record in the table has a unique value in that field.

                1 of 1 people found this helpful
                • 5. Re: Hide Duplicate Records in a Portal

                  I do have StudentWorkers table that contains just users, but it wasn't shown in the previous screenshot. When I base the portal on that table, each record displays as expected!


                  I didn't think about doing it that way because I already had another calculation that relied on my first method.

                  • 6. Re: Hide Duplicate Records in a Portal

                    Found and corrected a rather egregious error in my previous post. It is for the other option and thus does not affect what you have done to solve this, but maybe that bit of editing that I just did will clarify the second option for others...