The menu portal on the home layout shows the menu records via a multi-predicate relationship. In all cases, the top level menus continue to display. This is the correct behaviour as their IDs are listed in the foreign key field.
The opposite effect occurs if the user (me) clicks to "close" a menu. The arrow changes, as it should, but the sub-menus continue to display. I can verify that their IDs are removed from the foreign key field.
I can't say that I'm certain what you are doing with your menus from the discussion, but it sounds like you are trying to refresh items in a portal row.
Things may well have changed with the new release, but one thing has been an ongoing problem with portal refreshes -- the need to commit the parent record before the child record can be fully committed and flushed.
I would try capturing the portal row/field info to variables, committing the parent record after the changes, and then returning to the correct location to get the refreshed portal row content.
Thanks for the reply.
I tried that - no change.
Any luck with the Refresh Object script step (down in the Misc script step category), after a commit with flush cache?
Just tried that.
There is no flush cache available with that instance of commit. I know what you are talking about, though.
Curioser and curioser.
Too quick with the submit button:
1 of 1 people found this helpful
I just added the separate step to flush to disk.
Still no change to behaviour.
Thanks for your help.
Just added a new portal to the home layout showing the menu name field and the fk field then manually copied the IDs into the fk field in this portal. This worked. The menus showed up in the menu portal.
The sub menus (the correct ones for that top level menu) show up in the menu portal only _after_ the top level menu is "closed" and their IDs are _removed_ from the fk field by the script!! At this stage in the process, they are _not_ related.
There is something very strange going on here. To say the least.
I added a fresh instance of the menu portal to the home layout. The result is the same so it is not a problem with the original portal.
Message was edited by: StanMillar
If I pause the script for .55 (yes .55) seconds after flushing the cache and before returning to9 the home layout, it works as expected. Any delay less than .55 seconds does not work.
If I open the developer layout in a separate, hidden, window, all the problems go away without any pauses in the script.
How this differs in refreshing the window from using the script step, I don't know, but at least it works.