1 Reply Latest reply on May 31, 2016 8:03 AM by erolst

    Portal filtering assist needed.




      This is really hard to explain what i need help with.. think i rewrote it like 10 times... :/

      so please try to understand =D


      Am having 2 portals. both capturing from a log table.

      The first captures all logins.

      The second is to show what have been changed during inlogged period.


      what i have so far:

      portal 1 works fine. i have the starting date from that and ID. ID works fine.. Portal 2 is showing all items each ID have made. like it should.


      Now i need to show the logs only after loged in date, and before the next login.. only way i can  get the "before next login" is to use the next portal field in the portal.. but it needs to know the correct ID.


      example formel (own made to be able to explain):

      go to previus portal record, if ( previus ID = ID) set "End date" else to to next.   <--- but i dont know how to do that in the portal filtering =( if its even possible.


      This is the fields:





        • 1. Re: Portal filtering assist needed.

          Your table (or TO) names are quite confusing.


          It seems what you have here is an Audit Log and you only want to see changes recorded during the current login of the user.


          So if you have a Login table, you can relate that by ID; then use a relationship to the Audit table by ID, and filter a portal with


          AuditTable::dateChanged > GetAsDate ( Max ( Login_byID::timeStampLogin ) ), or, if you just have a login date,

          AuditTable::dateChanged > Max ( Login_byID::dateLogin )


          (in short: make sure you compare the same data types)


          or – less flexible, but with better performance for a large number of records – create a calculation field with that expression in the User table and use it as second predicate in a relationship.


          If you just want to see the changes during a specific session, than IMO the cleanest way would be to add a foreign key field to the Audit table where you auto-enter the primary key of the current Login record.


          Then you could create a field in the User table to hold a login ID (that you can set via clicking a portal row) and use that as relationship predicate (where now the userID wouldn't necessary).