I have a layout based on a table called EVENTS. I have another table called EVENT_CONTACTS that joins the EVENTS table with another table called CONTACTS.
On the layout based on the EVENTS table, I have a portal based on the EVENT_CONTACTS table. I have it set up so that when I click on the contact name field It pulls up a card goes to a layout to search for the contact I want to use based on the CONTACTS table. Then when the user chooses the contact the script will then go to another layout still using the card based on the EVENT_CONTACTS table and creates a new record sets the event fk and sets the contact fk the other fields do a lookup and the join record is created with all information needed for the join to be set. The script then finally commits the records, closes the card and then refreshes the portal on the original layout based on the EVENTS table.
This works flawlessly. I can go to any event click on the portal row and add a related contact.
Then as I was testing adding and deleting portal rows I noticed there was a situation where after going through adding a contact the portal would not refresh. I debugged the script and everything is in place to refresh properly. SO I started testing the differences of when it worked and when it didn't and I found that it only has the issue of not refreshing after I had deleted a portal record and then tried to add another one. For some reason, deleting a portal row and then adding another portal record with my script causes the issue with refreshing.
This is very odd and I am not sure if this is intended behavior or if this might be a bug.
Can anyone shed some light on to why after deleting a portal row would refreshing the join not work?
I will be happy to provide any additional information
Thanks,
OK, I see it now, and I think i understand the logic:
1. You are opening a new window and doing stuff there, then closing that window.
2. What you did in the card window (i.e. create a new related record) should be reflected in the relevant portal in the parent window.
3. When the card window closes the parent window is undimmed but otherwise untouched, and the change in the portal doesn't appear.
4. If you click somewhere on a blank part of the layout the portal refreshes and the change shows. This "click on a blank part of a layout" manual step as exactly what is achieved by either a scripted Commit step or Go to Field [ ] (i.e. with no field specified).
5. The reason this additional step is needed is that when you close the Card window you merely reveal the parent window IN AN UNCHANGED STATE, but nothing has been done at this point to ACTIVATE this window. Sometimes this is exactly what you require—you want the user to resume exactly where they left off—but in this case you have done something which needs to be reflected in the parent window as soon as you return to it, so the Commit step is required as this activates that layout and causes it to update.
A couple of other points:
1. The Commit step alone achieves your purpose; the two Refresh Portal steps are not needed.
2. I note that the two portals do not have scrolling switched on. Without this, there is no way to add more Contacts once the portal is full—4 or 6 records, depending which portal. This may be intentional, but if it isn't you need to allow scrolling, or use a different approach.
3. In some ways a different approach may be preferable anyhow, e.g. an "Add Contact" button in the title bar of each portal would in some ways look neater than the empty box in the portal itself. Since you are scripting the whole process of creating contact records you don't need these relationships to be set to allow creation, which means the portal will not have that empty box in it.