Is ExecuteSQL allowed ?
When you click on a portal row ,you can get the related record's ID and with that info you can eSQL the hell out of the related table, put everything in $$vars and show them as merge fields on a popover you make appear.
Yeah, definitely. I'm not sure how I would do this though. How do I connect the row with the Contact_ID using ExecuteSQL (I've only used it thus far for counting numbers of records with specific criteria)?
Why not put a popover button in the portal row? You could put the related fields in the popover.
How do I get the related record ID on portal row click?
I know I could use a popover but I feel like it may make it messy looking in the way it is setup. I also want to give the user the ability to take that selected Contact's data and use it elsewhere and I figured I would need to pull the Contact ID anyways.
Let's say you have a portal showing n fields.
Select all fields except the leftmost one, bring to front.
Select the leftmost one, make it as big as the whole portal line. Associate a script to it, transforming it into a button.
If the portal is displaying data from Client_Transactions, when you click on that field you can set a global or a $var to Client_Transactions::PK.
Once you have that value in a g or in a $, you can do whatever you want. (Well, almost).
The popover button can be invisible and yet a click on the portal row can still open it using Go To Object. So data from the portal record can easily be included in a popover panel. Data from table related to the portal record can also be included so long as you don't use a portal.
A popover located inside a portal cannot also contain a portal.
But there are ways around even that issue.
On the contrary, a popover can make for a very clean, lean look. You make a simple portal with just basic details to show what the portal contains and a small button which can open a—much larger if necessary—view of further details of the portal row record.
Is there any way to position the popover window? As in, I can have it come out of the left, right, top, bottom of the popover button, but if I make the popover button cover the portal row for ease of clicking, I'd like it to pop up not directly attached to that row but in a universal center spot.
I have been working on scripting the info on a button in the portal row. I can pull the ID but am doing something funky in pulling up the record info in the last step. The popover is much simpler. I just want it in one place rather than jumping around depending on the portal row.
1 of 1 people found this helpful
It takes more design work, but you could move the popover out of the portal and use a script to:
a) Capture the primary key of the portal row
b) Either set up a link to that one record or use ExecuteSQL to Query the data
c) open the popover
So starting with this relationship:
LayoutTable::__pkLayoutTableID = PortalTable::_fkLayoutTableID
Add this relationship:
LayoutTable::_fkSelectedRecordID = PortalTable|Selected::__pkPortalTableID
Set Field [LayoutTable::_fkSelectedRecordID ; PortalTable::__pkPortalTableID ]
Go to Object ["Portal Popover" ]
And the fields in the popover would come from PortalTable|Selected
Edit Note: Cleared up a few details after initial post.
You set the relative position of the popover to its button in its set up dialog, but even so it will change depending on where the button is within the overall window. for example, if you set it to pop out the left hand side, but the button for some reason is too close to the top of the screen for it to fit there, it will pop out lower down; it will always display where it can best fit the available window and may thus vary from one computer to another. If you want to control its location you could investigate a standard button that opens a modal dialog window instead.
I think my safest route is to use a button on the portal row to pull the ID and then place global fields in the layout and set variables for each item I need and then set the global fields with those variables.
Unless, is there something obvious I am missing on scripting in to display a single record's info in the related layout? I pulled the record ID from the portal row, but then when I try to go to the related table and perform a find to lock in that one record and then return to the original layout, I get an error. I'm pretty sure I'm just over-complicating the heck out of this one.
No need to perform a find. Look at my last post. With that relationship, you can access any field from the portal's record that you need--to set up global fields with data or anything else that you need.