I know I'm not going to answer this fully, but there are a few things which are going on here which can affect portal row visibility.
- If your cursor remains active inside the portal (even if changing rows), then your records may not have been committed to the server. One must exit the portal itself, not just exit any specific portal row, for a full commit of all records involved.
- Flushing cache to disk as part of a script might help with screen refresh scripting when completing a row and moving on to another row.
- Server/network latency can result in a portal record not appearing immediately during a refresh, varying with connection type. WAN connections are more prone to this issue.
You indicate in your title that this is affecting non-admin accounts. Are some of the clients using a different connection than the Admin users, and is it affecting all non-admin users or just some?
If all non-admin users have this problem and all admin users don't, regardless of conection type, then there may be issues with the permissions, though that seems unlikely in that they are editing the records via the portal. I think it is more likely a latency/refresh issue.
I agree with you that the permissions question seems very unlinkey given the behavior, but that is the only constant in the equasion. I can use my laptop connected via a 1GB ethernet cable to test the problem and it occurs every time I'm logged in at a user level but never happens when I log in as an administrator. Conversly, I can connect out on the floor using a wi-fi connection using a line PC and the problem happens the same way if logged in as a user, but never if logged in as an administrator.
I've never seen permissions affect portal displays before and I really don't know how else to trick the system into thinking the user has clicked out of the record. The fact that the first line does appear tells me the portal itself is working and the permissions allow data to display.
I haven't tried the flush cache to disk step for this. I'll give it a shot and see if it helps.
If any of this gives you any more ideas, let me know.
Frankly, most of that leaves me with fewer ideas, as it suggests the network isn't the issue, but the permission are the issue.
Let us know if the flush cache/refresh makes any difference.
If that doesn't solve it, maybe even if it does, check the permissions for any Record Level Access restrictions on the non-admin users. RLA is known to be one of the slowest things to resolve well in permissions, and that could be the issue (if there are any RLA restrictions).
I tried the Flush Cache to Disk step and the behavior is the same. I have looked at the Priviledge set and the Record access is set to Create and Edit in all tables...nothing custom. I do have custom priviledges for Layouts and Value lists, but just to keep them out of a couple of maintenance layouts. None of those layouts are involved here.
I know this one is harder to understand the more info I add...that's my frustraton too. The more things I try that fail the less sense it seems to make.
Any form of portal filtering or sorting on that layout's portal?
Or any sorting of the underlying relationship itself?
If so, try turning those off to see if it makes a difference.
Is the portal relationship based on any calculation field results?
Yes, the more ideas one tries without success, the weirder a problem seems -- until the answer is eventually found, then it's:
"Duh, of course!"
No to all of the above. The relationship is a simple value relationship ID=ID and here's no sorting happening. Sorry.
Time for a mental break, but I will keep thinking on it...
If you come up with an answer, be sure to let us know (so I can stop thinking ).
No worries. I'll keep you informed and keep working on it myself.
Thanks for the suggestions so far!
Back from lunch and had a few more ideas, but I warn you -- they don't have to do with permissions, so I have doubts about them being on target:
- Be sure the layout has had the Save Records without dialog option checked in the layout setup tabs.
- Check that any auto-enter values such as IDs in both the parent records and the portal-children records are set for auto-entry On-Creation. If these are not being entered until On-Commit, it may be causing some issues.
- Is this a file you can post here for examination with sample Admin and Standard Client accounts for testing?
- I suspect testing it on a different network (or locally) may yield different results. Have you tried it as a local file on your machine for testing? If not, give it a go. If you have, are the problems exactly the same, or different in some way?
Notice the ideas start to seem more random as we venture farther from what has worked in past experience...