You've only posted what restrictions you've specified for a single table. You haven't indicated what you set up for the portal's table nor how it is related to the layout's table.
And why would you expect to see any records in the portal on a record from the parent table that the user is clearly not permitted to view? That seems a very strange design here if that's what you are expecting.
(one step at a time as it were)
Because the main record is not showing, I am not concerned with the portal at this time. But, FWIW, the relationship for the portal (restriction wise) is identical to that of the main record.
Because FM is not showing me the main record, of course it will not show me the portal records (though there are none to be seen at the point).
The general question still remains: If I want to restrict each user to seeing only their own records, is this a rational way to accomplish this (because so far it doesn't appear to work).
I have accomplished something similar in the past by creating individual Privilege sets (one for each user). I want to make the privilege set generic, which would allow me to create new users automatically.
Yet I see no evidence in what you have posted thus far that indicates that it doesn't work. Your screen shots appear to show a correct set up and that it is functioning correctly.
How exactly is this failing from you?
Do you have a screen shot where the layout does not show "no access" but which fails to show portal records that should be permitted?
The user shown viewing their own record. They should see the information currently represented by <No Access>
After assigning a value to the global field, make sure that a Commit Records is done. I've seen cases in my own testing where changing a value used in the "lock expression" doesn't change the user's access to allow or deny it until the change is committed back to the file.
Tried the commit. No change with WebDirect.
Interestingly, I tried this using a FM Pro client and it does work as advertised...
So is there something (a bug or limitation) in WebDirect that prevents me from doing this?
If it works in Pro and not WebDirect, that suggests that you should use Report an Issue to report this as a possible bug. But by all means, check every little detail first. Comparing the values of two text fields like you do here will only produce a "True" result if every single character is the same in both fields. The addition of even a return or space will keep this from happening even though the fields will look like they should match when you inspect them. Not saying that this is what's happening here, but this is something to confirm first just to be sure before making a bug report and waiting to see what the FileMaker Techs have to say about this.